pr

　米国のある調査では、納品が遅延しているプロジェクトは90％、完成前にキャンセルになるプロジェクトは30％に及ぶという。また別の調査では、予算オーバーで納品されるプロジェクトおよびビジネス目標を達成していないプロジェクトはそれぞれ50％と報告されている。

プロフィール 株式会社豆蔵 代表取締役副社長 山岸 耕二氏 京都大学工学部修士課程卒業後、1982年シャープ株式会社に入社、超LSI研究所で次世代デバイスの研究開発に従事。その後オージス総研を経て、2001年ウルシステムズに入社。以後一貫してオブジェクト指向技術をベースとしたシステム開発やビジネスの創出に携わる。2004年より豆蔵に入社、現職で豆蔵のビジネスを統括する。

　「頭の中にモヤモヤとある業務のプロセスから要件を定義してシステムを設計し、そのまま構築してしまうことが機能しないシステムができあがってしまう最大の要因です」と話すのは豆蔵の山岸耕二代表取締役副社長だ。

　現状のシステム開発を思い出してみてほしい。まずユーザーに業務プロセスをヒアリングし、新しいシステムの要件定義を行い、システムを設計する。このとき、その業務プロセスが本当に最適なのかどうかの検証が行われているだろうか……。

　山岸氏は、「モヤモヤと考えている要件のプロセスをシステマティックでない方法で定義してしまうことで、システムとしては正常に機能しても、作るべきものをまったく間違っていることもあるのです」と話す。例えば、業務の効率向上を目的にシステムを開発したとしよう。仕様どおりに、予算内に期日どおりにシステムがカットオーバーしたとしても、業務効率が目標値よりも向上しなければ、それは失敗プロジェクトといえる。間違ったシステムを正しく構築しても失敗なのだ。

　「システム開発自体の失敗。目的を達し得ないシステム。どちらにせよ、ROI（投資利益率）が上がらないこと＝失敗に変わりはありません」（山岸氏）

　どちらのケースの失敗にしても、主要因は“あいまいな要件定義”にあることが多い。それでは、どのように要件定義を行えばプロジェクトは失敗しないのだろうか。その答えが、豆蔵が推進する「要求開発」だ。“要件定義”と“要求開発”、一見あまり違いが感じられないこの2つの言葉には、実は大きな違いがある。「要件は定義するものではなく、要件として開発するものです」（山岸氏）というのが豆蔵の考え方。

　そもそもシステム開発の出発点は、「ビジネスの中に生まれる要件をいかにシステム化するか」ということに尽きる。しかし“要件”とは必要な条件であり、当面のゴールでしかない。当面のゴールだけを定め、とりあえずスタートしてしまうためにプロジェクトは迷走する。そこで、スタートからゴールまでの道順を示す地図を作成する。この地図を開発する作業こそが豆蔵のいう“要求開発”なのだ。

　「要求開発とは、モヤモヤとした業務プロセスを、ロジカルにすること。これにより、いかにシステム化するかが明確に見えてくるのです。つまり、要求開発とシステム開発の両方を合わせて、初めて情報化といえるのです」（山岸氏）

図1　豆蔵が推進する情報化の考え方

　では、いかに要求開発を行っていくのか。豆蔵の萩本順三取締役は、「システム開発において、さまざまな方法論が必要なように、要求開発にも何らかの方法論が必要になります」と話す。現在では、あいまいに行われることが多いこの分野だが、豆蔵では方法論の確立に向けた着実な取り組みを実施している。

プロフィール 株式会社豆蔵 取締役 萩本 順三氏 Steve Jobsに憧れ、NEXT Cubeを借金して買い込み、インターフェイスビルダというオブジェクト指向開発環境を使って驚いた経験を持つ。オブジェクト指向は、今後のソフトウェア開発の主流になると考え、オブジェクト指向言語を独学で学び始める。学び始めのころは誰よりもオブジェクト指向技術に疑いを抱いていて、特に継承の効用については、納得できるまで5カ月ほど要したという。その後2年ほどでオブジェクト指向を習得しているうちに、いつの間にかオブジェクト指向の虜となり、現在に至る。

　「根本にあるのは、経営上の問題をIT化によりいかに解決できるかということです」（萩本氏）

　そこで豆蔵では、独自に開発した要求開発における方法論を既に試行的に展開している。その方法論のベースになるのは、山岸氏のほかユーザー企業やシステム・インテグレータ、コンサルティング企業などのメンバーなどが主宰する「ビジネス・プロジェクト・モデリング研究会」と呼ばれる団体だ。

　ビジネス・プロジェクト・モデリング研究会では、システム開発における「ラショナル統一プロセス」（RUP：Rational Unified Process）のような、要求開発のための方法論を体系化している。RUPとは米ラショナル・ソフトウェア（現IBM）が提唱する開発方法論で、オブジェクト指向とUML（統一モデリング言語）をベースに、ソフトウェアを「どのように開発するか」を規定している。ビジネスモデリング、要求定義、分析・設計、実装、テスト、導入といった開発ライフサイクルを包括的にカバーする知識ベースやガイドラインを提供する。「このとき、モデリングしたメタデータをRUPと共通化することで、要求開発からシステム開発までを一貫した方法論で実現することが可能になります」と山岸氏は話す。

　こうして要求開発の方法論が体系化されることにより、ユーザーの要求を明確にし、後戻りの少ないシステム開発が可能となる。この開発現場全体の支援により、コストの超過や納期の遅延、ユーザーの要求にそぐわないシステムの実現など、システム開発における課題を克服することができるという。

　「このような方法論は、すでに実際の開発現場で実証しながら体系化を進めています」（萩本氏）

　一方、「情報化においては、業務全体の流れをとらえ、その一部にシステムがあるということを理解しておくべきです。システム化だけを考えるのではなく、人間が行う業務も含めて最適な業務の全体像を考える。システム化で改善できる業務と、システム化だけでは改善できない業務があるのです」と萩本氏は語る。このシステム化だけでは改善できない部分が重要であり、これを十分に理解しておかないとシステム化の成功は望めない。ROIの低いシステムを作ってしまう原因の多くはこの視点を欠くことにあるだろう。

図2　「要求開発」による情報化推進の流れ

　ここで有効な手段となるのが、オブジェクト指向の考え方だ。オブジェクト指向により業務プロセスを視覚化することで、システム化すべき部分と人間が行う業務で改善すべき部分を明確にすることが可能になる。オブジェクト指向はシステム開発だけに有効なわけではないのだ。

　そのためにどうするか。山岸氏は、「情報化にかわるすべての人に要求開発に参加していただきます」という。つまりユーザー自身が、要求を開発できるようにコンサルティングするのだ。まず、情報システム部門と業務部門からプロジェクトメンバーを選出し、いわばスワットチームを編成する。スワットチームには、オブジェクト指向とUMLを講義するという徹底ぶりだ。

　スワットチームはさらに、業務と開発をコントロールするチーム、ビジネスモデリングを行うチーム、プロトタイピングを行うチームの3つに分け、まず業務と開発をコントロールするチームで業務の理解、問題の洗い出しを行っていく。

図3　プロジェクト体制

　次に、ビジネスモデリングを行うチームで業務の問題点をいかに解決するかというポリシーを決定し、プロトタイピングチームがシステム化を行っていく。この手法における最大のポイントは、各段階で成果を明確にすることだ。「ゴールを明確にし、それぞれのゴールで成果を上げることで次のステップに進む。この繰り返しがシステム開発の成功の近道なのです」と山岸氏。抽出された業務上の問題点を、システム化で解決できる範囲／できない範囲に分け、解決できる部分についてはシステム開発のフェイズに移行する。これによって、真にユーザーが求めるシステムを手戻りなく開発できるわけだ。

　また、顧客のシステム化に対するモチベーションを高め、とことん顧客をシステム化に巻き込んでいくことも重要だ。顧客自身に、システム化が自分たちのためであることを理解させることで、業務の視覚化が容易になり、システム化に向けたより戦略的なコンセプトを迅速に導き出すことが可能になる。

「このとき、経営者、各リーダー、一般社員、品質管理チーム、契約社員／派遣社員など、さまざまな立場からの視点を、いかにバランスよく巻き込んでいけるかが重要になります」（萩本氏）

　萩本氏はすでに、いくつかの企業の情報化プロジェクトを推進しているが、想定外の成果も上がっているという。「スワットチームのメンバーは、自分の業務をビジネスの視点からとらえることができるようになり、業務に対するモチベーションが高まるという効用があります。プロジェクト開始当初と終了時点では、顔つきが明らかに違います（笑）」

　今後、豆蔵では、要求開発という方法論の確立による“情報化業務における業務改革”を支援する事業を拡大する方針という。例えば、建築業界では、施工業者が設計を行うことはない。一級建築士の資格を持つアーキテクト（建築技師）が設計し、施工業者が工事を行う。今後は、情報化業務においてもこのような分業が必要になると豆蔵では考えている。豆蔵が目指すのは、まさに情報化業務における一級建築事務所なのだ。

　そこで豆蔵では、コアメンバーとして、この事業を一緒に推進するITエキスパートを募集している。豆蔵では、「ビジネスモデル・アーキテクト」と呼んでいる。では、このビジネスモデル・アーキテクトに必要な能力とはどんなものなのだろうか？

　「プロジェクトマネージャとして、リスク管理やスケジュール管理をこなしてきたという実績は当然必要になります。ただ、そうした能力を持ち『与えられたものをこなす』だけでは不十分。見えない“要求”を見いだし、さらにほかの人にもそれを見えるようにできる能力が必要です。そのために最も必要なのは、コミュニケーション能力といえるでしょう」（山岸氏）。

　業務改革を支援するといっても、その顧客企業の業務に最初から精通している必要はないそうだ。「実際に業務を担当している方以上に業務を理解できることなどできません」（山岸氏）。豆蔵の仕事は、顧客自身が「自分の仕事を視覚化して人に説明できる」「改善できるポイントを導き出せる」ように支援することなのだ。そのために必要な能力は、ファシリテーション能力（支援推進能力）だという。

　そして、システム開発フェイズに移行した際には、当然技術力が必要となる。しかし、表層的な技術力ではないという。「システムで可能な範囲は何か、システムにおける制約は何か、開発した要求を実現するには、どんな技術が最適かを判断するために必要な、情報システムの根本を理解しているという意味での技術力です」（萩本氏）。

　山岸氏はさらに、「要求開発のような分野は、健全に育てることが重要です。SIがシステム開発の中の1サービスとして要件定義をやっていては何も変わりません」と話す。「とにかく頑張って“何かを変えていくのだ”という強い信念が最も重要です。新しい分野を開拓していくというマインドを持った方とぜひ一緒に働きたいと思います」（山岸氏）。

豆蔵からスカウトされて、 「ビジネスモデル・アーキテクト」として活躍する！ 「豆蔵に転職して、ビジネスモデル・アーキテクトとして活躍したい」とご希望の方を＠IT自分戦略研究所がバックアップします。 Step1 スカウト可能性セルフチェック ↓ Step2 匿名でスカウトをリクエストする ↓ Step3 豆蔵からスカウトされて、転職！ Step1 スカウト可能性セルフチェック ビジネスモデル・アーキテクトとしてスカウトされる可能性を10問でチェック Q1. プロジェクトマネジメント経験は5年以上ある Yes／No Q2. 会議の議長を務めるのは得意だし、好きだ Yes／No Q3. 顧客の喜ぶ顔が何よりの報酬だ Yes／No Q4. UML2.0の仕様は、英語で一通り目を通した Yes／No Q5. エンジニアである前にビジネスマンでありたい Yes／No Q6. オブジェクト指向分析設計の経験がある Yes／No Q7. 自社、顧客の開発プロセス改善の経験がある Yes／No Q8. 顧客の要求を汲み取るのが得意だ Yes／No Q9. 自分は即戦力として通用する Yes／No Q10. Java、C++を使った基幹業務の開発経験がある Yes／No 【診断結果】 Yesが6〜10個の方 豆蔵での活躍が期待できます。ぜひスカウトをリクエストしてください。→Step2へ Yesが3〜5個の方 今後伸びる余地があります。頑張ってください。 Yesが3個未満の方 残念ながら、豆蔵の要求には達していません Step2 匿名でスカウトをリクエスト ＠IT自分戦略研究所を経由して、豆蔵にスカウトをリクエスト リクエストシート（Excelファイル）をダウンロード ※ボタンを右クリックして「対象をファイルに保存」 （1）必須事項を入力して、＠IT自分戦略研究所にメール添付で送信 　　　メールアドレス：jobagent@atmarkit.co.jp （件名：「豆蔵スカウト希望」） 　　　※リクエストシートの代わりに、職務経歴書をお送りいただいても結構です （2）＠IT自分戦略研究所から豆蔵へ、氏名・メールアドレスを隠して提出 　　　個人を特定されずに、スカウトのリクエストができます （3）豆蔵からの返事を＠IT自分戦略研究所から転送 　　　→返事が「ぜひお会いしたい」なら、Step3へ Step3 豆蔵からのスカウトを受ける ご本人了解のうえ、豆蔵に氏名と連絡先を通知します。豆蔵からの連絡をお待ちください。 ※本サービスで知り得た個人情報は、本サービス以外には利用いたしません。個人情報の取り扱いについての詳細は「プライバシーポリシー」をご参照ください。 ※本サービスへのお問い合わせは、以下メールアドレスにお送りください。 　 メールアドレス：jobagent@atmarkit.co.jp

株式会社 豆蔵
企画：アットマーク・アイティ 人財局
制作：アットマーク・アイティ 編集局
掲載内容有効期限：2004年8月31日