最近の企業システムについての相談は、単に「○○の機能がほしい」という要求ではなく、例えば「顧客からの問い合わせ対応のレベルを高めたい」とか、「トレーサビリティを確保したい」のようなビジネス的課題の表現で話が始まることが多い。

つまりは、当たり前のことをやるシステムはすでにあるのだが、求めているものは次の次元の話というわけである。そういう課題はつめてみると、業務の歴史的経緯や既存のシステムのさまざまな制約が絡まって面倒なことになっていたりするので、業務的な整理や改善と合わせてシステム的対応を考えなければ解決ははかれない。

こうした課題解決をはかるプロジェクトの企画プロセス(筆者らは、「要求開発」と呼んでいる)は、まさに道なき道で、「言われたものを言われたとおりに作ってきた」システム屋にはまず手が出せない。

ビジネス上の課題解決をはかるプロジェクトの企画プロセスは、道なき道を行くようなもの

かといって、業務にどんなに詳しいコンサルタントでも、システム開発の知識や経験がなければ、ITによる実現性が判断できないのでやはり現実解を出すことはできないだろう。世の中は業務知識の必要性が極端に強調されがちで、逆に技術を多少軽んじる流れを感じるが、ここは、システム開発にきちんと取り組んできた志あるエンジニアにも奮起いただき、業務の世界にも積極果敢に踏み込んで主役の座を確保してほしいところである。

この連載は、こうした課題にとりくむコンサルタント/エンジニアに対して、ユーザー要求を正しく導きだすためのヒントを6回にわたって提供していこうという試みである。トピックスとして以下の6点を予定している。

  1. シナリオをもって臨む
  2. 共通の目的意識をもつ
  3. ステークホルダーを正しくつかむ
  4. 脳裏にモデルをもって臨む
  5. ユーザー要求を鵜呑みにしない
  6. 合意の形成・同じ基準をもつ

ということで、初回は、「シナリオをもって臨む」というポイントである。

「とりあえず集まろう」は厳禁

さて、「この通りやれば間違いなく解決」というような都合のいいやり方があればいいのだが、先ほどあげたようなビジネス課題の解決をはかるITプロジェクトは、それぞれが個性豊かで、一本道があるわけではない。そもそもどこから手をつけていいかわからないし、最初に誰にアクセスしていいかもわからない。

そんな状況にあることから、「まずは関係しそうな人を広く集めて相談してみよう」というパターンにはまるようだ。しかし、何のシナリオもないままに、人を集めて、いきなり「どうしましょうか」で始めると、次から忙しい方々の協力は得られなくなってしまう。逆に、最初のところで、リズム感を演出して、関係者の信頼感を得ておくと、あとの展開はやりやすくなる。

一本道はないにしても、およそこうした検討を進めるときに明らかにしていかなければならないことや決めていくべきことなどはある程度一般化できる。筆者らが関わっている非営利団体の「要求開発アライアンス」では、こうした課題解決を伴うシステム企画に対して、参加メンバーらのベストプラクティスを集約して、「Openthology」という要求開発方法論を整備し、標準的な進め方を提供している。

それに従っていけば、曲がりなりにも必要な観点を網羅しながらシナリオに沿って検討を進めていくことができるというわけである。

システム開発のプロジェクトマネジメントは、建設業のプロジェクトのアナロジーで語られることが多いが、「対象が見えない」、「作るべきものが刻々変わっていく」、などの点でよりコントロールは難しく、失敗率も高い。ましてや、要求開発では、「システム」以上に見えない「要求」なるものを取り扱う。

システムのように着々とできあがる対象があるわけでもなく、進捗を動作で確認することもできない。また、業務絡みの要素が多い分、人間系の力学に影響を受けやすい。しっかりしたロジックをもとにした道標を頼りにしていかなければ、声の大きい方向に引っ張られて、簡単に迷走してしまう。

最初の1カ月はやること同じ - 迅速な立ち上げを

「シナリオをもって臨む」ことは、プロジェクトを通して重要ではあるが、特に筆者がその効果を感じるのは、プロジェクトのスタートダッシュのときである。

たいていのプロジェクトは、スタートしても最初の1カ月ぐらいは、どこから手をつけていいか決まらなかったり、メンバーの意識が定まらなかったりするために、まったりと時間が過ぎてしまうことが多い。プロジェクト末期の寸暇を惜しみ、深夜残業や休日出勤が余儀なくされるような状況を思えば、この時間の浪費はないがしろにできない。

手っ取り早くプロジェクトを立ち上げて、そのオーバーヘッドを解消すれば、結構なマージンが稼げるのである。幸い、プロジェクトの初期にやるべきことは、実はプロジェクトの個性にほとんど依存しない。

筆者はここのフェーズをプロジェクトインストールと呼んでいるが、方法論が示すような検討の流れ(図1)を踏襲すれば、すばやくプロジェクトの歯車をかみ合わせることができる。

図1: プロジェクト立ち上げ時の作業の流れ(クリックで拡大)

誌面の都合で、この場でプロセスの内容を詳しく説明はしないが、重要なのは、プロジェクトの中で、どういう順番に物事を検討していくのか、その際に具体的にやるべき活動は何か、それは誰とやるのか、といった段取りが事前に自分の脳裏にデザインされていことであり、かつ、可能な限り、それがプロジェクトのメンバーの間で共有されていることである。

日々がそのプロセスに従って進行し、今、全体の中のどこにあって、何を目的とする活動をしているのか、この作業の結果が次の検討のどこにつながるのか、次には何をするのか、といったところがつかめていれば、そのプロジェクトは非常に安定感をもつ。まちがっても真っ白なまま、プロジェクトの最初の一歩を踏み出してはならない。

次回は、そのプロジェクトインストールの最初にやるべき「プロジェクトの定義」について述べる予定である。