「やりたいこと」を要件定義にする3冊
システム開発でモメることは多々あるが、その本質は「やりたいこと」が分かっていないに尽きる。
「やりたいこと」が分かっている場合、リソースが足りないとか突発的な事象が起きたといったトラブルがあっても、まだ何すればいいかは分かる(できるできないは別として)。
しかし、「やりたいこと」分かっていない場合、リソースからスコープのあらゆる場面において、何をしていいか分からないことになる。恐ろしいことに、トラブルになって初めて「やりたいこと」が分かっていないことが見えるようになる。if文を書くときにelseで何するか決まってなかったり、リリース段階になっても運用方式が決まってなかったり。
分かっていないとどうなるか? それぞれのタスクを受け持つ人は、自分のタスクを完遂するため、「一つ前の」仕事をするハメになる。つまり、自分のタスクへのインプットとなる成果物を作ることになる。稟議書を書くシステムエンジニア、仕様を書くプログラマ、プログラミングするテスタ、テストするオペレータ。この経緯は[なぜ糞システムができあがるか]に書いた。
そして、「やりたいこと」を分かっていないのは、発注者である。冗談に聞こえるかもしれないが、本気だ。最も分かっているべき顧客こそが、分かっていない。「やりたいこと」を分かる(可視化する)ことが自分の仕事だと思っていないのである。ITの風刺画「顧客が本当に必要だったもの」を思い出してほしい。
出典 arison.jp
期待通りのシステムにならなかった理由として、開発者の思い込みや営業の押し付けだということがアイロニカルに描かれているが、「顧客が本当に必要だったもの」が最後のコマであることに注意してほしい。顧客が最初に説明した要件からどんどんズレていっただけでなく、そうしたズレを目にしつつ、できあがったモノを見て、ようやく顧客が「やりたいこと」に気付けたのである。
そして、これはシステムの発注者に限らない。開発者もまた、「顧客」である。オフショアの例を挙げずとも、全部ひとりで作り上げるわけではない。機材を調達したり、構築を依頼したり、運用を任せるとき、その発注元となるからだ。
発注する人と受ける人が、「やりたいこと」を分かり合うために、どうすればよいか。これが難しい。そもそも発注者側が、「やりたいこと」を明確にする義務があることを自覚しない場合がある。稟議を通すためだけの、ゴミみたいな中身ゼロの企画書を放って事足れりとしたり、そもそもドキュメントすら存在しない場合もある。
この「やりたいこと」について、発注者と受注者の両方に立ち、なおかつ同じ目線で分かり合うための本が、「はじめよう!」シリーズになる。
システム開発の本といえば、(その担い手である)受注側に寄り添ったものが多い。テクニカルなやつからマネジメント、最近だと紛争予防のための法務系まで、作り手の役に立つものばかりだ。
しかし、作り手に対し、「やりたいこと」が渡せていなければ、いくら作ることを頑張ったとしても多寡が知れる。「やりたいこと」が不明確な分、それぞれの仕事を進めるために、「一つ前の仕事」をすることになる。ゴミを入力するとゴミが出力される法則[GIGOの法則]に従って、ゴミみたいな要件からは、糞みたいなシステムができあがる。
だから、そうさせないために、「やりたいこと」を明確する。そのために、何よりも発注者、すなわち顧客が動かないと......なのだが、何をすれば「やりたいことが明確になる」か分かっていない顧客が多すぎる。あたりまえだ、開発者は多くの顧客を相手にしてきたが、”その顧客”にとっては初めてだろう。”その顧客”にとって、「やりたいこと」すなわち要件を定義するためにすべきこと、すべきでないことが書いてある。
これは、顧客側の「情報システム部」も同じ。レガシーを後生大事に護ることが”仕事”だとカン違いしている。これ、古株であればあるほど強く思い込んでいるように見える。だから、要件定義を求めても「今と同じように」「現行を踏襲して」という答えしかできない。その「現行」が何か、分かっていない「情報システム部」の人にとっても、本書は効いてくる。
顧客よりから考えると、最初は緑本『はじめよう! プロセス設計』になる。誰と誰が連携し、どうやって仕事を進めているのか(ビジネスプロセス)が明確になる。そもそもこの仕事が全体から見て必要なのかどうかも見えてくる。
現行の仕事のプロセスが見えるようになると、本来やるべきことなのにやれていないこと(=「やりたいこと」)のFIT/GAPが可視化される。すると、GAPを埋めるためにシステムが何をしなければならないか(あるいは、何をしなくてもよいのか)が見えてくる。仕事を回すために、システムに求められていることが分かる。極論を言うと、開発不要になるかもしれぬ。ビジネスプロセスが標準化され、システムのこの部分が不要となりました、という解さえあるのだ。
そして、システムに求める「やりたいこと」をソフトウェアで実現するためにどうすればよいか? その方法が、オレンジ本『はじめよう! 要件定義』にある。そもそも要件とは何か、要件定義をするということは何が決まってくるのかが、流れと内訳の両方から理解できるように書いてある。
これは、発注者に読んで欲しい。実際に要件定義を「書く」のは受注者でも良いのだが、何が定義されていなければならないか(UI、機能、データ)、そのために何を準備しなければならないか(利用者行動シナリオ、概念データモデル)については、発注する「中の人」が理解した上で決めなければならない。
UIとかデータモデルというと、なじみのない人は敬遠するかもしれぬ。だが大丈夫、「目玉焼きをつくる」という超簡単な仕事を例に、要件定義とは何かを教えてくれる(そして、「目玉焼きをつくる」を要件定義することは、意外と決めねばならぬポイントが多いことに気付くだろう)。
さらに、できあがった要件定義を設計に落とし込む際に効いてくるのが、青本『はじめよう! システム設計』になる。一人で要件定義を聞き出して、一人で実装する程度であれば問題ないが、そういう小規模なものはレアケースだろう。複数の人が連携して、前提を洗い、不足を補い、管理できるタスクにまで落とし込む必要が出てくる。
プロジェクトを横断的に見た場合、どのプロジェクトにも共通する層がある(フロント層、バック層、DB層)。そのそれぞれの層ごとに、何に気を付けることで他と連携して上手く回せるかが分かるように書いてある。開発者もまた、調達やオフショアする場合、あるいは別の担当に請け負ってもらう際の「発注者」になるのだから。
例えば、「目的語と動詞を明確にする」「受動態から能動態に書き換える」「二重否定による条件をやめる」の3つを実行するだけで、見通しの良い設計書になる。痛い経験を積んできた人は無意識のうちにやっていることが、意識的に書いてある。
要件定義を中心として、緑、オレンジ、青の順に進めることで、「やりたいこと」を可視化して、要件定義や設計に落とし込むことができる。わたしの場合、新人さんに渡してきたが、むしろ発注者に読んでほしい。
| 固定リンク
コメント