■ 要件定義のお仕事は、ビジネスモデリングそのものである!
筆者のコンサルタントとしての上流工程の経験から、「要件定義」というお仕事への取り組み方について、これまでの経験値からお話ししたいと思います。前回は、要件定義フェーズの位置づけや、システムとの関係性について、外堀から説明していました。
⇒「要件定義入門(1)上流工程での基本的な立ち居振る舞いとは」
今回は、要件定義というお仕事の内部からの説明になります。
ズバリ、要件定義は、ビジネスモデリングをすることである、と考えています。
では、ビジネスモデルとは一体何か? ここで、ジレットモデルとかデルモデルとか、どうやって儲かるための仕組みを考えるか、というお話をするわけではありません。たとえ、ジレットモデルやデルモデルであっても、それを機能させるために、ITシステムを実装する必要があるし、そもそもの業務オペレーションをどう組むかの作戦が必要になります。そして、そうしたビジネスモデルには、必ず、経営目標やKPIというものが設定されており、その達成を使命として帯びている、という性格を持ちます。
筆者は、「絵に描いた餅」的に、「こうやれば儲かりますよ」という構想を単に絵にまとめるだけでなく、実際に動くものとして、ITシステムなり、新業務フローなり、インプリメンテーションまで一貫して請け負うことを業としています。
それゆえ、筆者が請け負うビジネスモデリング = 要件定義 は、経営陣、現場、IT企画のそれぞれの立場の人からの要請をインプットにして、作業を始めることになります。
誰にとって、なぜ、その経営目標の達成が必要なのか?(Who, Why)
その経営目標の達成は、いつまでに、何を、どうしたいか(When, What, How)。
そこからかみ砕き始めます。そして、2つのCSF(重要成功要因と重要解決要因)の前提を置きます。何が成功かの定義と、どうやって成功するかの大きな方向性の定義を行うのです。
最後に、そもそもの依頼を受けた3つの部署に対して、適切な回答として、①ビジネスモデル(戦略的意思決定項目リスト)、②オペレーショナルモデル(業務改善リスト)、③システムモデル(システム化計画)を提示します。
■ お仕事とは、そもそも後工程への引継ぎを意識して行われるものである!
筆者は、納期設定が無い仕事は、やるべき仕事と認めていません。さらに、仕事は、誰からから依頼を受けて、誰かに納品するためのものと理解しています。それゆえ、要件定義のお仕事も、それを受けて次に誰が何をしたいのかを必ず気にかけて、自身のアウトプットの品質を管理することにしています。
要件定義のお仕事とは、経営、現場、IT企画の人たちに、ビジネスモデルを提示することです。では、その3部署の人たちは、あなたからビジネスモデルを表現した何らかの成果物を受領して、次に何をしたいのでしょうか?
(1)経営・・・経営目標の設定・精緻化
(2)業務・・・業務改革プログラムの設定
(3)IT企画・・・システムモデリング(システム要件定義)
ITシステム構築プロジェクトの場合、上記(3)の次はIT屋がシステム要件定義フェーズ開始とともに、あなたの作成した業務要件定義書をインプットにして、①システム機能、②データモデル、③業務設計を行います。これは、プロジェクトライフサイクルにおいて、明示的に計画されていることから意識されることが多いのですが、同時に、経営者向けには、KPI/KGIの設定、業務を司る現場には、業務改革プログラム(チェンジマネジメントの実施のための行動計画)を授けることにもつながることを忘れてはいけません。
どうも、システムモデリング、その中でもシステム機能(データ処理などのプログラムを実装するためのロジックそのもの)にばかり焦点がいって、前2者が忘れられがち。本物の上流工程担当になりたいなら、これらを三位一体で考えられるようになる必要があります。
■ いつまで、業務要件定義のために業務ヒアリングをしているつもりですか?
経営コンサルタントとして、クライアントからウンザリされることの代表例が、現状分析に時間とコストをかけること。筆者も、何も現状を調べないで、思い込みでビジネスモデルを構築していい、というつもりはありません。むしろ、三現主義(現場、現実、現物)を重視する姿勢を大事にしています。ここで言いたいことは2つ。
① 「暗黙的要件」を知っている業務要件定義担当者になる
② 問題解決は、「集中思考」ではなく、「拡散思考」で対処できる業務要件定義担当者になる
(1)暗黙的要件
業務ヒアリングで、ヒアリング対象者から情報が引き出せるのは、聞かれた方が認知している課題なり、お困りごとなり、関心事のみです。もしかしたら、その成し遂げたい業務改革(BPR)やITシステム構築の真のポイントを考えることの大事なヒントは話してくれないかもしれません。それが意図的にせよ、無意識的にせよ。
つまり、話者が分からない・知らないことは、聞いても出てこないのです。
例えば、ものづくりのオペレーション類型に、個別受注型と見込量産型があります。前者は、受注してから、設計や調達、生産が行われます。後者は、生産してから、受注があり、在庫引き当てがなされます。この時、ビジネスモデルをデザインする業務要件定義担当者が、見込量産型のものづくりが当たり前だと思い込んでいた時、しかも偶然にも前プロジェクトで特に苦労していた領域だったとしたら、受注引き当ての方法ばかり根ほり葉ほり聞き倒すことになります。
一方で、製品在庫引き当ての話ばかり聞かれた現場担当者は、受注があってから、注文通りのものを製作して納品するプロセスでしか製品を作ったことが無いので、いつまでたっても、両者の会話はかみ合わないまま時間切れとなってしまいます。勢い、その場合は、業務要件定義担当者の思い込みで量産型の業務フローで業務要件定義書が作成されるのは想像に難くありません。
こういう不幸な事態を避けるにはどうしたらいいか? いろんな業種、いろんな会社、いろんな製商品/サービスにおけるビジネスモデルをいっぱい勉強するしかありません。ヒアリング担当者が無自覚なポイントも、ヒアリング担当者がしている点と点だけを結んで、暗黙知も加味した業務要件定義書をきっと作成することができるでしょう。
当然、筆者も今でも毎日、学習を怠りません。
極めていよいよ遠し。
■ いつも同じ問題解決策を考える癖がついていませんか?
(2)問題解決思考
ファクトベース・コンサルティングとか、ロジカルシンキングという言葉を、筆者は毛嫌いしています。それらは、集中型思考の権化だからです。特に、要件定義でもより上流側の業務要件定義を進めるにあたって、百害あって一利なしの思考マインドです。どうして集中型思考は、要件定義にふさわしくないのでしょうか?
集中型思考とは、いくつかの事実を三段論法的につなぎあわせて、一つの解にたどり着く思考法です。演繹法的アプローチでも、帰納法的アプローチでも一緒です。
例えば、納品遅れが発生したとします。その原因は、工場出荷が遅れたから。どうして工場出荷が遅れたかというと、途中工程で予想外の作業リードタイムが発生したから。どうしてその工程でのリードタイムが長くなってしまったか? 必要な資材調達の手配が遅れたから。
集中思考の場合、ここで、最適な資材発注点をITの力を活用して最新式の演算方法で導いて、問題解決をしようとします。そのために、すぐにでも、計算ロジックの組み立てに全員の意識が向かってしまいます。その方が問題解決の早道と言わんばかりに。本当にそれでいいのでしょうか?
拡散思考の場合、資材調達の手配がなぜ遅れたか、理由と関連課題の存在可能性を次々と考えていきます。たまたま、資材調達のシフトに入った担当者が不慣れで、教育プログラムを強化した方が再発防止につながるとか、偶然そのケースでは、その在庫ポイントで遅れが生じましたが、通常はその前工程の内製プロセスでの段取り替えの方が時間を食っているかもしれません。
このように、拡散思考の場合には、たくさんある課題の真因、たくさんある問題解決策、より多くの気づきを出すことで、最適な課題解決方法を探ろうとする思考プロセスです。
拡散思考型で手に入った回答群がそれで抜け漏れが無いかは分かりにくく、筆者も自信をもって「これで全部です」ということができません。永遠に。ですが、こういう思考で問題解決にあたったほうが間違いが起きにくいことは確かです。
渡辺氏の著作P41に、拡散思考型で集めた回答を定量的に評価する軸として次の3つが紹介されています。
① より多くの条件が考慮されて得られたか
② より多くの選択肢の中から選び出されたか
③ より少ないコストで得られたか
ご参考にしてください。
業務要件定義では、拡散思考で課題や施策の抜け漏れが無いように工夫する。一方、その後に待っているシステム要件定義では、集中思考で固定された課題解決のための最善策を見つけ出す。前者はビジネスサイドの出身者の方が合っていて、後者はITサイドの出身者が得意とする方法ではないか、これまでの経験から、少なくとも傾向はあると思います。例外はどこにでもあるので、その限りではないスーパーマン(ウーマン)も何人も目にしてきたのも事実ですが。。。(^^;)
コメント