チームによるアジャイルの事例

社内システム開発とアジャイル開発

　連載第1回では、アジャイル開発に注目する理由と、本連載での題材となる「SKIP」の紹介、そして筆者の所属する会社での、SKIP立ち上げ時期における少人数でのアジャイル開発の事例を紹介しました。連載第2回となる今回は、SKIPが社内にリリースされた後、全社の活動として認められた中での開発の事例を紹介します。いわゆる「保守開発」の段階と言えます。特に今回は、チームとしての開発の中でどのようなアジャイルな工夫をしたのかについて紹介します。

　前回は「要件定義」という段階で、「何をどうやって作るか」というのが全く見えない状況で、動くアプリケーションを作りながら、徐々にイメージを固めていった様子を紹介しました。試しながら改修や改善を繰り返して育てていき、企画開始から2ヶ月という早い段階でのリリースを実現しました。それが、2005年の12月のことでした。

　その最初のリリースの後、口コミで徐々に社内のユーザーを増やしていき、また、増えたユーザーからの要望やニーズをくみ取りながら改修を繰り返して・・・という、良いサイクルで進んでいきました。その後、経営陣からの正式な承認をもらい、公式に社内システムとしての運用と保守の体制を作ることができました。

　それまで筆者は、システムインテグレータやITベンダーとして、プロジェクト体制でお客さまのためのシステムを構築して納品するという形でしか、ソフトウエア開発に携わっていなかったのですが、SKIPの社内展開については、お客さまのためというのではなく、自社の社員が利用するソフトウエアを開発するという、一般的には「情報システム部」と呼ばれるような立場を経験することができました。そこで得た知見から、私の考える、内部の立場からの「社内システム開発」の特徴は以下になります。

・プロジェクト型で作って終わりではなく、使われ続ける限り保守も続く
・与えられたミッションは、システムやソフトウエアの完成ではない
・生産性の向上は、明確にコスト削減につながる（人月計算をしていない）
・新しい技術を使った価値のある機能の実現はユーザーの満足度を向上する

　ここで挙げた特徴は、連載第1回（http://thinkit.co.jp/article/906/1）で紹介した、アプリケーションサービス企業での開発の特徴とよく似ています。そこに共通するのは、納品のために開発をしているのではない、という点です。つまり、社内システムも結局は、社内のユーザーに対してサービスを提供していると言えるのです。そうであれば、社内システムを内製の形で保守開発をする場面には、アジャイル開発がうまくマッチするのは当然かもしれません。

チーム開発におけるアジャイル開発の実践と工夫

　SKIPが社内で正式に承認されてからは、人もアサインされてチームで開発にあたることになりました。チームで開発する際に、マネジメント上で最も気をつけなければいけないのは、チーム内のコミュニケーションです。人数が2人から3人に増えるだけでも、コミュニケーションの経路は3倍に増えてしまいます。参加人数が多くなればなるほど、比例してコミュニケーションにかかるコストが増大してしまうのです（図1）。

　アジャイル開発では、チームの内外でコミュニケーションを非常に重視します。例えば、多くのドキュメントを残す代わりに、開発者同士のコミュニケーションで補完しあうことで、高い生産性を実現しています。では、チームの人数が増えて、コミュニケーションの経路が増えた場合にも、コミュニケーションの量を多くとれば多いほどいい・・・という訳ではありませんね。

　逆に、アジャイル開発ではコミュニケーションを重視するが故に、なるべく無駄の少ない効率的なコミュニケーションを心がけるようにしています。そのためには、開発者同士の自主性に任せるだけでなく、仕組みや場を用意する必要があります。

　今回は、SKIPを社内システムとして運用・保守開発をしていく中で、チーム内外のコミュニケーションや情報の共有を行う上で工夫した点などを、アジャイル開発の事例として紹介します。