失敗をしてしまったときや、何かしらの問題が生じてしまったとき、同じ失敗を繰り返さないように解決策（再発防止策）を考えることが大事です。
有効な解決策を考えられるかどうかは、問題解決力が大きく関係します。
この記事では、問題解決力、及び問題発見力に関して個人的な考えをまとめます。
問題解決における解決策の分類
効果の高い問題解決を行うには、解決策をカテゴリ分けして様々な角度から考えることが大事であると考えます。
ここでは、問題解決策を以下の3つに分類します。
- 気合系
- 仕組み系
- そもそも系
私の場合、それぞれのカテゴリ毎に解決策を考えることで有効な解決策が思いつきやすくなります。ただし、問題の内容によってはどの分類にも属さない解決策もあり、逆に複数の分類に属する解決策もあります。あくまでも解決策を検討するうえで目安だと考えてください。
気合系
意識、責任感、心がけなど、目には見えない人のメンタルに頼った解決方法を、私は気合系の解決策と呼んでいます。具体例としては「意識する」「注意する」「確認する」などが気合系の主な解決策になります。
仕組み系
人の意識に頼らず、仕組みによって問題の発生を防ぐ解決策を仕組み系と呼んでいます。仕組み系での具体的な解決策の例は「ツールを導入する」「ツールを作る」「チームや組織の体制を変える」などがあります。
そもそも系
失敗が発生する要因となる前提条件を見直す解決策をそもそも系と呼んでいます。具体的には、「問題が発生する原因となる行動や取り組み自体をやめる」「環境そのものを変えてしまう」「目的や目標を見直す」などがあります。
ここからは、具体的な失敗や問題に対して、分類ごとの解決策の例を考えていきます。
ケース1：自動車事故（個人）
自分が運転していた車で事故を起こしてしまったケースを考えます。
気合系
事故が起きないように気を付けることが、気合系の主な解決策になります。
- 運転中は運転に集中し、事故を起こさないように気を付ける
- スピードを出しすぎないように心掛ける
- 車間距離をできるだけ空けるように心掛ける
仕組み系
自動車そのものの機能によって、事故を起こりにくくすることが仕組み系の解決策になります。
- 安全性能の高い車に買い替える
- 自動運転車に買い替える
そもそも系
自動車の事故は、自動車を運転しなければ自分で事故を起こすことはなくなるので、自分で運転する機会をなくすことがそもそも系の解決策になるでしょう。
- 自動車を手放して他の移動手段を使う
- 自分以外の人に運転してもらう
完全自動運転車に乗れば自分の運転で事故を起こす確率はグッと減りますが、日本だとまだまだ自動運転の普及が遅れているので悩ましい問題ですね。
また、どれか１つの解決策に限定するのではなく、「車に乗る頻度を下げたうえで、安全性の高い車を買い、運転に気を付ける」と言った複合的な解決策も考えられます。
ケース2：寝坊や遅刻（個人）
気合系
- 寝坊しないように早めに寝る
- 頑張って早起きする
- 時間に余裕を持って行動する
仕組み系
- 快眠グッズを買う
- アラームを複数セットする
- 指定時間になったら電気が消える、など、物理的に寝る以外できなくなる環境をつくる
そもそも系
- 職場の近くに引っ越す
- リモートワークを導入する
- フルリモート、フレックスタイムを導入している職場に転職する
遅刻や寝坊に対するそもそもの解決策、遅刻や寝坊といった概念をなくしてしまう事でしょう。
そのためには、通勤や業務開始時間という概念をなくすのが良いでしょう。
ケース3：メールの宛先間違いや添付忘れ（個人）
仕事でメールを使う機会が多い人は、メールでミスをした経験がある人も多いかと思います。よくあるミスとしては、宛先を間違って送ってしまったり、添付ファイルを送るはずが、ファイルの添付を忘れたまま送ってしまう、というケースです。
気合系
- 送信前にメール内容をチェックをする
- 自分をCCやBCCに入れて、受信したメール内容をチェックする
自分をCCやBCCに入れてチェックを強化する、という方法は、習慣化してしまえば仕組みと捉えることもできますが、受信したメールをチェックするかどうかは本人の意識によるところが多く、追加し忘れないかどうかも本人の意識に依存するので、私はこの方法を気合系に分類しています。
仕組み系
- チェック機能があるメーラー使用する
- アドオン・プラグインなどを追加してチェックを強化する
- メーラーをカスタマイズしてチェック機能を追加する
例えば、Gメールだとメールの本文に「添付」という言葉があり、かつファイルが添付されていない場合は送信前に警告を出してくれたりします。
Gメールの場合はChrome上で動作できるので、Chromeの拡張機能を探したり、拡張機能を自作することでチェックを強化することもできるでしょう。
Outlookを使っている場合も拡張機能を追加できる仕組みなどがあります。
そもそも系
- メールでのやり取りをやめる（チャットツールを使う、直接話す、など）
- ファイル添付をやめる（URLで共有できるサービスを使ってURLを共有する）
メールでのミスが多いのであれば、そもそもメールをやめる。
また、ファイルの添付ミスが多いのであれば、そもそもファイル添付をやめることが根本の解決策になるでしょう。
ケース4：アプリケーション改修作業におけるバグ（チーム）
ケース1～3は、個人レベルでの問題でしたが、開発に関してはチーム単位の問題になります。
気合系
- 開発着手前に影響調査を頑張る
- コードレビューを頑張る
- テストケースのレビューを頑張る
- テストを頑張る
- 色んな人にテストしてもらう
仕組み系
- テストを自動化する
- CI/CDでビルド時にテストを自動実行する仕組みを入れる
- ペアプロ・モブプロを導入して、常にレビュー状態で開発する
そもそも系
- バグを許容する
- リスクのある機能改修をしない
- リファクタリングして改修作業がしやすい状態を作る
開発に関してはの問題解決は分類がなかなか難しいですが、ソフトウェアの世界での問題はソフトウェアを用いて仕組み化して解決することが望ましいと思います。
あるいは、開発の進め方自体を変える、組織体制を変える、といった方法も考えられるでしょう。
チェックリストやルール追加は仕組みなのか
失敗や問題に対するよくある解決方法として、「チェックリストの追加」や「ルールの追加」があります。チェックリストによって確認を強化したり、ルールを守ることを徹底することで再発を防止するというもの。このような解決策は、３つの分類のうちどれに分類されるでしょうか？
チェックリストやルールを守られることが100%保証されているのであれば、それは仕組み系の解決策と言ってもよいでしょう。しかし、チェックリストに沿って確認するかどうかや、ルールを守るかどうかはその人の意識・モチベーションなどの影響を受けやすいものだと思います。
その場合、仕組みと呼べるほどの解決策にはなり得ません。
私は、チェックリストやルールの追加はどちらかというと気合系の解決策であると考えています。
ルールを守らなければペナルティを与える、ルールを守れば報酬を与える、といった工夫によってルールを守る確率を上げることは可能かもしれません。
それでも、最終的に実施する人の意識によって左右されるのであれば、結局のところ気合系であると思います。
気合系に逃げない
ここでは問題解決を３つの分類に分けましたが、どの分類の解決策が最も有効なのかはケースバイケースで、明確な正解はないでしょう。問題の内容にもよるし、その時の状況や実践する人の性格や立場によっても最適な解決策は変わるかと思います。ただ、解決策を考えるうえで、最初から気合系の解決策に頼るのはあまり良くないと思っています。
「そもそも社会人としての意識が低い」のような仕事へのスタンスに問題がある人への対処の場合は、意識が変わるように指導・教育が必要で、気合系の解決策も必要かもしれません。
ただ、問題の再発防止や改善活動という点においては、気合系の解決策で根本的に問題が解決することは稀であると個人的には思います。
特にエンジニア、エンジニアからなるチーム・組織の場合はまず技術やツールを活用した仕組みによる解決方法を考えることが重要であると思います。
エンジニアの仕事は技術を活用して顧客の問題や課題を解決することです。自分の身の回りの問題を技術で解決できない人が、他人の問題や課題を技術で解決しようとするのは、とてもおこがましいのでは？と私は思います。
自分自身の身の回りの問題に気づき、それを仕組み化してツール・技術による解決を繰り返していくことで、エンジニアとしての技術力や顧客への提案力が身についていくのではないかと思います。
もちろん、様々な解決策を検討した結果、気合系の解決策に落ち着く場合もあることでしょう。ツールを導入することがベストだったとしても、問題の大きさに対して導入コストが高すぎる場合は導入を見送った方が良いでしょう。自分たちでツールを作った、環境を構築する場合も、開発の労力がかかりすぎる場合はあきらめて他のサービスを探すか、気合系の解決策に頼っても良いかもしれません。
もちろん、気合系の解決策が有効な場合も多いので、気合系の解決策を否定するつもりはありません。ただ、ツールや技術による解決策を検討せずに、最初から気合系の解決策を検討するのはエンジニアにとっては逃げであると、個人的には思います。
性弱説で考える
性善説か性悪説か、でいうと、私の場合どちらかと言えば性善説の立場です。
ただ、善だからと言って決められたルールを全て守れるのかというと、そんなことはないと思います。
人間は日によってやる気がなかったり、心に余裕がなくなっていることもあります。また、人間の記憶力はあいまいなので、守るべきルールをすべてを記憶しておいて状況に合わせてルールを守るように行動するのはかなり高度であると思います。
メンタルが強く、どんな状況でも仕事に集中できる人であれば、気合系の解決策で多くの問題を解決できるかもしれません。
しかし、世の中そんなに強い人ばかりではないと私は思います。
私自身、自分のことはポンコツだと認識しており、気合系の解決策だけでは同じ失敗を何度も繰り返してしまう人間です。
ポンコツな私が同じミスを失敗しないようにするには、ツールを導入したり、技術で解決を図ることが必要でした。
人の善悪や強さに依存しない問題解決をするには、仕組み系の解決策を考えることが重要であると思います。
問題が発生する前に解決する
問題が起きた時に再発防止を考えるのは大事ですが、問題が発生する前から、放置していれば問題になりそうだと認識していることがあれば、できるだけ早い段階で解決策を検討した方が良いでしょう。
実際に問題が起きていなくとも、効率の悪い作業の進め方をしている、とか、毎回注意して作業しないといずれトラブルが発生の可能性が高い、といった作業がある場合、それは改善すべき課題だと捉えられます。
作業が効率よく進められるための仕組みを作ったり、ミスが発生しにくくなる仕組みを事前に検討しておくのが良いかと思います。
いくつか具体例を載せます。
日程調整の難しさ
私が講師をしていた時に地味に大変だなと思ったのが、企業担当者との３者面談の日程調整です。
各担当者にメールで希望日を聞いて日程を調整するのですが、各担当者の方がお互いの希望日を把握していないためかなりの頻度で希望日が被ります。
それをメールでやり取りしながら１つ１つ解消していくのですが、講師の作業時間を削られる上に、気を付けて調整しないと日程が被ってダブルブッキングになってしまう可能性もありました。
幸い、面談に関してこれまでトラブルなく進めてこれましたが、効率が悪く、トラブルが起きる可能性の高い課題だと感じていました。
今は日程調整用のツールやサービスも世に出回っているので、今後似たような作業が必要になった場合はメールによる気合系の作業をやめて、サービスを導入して解決することを心に決めました。
同時編集の難しさ
開発の仕事でも研修の仕事でも、同じ資料を複数人で編集したい場合が多々あります。
そのような資料をExcel、テキストファイルのような、ファイル単位で管理している場合、誰が最新版を持っているのかが分からなくなることがあります。また、同じタイミングで複数人が編集を行ってしまった場合、誰かがそれぞれの編集内容を手動で反映させる必要があり、手間がかかります。最悪の場合、編集していたはずの情報が他の誰かの編集内容によって上書きされる、といったケースも考えられます。
また、ミーティングしながら同時に同じ資料を編集したい、と言った場合にファイルで情報を管理しているとかなり効率が悪くなります。
ドキュメントを整理したい場合はNotionのようなツール、図を描きたい場合はFigJamやMiroのようなホワイトボードツール、表形式でのデータの場合はGoogleスプレッドシートなど、今の時代、目的に応じて同時編集可能なツールは多数あるので、それらのツールを導入することで同時編集の課題が解決できます。
課題を見つけるための振り返り
簡単に認識できる問題や課題を解決することも大切ですが、個人やチームが成長していくためには、潜在的な課題を見つける力も大事です。
課題を見つけるには、時間を取って振り返りを行うのが良いかと思います。
特に、チームで仕事をしている場合は課題感についての認識が人によってバラバラであることが多いです。
自分自身が課題に感じていることでも、他のチームメンバーは何とも思っていなかったり、逆に自分自身が課題に感じていないことでも他のメンバーは課題だと感じている場合もあります。
開発チーム・開発組織の場合、生産性を上げることが目標になる場合が多いかと思います。その場合は、生産性向上を少しでも阻むものは課題になります。
チームメンバー同士でそのような課題の認識を合わせ、一つずつ改善する活動を繰り返していくことで、問題解決力、及び発見力を高めることができると思います。
チームでの振り返り
振り返りをする際は、進捗の確認やタスクの整理になってしまわないように注意する必要があります。あくまでも、生産性を低下させる原因となっている事象や、感情面でのモヤモヤなどの課題共有にフォーカスします。
振り返りをする際は本音を話せる心理的安全性が担保されていることが大事です。
例えば、とあるメンバーが「業務に対してモチベーションが低い」という課題を抱えていたとします。モチベーションが低いと開発の生産性にも影響があるため、この課題はチームとしての課題にもなり得ます。
しかし、仮に振り返りに直属の上司が参加している場合、上司からの評価を気にして本音での意見を言えなかった場合、振り返りの意味がありません。
また、モチベーションが低いことを伝えたとしても、「意識が低い」「仕事だから割り切ってやれ」など、気合系の解決策だけで片付けられるのも意味がありません。
例えば、モチベーションが低い、という課題を深掘りした結果、「同じような業務の繰り返しで飽きてしまった」という原因にたどり着いたとします。
その場合、例えば以下のような対策が考えられます。
- ペアプロ（ペア・プログラミング）やモブプロなどを導入し業務中に刺激が得られるようにする
- 新規で開発する部分に新しい技術を導入する
- 一定期間他のチームへ移籍する
チームメンバー同士の課題の認識を合わせ、仕組み系やそもそも系の解決策を考えて取り組んでいくことで、チームとしての生産性や問題解決力、発見力が上がっていくと思います。
まとめ
振り返りとそもそも系の問題解決に関してはできればもう少し深掘りしたい。
機会があれば別記事でまとめたい。
あと、後半から「問題」と「課題」の使い分けがよく分からなくなってしまった。。
日本語難しい。。。