pr

米国のある調査では、ビジネス目標を達成していないプロジェクトは50%、納期が遅延しているプロジェクトに至っては90%と報告されている。この原因の1つに「要件定義」があるとするのが株式会社 豆蔵(以下、豆蔵)だ。同社は、このような問題の解決策として「要求開発」を提唱。その方法論の確立と実践を推進している。要求開発という方法論の確立による“情報化業務における業務の改革”を目指し、豆蔵に共感できる、ITエキスパートを求めている。


豆蔵からスカウトされて、ビジネスモデル・アーキテクトになる
記事で紹介している「ビジネスモデル・アーキテクト」として豆蔵に転職したい方、@IT自分戦略研究所がバックアップします。詳しくは記事の最後で。

  「要件定義」がプロジェクトの失敗を招く

 米国のある調査では、納品が遅延しているプロジェクトは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エキスパート

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

 そこで豆蔵では、コアメンバーとして、この事業を一緒に推進する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

注目企業インタビューIndex

株式会社 豆蔵
企画:アットマーク・アイティ 人財局
制作:アットマーク・アイティ 編集局

掲載内容有効期限:2004年8月31日

■豆蔵 関連記事リンク
連載:ITエンジニアとしての道を究めるには

真の技術を理解しエンジニアとして勝ち残れ!

プロジェクトマネージャならば理解しておこう

連載:初歩のUML(@IT)

いまなぜ開発プロセスを注目するのか?(@IT)

5分で絶対に分かるUML(@IT)

連載:HORBと遊ぼう(@IT)

■豆蔵 会社概要
本社 東京都新宿区四谷4-3
ケイアイ四谷ビル
設立 1999年11月11日
資本金 6億円
(資本準備金 4億円)
代表者 代表取締役社長CEO
萩原紀男
事業
内容
ソフト開発及び関連するコンポーネントの企画・開発、コンサルティング、教育など

■待遇
給与 年俸制(前給を考慮して決定)、昇給1回(10月)、交通費支給
※勤務年数ではなく、能力と実績によって評価し、年俸に反映。
勤務
時間
裁量労働制(1日8時間)
休日
休暇
完全週休2日(土・日)、祝祭日、年末年始、有給、慶弔
勤務地 四谷(地下鉄丸の内線 四谷三丁目駅)
福利
厚生
各種社会保険完備、育児・介護休業制度、財形貯蓄制度、従業員持株会制度、慶弔見舞金制度、資格取得奨励金制度

■募集要項

■ビジネスモデルアーキテクト
職務内容
業務構造や業務フローなどを分析、UMLなどを用いてモデル化し、IT化のプランニングを担当。システムとしての要求仕様を開発します。
応募資格
・システム開発における仕様策定や業務分析、要求管理などの経験
・オブジェクト指向分析・設計の経験
・データモデリング手法を理解していること
・お客さまへの提案活動ができること
歓迎する経験・スキル
・エンタープライズモデリングの経験
・業務コンサルティング経験
・BPRプロジェクトの経験
・DOAの適用経験
・プレゼンテーション能力

ソフトウェアアーキテクト
職務内容
フレームワーク、コンポーネント開発、反復型開発のお客さまへの導入支援にあたり、提案から導入までをリーダとして行います。実際の作業は、お客さま固有のニーズや特性をヒアリングし、導入への最適なソリューションを提案し実施します。
応募資格
・J2EE/Webシステムの開発経験
・中規模以上のシステムにおけるプロジェクトマネージャもしくは開発リーダの経験
・Strutsの利用経験
・オブジェクト指向分析・設計の開発経験
・反復型開発に関する知識
・お客さまへの提案活動ができること
歓迎する経験・スキル
・J2EEフレームワークの開発経験
・パッケージ製品開発経験
・データベース設計の経験
・反復型開発プロセスによる開発経験
・トレーニング講師の経験
・プレゼンテーション能力

プロセスコンサルタント
職務内容
オブジェクト指向による反復型開発のプロセスコンサルティング
・ソフトウェアのプロセス改善コンサル、CMMプロセス改善コンサルティング
応募資格
大・短・高専卒 ソフトウェアエンジニアとして、5年以上の経験を持つ方
歓迎する経験・スキル
・RUPまたはXPによる開発やCMM/CMMI適用の経験またはコンサルティング経験
・オブジェクト指向技術UMLによるモデリングの知識
・ソフトウェア開発経験(特に分析、アーキテクチャ設計、設計経験)が10年以上
・プロジェクトマネージャ/リーダ経験
・SPIの立ち上げ経験、トップへの提案経験
・アセスメント・リーダ経験
・SEPG経験
・プロセス(開発プロセス、管理プロセス)の設計・実装経験
・PMBOKなどModernPMに関する知見と実践経験
・各種ソフトウェア開発方法論/手法に関する知見と実践経験
・ソフトウェアエンジニアリング全般に関する知見
・コンピュータサイエンスに関する知見
・プロセスやソフトウェアウェアエンジニアリングに関する講師経験

組み込み系コンサルタント、アーキテクト、エンジニア
職務内容
複雑かつ大規模化してきている組み込み制御システム(携帯電話、カーナビ、複写機、プリンター、情報家電、FA機器等)の開発を、工学的なアプローチ(プロセス、マネジメント、オブジェクト指向技術等)で改善するために、コンサルタント/アーキテクト/開発エンジニアとしてお客さまを支援していただきます。
応募資格
組み込み系システムにおける開発・マネジメント経験を有する方で、C++(C)言語での開発経験、UML、オブジェクト指向の実践経験(研究プロジェクトでも可)があるエンジニア
・常に業務の課題を捉え、業務改善を推し進めることに興味を持つエンジニア
歓迎する経験・スキル
・組み込み系システムにおけるプロセス改善活動(例:CMM/CMMI適応、オブジェクト指向適応)を行った経
・10名規模以上のプロジェクトマネジメント経験
・中大規模開発のアーキテクチャ設計(マルチタスク設計中心に)経験