2009/07/08プロジェクトマネージャは、プロジェクトの品質・コスト・納期に責任を持ちます。それに対してアーキテクトは、技術に責任を持ち、その中でもアプリケーションアーキテクトと呼ばれるエンジニアは、企業におけるアプリケーション・アーキテクチャを設計し、構築や実装を技術でリードする存在です。これまでシステム分析について、数回に分けて語ってきましたが、概要、問題分析に引き続いて、今回は「要求分析」を取り上げます。要求分析自体もステップに分かれますので、何度かに分けてお伝えしていきます。対面ではなく、コラムでの説明は難しいのですが、図を使いながら可能な限り分かりやすくすることを心がけます。要求分析の目的は、次の通りです。要求分析の手順は、大まかに4つのステップに分かれます。・要求モデル上で展開(掘り下げ)が進まない項目のうち漠然とした問題についてWHYツリーを用い分析を行なう。またがると思われる問題について整理する4.まとめ上記結果をまとめ、要求分析書を作成する。分析結果(目的体系、問題点リスト、問題点分析結果など)次の図は、成果物を中心に手順の概要を示したものです。中心にお伝えする予定です。08:01質問があります。後で要求が変わる事が多々あるかと思いますが、その様な変化に素早く対応するにはどうすればよいと思いますか?何故このような事を聞くのかといいますと、この記事の要求分析書が多いと感じたからです。変化があるたびにこれらの書類を書き直すのは大変だと私は感じたのです。19:04前の方が質問されているように、最近は変化が多く激しく感じます。社内外統廃合による人事、新技術発表による変化など始めにこれで決定したはずですとはなかなか言えない状況です。要求仕様からさらに基本設計など後工程も変化するはずですから、いちいち書き直すのは膨大な手間隙がかかります。変化にすばやく、なるべく負担をかけずに対応する方法があるならお聞きしたいです。多忙にしていて返答が遅れました。要求分析についてのアウトプットが多いので、後々の変更要求に対応するのが大変ではないか、というご質問と理解しました。要求分析の成果物は基本的に要求モデルのみと考えています。WHYツリー、流れとつなぎ図などは、要求をまとめるための手段という位置づけです。システムに対する要求は、責任部門として事業部門から出します。システム要求を出す側は、自らの責任範囲(主に組織)内における要求を主張することが多いと言えます。ところが、分析者サイドとしては対象範囲全体を見ないといけないということと、要求を出す側にも他者との関係や位置づけを知り、さらに建設的な意見を出してもらう必要があります。言うブレーンストーミングのための素材として、これを使用します。結果として関係者の共通認識を促し、より具体的で現実的な要求を引き出すことができます。先述の通り、私は要求モデルをロジックツリー形式で表現します。目的から手段を洗い出すトップダウン型と、これは何のためにという考えでKJ法などを使ってポトムアップ型の両方でまとめていきます。そのときに、どうしても要求モデルを下位展開できない場合、つまり原因がわからないので対処法も浮かばない、という場合に結果から原因を導き出すWHYツリーを利用すると便利です。・流れとつなぎ図この手法も、原因を突き止めて要求モデルの会展開を促すものですが、どちらかというと組織間のプロセス上での問題を突き止めるために使用します。要求分析の成果物とする場合もありますが、他の2つはモデルを策定するための手法です。要求モデルは、この中でも今回実現する、次のステップで対応する、また、これこれこういう理由で対象外とするということを明らかにします。後に要求モデルを見直す必要が出るケースは、要求分析に漏れがあった場合と、何らかの外的要因(予算、スケジュールの変更など)が発生した場合ですが、どうするかはその時点で責任者を交え判断するしかないと思います。実装手段は要求分析では取り上げないので、技術動向からの直接的な変更は無いと考えています。どちらにしても、おっしゃる通りで、書き直さないといけないのは大変になるので、できるだけシンプルにした方がいいというのは同感です。コメントありがとうございます。返答が遅れまして、大変失礼しました。インドリさんにもリターンしましたが、言われるように後々の変更で遡って対応するのは、困難なケースが多いと思います。先ほども書きましたが、システム分析フェーズでの要求分析ステップの成果物への変更は、大きく分けて以下の2通りと考えられます。1要求分析作業上での漏れ2予算、スケジュールやシステム化対象の変更など、プロジェクトの外的要因による変更の発生ここでは、成果物に対して事業部門の承認が必要ですので、極力技術的な実装手段は省くべきと考えています。2から先に取り上げると、機能分析や実現手段検討のステップに入って、当初予算やスケジュールを見直さなければならなくなり、その結果システム化対象領域の縮小などが発生する場合があります。このケースは、システム分析フェーズでシステム基本構想を策定した結果、ありうるということで、あらかじめ想定しておくくらいのリスクテイキングが必要だと思います。プロジェクトマネージャレベルではなく、経営層レベルでの話です。1は、世の中に多く存在する業務分析のメソッドで論理的にプロセスと成果物の流れを認識しながら進めることで、カバーできる範囲もありますが、突き詰めるとユーザー企業の事業戦略を理解できていたか、まで行ってしまいます。単なる要求モデルへの変更を簡単にできる方法はあるか、ということだけでは解決するのは難しいと思います。システム構築におけるユーザーとITベンダの役割分担にも話が及ぶと思います。以前セブンイレブンの情報システム部門の責任者の方にインタビューする機会があり、その考え方に感心したことがあります。上流工程(システム分析)は自社で実施されて、下流(システム設計以降)はベンダに任すという方針は一般的ですが、ある方法を取られて全体コストを下げ、納期遅延をなくしたという内容でした。長くなるので簡単に言いますと、システム分析では実装手段に言及はしませんが、機能の確定と帳票、画面、及び画面設計は済ませておくというものです。システム部門だけではできないので、事業部門も巻き込んで、喧々諤々の議論をしたそうです。事業部門には実装手段の話をしてもあまり通じないので、見える部分を中心に話し合う、そうすると機能的なものも見えてくる、ということだと思います。システム部門の方が実装手段を全く分からなくていいわけはありませんが、もう1つ見逃せないのは、その事業部門との議論の中に、下流を担当するエンジニアも参加させていたことです。この辺りまで踏み込めるユーザー企業はざらにないかもしれませんが、これくらいのことをやると、変更が少なくコストが抑えられ納期遅延も無い、ユーザーとベンダ、もしくはSIerがWIN-WINの関係になれるのだと思います。13:12高橋さん丁寧な返信有難うございます。非常に勉強になります。高橋さんの趣旨がよく分かりました。高橋さんの仰るとおりで、要求が複雑な場合、要求を分析するために色々な図を使うのは合理的だと思います。01:13ビガーです。このあたりのフェーズでは特にはヒトというか「キーマン」を如何に抑えるかが重要と思います。ものを使うんだろうなと思いました。WHYツリーなるものも興味深いですね。おっしゃる通り、トップから詳細化する中で迷いが出たときに事実を収集するというのは基本です。効率よくやるかが腕の見せ所でしょうか。セブンイレブンの話、絶対にそうあるべきです。どんな手法を用いようともエンジニアが要求の源泉を理解できるような状態でないと意味あるシステムなどできないし、顧客が満足するモノにならない可能性が高い。結局出来上がったモノである思います。モノ(クラウドサービスなど)は使いどころで選択できるようになってきたから一概に言えなくなってきたとは思いますが、サービスという形であってもモノを創っていくことの価値は不変だと思います。要は、エンジニアリングに最も価値がある(これは完全な主観です)のは今後も変わらないからエンジニアの方々もこの辺りの話を勉強する必要があると云いたいのですが、その辺りを高橋さんのコラムと今後リンクさせてもらいたいと考えています。10:27ビガーさん、ありがとうございます。システム構築に対する技術的アプローチも重要ですが、言われるように対顧客視点で誰がキーマンかを認識してうまく進めるのも同じくらい重要ですね。単なる窓口で虚勢を張る方も結構いるので、過去に何度見誤って自分の眼力に愕然としたことか・・・。そのキーマンをターゲットしマークしていくのは、アーキテクトかPMか、もしくは営業かという役割の話もありますが、大きく網を張ることができるのがコンサルタントと言うことができると思います。こちらの戦力や体制を見て最適な動き方ができるセンスを持つ、ということでしょうか。10:51これは要望です。次回の予告を見てふと思ったのですが、そういった表があるという事や書き方だけではなくて、実際のプロジェクトでやる「根回し」などの生臭い現実なども書いて欲しいです。うまいタイミングで現場感のある話を挟みたいと思います。10:02有難うございます。