旧態依然とした開発現場では、チームメンバーの主体性は乏しい。チームモチベーションを向上するには、自発的に決定できる職場にする。アジャイル開発のプラクティスを参考にチームモチベーションの向上方法を紹介する。

今回のポイント
  • 高い生産性を出したり、満足度の高いシステムを構築したりするには、自律型のチームにしなければならない。

  • 個人の能力に頼るのではなく、メンバーが助けあって開発できる環境を整える。

  • 主体性を引き出すには、「少人数チーム」「短い反復」「イテレーション計画」「デイリースタンドアップミーティング」「レトロスペクティブ」というプラクティスが有効である。

 本連載は、ウォーターフォール型の開発プロセスにアジャイル開発のプラクティスを部分的に組み込み、プロジェクトに潜む様々なムダを排除する「ハイブリッドアジャイル」を提案している。今回は、システムエンジニアの立場から、アジャイル開発のプラクティスを参考にして、開発チームメンバーの主体性を引き出す方法を解説する。

チームに主体性がないのは分業体制が原因

 連載の第1回で、開発プロセスの改革について説明した。その中で、改革の本質は「ムダをなくすこと」と紹介したのを覚えているだろうか。

 プロジェクトには様々なムダが潜んでいる。その最たる例は開発チームのメンバーに主体性がなく、指示待ち状態の人ばかりになってしまうことだ。このような状態では、指示がなければメンバーは何もしない。結果として、人的リソースがムダになってしまう。

 ウォーターフォール型の開発では、工程ごとに担当者を変えて、役割を分担していることも多い。仕様はドキュメントベースで上流工程から下流工程に伝達される。要件定義の担当者から設計者へ、設計者からプログラマへといった具合だ。このような開発工程では、必要事項がドキュメントとして渡されるので、コミュニケーション力はそれほど問われない。

 また、ウォーターフォール型の開発では、前工程のドキュメントが完成してから次工程が開始される。開発工程の上流から下流へとバトンリレーのように作業が流れるのだ。すると、下流工程のエンジニアは上流工程の成果物に合わせて開発するだけになる。その結果、図1のような受け身の姿勢になってしまい、指示待ちのメンバーが増えてしまう。

図1●受け身の姿勢ではモチベーションは上がらない
[画像のクリックで拡大表示]

 これでは、システムエンジニアやプログラマは、与えられた作業を与えられた期間までに終了すればよいと思うだろう。コミュニケーションも活発ではないので、たとえ余裕があってもほかの人の仕事を手伝おうとは考えにくい。自分の担当作業が最優先になるのは自然なことだ。言われたことをこなすだけなので、モチベーションも上がらないだろう。

 しかも成果物に不備があると、エンジニアは「設計書に書いてある通りに作った」などと言い訳をする。まずは自分の責任ではないことを主張するわけだ。当然の行動ではあるが、これでは生産性のないムダな時間と嫌悪な人間関係が残るだけである。

 このような事態を招いてしまうのは、決してメンバー個人が悪いわけではない。プロジェクトの開発プロセスと体制が問題なのだ。もし、受け身の姿勢が蔓延するチームを、主体性のある自律型のチームに変えることができればどうだろうか。きっと、生産性が向上し、ユーザーにとって満足度の高いシステムを提供できるはずだ。

チームメンバーに権限を与えて自律的な組織を作る

 主体性のある自律型のチームを作るには、そのチームに権限と責任を持たせるのが有効だ。チームメンバーが誰に責任を押し付けることなく、全員の責任だと思うようになり、前向きな改善が期待できる。チームメンバー同士の信頼関係も、より強固なものになるはずだ。

 チームの主体性をより引き出すためには、ハイブリッドアジャイルの開発プロセスを導入することも考えたい。ハイブリッドアジャイルとは、ウォーターフォール型の開発プロセスにアジャイルのプラクティスを取り入れた手法である。基本パターンは、基本設計の工程までとテスト工程以降をウォーターフォールで行い、詳細設計と製造に相当する工程をアジャイル開発する。基本設計の工程では、ウォーターフォール型の開発と同様に、プログラマとは別の設計者が設計書を作成する場合が多いだろう。

 大きく変わるのは、基本設計後の工程だ。ハイブリッドアジャイルでは、アジャイルのプラクティスを参考にしながら、コミュニケーションを重視して開発を進める。

 曖昧な仕様をチーム内で確認し、プログラマなどの開発者の意見も尊重しながら仕様を確定させるわけだ。より良いシステムにするにはどうすればよいのかをチーム内で議論して設計仕様を考えるので、チームメンバーが指示待ちになり受け身の姿勢になるのを回避できる(図2)。

図2●チームに権限と責任を持たせる
[画像のクリックで拡大表示]

 チームには、ユーザーの仕様確定権限を持つプロダクトオーナーも参画してもらうとなおよい。このような体制を敷くことで、エンジニアが不明な仕様をプロダクトオーナーにすぐに確認できるようになる。プロダクトオーナーと頻繁に打ち合わせをしながら開発を進めることで、ウォーターフォール型とは全く違うスピード感で開発できるようになるはずだ。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら