ロジカルに伝えることとストーリーを持って伝えること

今では、もう10年も前のことになってしまうが、某部署に異動していくつかのプロマネをした後がどれも技術的に未経験のソリューションで、若干の助走期間があったがプロジェクトが始まってしまえば助走期間でやったことは大して役に立たなかった。

そうしたソリューションの中で、あるエンジニアが考えた手法があった。ただ、その手法は机上でしかなく、考えた本人も実践でその手法が機能するかどうかは確かめたことがなかった。

一般的なシステム開発手法であるウォーターフォールでの局面間の割り当てから言えば、データ設計などが上流により過ぎている感を覚えるような構成なのだが、これは適用するパッケージの導入と構成の制約も考慮した上での仕立てになってた。

顧客から見れば、システム要件を話す時点で、どうしてデータ項目まで言及するのか戸惑うかもしれなかったが、それはそれで後工程が楽になるのとより早い段階から顧客が当事者意識を持つように作用するため、割といいシナリオだった。

脱線するが、なぜデータ項目を早く始めると顧客の当事者意識が高まるか、その理由を考えてみると良いと思う。

話を戻して。

その手法を考えたエンジニアの拘りが、仕様を確定した後の「ドキュメントを読み物として書く」というのがあって正直、それどうなんだと思っていたし、今でもどうかな、と思う。理由は、ドキュメントは仕様を書くもので機能的である、つまり、ロジカルに書かれて入ればよく、読み物として書かれると全部読まないとわからいということだ。

ドキュメントの観点で言えば、ドキュメントはロジカルに書かれて入れば良い。ドキュメントで扱うユニバース(書くことと書かないことの界面)の定義、ユニバースの中の機能分解と仕様。取り扱う数値が記載されていれば良いのだ。

ただ、そのユニバースに到達するための経緯は後のテストで紐解き直す必要が出てくればリファレンスが必要となるが、それは仕様検討の資料に繋がるので問題はない。

ここのドキュメントを作る目的から言えば上述のとおりでそれで十分である。これではドキュメントが刊行されないとプロジェクト全体を把握しきれない。そのために必要となるのがストーリーを持って伝えるということになる。

システム開発でストーリーを持って伝えれば良いのは、プロジェクト全体のフローである。局面の繋ぎ方、登場人物が出てくるタイミング。キャスティングの台本としてプロジェクト全体をストーリーを持って伝えなければ、ステークホルダーサードパーティは動いてくれない。それはチームメンバも同じである。

どちらも関わる人が読み、行動するために作成するのは同じであるが、幾重にもストーリー仕立てになっていると、ゼロイチの実装に近いドキュメントは使い勝手が悪くなってしまう。

そうした考え方から言えば、あるエンジニアの拘りは後の運用維持でそのドキュメントを読むことになる担当者の立場では迷惑でしかないし、拘った部分は履き違えていたのだ。

そのソリューションで設計書をどうしたかと言えば、上述どおり機能をロジカルに書いたし、ストーリーを持ってプロジェクトを進行したのであった。

 

世界一やさしい問題解決の授業―自分で考え、行動する力が身につく

世界一やさしい問題解決の授業―自分で考え、行動する力が身につく

 
世界一やさしい右脳型問題解決の授業

世界一やさしい右脳型問題解決の授業

 
自分の答えのつくりかた―INDEPENDENT MIND

自分の答えのつくりかた―INDEPENDENT MIND