第3回：プロジェクトマネージャのためのAgile入門（成功の為の12ポイント：後編）／大野 聖一

大野 聖一 / North Star Management株式会社

前編にてAgile開発成功のための12ポイント中6ポイント（ポイント①～⑥）をお伝えしました。

今回は、後編として残りの6ポイント（ポイント⑦～⑫）をお伝えしていきます。

早速、“マインドセット”に関するポイントを4点ご紹介します。

ポイント⑦：開発者自らのコミットメントが必要！

Agile型の開発の場合、開発者の生産性が如実に可視化されます。

このプレッシャーというのは、結構なものです。

開発者には、このプレッシャーに耐えれるだけのタスク遂行上のコミットメントが必要ということです。

本来は、プロフェッショナルとしてチームに参加しているわけですから、競争に晒されて切磋琢磨していく強さが必要ではありますが、実際の現場では、なかなかそうはいきません。個々のモチベーション管理が重要になる事は言うまでもありません。

ポイント⑧：全体最適の視点が重要！

開発者は、目の前のタスク消化に目がいき、部分最適に陥りがちです。

汎用性、共通化などの観点を取り入れて全体最適を意識する事が最終的な成果物の品質を高める事につながります。

前編のポイント②でお伝えした、“設計リーダー“がこの全体最適をとるための調整役を担うことができると考えます。

個々の開発者が高い視点を持ち、良好なコミュニケーションをとれるようなチームであれば、当然“設計リーダー“は不要です。

ポイント⑨：目的を見失わない！

目的が不明確な要件を明確化するためのプロジェクトであれば、システムの機能アップにリソースを割り当てすぎないように注意しましょう。

Agileによる導入を行う事とした目的をプロジェクト計画上明確にしておき、それを見失わないように都度確認する事が重要です。

イテレーションが進み、実際に動くプログラムを確認できるようになってくると、目的からそれた機能追加を必要以上に行いたくなるというのはありがちな話しです。

ポイント⑩：クライアントからの要件・要求は“絶対”ではない！

第１回記事の「Agileの本質」でお伝えした通り、Agile開発は、コストとスケジュールが不変であり、スコープが可変です。

クライアントからのスコープに関する要件は絶対的なものではないという事を理解しましょう。

ウォーターフォール型の開発経験が長い人ほど、この意識改革が困難です。（ウォーターフォール型の開発の場合、クライアントからの要件は絶対的なものです）

クライアントも含めたワンチームで協議しながら進めていくという意識をクライアント含めて全員が持つ事が重要です。

---

続いて“その他”のポイントを2点示していきます。

少し細かいですが、重要なことです。

ポイント⑪：朝会（スタンドアップミーティング）は有効！

担当者は、日々目の前のタスク消化に追われていますので、周りの人が今どんなタスクを行っていて、自分のタスクと関係があるのか、

似たような機能であれば共通化できないかなど、確認・共有するのは日々の朝会しかありません。

形式だけではなく、クライアントも含めた朝会がプロジェクト全体の状況把握、ベクトル合わせに有効です。

また、この朝会は短時間で毎日実施するのがコツです。

朝会のポイントは様々ありますが、話しが本題からそれますので、別の機会にお伝えします。

ポイント⑫：コーディング規約を最初に取り決めておく！

コーディング規約の取り決めは案外忘れがちです。

人によってコーディングルールが異なると、最終的にプログラムをマージしたときに統一感のないものになってしまいます。

保守性の観点からも、プロジェクト開始時点でコーディングルールを明確にし、周知しておくことが重要です。

社内の要員だけでAgile開発を実施する場合は、社内のコーディングルールがあるでしょうから、特段の考慮は不要です。

成功のための⑫ポイントは如何だったでしょうか？

Agileプロジェクトを企画している方、現在進行中の方などは、今回あげた12個のポイントを見直してみてください。

少なからず、成功へ近づけられると確信しています。

今回の連載では、Agile開発のテクニカルな進め方などには言及せず、プロジェクトマネージャとして必要なエッセンスのみを

お伝えしてきました。

当たり前！と感じるものもあったかもしれません。

しかし、当たり前の事を当たり前に実施する事は案外難しいものです。

ましてや初めてAgile開発に挑戦するときなどは、暗中模索で進めることとなり、不安になることと思います。

Agile開発について、”こうすれば正解”というの答えが存在するわけではありません。

あくまで先人の試行錯誤の上に成り立っているものであるという事を理解し、自分達にあった形を作っていければ良いのではないでしょうか。（最初は”なんちゃってAgile”でもよいのです）

プロジェクトチームに経験者を含め、成功・失敗体験からくる助言に耳を傾けながら進めていく。

そういう雰囲気のチームを作ることができれば、クリエイティブかつエキサイティングな体験を皆で共有することは、難しいことではありません。