本格的リニューアル構想中のため、一部表示に不具合があります m(_ _)m

要件定義入門(1)上流工程での基本的な立ち居振る舞いとは

プロジェクトマネジメント(基礎編) プロジェクトマネジメント(基礎)
この記事は約8分で読めます。

■ 筆者のコンサルタントとしての上流工程経験のTIPSをご紹介します!

プロジェクトマネジメント(基礎編)

筆者は、再生ファンド在籍中に派遣された買収先の会社の立て直し、東証一部上場製造業での経営管理の仕組み構築など、コンサルタントになる前から、業務プロセスやITシステムの改善・新規構築の経験をこれまで積んできました。

(注:わざと、「業務」と「プロセス」、「IT」と「システム」の言葉を重ねています。でも普通に自然でしょ。これらは「馬から落馬」「頭痛が痛い」という重言の類ですが。)

ですから、特定部署でのバリバリの現場のたたき上げでもなく、一方でプログラマーやシステム・エンジニア(SE)の経験もありません。特定の業務の専門家でもなければ、IT専門家でもありません。それでも、要件定義というものに20年以上、携わらせて頂いております。そろそろ、中途半端者の自分に貴重な経験を積ませて頂いた方々への感謝の意味も込めて、これまでの経験と思いをまとめる時期に来たのではないか。そう思ってこの小稿を書き始めています。

100%純正の「業務屋」さんは、プログラムがどうやって動くのかわからないので、業務のシステム化のための要求事項をまとめなさい、と指示されても、一体何から手を付けて、どう要求をまとめればよいか途方に暮れることも多々あります。一方で、「システム屋」さんは、プログラムを書くことはできても、そのプログラムが所期の業務目的を適確に満たしているのか、実は理解してないこともあります。筆者はそうした、業務の専門家、ITの専門家の間を取り持って、プロジェクトを進める役回りを務めています。

そこで大事なのが、「業務屋」から「システム屋」に「ビジネス要件」を「システム要件」に翻訳して伝えることです。後から認識の祖語が無いように、ドキュメントに起こして、説明・伝達することが通常です。よって、ここでは、どういう風に、「要件定義」関連のドキュメントを作成するのかというコツを中心に説明していきたいと思います。

 

■ 「要件定義」というタスクをこなす必要があるシステム開発の全体像

IT分野のテクノロジーの進化により、様々なツールや開発手法が編み出され、その時々にブームになったり、廃れたりしています。ここでは、一番オーソドックスな「ウォーターフォール方式」でのシステム開発手法の流れを下図の通り示しています。

PM(基礎編)_システム開発のフェーズ

「ウォーターフォール」とは、その名の通り、「滝」を意味し、ビジネス要件が最初に決まり、後は滝を上から下へ水が流れるように、ビジネス要件が次工程に渡されてシステム要件になり、更に各種設計書に化け、一番最後にプログラムの完成体として結実し、検収を迎えて、サービスイン(カットオーバー)と呼ばれる、本番運用開始になる様子を見事に表しています。

それは、「ビジネス要件」→「システム要件」という風に、システム開発プロジェクトの中を一方通行で情報が流れる様子でもあり、「要件定義」→「設計」→「開発」という風に、タスクが次々と連携されて実行されていく様子を模した表現でもあります。

その中で、「要件定義」は、ウォーターフォール方式のシステム開発プロジェクトでは、一番最初に登場するタスクで、プロジェクトのこれからの姿を決定する大事なものです。

① 何のためにシステム開発するのか(目的とスコープ)
② どういう業務をシステムで実現したいか(目標)
③ 経営や業務改善スケジュールに対応していつまでにシステムを構築するか(時期)

「目的」は、業務要件定義をする動機、そもそも業務要件定義を行って、経営上、何かをなし遂げたいという「意思(Will)」を明確にするものです。そして、自ずと、目的を達成するためにシステム開発を行う範囲(スコープ)を決めていくことになります。

「目標」は、「目的」達成のために、ひとつひとつの業務の水準や品質の有り様を決めていくものです。比較的細かい単位まで、現状業務の実態を分析したり、あるべき新業務についての絵姿を決めていったりするものです。

そうした「目的」「目標」を決めたら、それぞれ、時間軸をもって、いつまでに完成させるか、いつまでに新業務に切り替えるかを決めます。それが「スケジュール」「マイルストーン」等と呼ばれるものです。

それらは、きちんとドキュメント(書類)に起こされていないと、考えた人とそれ以外の人の間で認識の祖語を生じたり、考えた人の思いがぶれてしまい、後々、せっかく製作したプログラムが使い物にならなくなったりする可能性が大きくなってしまいます。

そこで、

「グランドデザイン定義書」(基本構想書)
何のために、誰が、いつまでに、どういう経営改革、業務改善、システム構築をしたいかを記述

「業務要件定義書」
新システムで実行させたい業務の概要と、その業務を行うに当たっての制約や条件、その業務で果たしたい遂行目的(システム全体の目的を達成するためにより具体化・詳細化されたもの)を記述

「システム要件定義書」
業務要件を、新システムで実現するひとつひとつの「機能」に落とし、システム化の実現性を記述

という文書(ドキュメント)を手順を追って作成してきます。

 

■ どうして「要件定義」が「上流工程」に位置付けられるのか?

システム開発において、大きく手順を「上流工程」と「下流工程」に分けることがあります。筆者は、「上流」「下流」が、「上位」「下位」、「上級」「下級」という響きに聞こえる弊害が大きいものと考え、あまり自分ではこうした区分を表す言葉を使うことはありません。

⇒「上流コンサルタントになりたいんですが? そうですか、今まで下流にいたんですね。

ここでは、一般的に用いられているということで、「上流工程」における「要件定義」という位置づけで説明します。渡辺幸三氏の「業務システムのための上流工程入門」によれば、上流工程は、

① 分析
② 設計
③ 検収

という3つの作業で構成されています。

PM(基礎編)_上流工程としての要件定義

① 分析
一般に「業務分析」と呼ばれるもので、数ある経営上、ビジネス遂行上の問題や不具合を列挙した上で、その中から「何を解決すべき問題とするか」という課題設定をしていきます。

② 設計
課題が設定されたら、その課題を解決するための方策を考えます。そうして案出された「解決パッケージ」の束(たば)を定義していきます。

③ 検収
「ウォーターフォール方式」の図解では一気に理解することは難しいのですが、順を追って2種類の検収があるとします。一つ目は、設計後に、業務ユーザが「設計書」に描かれた解決策で、自身の業務課題が本当に解決されるかを見極めることを意味します。二つ目は、SEやプログラマーが実際に製作したプログラム(情報システム)が、業務課題を解決するように挙動するか、実際に使ってみて確認することを意味します。

「上流工程」は、「下流工程」に何をやってもらうかを事前的に決め、実際に構築してもらった情報システムが意図した通りに製作されているか、事後的にチェックするものです。その中で、「要件定義」とは、情報システムに何をやってもらうか、整然と項目立てて決定すること、出来上がった情報システムがきちんと意図した通りに挙動するか、確認すべきチェックポイントが漏れなく設定すること、この2つを対象に作業されるものです。

ITの専門家に何を作ってもらうか、作ってもらったものが意図したものかどうか、それを決めるのが「要件定義」というお仕事なのです。

 

■ 「要件定義」をする人は、どこまでITのことを分かっている必要があるか?

極論を言ってしまうと、「要件定義」を担当する人は、「業務屋」さんが多いので、ITとか、情報システムの挙動やプログラミングの所作に明るい人ばかりではないと思います。あえて言う必要はないのかもしれませんが、筆者も「業務屋」上がりのコンサルタントなので、いわゆるコーディング(プログラミング)を自分の手でやったことはありませんし、実際にできません。ですので、どういう風にプログラムが書かれるのか、筆者の経験を踏まえても、知る必要はない、と断言します。そうでも言わないと、筆者のこれまでの20年は無意味なものになってしまうので。。。(^^;)

PM(基礎編)_テクノロジーの進化で変化するのは下流工程の方だ!

上図にあるように、情報システムというものは、そのテクノロジーの進化と共に、ツールも基本思想も、開発手法も多様化し、変容してきました。どうやって作るかは、IT専門家に思い切って任せても問題ありません。「モデル駆動アーキテクチャー:MDA」は一部には実用化されていて、自然言語で書かれた仕様書・設計書の類を読み込ませただけで、プログラムをコンピュータが自動で作成してくれます。これが昨今流行語になっているAI(人工知能)によって、「自己学習(自動学習)」機能により、プログラムバグ(狭義はコーデングミスだけ、広義では要求仕様未達成まで)までも自己修正・自己修復してくれるようになりました(なりつつあります)。

中には、「業務要件」整理も、「プログラム」設計もできてしまう器用な人、多芸な人が多くいらっしゃいます。しかし、そういう器用な人は、小規模なシステム開発プロジェクトならば重宝されるかもしれませんが、より大規模、よりクリティカルなシステム開発プロジェクトの場合、全くシステムのことを知らない人が「要件定義」を担当した方が、イイものができるという感覚が筆者にはあります。

中途半端にシステムのことを知ってしまうと、システムの限界を気にして、業務要件定義を考える際に、システム制約を頭がよぎり、本当にやるべき業務を諦めてしまうことがあるからです。また、業務要件定義はできるだけ、その業務を実際にやっている人、業務に精通している人を優先的にアサインした方が、明確で目的意識の高い業務要件定義が実施できます。いたずらに、システムにも造詣が深い人、という人選は避けた方がよいでしょう。自分自身の仕事がどうなるのか。その真剣度が「業務要件定義」の品質を決めることになりますので。

⇒「要件定義入門(2)要件定義というお仕事を縦横無尽にぶった斬る!

PM(基礎編)_要件定義入門(1)上流工程での基本的な立ち居振る舞いとは

コメント