前編では統一プロセスとアジャイル開発をベースにした新たな開発手法であるシンプレクス流「大規模開発手法」の3つのポイント(1)チームビルディング、(2)開発プロセス、(3)アーキテクチャのサマリーをお伝えした。今回の後編では、(1)チームビルディングと(2)開発プロセスの具体的な手法について説明していきたいと思う。
大規模開発でのプロジェクトマネージャーの役割で最も重要なことは、プロジェクトメンバー全員を同じ目標に向かわせ、各メンバーが主体的に行動できる自立型チームをつくりあげることにある。そのためには、プロジェクトメンバー全員に大規模開発は個人戦ではなく団体戦であることを認識してもらうことが重要であり、これこそがチームビルディングの目的である。そして、チームとしてプロジェクトを進めるためのルールが開発プロセスである。では、具体的な手法のポイントを挙げていこう。
大規模開発はプロジェクト期間が長いため、緊張感が続かず達成感も得づらい。この問題への対処として1ヵ月毎にイテレーションを区切って開発を行う。こうすることで常に締め切りが1ヶ月毎に来るため、程よい緊張感と達成感を得ることができる。この1ヵ月のイテレーションで重要なのが、「中途半端な成果物を残さない」ことである。例えば、ある機能についてプログラミングが50%しか終わっておらず、正常に動作しないような成果物のことである。こういった中途半端な状態を許すと、達成感が得られずダラダラと進捗が遅れていく。こういった状況を避けるためにはイテレーションの進め方が重要になってくる。
各イテレーションの最初に、そのイテレーションの計画を作成するが、ここでポイントになるのは各タスクにバッファーを設けずに見積を行い本来の〆切である月末から1週間前に完了するように予定を立てることである。これは、バッファーは各タスクではなく、最終週にまとめて確保するということである。この計画をバーンダウンチャートで表現し進捗管理を行う。具体的な手順は、最初に最終日ギリギリに終わる線(限界線)を引く。次に1週間前を完了予定とした線(予定線)を引く。そして、進捗を日々入力していき現在地点をプロットする。予定より遅れていても現在地点が限界線より下にある場合(下図の「問題なし」の領域)はバッファー内に収まる想定であるため、予定より遅延していても問題なしとする。
上記のようなバーンダウンチャートはサブチーム単位で作成する。ここで重要なのが最終週のバッファーは個人ではなくチームに割り当てているということである。チームのバッファーとは、1人が予定通りに終わることで、最後の1週間は他のメンバーを助けることができるということを意味する。これは、プロジェクトチーム全体にも該当し、いずれかのチームが予定通りに終われば、終わっていないチームを助けることができる。こうして、プロジェクトチーム全体で助け合い「中途半端な成果物」を残さないようにイテレーションを戦い抜く文化を作り上げていくことができる。
イテレーションの中間点で必ず行うのが、ドラフト会議と呼んでいるチームリーダーで行うミーティングである。ここでは各チームから予定通りに終わりそうなメンバーの名前を出してもらい、遅れているチームは誰がほしいか指名して、チームメンバーを入れ替える。イテレーション終盤でもドラフト会議を行い、最後はプロジェクトチーム全体がシャッフルされた状態になっていることもある。こうすることによりチーム間の壁をなくし、プロジェクトチーム全体で目標を達成する意識がでてくる。
イテレーションが終わると必ずふりかえりミーティングを開催し、課題の洗い出しや解決策の検討を行う。ここで重要なのは、リーダが解決策を指示するのではなく、メンバー全員で解決策を考えることである。自分たちで考えた解決策は必ず実行され、イテレーションを重ねる毎にプロセスが改善されていく。すると、後半戦になればなるほど品質や生産性が上がってくる。
エラー発生時の原因究明のコツ、開発時にやってしまいがちなミスといったTIPSの共有は非常に重要である。しかし、TIPSの共有は頭ごなしに「TIPSを共有しなさい」と指示しても効果ない。これは常にTIPSは共有するものだという意識を啓蒙していくことが重要となる。例えば、レビューの場で問題点を発見した場合に「他のメンバーにも共有しておいて」だとか「他に同様のミスしているメンバーはいないか?」などの指摘を常に行うことによって、各メンバーにTIPSを共有する意識が浸透する。意識が浸透すると何も言わなくても各メンバーが自発的に共有を行うため、同じミスを限りなくゼロにできる。極端な話をすると、40人のチームであれば1人がミスを共有することで残り39人のミスを防ぐことができる。
大規模開発では、開発期間が長いためメンバーの教育を計画に入れることで品質・生産性の向上が見込める。例えば開発者であれば、レビュアーがメンバーのソースコードレビューを行う際にペアプログラミングという形式でレビューを行う。メンバーの目の前でコードを解説しながら直していくと、目の前でコードの品質が上がっていく過程が見えるため効果が高い。理解の早いメンバーはプロジェクト途中から品質・生産性が向上し、教育側にまわるようになる。
手法の各論をご紹介したが、上記を習慣化することで、チームに結束力が生まれ、メンバー1人ひとりが主体的に行動できるようになり、開発後半になればなるほど時間に余裕ができる。実際、この開発手法を用いた大証FXのプロジェクトではメンバーの平均残業時間は月30h~40h程度で収まった。さらにこういったチームでは、次のプロジェクトにもノウハウが継承され、さらに生産性が向上する。現在のプロジェクトでは、前回と比べ1人当りの生産性は約1.5~2倍となっている。
また、大規模開発の特徴として優秀なメンバーだけでチームを作ることはできないという点がある。大勢の優秀なメンバーを集めることができないとしたら、プロジェクトの中でチーム力を上げることでしか品質・生産性を上げる方法はない。そのための手法が、シンプレクス流「大規模開発手法」である。しかし、本当に大事なのは、手法を使うこと自体が目的ではなく、プロジェクトメンバー相互の信頼関係を構築しプロジェクトを成功に導くことである。マネージャーは、手法を上手く使いチームとして苦楽を共にし達成感を得ることができる仕組みを構築し、1人ひとりを教育して成長へと導いていかなければならない。そして、1人ひとりが強くなり、自立型チームのメンバーとして行動できるようになることは、会社が強くなることにもつながる。最終的にメンバー全員がいい顔をして楽しく開発に携わることができれば、そのプロジェクトは必ず上手くいくだろう。
株式会社シンプレクス・コンサルティング
小松哲平
1999年大学卒業後、国内メーカー系SIにSEとして入社し、販売物流システムの開発を経験。2002年、大手ユーザー系SIに転職。アーキテクトとして金融系基幹システムのDB設計やフレームワーク開発に携わる。2005年、ITコンサルティング企業へ。コンサルタントとして開発プロセス導入のコンサルティングや会計システムの要件定義コンサルティングで実績を残す。2008年1月より当社。大証FXの清算決済サブシステムのリーダーを担い、「大規模開発手法」を構築。現在、PMとして次世代インターネット取引システムプロジェクトの指揮を執る。