インシュアテック研究所としてアジャイルの研究を進めていますが、どうなればアジャイルなんだろうと悩むこともしばしば。そんなときに川口 恭伸さんのブログの非アジャイルマニフェストがとても参考になったので、私も作ってみました。
アジャイルマニフェストの１２の原則を逆を書いてみるとこれがアジャイルか？アジャイルではないのか？としっくりきます。
１．価値あるソフトウェア
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
顧客満足/価値はともかく、納品予定の時期通りにソフトウェアを一回提供します。継続的なカイゼンは、請負契約のため仕様提示いただけないと対応できません。
２．要求の変更
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
要求の変更を開発の後期に出されても断れるよう、契約条項や変更委員会の設定をどうするかこそが、腕の見せ所です。いかに裁判で負けないよう証跡をのこすかが重要です。
３．短い間隔でのリリース
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
読み切れない設計書を2‐3週間から2-3ヵ月という予定通りに納品します。スケジュールを盾にお客様にいかにOKと言わすがポイントです。
４．日々の協働
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
ビジネス側の人と開発者は、いつもは別の場所にいて、必要最低限の情報しか開示しません。定例ミーティングで進捗・課題確認を行います
５．意欲ある人々
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
2次請、3次請の頭数をどれだけ集めるかが腕の見せ所です。セキュリティを重視して開発効率の悪い環境を与え、委託先リーダーの進捗報告の問題をいかに指摘するかが重要です。
６．フェイス・トゥ・フェイス
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
情報を伝えるもっとも効率的で効果的な方法は、PPAPで資料をメールに添付して全員をCCに入れることです。（メール宛先の順番について失礼にならないよう注意しましょう）
７．進捗尺度
動くソフトウェアこそが進捗の最も重要な尺度です。
WBSの定量評価こそ進捗のもっとも重要な尺度です。そのためWBSの正当性についてあらゆる手段で検証すべきです。
８．持続可能な開発
アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
非アジャイルプロセスはPG/ITフェーズのデスマーチを促進します。遅れてきた場合は、責任のある請負会社にいかに早く増員させるか、土日、残業についてギリギリまで働かせないといけません。
９．技術的卓越性
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
技術的卓越性はリスクとなりえますので枯れた技術が推奨です。優れた設計はポイントではなく、いかにマネジメントで抑えるかの注意が重要です。
１０．シンプルさ
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
委託する側は委託させる側に要件定義/設計タイミングでいかに大量の量を作ることを合意させるかが重要です。ユーザーに使われるかどうかは二の次です。
１１．自己組織的なチーム
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
最良のアーキテクチャ・要求・設計は古参の実力者から生み出されます。そのため、過去のアーキテクチャを引きずるため、新たなクラウドやSaaSを使っていくような設計にはなり得ませんが、リスクを鑑み、それが正しい設計です。
１２．チームでのふりかえり
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
トラブルが発生するとチームがどうやったらトラブルを出さないか、定期的にふり返り、監査し、チェックシートを増やしてきます。そもそもの問題やチームの改善よりも、チェックシートをつけることが重要となります。
まとめ
書いてみると若干笑えない内容に・・・。
インシュアテック研究所では非アジャイルでなく、アジャイルマニフェストを肝に研究を続けていきたいと思います。アジャイルに興味がある方は下記本も参考に下さい。
以上ありがとうございました。
