あの日々はどのくらいアジャイルだったのだろうか

10年ほど前に、うまくいったと思えるソフトウェア開発の経験があって、今もときどき思い返すことがあります。そして、それは ある程度アジャイルだった のではないかと思っています。うまくいった例の原体験とも言えるものです。

https://twitter.com/masskaneko/status/3102383231991808

2010年11月13日 @masskaneko
いまのチームにはアジャイル開発について知ってる人は誰もいない。けど、週単位の活動と軌道修正はイテレーションそのものだし、実装できるところからどんどん進めていく。

ある程度アジャイルだった という言い方をすると、アジャイルなのか、そうじゃないのかと疑問を持つ方がいるかもしれません。しかし、アジャイルか否かという考え方はナンセンスで、どのくらいアジャイルか という見方をすることが適切と常々考えていました。これについて調べたところ以下の優れた記事を見つけました。

flxy.jp

記事にはこう書かれています。

つまり形容詞であるアジャイルはゼロイチにはならず、アジャイルであるアジャイルではないという二元論のような考え方はそもそも存在しないということです。あくまで度合いの話であって、よりアジャイルか、あまりアジャイルじゃないという見方をすることも大切です。

この記事では、なぜ私の原体験がある程度アジャイルだったと思うのか、どの程度なのか、原体験の記憶があるうちに記しておくことにします。程度を語るには尺度が必要ですが、アジャイルの程度、アジャイルらしさについて定めている文献を知りません。そこで、12の原則をよりどころにし、順にひも解いてゆくことにします。

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

プロダクトはカーエレクトロニクスデバイスで、ビジネス形態は BtoBtoC だったので、顧客には企業とユーザーの2種類がいました。どちらの顧客についても顧客満足を最優先していたかは覚えがありません。少なくとも、開発者である自分たちがユーザーになるデバイスだったので、自分たちから見て役立つものを作ることは心がけていました。

また、1週間のイテレーションで内部リリースし、2週間～1か月で toB にリリースしていたので、"早く継続的に" については部分的に当てはまると思います。

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

特に歓迎はしませんが、耐えられはしたかという感触です。私を含めチームの何人かは、既存の要求、アーキテクチャ、コードの関係をよく理解していましたし、何のために何のコードが書かれたかというトレーサビリティの情報は全てではありませんが Trac Lightning に蓄積がありました。

また、ユニットテストレベルに限定ではありますが、テストが書かれたプロダクトコードの割合はファイル数について70%以上、テストが書かれたプロダクトコードのブランチカバレッジは90%以上、テスト設計はデシジョンテーブルで行ってテストコードの説明を Doxygen で記述していました。

ですから、要求の変更に対して、既に実現した要求のうち関連するものを見つけることは、その何人かの暗黙知に頼ればできましたし、ユニットテストが普及していたので耐えられました。ただし、歓迎はしません。

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

1週間のイテレーションで内部リリースし、2週間～1か月で toB にリリースしていたので、当てはまると思います。

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

これはわかりません。ビジネス側の人と開発者は違うのでしょうか。プロダクトは、作られ、ユーザーに使われて役に立ち、ユーザーが価値に対して金銭を払い、ビジネスが成立します。あるいは、ユーザーが価値があると期待して金銭を払った後、プロダクトはユーザーに使われて役に立ちます。

これを考慮すると、プロダクトの提供組織には、作ることに責任を持つ人、役に立つことに責任を持つ人、儲かることに責任を持つ人がいると分けることができます。そして、開発者は作る人です。ビジネス側の人とは儲かることに責任を持つ人でしょうか。だとすると、一緒には働いていませんでした。儲かることに責任を持つ人と接することはまれでした。

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

これはわかりません。ある程度アジャイルであったと思う日々に登場するメンバーは、その日々が始まるときに集められたわけではありません。意欲について語ることはありませんでしたので、何らかの意欲があったのかもしれませんが、それを知る由はありませんでした。

メンバーの担う仕事が無事終わるような環境と支援が十分だったのかはわかりません。一人一台実機を持っていて、いつでもテストできたのは実は良かったのかもしれませんね。他の組み込みシステム開発の現場を聞くと、一人一台なんて無い場合を聞きますので。

そして信頼していたのかというと、どうでしょう。疑っていた覚えはありません。疑うのは欠陥やプロジェクトリスクであって、人を疑っていた覚えはないのです。

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

これはうなずけます。オンラインのコミュニケーション機会はメール、チケット、そして今は懐かしき IP Messenger。フェイス・トゥ・フェイスの機会は、公式には週に1回のマネジメント会議と不定期なレビューがあり、そのほか雑談を含め非公式なものが沢山ありました。

ソフトウェア開発者がテスト担当者にバグを再現するコツを聞くことはよくありました。チケットに書かれた再現手順を行っても再現できないときは、毎回テスト担当者に直接聞いたものです。

ソフトウェア開発者は測定器の使い方や基板のことがわからなければ、すぐ近くにいるハードウェア開発者に質問することができました。逆に、ソフトウェアの動作として気になっていることを聞かれて設計を説明することもありました。

難しいバグを手分けして調査したり、要求の実現方法が複数考えられるときに分担するとき、どう動いたかを IP Messenger で簡単に伝え、それだけで分からなければ相手の席まで行って画面やログを見ることもありました。

フェイス・トゥ・フェイスで話をすることが効果的な状況とは例えばこれらだと思います。オンラインで伝えられることを基にし、それだけで不足であれば、気兼ねなく直接伝える・質問することができていました。

動くソフトウェアこそが進捗の最も重要な尺度です。

これはまさしくそうでした。一週間のイテレーションで新しい振る舞いを開発してテストできたかをマネジメント会議で確認していました。

設計書はイテレーションでも書きますが、それはそのイテレーションをこなすための記述に留めており、数か月、数年先のための包括的な記述は後でまとめて書きました。もう少し正確に言えば、イテレーション内で書く設計書の実態は9割以上UMLの図で、文章はほとんどありません。また、イテレーションの中で行う手動でのテストケースは典型的なもののみ記し、ほとんど文書化しませんでした。言い換えれば、イテレーション内の実機手動テストで文書化していたのはスモークテストのみなのです。

テスト結果、プロダクトコード、設計書(実態はUML) の順に進捗として重要でした。

アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

この原則にも沿っていたと思います。イテレーションは1週間(5営業日)を守っていました。ときに7営業日、10営業日になるということはありませんでした。

ただ、ストーリーポイントやサイクルタイムという数値は使っていないので、 1イテレーションでどれだけの仕事量をこなせたのかはわかりません。おそらくチームの誰も、ストーリーポイント、サイクルタイム、それどころかイテレーションという用語さえも知らなかったでしょう。

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

技術的卓越性については思い当たるところがありません。優れた設計については、それを高い保守性と解釈すれば思い当たるところがあります。

レビューから察するに、保守性を高めることを心掛けていた開発者が何人かいました。その方法ではテストを書きにくくなってしまう、密結合になってしまう、似た処理が重複してしまう、といった意見が出てくるのです。いくつか先のイテレーションで実現予定の項目を考慮してインターフェースやデータ構造を決める意見もありました。

そういった意見を出さず、それはどちらでも良いと公言する、保守性に頓着の無さそうな開発者もいました。そう大まかに分けたときにどちらが多かったのかはわかりません。

私はどのイテレーションで何を実現するか計画し、イテレーション内で設計書を書き、自身もコードを書く立場で、保守性に頓着を持っていました。もしこのポジションが優れた設計に対して無頓着であったら、いくつか先のイテレーションで進捗が停滞してしまったのではないでしょうか。

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

要求については少しは沿っていたと思います。要求同士の依存関係を考慮し、ベースとなるよりシンプルな要求から実現する計画を立て、イテレーティブに実現していきました。ただ、OEMの要望、互換性維持のために開発者からは不要に思える要求を実現することもまれにありました。

コードについて、私が直接書く範囲ではいくらかシンプルになりましたが、コードベース全体として理想には遠かった覚えがあります。静的解析ツールで無駄を見つけて消すことは全員でやりましたが、全員で取り組んだのはそれくらいだったでしょうか。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

これは12の原則のうち沿っているかの判断が最も難しいものです。エラスティックリーダーシップやチームギークを斜め読みした程度の頭には荷が重いのですが、いくつか自己組織化の要素が思い当たります。

開発者は全員実機を持っており、手動テストができる環境がありました。実機のテストはテスト担当者だけに任せということはありませんでした。
多くのメンバーは自動車(開発対象のプロダクトが搭載される環境)を運転するため、自分がユーザーならこれはうれしい、許容できないという判断をすることができます。
一部のメンバーは、他者が担当しているチケットに対して助言や関連情報を書き込んでいた覚えがあります。例えば、「●●APIを使えばできそうです」「何番と同じ原因ではないでしょうか？」など。
多くの開発者は、バグの原因を調べる際に他の開発者の担当部分も調べ、バグチケットの担当者を変更する際に推定原因をコメントします。
マネージャー(元開発者)は、低頻度ではあるものの、コードや設計書を見て助言をすることがあります。

逆に、自己組織化とは遠いと考えられる要素もあります。

プロダクトの個々の振る舞いについて1ユーザーとしての是非を判断できるものの、プロダクト全体の未来を考えることはない
新しい価値の考案はだいたい企画部門やOEM任せで、要求獲得は一部の開発者のみ関わる。大半のメンバーにとって要求・価値とは他人が定義するもの。その是非の判断はできても定義には関わらない。

ここを深堀りするには12の原則のようなよりどころ、フレームワークが必要です。本文では以上の思い付きに留めておきます。

チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

最後の原則です。ハードウェアプロダクトとして市場に出した際は振り返りをしますが、スプリントレトロスペクティブに相当する頻度にはほど遠いものです。イテレーション毎に開発チーム全員が参加するマネジメント会議の議題は計画と進捗であり、振り返りはしません。「来週からこうしてみない？」という小さくて頻度の高い改善はあったのかもしれませんが、10年前の小さなことはさすがに覚えていません。ツールと手法を採用したきっかけなら覚えています。プロダクトを市場に出した後の振り返りばかりではありません。

チケット管理ツール
- 他のチームが使って良い評判を聞き、新製品開発のタイミングで採用
UMLモデリングツール
- 誰も使えって言ってないのにいつの間にか普及してた (ただし使う図は一部)
ユニットテスティングフレームワーク
- 市場に出した後の振り返りで手動なんてやってられないという結論に
静的解析ツール
- 最初は他のチームが診断してくれた。良かったので以後自主運用。
大きなリファクタリング
- 負債に耐えかねた私が静的解析ツールのメトリクスとバグチケットの相関を示して実施決定
イテレーティブプロセス
- 顧客企業に2週間～1か月毎に出すには毎週作ってテストという結論に

おわりに

各原則にどれだけ沿っていたか、◎、〇、△、×で大まかにまとめました。

主観評価	主観評価	原則文面
〇	まぁそうっすね	顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
△	なくはない	要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
〇	せやな	動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
×	そうでもない	ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
×	ちがうかなあ	意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
〇	そうねぇ	情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
◎	これや！	動くソフトウェアこそが進捗の最も重要な尺度です。
〇	そうね	アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
△	さぁね	技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
△	ちょっとは？	シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
？	はて…	最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
×	そうでもない	チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

あの日々はどのくらいアジャイルだったのだろうか。

誰もアジャイルと言ってなかったけれども、ある程度アジャイルだったのではないだろうか。

10年前の懐古はここまで。今は2020年。未来を見よう。