5．　現場でのアジャイル開発スタイル（PO実践編）

　　発注者は開発者から信頼された仲間になるべし。　
　　ゴールを示し、皆に理解してもらってチームを作り、
　　一人ひとりを知って適材適所に配し、
　　状況・問題点・今後の方針を積極的に聞き、対外調整を実施し、
　　丁寧な対話とバランスの良い優先度判断を常に心がけ、
　　仲間であり人格者のリーダとして信頼されるようになり、
　　仲間とともに持続的なWin-Winと成長を目指すべし。

5.1 技術者を集める

　良いソフトウェアを作るために、1章で示した【優良ソフトウェア開発原理】が重要です。
　優秀な技術者を集めて/育てて、チームを作り、高いモチベーションを実現し、持続させていかなければいけません。

■ 良い技術者を集めることが重要です。

　チームメンバに期待する能力／意欲／姿勢、条件にはどんなものがあるでしょうか？以下に例を示します。

優秀なソフトウェア技術力（設計～コーディング・試験まで全て）
相手に理解してもらえるコミュニケーションの基礎的な能力
開発システムへの興味とモチベーション（意欲）
POとの協働姿勢、素直で正直
積極性・提案する姿勢
専念できる（他と兼務しない）

　　　　　図5-1　３つの大きな期待

■ 良い技術者はチームとして育てていきましょう。

　少なくとも１名、可能なら2～3名は、設計からコーディング・試験まで、全ての工程に精通した技術リーダがアジャイル開発では必要でしょう。

　しかし、全メンバが全ての条件を満足することは一般には困難です。特に、短期間で体制を作る場合には条件を緩める必要があるでしょう。不足する部分については、チーム内で成長を促し育てることが大事です。将来必要になるスキルを早めに伝え、必要な調査時間・学習時間は業務に組み込むことが必要になるでしょう。チームのメンバは相互に成長しあえるように、ノウハウを共有するように誘導しましょう。

■ それでもチームをまとめるために交代してもらうケースはあります。

　以下にようにコミュニケーションの基礎からの育成が必要になる場合や、アジャイル開発の考え方に適合できない場合には、スキル不一致で交代することもやむを得ません。

真実を言わない。事実と予想が区別できない。
声が小さすぎて聞き取れない。
指示がないと動かない。黙って待っている。
論理的な思考・会話が困難である。
一度決めたことを変える事を拒絶する。

　また、技術力は抜群であっても、それ以外の面でチームに悪影響を与えるメンバであることもあります。相互不信に陥る前に交代を求めていきましょう。

仲間を攻撃する。共に成長するという視点に欠ける。
反抗的な姿勢をとる。ゴールに反対し続ける。

■ プロジェクトが長期にわたる場合、要員の交代にも備えましょう。

　長期のプロジェクトでは技術的キーマンの入れ替えは当然発生します。突然、キーマンを抜かれないための注意も必要です。準委任契約は、人を個別に指定して契約することはできません。受注会社でも人材育成上キーマンを次のポジションに移すことは避けられません。受注会社としての人材育成に伴うキーマン交代計画は、早めに共有してもらって備えるようにしましょう。他にも、不慮の事故、親や家族の介護、体調不良や病気など、交代が必要になるシーンはプロジェクトが長期化すれば、避けることは困難です。備えることを考えなければいけません。

■ 属人化はアジャイル開発の弱点の一つです。

■ 自動テストの整備をして属人化リスクの低減を図りましょう。

　アジャイル開発では、特定の技術的キーマンが発生することが普通です。開発現場側のキーマンが一人に集中しないようにPOも配慮しなければいけません。重要な情報はキーマンの外に見える状態で残されていなければいけませんが、自動リグレッション・テストを整備することが属人化を避ける最大の対策となります。維持管理や機能拡張を行っていく際にも大切です。リグレッション・テストの自動化ができると開発プロジェクトは一旦安定状態に入ったと考えることができます。

■ 新メンバの参加障壁を低減するための準備を、タイミングは選びつつ行いましょう。

　アジャイル開発でメンバが追加・交代する際に必要なドキュメントの整備を計画しましょう。詳細設計のドキュメントはソースコードで十分です。システムの概要、アーキテクチャ図、外部API仕様などが求められますが、あまりにも初期の時期にそれらを整備するのは難しいかもしれません。システムの基本設計が安定しはじめたら、それらのドキュメントは速やかに整備するのが一つの考え方です。

5.2 自らがゴールを示し、皆に理解してもらってチームを作る

■ もしPO自身のゴールイメージが不明確なら、まだ開発に入ることは止めましょう。

　アジャイル開発ではPO自身の判断が成功の鍵を握ります。車で言えば運転手です。最終的なソフトウェアのゴールイメージを持たなければ目的には到達できませんし、開発プロジェクトは迷走するでしょう。PO自身が開発したいもののゴールイメージを全く持てない場合には、開発メンバにゴールを伝えることもできません。開発に入るタイミングはもう少し後、ゴールイメージを具体化した後にすべきです。

■ 良いソフトウェアを作るために必要なものは、開発者の高いモチベーションです。

■ ゴールを共感してもらって、モチベーションを高く維持することに注力しましょう。

　ゴールに共感してもらうことが非常に重要です。皆が一つの目標を共有できれば良いチームになれますし、小さい成功を繰り返せばよりチームのモチベーションが高まっていくでしょう。ゴールが理解されなければ、高いモチベーションを維持して欲しいと思っても、それは難しいでしょう。

■ ゴールを正しく理解してもらうために、何度も説明しましょう。

　ゴールは、まだこの世界に存在しないもののことも多いでしょう。そのゴールイメージを正しく伝え理解してもらうことは大変難しい作業です。一度で伝わることはないと覚悟し、機会を見て何度も説明しましょう。プロトタイプ・システムが動き出すまでは、皆のイメージはなかなか合わないものだと思いましょう。

■ ゴールが変化した際には、丁寧にその理由を伝え理解してもらう努力をしましょう。

　ゴールイメージが不安定なときには、途中状態も含めて皆に共有していきましょう。共有によって、将来の変更への備えが得られる場合があります。たとえば、この辺りはまだ議論が再燃しそうだから、後で見直す想定で開発を進めていこう、などの判断ができると効率的になります。ただし、変更の可能性が多すぎると前進できなくなります。汎用化しすぎることなく作りなおす覚悟を持って仮に決める姿勢が大切です。

　また、競合サービスの影響など外的要因によって突発的に、ゴールが変化することもあります。その変化に至った理由をできるだけ皆に理解してもらい、モチベーションの低下に繋がらないように配慮していきましょう。

5.3 一人ひとりを知って適材適所に配置する

　アジャイル開発では優秀な技術者を揃えたいところですが、全員が同じスキル・特性とは限りません。チームとしての力を発揮するために、一人ひとりのスキルや興味をできるだけ生かして適材適所の配置に努めましょう。4章でも紹介したとおり、コミュニケーションの質を上げるには、メンバの一人ひとりを良く知ることが重要でした。そこで得た一人ひとりの人物モデルを活用して適材適所を考えることが大切です。ただし、目の前だけを見てはいけません。チーム力の可用性（継続性）や育成（スキル向上）を考えた配置とのバランスも大切です。

5.4 状況・問題点・今後の方針を積極的に聞き、現場を正しく理解する

■ 良い優先度判断をするためには、正しい情報を集めるように努力しましょう。

　良い判断をするための大前提は、実際の状態を正しく認識していることです。常に、現場の実態を見て、現場の実態も勘案した優先順位を考え続けていかないと、良いソフトウェアが作れないだけでなく、失敗するリスクが高くなります。

■ 朝ミのヒアリングは、ポイントを絞って短時間で終えましょう。

　朝のスタンディング・ミーティング（朝ミ）では、昨日の実績、今日の予定、現在作業進捗が悪いならその課題が何か、今後の見通し・完了予定時期、を簡潔に確認し、短時間で終了しましょう。朝ミで課題を報告した開発メンバに対しては、必要なメンバを別途招集し、詳細に相談をする場を設定します。

■ 昨日の昼に発生した大きな問題が翌日の朝ミで最初に報告された場合、なぜ速報が遅いのかを確認し、改善していきましょう。

　朝ミは緊急情報を報告する場ではありません。悪い情報は速報を入れるという習慣がまだ浸透していないと判断した場合には、次回から改善を促しましょう。

■ 開発の作業現場に足を運んで、現在の状況を確認し、困っていることが無いかを確認しましょう。

　POは、ステークホルダとのシステムのゴールの調整やプロジェクトの予算措置、各メンバからの相談に対する判断など、きわめて忙しい存在です。しかし、時々、開発の現場にも足を運んで、現在の開発メンバの状況を自らの目で確認し、積極的に課題を検出していきましょう。モチベーション高く皆が開発を行っているでしょうか？作業環境や生活面で困っていることは無いでしょうか？生活利便性の解決はモチベーションの向上に効果があります。

5.5 ステークホルダとの調整を実施する

　システム開発は、ステークホルダとの調整と共に進みます。ステークホルダとは、開発資金を提供する人、システムを構築し運用する人、サービスを売る人、最初に開発システム／サービスを利用する予定のユーザ等、多岐に渡るでしょう。それらのステークホルダと開発システムの仕様については調整をしなければいけません。

■ ステークホルダとの合意は、チームの代表として現場も見て判断しましょう。

　ステークホルダと開発チームとの間に立って調整をするのはPOの役割です。しかし、POはステークホルダと開発チームとの相互の主張を確認した後に判断することが基本であることを忘れないでください。重要な合意の際には、2フェーズ・コミット（図5-2）による合意確認が大切です。POは最終決定の責任者ですが、現場が反対する決定をした後に開発メンバをどう説得するか、納得させるかにつては事前に考えなければいけません。開発現場・チームの実態を正しく知って、代表として判断をしなければ、チームのリーダとして認められることはありません。

　　　　図5-2　ビジネス上の２フェーズ・コミット

■ アジャイル開発ではリリース・タイミングの自由度が高いことを活用して、開発チームとステークホルダの調整を実施しましょう。

　ウォーターフォール開発・製造請負契約では、リリース回数は通常1回です。しかし、アジャイル開発・準委任契約ではPOの判断で何度でも可能です。今開発に入れるか否かという0/1の判断ではなく、常に優先度の高いものからリリースしていくことで、開発チームとステークホルダの双方の都合を調整できることがあります。品質レベルを含めて双方に信頼される調整をしなければいけません。

5.6 丁寧な対話を続け、バランスの良い優先度判断を続ける

　4章で示したように、コミュニケーションは継続して対話相手の人物モデルを改善することによって質が改善していきます。それがモチベーションの向上や、チーム力の向上に繋がり、良いソフトウェア開発に繋がっていきます。しかし、ちょっとした一言によって、モチベーションを大きく損なう可能性も持っています。十分な関係が出来るまではより丁寧なコミュニケーションを継続するようにしましょう。

■ アジャイル開発では変化は必然です。期限があるときに、追加分があれば、削る（先送りする）分も同時に作りましょう。

　開発の途中での追加要求による追加変更作業量がAなら、従来予定の作業からA以上の作業量を削減しなければ、開発終了時期が遅延します。アジャイル開発では削った分（＝優先度を下げた分）をバックログとして、先送りします。その決断をPOはしなければいけません。必要ならステークホルダと急いで調整をしましょう。

5.7 人格者のリーダとして信頼される

　チームのメンバから信頼されるリーダになることを目指しましょう。まずは、仲間になることが第一歩です。同じ目線を共有できるようになりましょう。

　小さい成功の積み上げや、開発チームの代表としてのステークホルダとの調整などの実績を通して、リーダとして認めてもらえるように努力を続けましょう。

　開発上の課題や商用サービスでのトラブル対応などについても、隠さず、冷静にかつ先頭に立って、常にバランスが良い判断を続け、開発メンバにとって風通しの良い組織が構築できれば、きっと信頼され人格者としても認められることでしょう。そこへの到達は容易ではなく、時間がかかるかもしれません。諦めることなく続けていきましょう。

5.8 仲間とともにWin-Winと成長を目指す

　POはチームメンバとのWin-Winの関係の姿勢を出し、実践することが重要です。

■ 開発メンバの自己研鑽を推奨しましょう。

　アジャイル開発を支持するソフトウェア技術者は、新しい技術を常に習得するモチベーションを持っているケースが多々あります。そういった自己研鑽意欲を活かしてあげなければいけません。いつかプロジェクトにも良い効果をもたらしてくれるでしょう。プロジェクトの成功と技術者としての成長の両方を目指して行きましょう。

■ 開発メンバの超勤削減と健康管理もPOの考えるべき範囲です。

　発注者先の勤務管理責任は発注先の管理者にあります。しかし、超勤を発注者側だけに任せておくことは危険です。超勤は、一定レベルであれば生産性を高めるかもしれません。しかし、アジャイル開発では原則として避けるべきでしょう。

準委任契約の場合には、超勤した分が支払額の増加につながります。休日出勤の対応をお願いしたらいくらかかるか、は知っておかなければいけません。
超勤を前提としない進め方をベースに計画をしましょう。超勤は、いざというときに遅延を回復するバッファとしましょう。そのバッファを最初から使い尽くしてはいけません。
超勤が長期間続くと風邪を引きやすくなるなど、健康面でのリスクが高まるでしょう。さらに、超勤が続くと、燃え尽きることがあります。モチベーションが無くなる状態は避けなければいけません。
アジャイル開発は、幅広い情報処理の知識を持った高スキルの技術者を期待します。技術勉強会等に参加するなどして開発物以外のことを自己学習する時間的な余裕を与えましょう。

　POはゴールイメージをもとに、時間・コスト・成果物(機能・品質)のバランスを自分で判断していく必要があります。ソフトウェア開発はバランスの産物です。バランスを間違えると良くないソフトウェアになってしまいます。バランスが悪いもの、それは乗用車にロケットエンジンを積み込んでしまうようなものです。

■ 相互に休みやすくするコツを実践しましょう。

　休暇の取得は、全員が持つ権利です。相互に助け合う体制になると、気持ちに余裕を持って休暇を取得できるようになるでしょう。

皆が休暇を取得しやすくするために、日々の自分の最終状態を常に他のメンバが共有できる場所に置きましょう。チケット管理システムなど利用し、帰宅前に記載を意識すべき作業として位置づけるべきです。
急に休暇を取得する場合には、作業に関する引継ぎ事項の伝達と、休暇からの復帰する時期（明日出社可能か）の見通しも含めて連絡する習慣にしましょう。

2022.9.25 改版に向けて