IT古典良書を読み解く《第8回》「初めてのアジャイル開発よろず相談室」
初めてのアジャイル開発 〜その３（完）〜
「初めてのアジャイル開発よろず相談室」
初めてのアジャイル開発編 完
こんにちは。スクラムマスターの伊藤です。
「一生懸命やればやるほどつきが回ってくるようだ」
- トマス・ジェファーソン （P.49 第4章 物語より）
エジプトの壁画には「最近の若いものは」という記述があるそうです。人は進化しているようで根本は変わっていないのかもしれませんね。それだから、古典を読んでも通じるものが多いのかも知れません。
「初めてのアジャイル開発」を読み解く最終回はよろず相談室として、アジャイルをより良くするヒントと、よくある質問を紹介したいと思います。
《よもやま話》
エジプトといえば世界四大文明の一つでピラミッドが有名ですが、世界初がとても多い印象です。パンもビールもワインもエジプト発祥で、1年を365日にして、スポーツイベントやペットに名前を付けるということまで始めるのですから現代とあまり変わらないですね。※諸説あります
アジャイルを成功させるヒント
ここではアジャイル開発で陥りがちな問題を解決するヒントを紹介していきます。既にアジャイル開発を経験した人ほど同感する点があるかと思います。（P.301 第11章 プラティクスのヒント）
■「水曜日」に終了することを検討する
スプリントの終了日を金曜日でなく、その週の水曜日（または木曜日）に設定することを検討するように書かれています。こうすることで、目標は水曜日だが、木・金を不測の事態が起きた場合の予備日としたり、デモやふりかえりを行う時間として使うことも出来ます。月曜日開始、金曜日終了のプロジェクトが多いと思いますが、日本では月曜日が祝日になることが多く、開始日がずれてリズムが崩れる原因となるため開始日も水曜日にするといつも同じリズムを刻めるというメリットもあります。本書には以下のようにも書かれています。耳が痛い方もいるのではないでしょうか。
月曜日にイテレーションを開始するという動かせないデッドラインに間に合わせようとして、週末を仕事でつぶす可能性が低くなる
■間接タスクを計画に組み込むこと
1日8時間使えるものとしてタスクを見積もると、実際は作業時間がそれほど取れずに遅延するということが往々にしてあります。これは間接タスクが組み込まれていないためです。具体的には以下のような間接タスクになります。
頻繁なリスクマネジメント、デモ、プランニング、ふりかえり、デイリースクラム、ある程度の確率で発生する予期しない不具合への対応、インフラの障害への対応などといった事柄は、どれも時間がかかるため、スプリントのタスクリストに挙げておく必要がある。アジャイル開発を初めて行うマネージャーは、これらの間接タスクに気が回らないことがある。
■立候補
アジャイルは自律的なチームを作っていくことが重要ですが、このヒントがその手助けになりそうです。タスクを洗い出した後に、担当者をマネージャーのような人がメンバーの特性を見て決定しているチームも多いかもしれません。以下のように書かれています。
仕事に意欲を持って打ち込み、満足するための簡単なプラクティスは、マネージャーがタスクを割り当てるのではなく、メンバーがタスクに立候補するよう推奨することである。
仮に、誰も立候補しないタスクがあったらどうするか？
「我々は自律的チームとして働いているのであって、マネージャーに指揮されているのではない。これはチーム全体で解決しなければならない問題だ。」とチームがこのレベルまで自律的になることを目指すのが良いでしょう。
■その他 現在も使われるキーワード
本書は2004年と16年前の発売ですが以下のようなものを使うことを成功するプラクティスに挙げています。
- CIツール
- Wiki
- ホワイトボード
- マインドマップ
- テスト駆動開発
《よもやま話》
本書にはアジャイル開発手法としてスクラム、XP、Up、Evoおよび組み合わせが紹介されていてスクラム＋XPが推されているような記載となっています。現在はスクラムが圧倒的に使われていると言えそうです。他の手法のプラクティスも取り入れることが行われていて個人的に大好きで実は効果も高いのがXPで提唱している「週に40時間以上働かない」というものです。それを超えると品質が低下するそうです。
（イメージ：John Darroch - Individual placard at march against racism in Auckland.(2019)/ Adapted.）
アジャイルの見積手法
アジャイル開発では作業量を見積もることが度々発生します。基本的には担当者が決めたりするのですが、重大なプロジェクトの場合には広帯域デルファイ法(Wideband Delphi)の利用を検討すべきと書かれています。筆者も使ったことがありますが、簡単な割にしっくりする結果が出やすいと感じています。(P.316 広帯域デルファイ法を使った見積もり改善)
5つのステップからなりますので紹介します。
1. 少なくとも3人以上が集まって情報源を議論する。見積の単位を検討する
2. 各自が見積もりを作成する。ここでの見積もり手法は何を使っても良いが3. 種類の見積もりを作成する。
これはPERT見積もりと呼ばれるもので以下の３つになる。
3. 見積もりをまとめ役に提出し、それぞれの平均を出す。バイアスを避けるため、誰が行った見積もりかをグループ全体に知らせることはしない。見積もった人は、自分の考えや仮定事項などを話し合う
4. 2、 3を少なくとももう1回は繰り返す。まさにアジャイル。反復型ですね。
5. 最後のサイクルの平均値を使って次のPRET式によって最終的な数値を計算する。これによって期待値が算出されます。
《よもやま話》
デルファイ法は聞いたことあるけど、広帯域デルファイ法は聞かないなぁという方もいると思いますが、なんと「広帯域デルファイ法」でGoogle検索すると1ページ目に本書の目次が３つもヒットします。ちなみに、Wideband delphiで検索するとWikipediaは英語ページのみヒットしたりします。日本ではあまり使われていないようですね。
本書にはデルファイ法は1948年にRAND社で作り出され、1970年代にバリー・ベームによって改良され広帯域デルファイ法になったと書かれています。
アジャイルFAQ
アジャイル開発は導入に様々な障壁があったりします。こういった場合はどうするのかというFAQを紹介します。見出しをみると、こんなピンポイントな質問が用意されているのかとも思いますが、困っている人が多いという裏返しのようです。（P. 361 第12章 FAQ）
理想的な回答
プロジェクトを2回の契約フェーズに分ける
フェーズ1では価格と期間を固定しスプリント1～3程度まで行い、
そのフィードバックを得てフェーズ2の見積もりに反映させる
一般的な回答
元も子もないですが、開発ベンダーがリスクを背負うというものです。
得意な方法で開発は実施し見積もりは広帯域デルファイ法を使うなどして
リスクを下げます。
アジャイル開発の早いフィードバックにより信頼を勝ち得ることで交渉し
直す可能性も高く出来る。
■ アジャイル採用するのに顧客を（あるいは経営陣を）説得するにはどうすればよいか
アジャイルを採用すべきだと提案してはならない。実験してみることを提案するとよい。その理由に失敗率が下がる、フィードバックが早い、利用が広まっているといったデータを挙げる。その後、利害関係者に対して半日ほどのセミナーを実施し実験が効果的だということを証拠を挙げて説得し、顧客には舵を取り続けられることを強調すると効果がある。次にパイロットプロジェクトを実験的に行うという確約をとり、後ろ盾となってくれると経営陣を見つける。プロジェクトを実施し、経験と成果に関するデータを集め、それを報告し続けるかどうかの判断を下す。
■ アジャイルを採用した場合には、もともと存在するテスト部門や品質管理（Quality Assurance :QA）部門の役割はどうなるか
方法が２つある。
1つ目の方法は開発チームの一員としてスプリントの早い段階から
テストの作成・実行その他の評価を行う。
2つ目の方法は、スプリント毎に内部リリースをQAチームに引き渡し、
評価してもらうことである。
QAチームはN-1回目のスプリントの成果物を評価する。
■ アジャイルを採用する場合には、保守用のドキュメントはどのように作成すればよいか
まず、必要性にもとづいて、どのようなドキュメントを作成するか決める。保守担当者に役立ったあるいはなくて困ったものを挙げてもらう。作成の上でのヒントを紹介。
ドキュメントをプロジェクトのWebサイト、Wikiなどに置く
注意が必要な、あるいは難解なテーマは、それを発見して目立つようにして「技術メモ」としてWikiページを作成する
動画を活用しても良い
終わりに
3回に渡ってお届けした「初めてのアジャイル開発」いかがだったでしょうか。アジャイル開発は進化していくものですが、現在でも通じる、あまり変わることのない根幹の部分を紹介するよう心掛けましたので、アジャイル開発をする上でヒントになれば幸いです。
最後にですが、アジャイルソフトウェア開発宣言というものがあり、個人的に大事だと思っていることが「計画に従うことより変化への対応を」です。なんちゃってアジャイルで苦労しているプロジェクトも多いですがアジャイル開発のルールを遵守するあまり、動脈硬化を起こしているプロジェクトも少なくないようです。形式にこだわって、中々進まないお役所仕事のような形式主義ではなく現実に即した対応をする現実主義でいきたいと思います。
《よもやま話》
最後の話はなんとJoelが苦言をしているblogがあったりします（2006年 執筆）。スプリント内の割り込みは禁止ですが、2時間で終わる本当に緊急のタスクを入れられないのはビジネスにおいて本末転倒ではといった内容です。ちなみに単行本には未収録です。
（原文）
- From the “you call this agile?” department
(日本語アーカイブ)
- アジャイル(?)なチームの話 https://bit.ly/3ns31J2
執筆者プロフィール：伊藤 慶紀
大手SIerにて業務用アプリケーションの開発に従事。
ウォーターフォールは何故炎上するのか疑問を感じ、アジャイルに目覚め、
一時期、休職してアメリカに語学留学。
Facebookの勢いを目の当たりにしたのち、帰国後、クラウド関連のサービス・プロダクト企画・立ち上げを行う。
その後、ベンチャーに転職し、個人向けアプリ・WebサービスのPM、社内システム刷新など様々なプロジェクト経験を経てSHIFTに入社。
趣味は将棋、ドライブ、ラーメン、読書など
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/