7．　開発担当者の心得

　　受注者全員が日々、全体と優先度を考え行動すべし。　
　　真のゴールとPOの価値観を理解し、チームの現状を把握し、
　　自らの状況を適切な相手に適切なタイミングで伝え、
　　次の作業案をもって優先度を都度POと相談し、
　　技術者としての高い付加価値を提供し続けるべし。

7.1 真のゴール、POの価値観、チームの状況を理解し、POの判断に近づく努力をする

■ POを全力で支援する姿勢を持ちましょう。

【現実5】　
　アジャイル開発では、POに最も負担が集中します。

　アジャイル開発では、ステークホルダとの仕様調整や各種の判断がPOの責任となり負担が集中します。時には、POの判断やレビュー待ちなどでプロジェクトのスピードが減速することもあるでしょう。そんなアジャイル開発をより効率的に実施するには、開発メンバは何をすればよいでしょうか？

■ POの判断に近い判断ができるようになって、主体性を高めましょう。

　それには各開発メンバが、POに近い判断ができるようになるのが理想です。POの考える真のゴールを正しく理解し、POと同じ価値観をもって、今のチームの状況を見ながら判断していく練習を積み重ねましょう。そうやってPOと同じ判断で作業が進められるようになれば、POからの修正の指示は減少し、最終的にはあなた自身が自立して動けるようになるでしょう。

■ POの人物モデルを持って、自らを成長させていく。

　では、POの判断に合わせるには、具体的には何をすれば良いでしょうか？4章で示したように、まずは、相手の人物モデルを自分の中に持つことがコツの１つです。そして、各種の状況におけるPOの判断を見て、その人物モデルの価値観での判断と比較してみましょう。異なっていれば、その人物モデルを補正し成長させます。その判断の差が発生した理由が理解できないときは、POに確認しましょう。「こういう判断もあったと思うのですが、なぜその判断では無かったのですか？」と。

■ POに求められている役割・責任や心得も理解しましょう。

　3章、5章で示したPOの役割・責任や心得等を理解して、POの判断に近づきましょう。

■ 優先度の変化や要望の変化の際も、その背景を含めて理解しましょう。

　アジャイル開発では、変更がよく発生します。でも、その変更には理由があるはずです。変更の際には、その背景を知るように努め、POの判断を深く理解していきましょう。

■ 他のメンバの作業状況も知り、チームの状況を把握しましょう。

　POとできるだけ同じ視界を持つことが重要です。あなただけではなく、チーム全体の状況も積極的に把握していきましょう。ただし、それに時間をかけ過ぎることは望まれていないと思われます。毎朝のスタンディング・ミーティングの場などで、自分の報告・相談をするだけではなく、他のメンバの報告・相談も興味を持って聞いておきましょう。

■ POの人物モデルが成長すれば、POの判断に近づけます。

　ステークホルダとの調整など、完全にPOと同じ視点で判断することは困難ですが、POの人物モデルを通して理解が進むと、開発者がPOの判断をかなり正しく予測して作業を進めることが可能になると思われます。

7.2 自らの状況を適切に伝えるコミュニケーション姿勢を持つ

　POは、正しい情報を持っていなければ、正しい判断はできません。あなたの情報を適切にPOもしくは関係者に伝える姿勢を持ち続けなければいけません。では、適切に、というのはどういうことでしょうか？

適切な相手 ：　報告・相談は、適切な相手を選びましょう。作業のスコープや優先度の相談であればPOですが、ある製品の使い方であれば、製品ベンダに聞くべきかもしれません。技術的な問題であれば、メンバの中に対応できる人がいないかを朝のミーティングで全体に向かって呼びかけるべきです。
適切なタイミング・頻度 ：伝えたい内容と相手の状況とのバランスを理解して、タイミングをはかって報告・相談をしましょう。相手は何か急いでいる状態か否か、報告すべき内容は緊急性を伴うか否か。判断できないときは、短く相手に都合を聞くべきでしょう。「この後、ＸＸＸの締め切りについて相談したいのですが、お時間大丈夫でしょうか？」さらに、作業が長くかかる場合には、順調なのか／問題があるのか等、その作業への期待にあわせて報告の頻度を上げていきましょう。ずっと、報告せず一人頑張った挙句、「できませんでした」という報告をするのではなく、途中で「苦戦中です」と、状況を入れるべきです。
適切な粒度 ：朝のミーティングなどでは、できるだけ簡潔に結論を言うべきです。さらに相談が必要であれば、あらためて場を持って、より詳細に伝えるべきです。相手から質問を受けた場合にも、相手の求める会話の粒度を意識すべきです。「Ｙｅｓ」、「Ｎｏ」だけ聞きたいのか？判断根拠等を聞きたいのか？不明なら、大きな粒度から徐々に詳細に語っていきましょう。朝のミーティングでの報告が、昨日と内容が同じという報告は良くないケースです。同じ課題を取り組んでいたとしても、粒度を細かくして、具体的な差分を伝えなければ、進捗状況は伝わりません。

■ コミュニケーションが嫌な場合にはPOに相談しましょう。

　アジャイル開発では密度の高いコミュニケーションが必須で、かつ、徐々にコミュニケーション・スキルも向上することが期待されます。しかし、もし、あなたがそれに耐えられないのであれば、POに相談しましょう。プロジェクト離脱のタイミングをPOに判断してもらうことも一つの道です。

■ あなた自身の人物モデルをPOとチームメンバに持ってもらいましょう。

　POにも自らの人物モデルを正しく持ってもらわなければ、質の高いコミュニケーションには至りません。POとチームメンバが4章で示したあなたの人物モデルを正しく作れるように情報を提供すべきでしょう。

■ POは現場の状況に興味を持っています。

　POは作業進捗に対して、期待の期間とのズレがあった場合に、「時間がかかった理由は何？」とよく尋ねるでしょう。それは、POが現場の状況を正しく理解するための質問です。「何か想定外の問題が発生しているのではないですか？」と、同じ意図かもしれません。作業が上手く進まない要因は、素早くPOに報告して、このままのアプローチで良いのかを確認していくべきです。POからの質問に対して、「一人悩んで、ずっと調べてました」という回答が出るケースは、アジャイル開発の進め方としては望ましくない状態です。

7.3 次にやるべき作業案をもって優先度を都度POと相談する

■ POの負担を下げることに貢献しましょう。

■ 技術者として、主体的であることを目指しましょう。

■ コミュニケーションは、あなたの中のPOの人物モデルを確認し補正するタイミングだと思いましょう。

　アジャイル開発では、作業の優先度に迷いがある場合には、POに相談するものです。PO自身の負担を下げて、あなたの中にあるPOの人物モデルを試し改善する姿勢を示すのであれば、あなたの考える選択肢と優先順位を同時に提示すべきです。あなたは常に受身ではなく、技術者として主体的であるべきなのです。たとえば「案はA, B, Cの３つあります。XXXの理由で案Aが良いと思いますが、いかがですか？」と聞いてみてはどうでしょう。決めるのはPOであっても、提案するのはあなたで良いのです。

■ 次に、実施するべき作業が不明で、作業待ち状態に入ったのであれば、急ぎPOに作業割り当てを依頼しましょう。

　アジャイル開発では、準委任契約という枠組みを使います。シンプルに言えば、結果に対して費用が支払われるのが製造請負契約、稼動時間に応じて費用が支払われるのが準委任契約です。つまり、POはあなたが仕事を持っていない状態を避けたいのです。全ての作業が完了し、作業割り当てが無くなったときや、他者の作業待ちに入って当面の作業が無くなった場合には、急ぎPOに次の作業割り当てを依頼しましょう。普通は、チケットシステム上にバックログとして積んである次の優先度の作業になるはずです。それで良いかを確認して進めましょう。

■ 仕様を実現する際に、もし仕様を若干変えるだけで、劇的に実装期間が短くなる方法があれば、それもPOに伝えましょう。

　仕様は原則として守るべきものですが、アジャイル開発ではその実装にかかる費用とのバランスを重視します。もし、若干仕様を変えるだけで、3ヶ月かかる実装が１週間で済むのであれば、POには魅力的な提案に感じるかもしれません。

7.4 技術者として高い付加価値を提供する

■ 要求スキルの多様化に対応し、自分の付加価値を上げていきましょう。

　「設計はできません」、「Javaでのコーディングしかできません」、「試験工程しかできません」などのように限定的な技術スキルのメンバは、直ぐにアジャイル開発に対応することは難しいかもしれません。アジャイル開発では、基本設計は無理としても、その他の工程は誰もができなければ効率が低下します。まずは、プロとして、情報処理技術について広く深く理解していきましょう。

　その昔、大量生産が重要だった時代に、工程毎に要員が割り当てられる流れ作業（ライン生産方式）が生まれました。その要員は常に同一工程を担当するため、後に、「単能工」と呼ばれることになります。市場が成長し、ニーズが多様化してきた頃、多品種少量生産のモデルとして、一人または少人数のチームで全工程を担当するセル生産方式が生まれました。彼らは全工程を担当できるため「多能工」と呼ばれるようになります。
（巻末の補足6）

　さて、ソフトウェア製造産業は、大量生産でしょうか？それとも多品種少量生産でしょうか？当然、後者です。ソフトウェアの大量生産はコピーで済んでしまいます。皆さんは、多能工として、マルチな能力を発揮していかなければいけません。もう、単一工程の専用歯車ではないのです。

■ アジャイル開発について他書籍を参考にしましょう。

　本書はアジャイル開発を日本で実施するのに大切な部分を特に抜粋強調して書いています。しかし、アジャイル開発の本場である米国のノウハウを紹介した書籍も多数あります。それらにも興味を持って目を通してください。POの右腕として信頼される技術者を目指してください。

■ 常に、新たな情報処理技術を身につけ、プロジェクトの中長期的な方向についてもアドバイスして貢献しましょう。

　首都圏であれば、各種の勉強会、LTの場などが企業枠を超えて開催されています。積極的に参加することを推奨しましょう。

　近年では、低コストなPOD（Print on Demand）サービスも普及してきました。業務に関連しない技術情報について、外部に発信することで理解を深めていくことも良いでしょう。

　ただし、業務に関わる情報を外部に漏らすことは、禁止事項になります。

7.5 相互にフィードバックし、双方が成長する

■ チームメンバもPOが良いリーダになるように誘導しよう。

　POが当初からアジャイル開発の成功経験が豊富な人格者であるとは限りません。もしかしたら、これまでウォーターフォール開発しか実施しておらず、初めてのアジャイル開発である可能性もあります。そうでなくても、人間は神様ではありません。完璧ではないのです。PO自身がアジャイル開発のPOとして上手く振舞えるように、適切に開発メンバもフィードバックしてあげましょう。特に、コミュニケーションの質が悪い、優先度の判断・変更理由が全く理解できない、など、チームメンバ全体のモチベーションに関わる場合には、きちんと話し合って双方の改善点を明確にして対応していく進め方が必要でしょう。真に良いPOであれば、常にWin-Winの姿勢を持っているはずです。適切に改善してくれるでしょう。

7.6 アジャイルの罠に注意する

　アジャイル開発だからこそ、迷い込む間違いがあります。注意しなければいけません。

■ 動くもの見せると細かな指摘が多く出ます。しかし、細かな仕上げは最後に回し、最も重要な部分の作業を進めましょう。

　アジャイル開発では動くものが早めに確認できます。すると、具体的で細かなコメントが多数、出やすくなります。しかし、それらにすぐに対処するのは止め、コメント対応の優先を見極めましょう。細かなコメント対応を気にしすぎているとプロジェクトの前進のペースが一気に遅くなります。いつでもできる細かなコメントへの対応は最後でいいのです。もっとも重要な部分を先に実施していくのがアジャイル開発です。システムの鍵となる重要部分をできるだけ早く一回通して動くものを作り上げ、プロジェクト全体の目処を早くつけることの方が大切なのです。そして、重要な部分・時間のかかりそうな残り部分を検出して、そこに手を打っていくことがアジャイル開発なのです。

■ アジャイル開発の初期には、アーキテクチャを固めることが重要であって、プログラムコードの品質を目的にしないケースもあります。その場合、そのお試しコードは後に捨てることもあります。

　プログラムコードに価値を置きすぎると、そのお試しコードを利活用することが主眼となって、見通しの悪い設計になる場合があります。最初に一通り動かす際に使ったプログラムコードは、後々、捨てて、良いプログラムコードに置き換えることも普通に行われなればいけません。もちろん、100％のリファクタリングは費用対効果が良くありませんから、維持管理のし易さを考えながらバランスの良い判断をしなければいけません。新しいチームメンバが入った際のプロジェクト理解用の作業としての活用法もあるでしょう。

■ POにリーダシップがあるため、開発メンバに主体性が芽生えない場合には、指示待ち人間に留まってしまうケースもあります。

　請負開発では受注側の提案したことの責任が強く問われましたが、アジャイル開発ではプロフェッショナルとしての善管注意義務は発生するものの、最終責任者はPOです。技術力を活かした主体性を発揮してPOに貢献することが期待されています。

　しかし、常にPOの指示に従い続ければ無難に進むという側面もあるため、モチベーションが高まらない場合には、そのまま指示待ち人間としてスキルが固定化されるリスクがあります。そういう開発メンバはアジャイル開発には向いていないと思います。

7.7 ウォーターフォールの悪癖は矯正する

■ 過剰品質は悪です。【オーバーフィット問題】

　アジャイル開発ではかかった時間に対する効果を重視します。自分が満足したいからといって、優先度の低いところの対応に時間をかけてはいけません。POは、そんな時間があるんだったら、もっと別のところをやって欲しいと思うはずです。自分の足元だけを見て満足してはいけません。時間がかかる場合には達成レベルと優先度をPOに確認することが必要です。

■ 悪い情報の速報を入れないのは駄目です。

　「悪い情報だが、もう少し問題が明確になるまで報告するのは止めておこう」という判断や、「問題だが、報告すると直ぐに対策を出せ、と言われるから、対策が決まるまでは問題の報告は遅らせよう」という判断は駄目です。POには悪い情報をできるだけ早く報告し、それを含んだ視野の中で良い判断をしてもらいましょう。

■ 自らの失敗や遅延を、ごまかしたり曖昧にして報告してはいけません。

　正直で、透明性の高い組織文化を作ることにあなたも協力していかなければいけません。失敗や遅延の大きさに応じて、チームメンバの作業の優先度を変化させるのもアジャイル開発です。ごまかすことで発生した不信感は、その後のコミュニケーションの質を悪化させます。

■ ドキュメント化を最初にするのは時間の無駄です。Face to Face（F2F）で議論し、ドキュメントは結論を記録・共有するものと考えましょう。

　方式を議論する際に、検討資料を作って案を3つ並べて、各種の観点で評価して選定していく、そういうスタイルをPOが望んでいるでしょうか？望んでいれば問題ありませんが、「その方式は議論するまでもなく、こうではないですか？」、「いや、ここはこうではないでしょうか？」という議論をホワイトボードの前で、サクサク決められる部分も多くあるのではないでしょうか。重要な選択については、決定した方式と決定のポイントをドキュメント化することが期待されますが、コミュニケーションのための大量のドキュメント作成は止めましょう。ウォーターフォール開発では受注側にとって判断経緯の記録は責任問題に備えるために重要でした。しかし、アジャイル開発では発注側のPOが責任を持ちますし、判断や実装は１回ではなく、訂正可能なのです。

■ ソースコードのレビュー単位は小さくしましょう。

　ソースコードのレビューに出す際は、ソースコードをレビューする人の負担も勘案し読みやすさを考え、小さい単位にしましょう。自己満足を優先した巨大なソースコードをレビューに出すと、相手の応答は遅くなり、方式のズレがあった場合等に大きな無駄作業となります。やむを得ず巨大なソースコードをレビューに出す場合には、F2Fで適切に解説を行い、レビュー速度を改善しましょう。アジャイル開発ではソースコードもコミュニケーションの一部として大切なものになります。

■ 作法主義・前例主義を優先してはいけません。

　作法も、前例も、アジャイル開発にとっては判断のための一つの情報にしか過ぎません。ウォーターフォールで慣れた作法・実績のある作法であっても、その場で本当に重要なのかを改めて考え直してください。臨機応変が大切です。

■ 絶対的な工程の区切りはありません。バランスです。

　ウォーターフォール開発では、原則として前の工程に戻りません。そのための工程完了の判定の実施などをする開発もあるでしょう。しかし、アジャイル開発では、その区切りは曖昧です。大枠での工程、自分の作業が何工程なのか、などは意識するために工程名は使いますが、決して工程で区切るのではなく、工程名はコミュニケーションの用語だと思いましょう。

■ 作業の順番は重要です。「上から並んでいる順にやってます」は考えていないことかもしれません。

　請負開発では、結局100%やりきることが求められました。その時は、どの順番に実施するかよりもやりきる事が重要でした。しかし、アジャイル開発は作業の順番が重要です。たとえば、試験をするにしても、上から順番でいいのか？バグを見つけたら最も修正に時間がかかるところはどこか？もっともサービスで重要なところはどこか？連続で実施した方が効率的なものはないか？他のメンバの効率をあげるにはどれを実施すればよいか？途中で試験を打ち切った場合に大切な部分は試験できているか？などを考えて順番を調整することが大切です。

■ 作ったソースコードは捨てることもあります。先行しすぎた単体試験は無駄になります。

　「手戻りが発生します」、「既存のソースコードが無駄になります」は、ウォーターフォール開発では工数が増加するため大きな問題でしたが、アジャイル開発では優先するもの次第で、捨てる事が発生します。たとえば、スパイラル開発で、暫定的に作っておいた部分や、設計が悪かった部分などです。それらの部分に対してUT 100％を最初から目指すことは無駄になります。

2022.9.25 改版に向けて