概要
人にお願いしてシステムを作ってもらう事があるが、お願いした事と微妙に違うものができあがってしまう事があった。このような体験があってから、依頼の仕方が悪かったのかと仮説を立て本書を読むことにした。
プロジェクトが失敗するパターン
さまざまなパターンがある事がわかった
- ゴールがバラバラ
「関係者ごとに目指すゴールがバラバラ」よくある話だと思う - 現場の声を聞きすぎてコストが膨らむ
経営者にインタビューすると「現場の声を聞いて、使いやすいシステムを」となるが、実際に現場の声を聞きすぎると、投資額が増える割にビジネスにとって役に立たないシステムになる
痛いほどよくわかる。
これの解決策として、Why -> How -> What の順番で考えよ
ということがあった。これは、The Golden Circle で有名なこの話と同じだ
https://www.smartinsights.com/digital-marketing-strategy/online-value-proposition/start-with-why-creating-a-value-proposition-with-the-golden-circle-model/
つまりは解きたいゴールを明らかにする。ゴールが明確でなければ稼働まで辿り着けない。
Why
- このプロジェクトはなぜやるのか
- 本当に今のままでは事業を継続できないのか
- 最低限達成すべきことは何か
を明確にする。問題になるのは、現場が理解しない（できない）のではなく、各関係部署が共に目指せるプロジェクトゴールを明確にする必要がある。
プロジェクトが共有できてないと気づいた時には、手を止めて共有することが先決となる。
良いプロジェクトゴール作りにするためには
- 以降の工程で使えるゴールにする
プロジェクトを進める上での判断の価値基準になる。 - 地に足のついたゴールにする
華々しいゴールを設定したがりがちだが、実情にあったゴールにしないと困難を乗り越える事ができない。 - 何のためのプロジェクトか（Why）をゴールに込める
プロジェクトのゴールがしっかりしていないと、あれもこれもとごった煮になる。 - ゴールのわかりやすさにこだわる
途中から参画するメンバーにとってもわかりやすいゴールにする
ストーリー仕立てだとコンセプトを誰でも理解できる
How
システム機能を具体化する前に「システムが変わったらどういう絵姿になっているか」という将来像を描く
業務フローを中心に書くのがポイント
- 変化点を必ず書き出す
どのような意図で、何を変えるのかを意識する - 正常系（メインフロー）を決め、その後に異常系（イレギュラーケース）を考える
このフェーズではメインフローを書き切ることが重要 - 詳細まで詰めない
フローを書いているとさまざまな疑問が湧いてくるが、そこはTODOとして管理して
全てのフローを書き切ったあとでTODOを整理する - 一人で作らず、人を巻き込む
このフェーズで人を巻き込まないと「自分達で作った」とものとしてメンバーは認知せず、非協力的になってしまう可能性がある
What
要求定義、要件定義と同義。特に機能要求定義。
まずは言葉の整理
要求定義とは、「システムはこんな風であって欲しい」とシステムに求めることを明確にする作業
利害関係者の意見をまとめて、実現すること・実現しないことを揺るぎなく決めること
要件定義とはシステムを作る人が、システムに必要な性能や実装すべき機能などを明確にする作業
システム要求を作る上での障壁
- 完璧なリストアップができない
できあがったシステムを使った具体的なイメージしきれない - 予算オーバー
リストアップされた機能に優先順位をつけ、作る機能と諦める機能を取捨選択する必要がある - 立場が変わればシステムに求めるものが違う
関係者全員の同意が必要だが、必ず関係者間で思惑が食い違いが発生する。
What まで出し切った後のポイント
必要な要求を見極め、納得と合意を得られる優先順位を決める
絞り込みには説得ずくめのコンセンサスが必要不可欠
システムを使いこなし業務を良くして利益を出さなければ構築する意味がない。
どれも大事に見える、比較できないということに陥りがち。
もっとミクロで観ていくと「今回のゴールに必要」「現場のITスキルだと使いこなせない」「先進的すぎて本当に実現できるのか」という項目も出てくる。
以下の３つの基準を、３段階評価する（あくまでも一例）
- ビジネスベネフィット
投資効果につながる
売り上げ向上、原価削減、プロジェクトゴールへの貢献など - 組織受け入れ態勢
増員が必要
トレーニングが必要 - 技術的容易性
作るのは難しくないか
不確実性を抱えてないか
これらの基準は関係者を巻き込んで決める。自分達で基準を決めてもらうことで、プロジェクトの見方になってもらう。
本書は 400ページ弱ほどの本なので、ごっそり自分に最も関係しそうなところだけ雑にまとめるとこんな感じだ。