企業では、ビジネス競争に打ち勝つための、ITの有効活用を目指したプロジェクトが企画され、システム開発を発注、もしくは社内でのシステム構築が行われています。このプロジェクト企画の良し悪しがIT投資の成果に大きく影響することになります。
ところが、システム開発の手法は様々に存在しますが、この「プロジェクト企画」の段階を効率よく最適に行う手法がなく、場当たり的なことも多くあります。
たとえば、ビジネスを企画するプロジェクトの運営に事務局しかなく、会議は空中戦、いつのまにか戦略が企画化されることも多いものです。
また外部コンサルタントを入れても自社のビジネス特性や文化と合った戦略は示せず、どう事業を回せばいいのか、どのようにビジネスの行動計画に落とし込み、必要であればシステム企画・開発につなげればよいのか分からないという状況に陥ることも多いでしょう。
このような状況になると、元々ビジネスを活性化・改革・企画するためのプロジェクトが存在するはずが、プロジェクトとしての体をなさないまま、各部門が勝手な考えで業務開発を行ったり、ＩＴベンダーにシステムを発注してしまうことにつながっており、その結果ビジネスチャンスを見逃し、莫大な労力の損失につながっているのです。
まずは、ビジネス戦略を見える化し、参加者で戦略を指さししつつ、ビジネス企画・開発をプロジェクトとして進めていく方法が必要です。
また、その中で必要最低限のシステム開発を行います。
ところが、現状では、ビジネス企画の行動が伴わないまま、システム開発を企画・開発してしまうことが多いのです。
このことを１本の木に例えると、木を育てず、枝や葉を形づけようとしていることとなってしまいます。
図 ビジネスの木
本来のビジネスとしてのデザインを見失ってしまったビジネスの木は、継続的な成長はできません。場当たり的なシステム開発は、その場限りの利便性を高めても、企業の不良財産を増やすばかりで、ビジネス上の優位性を保つことはできないのです。
これまでは、システム開発段階においても多くの問題がありました。
システム開発においては、実際のアプリケーションができてきた時点で、システムやプロジェクト企画の問題に気付かれることが多いのではないでしょうか。
このように従来の開発では、本当に必要な価値のある要求を実現しているのだろうか。あるいは、業務オペレーションに必要とされるシステムなのだろうか、という問いに答えるのはすべての開発を終えてからということになり、適切なリスクマネジメントが働かないという問題があります。
さらに、現在のビジネスでは、戦略立案から、スピーディな実行と変更への対処が何よりも求められますが、システム開発は長期間となり、その間にビジネスの要求が変化してしまうことも少なくありません。また、動きの速いビジネスシーンでは半年や１年後に間違いに気づいて方向修正しても市場は待ってくれません。
図 システム開発
匠メソッドでは、ここまでにあげたプロジェクト企画の課題やシステム開発の課題に対して、用途別に「匠メソッド 要求開発プロセス」「改良型ウォータフォールプロセス」「ビジネスアジャイルプロセス」を提供しています。
| タイプ | 特徴 | ビジネス企画・開発段階 | システム開発段階 |
|---|---|---|---|
| 契約主導型ビジネス開発（システム開発含む） | システム開発を他社に発注することを前提とした開発スタイルに適合。基幹系・バックエンド開発などに向いている。 |
匠メソッド 要求開発プロセス （特徴）要求開発方法論(Openthology 2.0)をベースに、さらに分かりやすく解説。また、匠メソッド独自のコンセプトにより改良を行ったビジネス企画・開発プロセス。このプロセスをカスタマイズすることにより、事業企画・改革プロセス、サービス開発プロセスなどの作成も可能。 |
改良型ウォーターフォールプロセス （特徴）受発注契約がやりやすいウォータフォール開発の特徴を残し、検証された要求と検証されたアーキテクチャを獲得するというリスクマネジメントを導入。さらに現代の開発にそぐわない詳細ドキュメントなどの廃止を行ったプロセス。実質的には、契約主導の反復型開発としてウォータフォール開発をブラッシュアップしたもの。 |
| 価値優先型ビジネス開発（システム開発含む） | ユーザ企業のビジネス開発プロジェクトの中に、システム開発チームを融合し、ビジネス価値を高めるためのスピーディなビジネス企画、開発を行う。 |
ビジネスアジャイルプロセス （特徴）要求開発プロセスのサブセットをプロセスとして導入し、ビジネス戦略、プロジェクト戦略の方向性をきめつつビジネスをアジャイルに企画・開発を行う。その際にIT開発が必要とされる場合はアジャイル開発チームを参加させることで、ToBeビジネスの結果イメージをできるだけ早く獲得したり、必要なビジネスコンポーネントはその場で試作し開発リリースを行う。 |
|
契約主導型ビジネス開発は、従来の要求開発方法論(Openthology)をベースとして、より分かりやすく、より現実的に回せるよう説明を加えた「匠メソッド 要求開発プロセス」と「改良型ウォータフォールプロセス」をセットとして利用するもので、従来型のユーザ企業が開発企業に請負契約として発注する形態の開発で使用するものです。
それに比べて価値主導型ビジネス開発は、ユーザ企業のビジネス価値を最大化するための企業活動の中にシステム開発を入れ込んだものとなっています。
この両者をうまく使いこなすことで、目的に応じたビジネス開発（システム開発）ができるようにすることを目指します。
