とあるPJの立て直し: 開発体制について

　とあるプロジェクトの立て直しの記録に基づいて、プロジェクトマネジメントをテーマにシリーズで書き残したいと思います。今回は開発体制について触れていきたいと思います。

要旨

開発体制の状況

　本プロジェクトでの開発体制はプロジェクトマネージャー（以下、PM）が全体を見渡せる唯一の人でした。元々の開発体制の構造を表すと以下のようなパタンです。

　朝会をやっていたようですが、「各開発メンバーとPMの1on1」で行われていました¹。朝に1対1で数分程度、その日に何をやるのか作業を分担され、それが完了するまで日々帰れないような状況でした。朝に何を渡されるのか、それが本当に一日で終わるのか分からないため、開発メンバーはかなり疲弊していました。また、1on1で行われているため、隣の開発メンバーが何をやっているのか（同じシステムのことをやっているのか、そうでないのかすら）知らなかったそうです。

　開発メンバーは単なる作業員ではなく、価値を生み出す重要な存在です。あなたは金の卵を産むガチョウがいたらどうしますか？きっと大切にすると思います。

　このような体制からか、メンバーが入れ替わったことによりこのような体制になったのかは定かではありませんが、プロジェクトの初期段階から開発メンバーが全員入れ替わっており、「なぜそのような設計にしたのか」「どう動けば正解なのか」を知っているメンバーが残っておりませんでした。残っていた開発メンバーも全体像がわからないまま、渡される作業をこなしているような状況です。バベルの塔の逸話を思い出します。

　メンバーの入れ替わりが激しいようであれば、その点に疑問を持つべきです。人が居着く組織作りを目指しましょう。

　経験が浅いことそのものは問題ではありません。開発に対して必要なスキルセットを満たすチーム構成になっていないことが問題でした。チームで必要なスキルセットを満たしていないと、前回の品質の課題で触れたように設計の段階から品質の懸念が発生してきます。当然ながら品質の低い設計では、実装をするとさらに品質が下がっていきます。

　他の視点では、入れ替わった影響からか「ここが初めての現場です」という1年目のメンバーもいました。このような開発スタイルが一般的なものと思い育ってしまうと大変悲しいことです。

透明性を確保する

　チームを作るための第一歩は透明性の確保です。開発メンバーは自分が何を作っているのか全体像が見えていませんでした。顧客が何を作ろうとしているのかPMを通して渡される断片的な作業の積み重ねから全体像を想像するしかありませんでした。当然ながら顧客と会ったこともなく、（要件が固まっていなかった可能性はありますが、）全体的な要件も知りませんでした。チーム作りでは透明性はすべての基盤になります。これがない状態でチームはできません。

　経験の浅いうちは自分だけが情報を持っていると偉くなったような優越感を覚えてしまうかもしれませんが、情報は元来多くの人に行き渡り共有してこそ価値があります。秘匿しなければ価値が出ない情報にはあまり価値がありません。チーム内では必要以上に情報を分断しないことを意識するとよいでしょう。同じ情報を持っていると同じ判断ができるようになり、合意形成も円滑になります。

勉強会で育てる

　あなたがよいスクラムマスターであれば、マルチファンクショナルなチームを作るために必要な技能が欠けていれば勉強会を提案すると思います。勉強会やOJTでの教育が有効な手立てです。個人個人の技能を伸ばすとともに、チームとしての働き方についても教育していきます。

　このときの立て直しでは、私はすぐに強化すべき技術を中心に10以上の勉強会を実施していきました。以下に勉強会の一例を示します。

チームを作る

　情報を分断しないことも、勉強会をやることもチーム作りの一要素にすぎません。チームのためにできることは何でもやりましょう。勉強会を行い、チームを作り上げていくと、メンバー一人一人が活躍できるようになり成長してきます。そうなってくると、さらなる活躍の場を求めて旅立っていきます。これはチーム作りのよい傾向です。このときに市場全体で人材獲得の競争力を維持できるかどうかは組織次第です。