プロジェクトには、常に問題が発生します。進捗の遅れ、重大なエラーの発生、いろいろです。
問題を解決したい。でも一向に解決しない…
それはもしかしたら、「問題」「原因」「課題」を正しく定義できていないからなのかも。正しい定義の仕方を身につけましょう。
間違いだらけの問題定義
こんな定義の仕方をしていませんか?
あるプロジェクト、メンバーAさんの進捗が遅れています。
問題、原因、課題を考えます。こんな定義の仕方をしていませんか?
Aさんの進捗が遅れている…
- 問題 Aさんの作業効率が悪い
- 原因 Aさんは経験不足のため他の人より作業が遅い
- 課題 Aさんが残業して残作業をこなす。。。
ちょっと対策ひどくないですか…?
解決する気がしませんね。どこで間違えているのでしょう?
問題、原因、課題を正しく定義する考え方
問題、原因、課題の定義を間違うと、間違った対策になってしまいます。
意識すべきは以下。
- 問題=目標と現実の差
- 原因=問題を生じさせる客観的な事実
- 課題=解決に向けた測定可能な行動
どのように考えればよいのか、みていきましょう
問題:「目標」と現状の差
問題の定義を間違うと、その後もすべて間違えます。
大事なことは、そもそも目標が定義されているか?
あいまいな問題になっていないか
例えば、このようなことを、問題にあげていませんか?
- 仕様が決まらない
- 作業効率が悪い
- コミュニケーションがとれていない
この問題は永遠に解決しません。問題が解決した姿が思い浮かばないから。辿り着くべき目標が不明確なのです。
問題とは「達成すべき目標が達成できなかったこと」。目標のないところに、問題は存在しません。
目標がなんであったか、をまず確認しましょう。目標が分からないのなら、まずは目標を確認するべきです。
問題をブレークダウンする
問題定義で、もうひとつ意識しておくべきことは、問題の大きさが適切か?ということ。
例えば、次のような問題。
プロジェクトの作業工程が圧迫している
- 問題 納期にプロジェクトの納入が間に合わない
問題定義として正しいかもしれません。でもこれを、新人のAさんが解決するのは、ムリでしょう。
問題は、担当者が対応可能な範囲でなければなりません。問題が大きすぎる場合はブレークダウンする必要があります。
目標と現状の差から問題を導出する
目標が何であったか、それに対しての現状がどうであるか。
その目標と現状のギャップが「問題」です。
Aさんの進捗が遅れている…
- 問題 Aさんが担当しているコーディング作業が、完了予定より1週間遅れている
「1週間前に完了している」が目標、それに対して「完了していない」という現状。
そのギャップが、問題です。
問題を考えるときは、そもそも目標がなんだったか、を確認すること!
原因:問題を生じさせる「客観的な事実」
問題が定義できたら、それを発生させている原因を探ります。原因は、客観的な事実として定義することが重要です。
原因を定義しないと、対策が陳腐になる
原因を考えないで、いきなり対策を考えるとどうなるでしょうか。
Aさんの進捗が遅れている…
- 問題 Aさんが担当しているコーディング作業が、完了予定より1週間遅れている
- 対策 頑張ってコーディングを終わらせる。。。
原因を追究しておかないと、対策が、問題の単なる裏返しになってしまいます。これでは解決しませんね。
なぜなぜ分析で原因を探る
問題を定義したら、その原因を深堀りする必要があります。「~はなぜか?」を繰り返して深堀りしていきます。
- Aさんのコーディング作業が遅れている。
- なぜ? 〇〇ライブラリを使った実装が完成できていない
- なぜ? ライブラリのどのAPIを使えばよいか分からない
- なぜ? ライブラリのヘルプドキュメントがない
このなぜなぜ分析を行うことで、ほんとうの原因を明らかにしていきます。
原因を個人の能力に言及しない
原因定義のときに注意したいのは、原因を人の能力のせいにしないこと。
- Aさんのコーディング作業が遅れている
- なぜ? Aさんのコーディング経験が浅い
たとえ間違ってはいないとしても、原因の追究がそこで止まってしまいます。
原因は、他の人が見ても納得ができる、客観的な事実として定義する必要があります。
真の原因を定義する
なぜなぜ分析を繰り返し、人の能力に言及しないように注意しつつ、真の原因を特定します。
Aさんの進捗が遅れている…
- 問題 Aさんが担当しているコーディング作業が、完了予定より1週間遅れている
- 原因 〇〇ライブラリを使った実装が未完。ライブラリのヘルプドキュメントがないため
原因を人のせいにせず、客観的な事実として定義すること!
課題:解決に向けた「測定可能」な行動
問題と原因の次は、解決するための課題です。
課題定義で大事なことは、「実行可能であること」そして「実行したかどうかが分かること」。
つまり課題は、達成度合いを測定できる行動として定義する必要があります。
課題を思いつきで定義しない
課題をこんなふうに定義してしまう場合があります。
- アルゴリズムの実現方法を考える
- ライブラリの使い方を調査する
- 他チームと仕様を調整する
なにがよくないのでしょう?
この定義だと、解決に向かって行動できているのかが測定できないのです。
「アルゴリズムの実現方法を考える」といったって、どこまで考えればよいの?そもそも、考えただけでは問題は解決しない(コーディングしないとね)。
課題は、測定可能な行動とする
意識や心意気といったもので、課題を定義してはいけません。
実際に行動に移すことができ、達成度合いが測れる必要があります。
「アルゴリズムの実現方法を考える」を測定可能な行動で定義する
- アルゴリズムの類似事例をネットで収集する
- アルゴリズム実装方法をデザインメモにまとめる
- デザインメモをチーム内でレビューする
- アルゴリズムのコーディングを実施する
個々の行動は明確です。どの段階まで達成できたかで、進み具合が測定できます。
解決に向けた行動として課題を定義する
課題を、達成度合いを測定できる行動として定義しましょう。
その指針に従い、問題解決のために行動していきます。
Aさんの進捗が遅れている…
- 問題 Aさんが担当しているコーディング作業が、完了予定より1週間遅れている
- 原因 〇〇ライブラリを使った実装が未完。ライブラリのヘルプドキュメントがないため
- 課題
- (1)ライブラリのヘルプが存在するかをネットで探す
- (2)ライブラリ使用経験者であるBさんに実装方法を質問する
- (3)コーディング方法をデザインメモにまとめレビューする
- (4)デザインメモに基づきコーディングを行う
測定可能な行動としておくことで、もし問題解決と外れたほうに向かったら、軌道修正する。こういった対応もとれるようになるわけです。
課題は、達成度合いを測れるような行動にすること!
見直し前と後の問題定義を比べてみる
見直し前と見直し後の定義を、比較してみましょう。
Aさんの進捗が遅れている…
- 問題 Aさんの作業効率が悪い
- 原因 Aさんは経験不足のため他の人より作業が遅い
- 課題 Aさんが残業して残作業をこなす。。。
Aさんの進捗が遅れている…
- 問題 Aさんが担当しているコーディング作業が、完了予定より1週間遅れている
- 原因 〇〇ライブラリを使った実装が未完。ライブラリのヘルプドキュメントがないため
- 課題
- (1)ライブラリのヘルプが存在するかをネットで探す
- (2)ライブラリ使用経験者であるBさんに実装方法を質問する
- (3)コーディング方法をデザインメモにまとめレビューする
- (4)デザインメモに基づきコーディングを行う。。。
見直したあとのほうが、問題解決への行動を起こしやすいですよね。
まとめ
最後に、いちばん気をつけること。
問題が解決しないときに、「〇〇君のせいだ」など、誰かのせいにしていませんか?
肝に銘じておきましょう。
その誰かを責めても、問題は解決しません。
正しく問題を定義して、解決を図りましょう。
コメント