ということを以前考えていたので、やや加筆しつつここにメモ。
筋の良い解決方法に辿りつくためには
- 仕様を十分に理解できている
- 選択肢が十分に洗い出されている
- それぞれの選択肢について、実現する上での制約が洗い出されている
- それぞれの選択肢について、メリット/デメリットが十分に洗い出されている
の4状態を辿ればよくて、これができるとあとは決めれば良い状態になる。このフェーズは上から順に辿る必要がある。なぜなら上の状況が変わると下の判断に影響が及ぶため。それぞれが十分に行われていないと大きな手戻りが発生してしまう。
これはタスクの大小問わず、日々の暮らしのうちおおよその課題には適用できると思う。
仕様を十分に理解できている
仕様が与えられたらすぐさまその実現方法を考えようとなってしまいがちだが、まずは立ち止まって仕様を理解することに注力する。以下のようなことを気にかけておくと良い。
- そもそも仕様に不備はないか?
- 仕様で実現したいことは別の形で実現できるのではないか?
- 仕様に書かれている中で曖昧な点(書いた人と認識がズレそうな点)はないか?
次のフェーズで選択肢を列挙するにあたって、全く無意味なものを出すのを防ぐことができる。また、全く無の状態から列挙するのは大変なので、とっかかりを見付けるためにも役立つ。 3つめのフェーズとやることは微妙に被っているけど、おおざっぱに枝刈りする意味でまず最初にやっておけるとよい。
選択肢が十分に洗い出されている
課題の解決方法はひとつとは限らない。いろんなパターンを洗い出して一番良いものを選び取ることで、筋の良い解決方法に辿りつくことができる。ここでパターンを洗い出せていないと次以降のフェーズの検討を進める際に選択肢が増えてしまい、十分な検討がなされていないのでまたこのフェーズに戻ってくることになる。4フェーズの中で一番重要なフェーズといえる。
選択肢といっても亜種を何パターンも出しているのでは、結局どれを取っても変わらないことになりあまり意味がない。できるだけ違う経路で同じ場所に辿りつけないだろうか? を考えたいところ。
十分な選択肢を洗い出す決定的な方法はない。本当に他に実現方法はないか? を常に考えておく癖をつけておくとだんだん身についていく。松竹梅で案を出すのが典型的なやりかただと思う。つまりスコープと工数にグラデーション(松から順に小さくなっていく)をつけた3パターンを出すということ。
自信がなければ、次のフェーズに行く前に誰かにレビューしてもらうのも有効そう。
それぞれの選択肢について、実現する上での制約が洗い出されている
これは1つめのフェーズに似ている。選択肢を挙げたけど実は実現不可能な項目が存在しないか? をいまいちど立ち止まって検討したい。最初は見えてこなかったけどここにきて見えた結果実現不可能と判断できることはよくある。具体的にはこのフェーズで以下のような制約が見えたりする。
- 工数
- 予算
- ステークホルダーの利害
- 他チームとの兼ね合い
- 関連会社との兼ね合い
これらは典型的な例として挙げているだけで、実際には他にもいろいろあろう。
それぞれの選択肢について、メリット/デメリットが十分に洗い出されている
選択肢を挙げるフェーズの次に重要なのがこのフェーズ。メリットとデメリットを洗い出せていないと、どれを選べばよいのか判断することができない。大抵の場合トレードオフになることが多いので、基本的には以下のような軸で考えて、必要に応じて軸を増やしたり減らしたりする。
- 技術的な難易度
- 影響範囲
- 既存機能との整合性
- 横展開可能性
- 負荷
- 直近何らかの開発で触ることが分かっている場合、その工数を増大させないか
- 予算
慣れていないと十分にメリット/デメリットを列挙することもできないので、ここでも誰かにレビューしてもらうと良い。
決めるには
ここまできたらあとは決めるだけ。決めるにはどのメリット/デメリットを重く捉えるべきかの認識が重要になる。評価軸が多い場合は表にして点数をつけると判断をつけやすい。
意思決定者が自分ではない場合はここまでのサマリーをまとめて意思決定者に持っていくことになる。持っていく前に、自分の中でどのメリット/デメリットが重要なのかと、その理由を持っておくと意思決定者の判断に役立つので、何も考えずに持っていくよりはある程度考えてから持っていく方が望ましい。
これらのステップは必ずしも一人でやりきる必要はない。最後に意思決定者に持っていく段になって実は前提が違っていて別の案の方が良いですねとなることも往々にして発生しがちだと思う。タスクの性質に応じて相談のタイミングを調整すると良い。
