要件定義をロジカルシンキングで解析する

「30の「勝負場面」で使いこなす ロジカル・シンキングの道具箱」を読んで、高度情報処理試験の論文問題を解いているような気がしてきた。
要件定義と問題解決、ロジカルシンキングについて考えたことをメモ。

【1】業務系システム開発のリスクは、Railsのような最新技術の習得、TiDDのようなプロジェクト管理、TestLinkのようなテスト管理など色々あるが、一番のネックは要件定義だ。
元々の要件が顧客の認識とずれていたら話にならない。
しかしながら、新規顧客の場合、顧客と一緒に開発してリリースして運用しなければ、顧客の本来の要求が何だったのか、が分からない時はすごく多い。

だから、SIerのビジネスモデルとしては、1次開発は赤字だったとしても2次開発や運用保守で黒字になるように仕向けるのが普通だろう。
特に大手SIerが政府の公共システムを受注する場合が当てはまるだろう。
だが、そういうリスキーなビジネスモデルもそろそろ割に合わなくなりつつある。

【2】要件定義を真正面から取り組む必要がある。

要件定義は結局は、顧客の業務で現れた問題や課題をシステム化で解決することだ。
IT業界の営業は、顧客の業務のソリューションに特化したITコンサルタントにならなければならない、といわれる理由は、結局そのことだ。

だが、顧客は自分の業務の問題点を把握しているとは限らない。
普通は、問題の本当の原因ではなく、起きた事象と間違った解答を要件として提示してくる。
それをそのまま仕様に落とすと、本来の問題を解決するシステムではない仕様で実装してしまい、役に立たないガラクタのシステムができるだけ。

だから、要件定義では、顧客の要望をそのまま鵜呑みにしてはいけない。
要望を整理して、本来の課題とその解決策を提示しなくてはならない。
つまり問題解決スキルが要求されている。

【3】「90分で学べるSEの思考術 (ITプロフェッショナルの基礎知識)」では、SEが上流工程で問題解決に関与する状況が多いと言う。
そして、多くのSEが思考の壁にぶち当たるのはこの当たりからだ、と言う。

つまり、要望を単なる箇条書きの仕様と見なすのではなく、構造化された一つのモデルとして提示する能力が必要になってくる。

今までUML、DOAなど色んなモデリング手法を学習してきたが、要件定義では、結局、ロジカルシンキングを中心として論理で整理するのがBetterな気がしている。

仕様とは一つの仮説であり、一つの論理的なモデル。
要望をロジックツリーで整理して、問題と解決策へ昇華できれば、解決策を仕様に落としてしまえばいい。

ロジックツリーがロジカルシンキングで基本なのは、論理的思考の基本スキルが全て含まれているからだろう。
ロジックツリーは、情報をツリー構造に整理するだけ。
しかし、MECEであるか、4Pや3C、PLMのフレームワークで整理されているか、因果関係が言い尽くされているか、などを検証するのは結構大変。

そして、その解決策を仕様へ落とす作業、つまり設計工程でも、整合性を取りながら一つの論理モデルを作るのはそれなりのスキルを必要とする。
僕の短い経験では、アクティビティ図、ステートチャート図、デシジョンマトリクスの3種類で業務分析していくのかな、と思う。

「SEは脳みそで汗をかく職業」とうちの上司は言っていたが、上記の作業はまさにその通り。

【4】羽生さんのBlogで下記の気になるフレーズがある。

【元ネタ】
株式会社スターロジックの羽生章洋が書いてるブログ:要件定義の営業コスト化 - livedoor Blog（ブログ）

株式会社スターロジックの羽生章洋が書いてるブログ:雑多な日々 - livedoor Blog（ブログ）

以前に要件定義の営業コスト化ということを書きましたけど、要するにお客様に「これ書いてくださいね」とお願いしてしまえば、そこに要件が整理されちゃうという感じです。

ネット注文では、顧客に商品を買ってもらうために、顧客自らに、自分の個人情報と欲しい商品情報を入力させる。
リアル注文に対するネット注文の比較優位の一つは、販売者が顧客の注文要望を受け付ける必要がないことだ。
要件定義でも、顧客自身に、仕様を書かせてしまえばいい。

つまり、顧客自身に、問題解決のテンプレートに書いてもらえれば、それがそのまま仕様書になるようにすればいい。

羽生さんの会社で提唱されている「マジカ！」「Buri」などのツールや製品を見ると、こんなイメージでシステムを作っているのかなと思う。
＃自分が理解した範囲内で書いている。間違ってたらスミマセン。

【元ネタ】
ワークフロー入門Buri-TECHSCORE-

マジカ！のシートに、顧客自身にシステム要件を書いてもらう
シートを並べれば、そのまま業務フローになっている
↓
上記のシートの組み合わせをBPMNのモデル(XPDL形式)に変換する
↓
BuriというフレームワークでJavaプログラムへ変換する
Seasarファミリーの一つみたい
↓
後はゴリゴリ書くだけ。

上記まで問題解決が自動化されたら、受託開発はもっと安価になり、ITビジネスもデフレになるだろう。
実際はそこまで自動化できていないが、オープンソースで提供されるツール群には市販のERPパッケージ製品に劣らないビジネス製品もある。

要件定義、問題解決、システム化をもっと綺麗に整理できないか？