欲しい人の次元でイメージするチカラ

一昨日の　プロジェクトは複数のシナリオでリスクを洗い出す　と昨日の　先を読む理由 　を書いた後、そういえばこの記事は　先を読む理由　のリスクを洗い出す時にシナリオを使うので「順序というか関連があるんだよなぁ」と思いついたけど仕事をしている間に記憶から溢れていたたところ、御昼ご飯を食べながらこんな話を向けてこられて、記憶が蘇ったんですね。

アーキテクト「プロジェクトの応援に要件定義フェーズから参加しているんですけどね」
ワタシ　　　「どのプロエジェクトだっけ」
アーキテクト「アレですよ、Webシステムの」
ワタシ　　　「あぁ、アレね。どうなの、あまり悪い噂は聞かないけれどさ」
アーキテクト「いやー、あんなプロジェクトの進め方初めてである種のカルチャーショックですよ」
ワタシ　　　「何が。想像つかないんだけど。いまどのフェーズだっけ」
アーキテクト「まだ要件定義ですよ」
ワタシ　　　「要件定義でカルチャーショックなことが起きるの。イミフだけど」
アーキテクト「だって、要件なんでしょうねって聞くと、機能を語り始めるんですよ。機能！」
ワタシ　　　「確かに要件定義じゃないわな」
アーキテクト「でしょ。かみ合わないんですよ」

システムに限らずものづくりをするなら要件があってそれを実現するためにプロジェクトの体裁をとってことを進めることは理解していただいていると思います。
＃大丈夫だよね？

解決したい課題、通常は経営上の課題があってその課題の解決策から要件を抽出して、抽出した要件を人手かシステムで実現するわけです。

[課題]　→　[解決策]　→　[要件]　→　[業務要件]　＋　[システム要件]

抽出した要件のうち、システム要件を機能として実現するためにシステムの機能仕様を設計し、実装するように進みます。

事業企画	要件定義	基本設計
[課題]　→　[解決策]	→　[要件]　→　[業務要件]　＋　[システム要件]	[システム要件]　→　[機能仕様設計]

さて、アーキテクトは何にショックを受けているかというと要件定義フェーズなので要件からシステム要件を抽出するものだと思っていたら、一つ飛ばして機能仕様を始めているのでそれにびっくりした、というわけです。

欠けている思考
そのプロジェクトでは一体何が欠けているのでしょうか。実は、要件定義フェーズで要件を定義せず機能仕様を書こうとするシステムエンジニアは少なくないんですよ。それは多分に要件定義の経験の問題からくるものですが。

そうしたことが起きるのはなぜでしょうか。

それは、「要件を出す人の次元でプロジェクトの目的をイメージできないから」です。事業の当事者であるお客さまの立場で何が困っていることかをイメージできない、そういうことなんです。

だからシステムエンジニアの視点でいきなりシステム機能仕様を語り始めるんです。これ、危ないんですよ。だって、お客さまからみたら課題から機能仕様に飛んじゃうんですから。

そんな状況でシステムを実装してお客さまにできました、と言ってもシステム化の対象を合意していないんですから。

システム化の範囲が合意されていないし、要件、つまり要求から何が得られるか具体的にイメージできていないところで出来上がったシステムを見ても初見ですよ。そんなのいいのか悪いのか判断つかないですよね。それにそのシステムで一体どの要件が解決されるのかもわかっていないのですから。

そこには要件とシステム機能仕様をつなぐものがないんです。

プロジェクトでは要件から

・出来上がる（はずの）システムが稼働する姿を概念的にイメージして
・それを具体的に想定して
・プロジェクトが達成する目標を設定して

行くことが必要なんです。それが要件定義なんです。それを思考する力が欠けているんですね。

ワタシ　　　「それじゃシステムエンジニアの独りよがりのシステムになっちゃうんじゃないの」
アーキテクト「そうなんですよ。利用者不在ですから」
ワタシ　　　「そこまでわかっているならキミがなんとかするしかないね」
アーキテクト「やっぱり…ですか」