センタ長2018.10.31コピーしましたPRバトンリレー型の役割分担では、ムダな時間と認識の食い違いによる手戻りが発生する。コミュニケーションを重視して、チーム力を発揮できる少人数チームの体制にする。アジャイル開発のプラクティスを参考に、ムダのない効果的なプロジェクト体制の作り方を紹介する。今回のポイント仕様伝達のムダな時間や手戻りの発生を抑えるには、バトンリレー型の役割分担から脱却するのがよい。指示型の体制ではなく、チーム内のコミュニケーションを重視した自律的な少人数チームの体制にする。効果的な体制をつくるには、アジャイル開発手法のスクラムやFDD、DSDMの体制が参考になる。本連載は、ウォーターフォール型の開発プロセスにアジャイル開発のプラクティスを部分的に組み込み、プロジェクトに潜む様々なムダを排除する「ハイブリッドアジャイル」を提案している。今回は、システムエンジニアの立場から効果的な開発体制をつくる方法について解説する。体制のムダを認識する旧態依然のウォーターフォール型の開発体制や指示型の開発体制では、プロジェクトにムダな時間やコストが発生しがちだ。ウォーターフォール型の開発体制では、工程ごとで担当者が異なることが多い。そのため、工程終了時には次工程の担当者に仕様を伝達しなければならない。担当者間で認識に食い違いがあれば、手戻り作業が発生してムダな時間とコストが生じてしまう。指示型の開発体制ではメンバーが自律的に動けない。指示がなければメンバーは何もしないので、人的リソースがムダになる。このようなムダを減らすには、できる限りマルチな工程を1人で担当できるようにすること、自律的な開発チームを組織し、管理や改善を自らできるようにすること、の2つが重要である。1人のエンジニアが様々な工程を担当できれば、仕様を伝達する回数が少なくなるだろう。手戻りのリスクも軽減できるのでムダを省くことにつながる。これには人材の育成方法を変更しなければならない。実現するのは難しいと言える。自律的な開発チームでは、チームメンバーが開発に必要な役割をしっかりと認識し、自発的に動く。指示待ちのメンバーはいなくなり、人的リソースのムダを回避できる。人材育成と違い、自律型のチームづくりであれば、今すぐに取り組める。効果的な開発体制を整えるには、まずチームづくりから取り掛かることをお勧めしたい。チーム力を発揮できる体制を敷くどのようなチームづくりをすればよいのだろうか。ウォーターフォール型の体制と、自律性が求められるアジャイル開発の体制を比較し、チームづくりのポイントを確認する。図1は、ウォーターフォール型の開発体制とアジャイル開発のスクラム・オブ・スクラムズの体制を比較したものだ。スクラム・オブ・スクラムズは、中規模以上のプロジェクトで有効な開発手法である。図1●開発体制は似ている[画像のクリックで拡大表示]2つを見比べてみると、チームの体制はそれほど変わらないことが分かるだろう。「ステークホルダーとプロダクトオーナー」「プロジェクトマネジャーとグランドスクラムマスター」「チームリーダーとスクラムマスター」と呼び方は違うが、それぞれの役割に大きな違いはない。ステークホルダーやプロダクトオーナーは、プロジェクトに対する最終的な権限や責任を持つ。プロジェクトマネジャーとグランドスクラムマスターは、開発するシステムに必要なスケジュールや予算などを管理する。チームリーダーとスクラムマスターは、チーム(スクラム)のメンバーを統率して、チームとして最大限のパフォーマンスを発揮できるようにコントロールする。違いがあるとすれば、開発チームの人数だろう。アジャイル開発のスクラムでは、7人前後の少人数の自律的なチームで構成することが特徴だ。次に、作業工程への関わり方を確認する。図2上のようにウォーターフォール型の開発では、工程ごとに担当者が決められており、それぞれの工程は異なるエンジニアが担当することが多い。そのため、バトンリレーのように上流工程の担当者から下流工程の担当者へと作業を引き渡す。バトンリレーがスムーズに進めばよいが、往々にして作業を終えた担当者は別の作業に移ってしまう。製造工程を担当するプログラマが基本設計の担当者に仕様の確認をしたくても、既にプロジェクトからいなくなっていることもあるわけだ。図2●工程への関わり方[画像のクリックで拡大表示]一方、アジャイル開発では、イテレーションの中でウォーターフォール型の開発の各工程を同時に進行する。要件定義や設計、製造、テストのすべてのフェーズで常に同じ担当者がいる状態になる。そのため、ウォーターフォール型の開発とは違い、曖昧な仕様などはすぐに確認できるというわけだ。ウォーターフォール型の開発とアジャイル開発の違いは他にもある。それが、コミュニケーションパスだ。ウォーターフォール型の開発のプロジェクトは、プロジェクトマネジャーから各チームリーダーに指示が下り、チームリーダーから各チームのメンバーに伝達される。逆にメンバーからの報告は、メンバーからチ-ムリーダーに伝えられ、チームリーダーからプロジェクトマネジャーへと上がっていく(図3)。このようにウォーターフォール型の開発のコミュニケーションパスは、上下の流れになる。図3●コミュニケーションパスの違い[画像のクリックで拡大表示]一方のアジャイル開発では、上位スクラムチームの中で、グランドスクラムマスターとスクラムマスターがプロジェクト全体の情報を共有しながらプロジェクト全体をコントロールする。各スクラム内では、スクラムマスターがメンバーをまとめ、協力しながら開発を進めていく。各スクラム内では、メンバー同士が相互接続されたネットワーク型のようなコミュニケーションパスになるわけだ。ウォーターフォール型の開発では、上位者からの指示や前工程の担当者からの伝達による個人単位の担当作業になりがちだ。アジャイル開発では個人ではなくチームが一体となり、人とのつながりを重視して、各自コミュニケーションを取りながら開発を進めていく。ここまで説明したように、ウォーターフォール型の開発とアジャイル開発のチーム体制は似ている。チームの人数や作業工程への関わり方、コミュニケーションパスに大きな違いがあるわけだ。この記事は有料会員限定です「日経SYSTEMS」定期購読者もログインしてお読みいただけます。リリースまでの時間を短縮みずほ銀行システム統合、苦闘の19年史Amazonランキング書籍総合1位(2/11-13)!前代未聞の労力と巨費を投じたプロジェクト、2度の大規模システム障害を乗り越えどのように全面刷新したのか、全貌を解き明かす。現場の負担軽減を!医療界でのAWS活用法500万社が導入。このセミナ...SEのための「システム営業力」養成講座SEとして仕事をする方が、顧客や経営層に対する提案力や会話力を身につけるための講座です。情報銀行の成り立ち、事例、現状課題やその行方を網羅。経営戦略である以上、「会計」の知識やスキルが欠かせません。