|
[2011 年 12 月号] |
［技術講座］
今月号では、OGIS Scalable Agile Methodの原点となった 3 つの事例を紹介するとともに局所最適なシステムの乱立を防ぐためのITガバナンスとアジャイル開発の関係について説明します。また、スクラムの理論的な背景となった「組織的知識創造」の概要を説明し、そのような「組織的知識創造」を阻害する要因とその克服方法について論じます。
オージス総研アジャイル開発白書とは、日本でのアジャイル開発の普及と活用を目指してアジャイル開発の基本概念からITガバナンスとの関係までに至る解説を行うものです。アジャイル開発白書は、3部構成になっています。
アジャイル開発白書第 1 部では、アジャイル宣言とアジャイル開発手法スクラムの概要を説明するとともに、ユーザ企業とITベンダーに分かれた日本の特殊な産業構造がアジャイル開発の普及の大きな障害になっていることを説明しています。さらに、ユーザ企業でのIT業務の全体最適を支援するための枠組みとしてエンタープライス統一プロセスの概要を説明し、ソフトウェア開発を改善し、ユーザ企業とITベンダーのより良い関係を築くためにプロジェクト測定を活用することを提案しています。
アジャイル開発白書第 2 部「OGIS Scalable Agile Methodの真髄」では、日本でのアジャイル開発の普及を阻む不安を取り上げ、その不安の解消方法としてアジャイル開発手法とプロジェクト測定の組み合わせを提案しています。提案された開発手法は、アジャイル開発手法スクラムと統一プロセス( UP )をアジャイル化したアジャイル UP に基づいています。また、プロジェクト測定は機能規模測定手法 COSMIC 法に基づいています。
当社では、1995 年に反復開発を取り入れた基幹系システム開発を皮切りに、以下のようなアジャイル開発と反復開発の適用を推進してきました。
反復開発もアジャイル開発も白書第 1 部で説明したように、一定の期間毎に動くコードを作成しながら開発を進める手法です。この両者は、一定の期間毎に動くコードを作ることで客観的に進捗が評価できたり、お客様のフィードバックを得ることができるという点で共通しています。
これら各時期の代表的な 3 つのプロジェクトの概要をまとめたものが表 1 です。
| Aプロジェクト | Bプロジェクト | Cプロジェクト | |
|---|---|---|---|
| 業種 | 製造業 | 製造業 | リクルート業 |
| 前提条件、動機 | 全世界の工場に展開できるソフトウェアを開発したい（技術的なリスク高） | メインフレームからオープン系の移行で、納期とコストを守って開発したい | 既存システムのドキュメントがないが、リリース日は厳守したい |
| チーム規模 | 20名程度 | 30名程度 | 10名程度 |
| 要求の不確定性 | 大 | 中 | 中 （仕様追加あり） |
| 契約 | 準委任 | 準委任 | 請負 機能規模で契約 |
| お客様 | 積極的な関与 | 積極的な関与 | 形よりも実質重視 |
| 開発結果 | 納期通りリリース | 納期通りリリース | 納期通りリリース |
| リリース後の状況 | 全世界の工場に展開 現在も稼働 | 従来よりも障害が少 現在も稼働 | 現在も稼働 |
これらのプロジェクトの結果からアジャイル開発や反復開発で以下のことが達成できたことが分かります。
これらのプロジェクトを成功させるために大きく影響した要因としては、以下のようなものを挙げることができます。
*: Aプロジェクトはテストの自動化を行っていません
これらのプロジェクトの経験をまとめたものが、オブジェクトの広場2011年9月号と10月号で説明したOGIS Scalable Agile Methodなのです。
今後アジャイル開発が普及する過程で、「かつての RAD (Rapid Application Development) の轍を踏まない」ことに注意する必要があります。つまり、「早く、安く、うまい」ことだけをよしとしていると、以下のような点に足を掬われる可能性があるということです。
誤解がないように言えば、現時点でもこれらの問題は存在します。そのため、これらは「アジャイル開発の普及」で新たに発生する問題ではありません。これらの問題のうちで B については、「OGIS Scalable Agile Methodの真髄」で説明した以下のような技術プラクティスを適用することで１つの開発プロジェクトのレベルでの低減を行うことが可能です。
しかし、B の問題の中には例えば「1 つの業務要求の変更が複数のシステムの変更に波及する」というように 1 つのプロジェクトという枠内では解決できないものもあります。このような問題や A のような問題を開発するためにはアジャイル開発であろうとなかろうと、 1 つのプロジェクトや 1 つの開発ライフサイクルを超えた観点で以下のことを考える必要があるのです。
つまり、現在のビジネスに勝つための手段としてアジャイル開発を活用する一方で企業の IT 業務の全体最適化を行うためのガバナンスも考えていく必要があるということです。より具体的には以下のようなことが必要になります。
アジャイル開発とも比較的整合する形で、このようなガバナンスを実現するためのフレームワークとして提案されたのが白書第 1 部で紹介したエンタープライズ統一プロセス（ EUP ） [1]です。また、企業システムのあるべき姿とその姿への移行シナリオを提案するものとして百年アーキテクチャ[2]があります。
エンタープライズ統一プロセスでは、経営戦略に基づいて企業全体で効率的に開発を行うために以下のようなエンタープライズ作業分野を設定しています。
プロジェクトの外でこれらの作業を行うことで、アジャイル開発で局所最適なソフトウェアを作ることを防ぎ、企業戦略に沿ったソフトウェアを開発することができます。（図 1 ）エンタープライズ統一プロセスの考え方は、「OGIS Scalable Agile Methodの真髄（前編）」で紹介したアジャイルUPのモデル作業分野のワークフローに組み込まれています。また、エンタープライズビジネスモデリング作業分野での具体的なモデリングの進め方については[3]や[4]が参考になります。
 |
エンタープライズ統一プロセスの書籍（原書）が刊行されたのが 2005 年でそれ以降にクラウドや仮想化のような新たな技術が登場したり、アジャイル開発やOSS (Open Source Software) の普及が大きく拡大しました。そのため、エンタープライズ統一プロセスにはこれらの技術やアジャイル開発やOSSを考慮していなかったり、考慮が足りなかったりするという点で不十分な面があるということに注意する必要があります。
百年アーキテクチャでは、A, B のような問題を「アーキテクチャ成熟度ステージ」という観点での成熟度の不足と捉えて、SOA（Service Oriented Architecture）、OSS、モデリングの活用により成熟度を向上させ、ビジネス上のニーズにより柔軟に対応できるような企業システムの実現を提案しています。このような方法を適用することで、エンタープライズ統一プロセスのエンタープライズアーキテクチャ作業分野の目指すべき大きな方向性を定めることができます。
アジャイル開発に「早く、安く、うまい」ことだけを期待すると、従来から存在した「局所最適なアプリケーションの乱立」などの問題が残るという点を見失いがちになります。そのような問題を解決するためには、エンタープライズ統一プロセスや百年アーキテクチャで提案されているような１つのプロジェクトや１つの開発ライフサイクルを超えた観点（ガバナンス）も必要になることを理解した方がよいでしょう。
白書第 1 部で紹介したスクラム[5]を生み出す理論的な背景となったのは、野中らの「組織的知識創造」[6]です。この「組織的知識創造」は、日本のメーカーがホームベーカリーや低価格コピー機などの画期的な製品開発の原動力となったものです。
 |
「組織的知識創造」は、日本の文化で重視されてきた言葉や文章で表現することが困難な「暗黙知」と西洋の文化で重視されてきた言葉や文章で表現できる「形式知」を相互に変換するSECIプロセスとそれを促進するコンテキストを土台としています。
SECIプロセスは図 2 のように図示され、以下の4 つの知識変換モードから構成されています。
| 共同化 | 経験を共有することで、メンタルモデルや技能などの暗黙知を創造する |
| 表出化 | 暗黙知をメタファー、アナロジー、仮説、モデルなどのコンセプト（形式知）に変換する |
| 連結化 | コンセプトを組み合わせて１つの知識体系を創り出す |
| 内面化 | 形式知を実践（具体化）してみて、それを追体験したり、実感することで暗黙知を生み出す |
また、SECIサイクルを促進するコンテキストとは以下のようなものです
このような「組織的知識創造」は、「競争力のある独創的な新製品（＝知識）を生み出す」という点で有効だったと言えるでしょう。
スクラムは、このような「組織的知識創造」の考え方を取り入れて、ソフトウェアに対するニーズ（要求）という暗黙知をソフトウェアプロダクトという形式知に変換することを中心に据えた開発手法と捉えることができます。また、スクラムで重視している「自己組織化」という組織のあり方は SECI サイクルを促進するコンテキストの「自律性」や「最小有効多様性」に基づいていると考えることができます。つまり、「役割分担」や「上からの指示」に基づく組織ではなく、チームに与えられた課題を解決するという共通の目標のために、メンバー１人１人が自律的に自分がなすべきことを考えるという組織です。
「組織的知識創造」に対して、スクラムで追加された特徴としては以下のようなものがあります。
前者はユーザニーズに即し、市場の変化に機敏に対応するために役立つものであり、後者はチームの開発能力を高めるために役立つものです。
スクラムがアジャイル開発手法として世界的に普及してきたという事実は、ビジネス競争力に役立つソフトウェアプロダクトを開発する上で「組織的知識創造」が有効だったことを示していると考えられます。
「組織的知識創造」を現在に活かすためには、「組織的知識創造」という概念が提案された1980年代と現在の間の状況の違いを理解する必要があります。1980年代までの日本の状況は、以下のように特徴づけられます。
このような背景の中で、独創的な新製品を考案し、それを高品質、低コストの優れた製造技術で生産したのが日本の製造業の大きな成功要因だったと考えられます。
そのような状況は過去20年間で以下のように変化をしました。
これらの変化は、欧米でもすでに起きていることなので避けがたいものと言えるかもしれません。この「さらなる競争の激化」は、欧米でのアジャイル開発普及の大きな原動力になっていると考えられます。
また、以下のような変化も生じたと考えられます。
このような「事なかれ主義」と「チャレンジと成長の場の減少」は、「組織的知識創造」を阻害するものであり、ひいては「新たな可能性（ビジネスチャンス）への挑戦」を困難にします。また、過去 20 年間のさらなる競争の激化により「ビジネスや技術の変化」のスピードが 20 年前よりも大幅に速まっています。そのような「ビジネスや技術の変化」のスピードアップにより「チャレンジと成長の場」は若手だけに必要なものではなく、ベテラン社員にも必要になっています。これらをこのまま放置すると、時代の変化に対応できなくなり、ビジネス競争から脱落していくことになります。また、これらは「IT業務」の革新を阻み、「アジャイル開発」の導入を阻むものでもあります。
厳しいビジネス競争で勝ち残るためには、「事なかれ主義」を排除し、若手とベテランの両方に「チャレンジと成長の場」を提供して「組織的知識創造」を活性化することが今後求められます。そのような取り組みを行う際に、「組織的知識創造」を具体化したものとしてスクラムのフレームワークを活用することができます。
近年、欧米ではアジャイル開発がプロジェクトレベルで使われるのは当たり前になりつつあり、企業全体のアジャイル化ということがホットな話題になりつつあります。そのような企業全体のアジャイル化を行う上で以下のような点が強調されています。
企業全体のアジャイル化を行う際には、現状の開発のやり方がマチマチの組織がスクラムやXPなどの書籍に書いてあるとおりの開発方法を一気に取り入れられる訳ではありません。現実的には現状の開発のやり方を少しずつアジャイル化していくことになります。このように段階的にはアジャイル化を行う際に、これらのアドバイスを念頭に置くことで大きな方向性を見失うことを防ぐことができるでしょう。
| © 2011 OGIS-RI Co., Ltd. |
|
