この国では犬が

本と芝居とソフトウェア

2024年のふりかえり

生活

年末なので、少し早いけれど今年をふりかえっておこう。

やったこと

昨年末には、こう書いていた。

幸い、「価値のあるものを生み出すこと」は、自分だけでなく、周りの人たちや社会にとっても利益こそあれ、不利益はあまりない。と思う。
であれば、素直にそれを楽しんだらいいのだろう。

この考えは、ここを経て、

enk.hatenablog.com

  • 僕は、世界に価値のあるプロダクトを届けたい。これが行動原理だ。
  • また、自分が楽しく、幸福を感じていたい。これも重要で、譲れない。
    • なお、どちらが第一原理かは明確になっていない。

ここまで進んだ。

sizu.me

今日は、価値を生み出している、と思えるようにする、という選択肢を手に入れた。

わかったこと

やっぱり、そうだったんだ。

価値を生み出したい。それだけは揺らいだことがない。
それを軸にしていれば、多分間違えない。

価値を生み出している、と思えることをやる。

という、暫定的な解。

森博嗣さんの「なにものにもこだわらない」という座右の銘がとてもいいなと思っていて、ひそかに裏・座右の銘にしている。（ちなみに表・座右の銘は「みんな死ぬ」。）

なので、これにもこだわるつもりはない。こだわるつもりはないけれど、一つ決めると他が自由になれる。逆説的に、（それ以外の）なにものにもこだわらなくなれる。
なので、一度そう決めてみようと思った。

次にやること

正直、一度「自由を手に入れてしまった」感覚がある。

一周目のゴール。あるいは第一部完、かな。

来年は、この自由を思い切り謳歌してみたい。

謳歌していたら、きっとまた課題が見つかるだろう。
人はあんまり自由でもいられないものだから。

追記

これ書いたあと、あれ、と思って。

考えてみたんだけど、結論は大丈夫そう。
ということを、一応追記しておく。

まず、「価値を生み出せなければ意味がない」（と思っているのではないか？）というのは「取り違え」。
「JavaScriptはブラウザで動くから、Javaも動くということ？」と言っているのと同じくらいナンセンス。*1

僕は「価値を生み出す（自分が生み出している状態）のが好き」なだけ。それ以上でも以下でもない。

他人が価値を生み出すのが好きかどうかは関係ないし、もちろん、価値を生み出さないなら意味がないとかもない（はじめからそんな話はしていない）。
それは自分に対しても同じで、好きなのは事実だけど、「価値を生み出さないなら意味がない」ということには論理的につながらない。似て非なる話。

一方で、「価値を生み出すのが好き」なのは疑いようのない事実なんですよね。
なので、自分が価値を生み出せなくなったら、「とてもつらい」と思う。好きなことできなくなるんだからね。

ここから得られる教訓は2つかなと思っていて、

  • 価値を生み出し続けられるように、健康を大事にしよう。
  • 価値を（今よりも）生み出せなくなっても楽しくいられるように、ゆっくりと違う価値観の軸も探していこう。

かな。

前者については割と大きな発見で、なぜか健康というものをなんとなく重視していない（かといって特別ないがしろにしているわけでもなく、「どうとも思っていない」）人生を送ってきたのだけれど、昨日これに気づいてから、ちゃんと大事にしよう、と思うようになりつつある。

後者については、別に今だって散歩が好きだったり、お酒が好きだったり、価値を生み出すこととは関係ない好きなことはあるから、そんなに悲観はしてない。
それでも、価値観の中心に「価値を生み出す」ことがあるとわかってしまった以上、いつか来るその喪失には備えておくに越したことはない。
まあ、こちらの優先順位は2番目でもいいかな。ゆっくり考えていく。

まずは、健康を大事にすることから。長く価値を生み出し続けられるように。

「健康を大事にする」っていう、多くの人がさっさと見つけるような目標を、こんなに大回りして見つけたのなんか面白いな。
でも、大回りしたからこそ、実感と納得感を持って取り組めると思う。やっていくぞ。

*1:Java Appletの話はしていない。

「アジャイルかどうかは、どうすればわかる？」

アジャイル

先日「アジャイル入門」的な内容でお話しする機会があったのだけど、その中で「アジャイルかどうかは、どうすればわかる？」ということに悩んでいる方が多く、「難しいな〜」と思いながら以下のリストを（一つの提案として）ひねり出した。

  1. 毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？
  2. 毎日、学んだことを計画に反映し、最善の計画に更新しているか？
  3. 計画変更のコストは、ゼロ（に限りなく近い）か？
  4. 1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？）

「これが正しい指標だ」と言うつもりはまったくなく*1、あくまで僕がこれまで学習や実践を重ねてきた中で、「このへんちゃうかな〜」と考えた提案であり、試案だ。

あくまで、「取り組んでみているけど、手応えがない」とか、「アジャイルできてる気はするけど、本当にそうなのか知りたい」といった悩みに対して、一つの手掛かりになれば、というレベルのアイデアだ。

とはいえ、案外いい線いってるんじゃないかな、というちょっとした自信のようなものもある。
この記事では、そのあたりを少ししっかり目に言語化してみようと思う。

1. 毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？

これは、アジャイル宣言の背後にある原則に示されている「価値のあるソフトウェアを早く継続的に提供」や「動くソフトウェアこそが進捗の最も重要な尺度」といった価値観を表現している。

ちなみに、原則の中には「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします」というものもあるが、これは現代の（少なくともWebサービス開発の）環境では長すぎて、競争力にはつながらないと感じる。すでに世の中には「毎日、何度も」リリースできていて、そのことから利益を得ているチームが数多くあるのだから、そこを目指すのが妥当だろう。

また、これはアジャイルソフトウェア開発宣言に示されている「包括的なドキュメントよりも動くソフトウェアを」の直接的な表現でもあるし、「契約交渉よりも顧客との協調を」や「計画に従うことよりも変化への対応を」を実現するための方法でもある。

というのも、最終受益者（≒顧客）に価値を届け続けることによってこそ、顧客との協調は最大化される。そして、本番環境に動くソフトウェアをリリースすることこそが、「変化への対応」をも超えて、より積極的に「より高い価値への変化（≒フィードバック）」を生み出していく最良の手段でもあるからだ。

2. 毎日、学んだことを計画に反映し、最善の計画に更新しているか？

1つめの項目に「変化を生み出す」という意味があるとすれば、この2つめは「変化に適応する」ことを表現している。

アジャイルソフトウェア開発宣言で言えば、ずばり「計画に従うことよりも変化への対応」と直結しているし、「契約交渉よりも顧客との協調」という点でも、最初の契約（約束）を守る、守らないといったこと（交渉）よりも、常に最良の計画に更新し続けることで、顧客との協調を実現しようとしている。

原則で言えば、「変化を味方につけることによって、お客様の競争力を引き上げます」であったり、「シンプルさ（ムダなく作れる量を最大限にすること）が本質」といった価値観が表現されている。

最初に考えたすべてを作ることが、価値につながるとは限らない。というより、つながらない可能性が高い。それがアジャイルが前提としている世界観だ。
常に計画を見直し続ける。価値の高いものから作る。価値の低いものはあえて作らず、より価値の高いものを探し続ける。それこそが「シンプルさ（ムダなく作れる量を最大限にすること）が本質」を体現する行動だ。

3. 計画変更のコストは、ゼロ（に限りなく近い）か？

これは、2つめの項目を実現するための重要な前提だ。
2つ目のサブ要素なので、リストからは省いてもよかったかもしれないが、アジャイルから遠い状態のチームからするとやや想像しにくく、重要な前提であると気づきにくい要素でもあるのではないかと思い、あえてリストアップした。

アジャイル宣言の背後にある原則の中でも、「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません」であったり、「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します」、「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです」、そして「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」といった原則に忠実であれば、これが実現できる可能性が高い。
逆に言えば、計画変更のコストが高いとすれば、これらのいずれかがおろそかになっている可能性が高い、と考えると課題を発見しやすくなるのではないかと思う。

4. 1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？）

1〜3は（決して不可能ではないが）なかなか高い要求だと思う。
おそらく、1〜3のすべてが実現できているチームは、「アジャイルかどうかは、どうすればわかる？」というメタ的な疑問で悩むことはなく、よりアジャイルになることを目指しながらも、具体的な価値提供に集中しているだろう。

だからこそ、この4つめの項目もとても重要だ。

アジャイルソフトウェア開発宣言の冒頭では、「よりよい開発方法を見つけだそうとしている*2」と宣言されている。
また、アジャイル宣言の背後にある原則の最後には「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」という項目がある。

よりアジャイルになろうとする態度や行動それ自体が、アジャイルであるための条件の一つでもあるのだ。

技術の重要性

ここまで、4つの項目がどのようにアジャイルの価値基準や原則を表現しているかを説明してきた。

ここで一言、技術の重要性に触れておきたい。
というのも、ここまで説明してきて、技術の重要性に直接言及していないことに気づいたからだ。

これらの項目が実現されている状態の背景には、もちろん、「技術的卓越性と優れた設計に対する不断の注意」が必要になる。アジャイル宣言の背後にある原則の9つめだ。

特に僕が提案している項目の1つめである「毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？」は、自動テスト、リファクタリング、継続的デリバリーに投資し、また習熟していなければ、実現できるはずもない。逆に言えば、それらにしっかり投資し、習熟すれば、十分実現可能な目標でもある。

「アジャイルかどうかは、どうすればわかる？」

最後に改めて、「アジャイルかどうかは、どうすればわかる？」という質問への数多くありうる答えの一つとして、以下の4項目を提案したい。

  1. 毎日、何度も「完成品」を「最終受益者（エンドユーザ）」に届けているか？
  2. 毎日、学んだことを計画に反映し、最善の計画に更新しているか？
  3. 計画変更のコストは、ゼロ（に限りなく近い）か？
  4. 1〜3への答えが「No」なら、日々、少しずつ、この状態に近づいているか？（そのための努力を続けているか？）

これらは、「よりアジャイルになるために、どのような判断・意思決定をするとよいか」に迷ったときの一つの指針として使ってもらえると有用なのではないかと思っている。
これらから遠ざかる判断や決定なら、アジャイルからも遠ざかっている可能性が高い。

世の中のアジャイルなチームの多くは、これらを多く満たしている（はずだ。僕の知る限り）。

これらを満たしていなくても、アジャイルだと言えるチームもあるかもしれないし、アジャイルではなくても、うまくいっているチームもあるだろう。
それらを否定するものではない。

ただ、こういう状態はとてもいいものですよ、ということを言い添えて、この記事を終える。

*1:むしろ、「これが正しい指標だ」と言い切ってしまうような態度こそアジャイルではない、という言い方もできるかもしれない

*2:原語は"uncovering"

動作するきれいなコードを速く書くための3つの習慣

プログラミング

僕はかれこれ10年以上プログラマをやっていて、それなりにプログラミングができるんだけど、最近プログラミングをしていて、「これってスキルというよりも、ただの習慣だな」と気づいたことがいくつかあった。

「スキルというよりも、ただの習慣」というのはつまり、実は10年も費やさなくても、ものの1年もプログラマをやっていればたぶん実践できるであろうこと。

もちろん、10年以上かけて身につけたスキルというものもある。たとえば設計への洞察力はそう。
でも、「習慣」は意識して取り組むだけでたぶん誰でもできるのに、（過去の自分も含めて）やっていない人が多くて、もったいないな、と思ったので、書いてみることにする。

ちなみにこれらは、Kent BeckやMartin Fowlerのような偉大な先人たちが言っていることとほぼ同じだと思うけど、特に出典は明記しない。
もちろんこれらを自分で考えたと主張するつもりは1ミリもなく、先人が言っていたことを（結果的に）まとめ直しただけだろう、ということは言っておきます。

1. 動かす前に設計する

動かす前に設計すること。

これはできる場合とできない場合とがあって、対象ドメインや既存コードへの馴染みがあまりにもない場合は、とにかくまず動かしてみる方が有効である場合もある。

でも、動かす前に設計した方がよい場合の方が多い。本当に初めてのドメインやコードに当たることってそんなにないですからね。

別の言い方をすると、いきなりコードを書かない、ということ。
今表現しようとしている追加機能や機能変更が、「何を意味しているのか」を考える。そして既存のコードを見て、そこにどう当てはまるかを考える。さらには、既存の設計をどう変更すべきかを考える。

特に最後が重要で、「機能を追加・変更しようとしている自分」は、「それまでにコードを書いた人たち」の「誰も知らないこと」を知っている可能性が高い。「新しい」機能や変更なわけですからね。
だから、その知識を最大限に使って、適切な設計を考える必要がある。

いわゆるリファクタリングだ。
これから書くコードが、もっともよく適合する構造へのリファクタリング。

もちろん、結果的に既存の設計がそのまま活かせることもあるだろうし、自分のスキル不足で、よりよい設計があっても思いつけないこともあるかもしれない。
ここで言いたいのは、結果がどうあれ、必ず一度「それを考える」、つまり「動かす前に設計する」という習慣を欠いてはいけない、ということだ。

2. 動いたあとに設計する

動かす前に設計しても、最善の設計を思いつけるとは限らない。思いつけたと思っていても、あくまでそれは「想像した最善の設計」にすぎない。

だから、動いたあとにもう一度設計する。
機能が追加・変更された「事後」のコードを見て、ドメインを適切に表現できているか、疎結合・高凝集な変更容易性の高い構造になっているか、といったことを検討し、そうでない部分は修正する。

これもいわゆるリファクタリングだ。

動かす前の設計よりも、よりよい設計にできる可能性は高い。
書かれたコードはもちろん、動かすためにコードを書く中で得たフィードバックも含めて、最も情報が多いタイミングだからだ。

そして、「動かす前に設計する」で書いたのと同様に、これもやはり「高い設計スキル」を前提としない。設計スキルが低ければ、結果的によりよい設計に辿り着けない可能性はある。それでも、「動いたあとには、設計する」という行動を必ず取ることの重要性を言っている。

3. 動かそうとしているときは設計しない

ここまで、動かす前と、動いたあとに設計することの重要性を説いた。

では、動かそうとしているときはどうか。
動かそうとしているときは、逆に「設計しない」ことが重要だ。

動かすためにコードを書いていると、「この部分が読みづらいな」とか、「ここのコードの様子がおかしいぞ」といったことに気づくことがある。
そんなとき、設計を改善してはいけない。

選択肢は2つ。違和感を保留しながら*1、動くまでコードを書き続けるか、動かそうとするのを一度やめて、「動かす前に設計する」に戻るかだ。

デフォルトの選択肢は1つ目になるだろう。動いたあとに設計すればいいだけだからだ。
動かす前にも設計していれば、大きな瑕疵が見つかることは多くはないだろう。小さな違和感であれば、目をつぶって進み、動いたあとに落ち着いて見直せばよい。

2つ目の選択肢を取るのは、動かすためのコードをそのまま書き続けるよりも、一度動かすのをやめて設計を改善したあとに改めてコードを書く方がトータルでかかる時間が短くなりそうなときだ。
この「短くなりそう」という判断には、一定の経験から来るスキルが求められる。

もっとも、この判断を間違えても大きな問題はない。
守らなくてはならない、かつ、スキルに関わらず実践できる重要なことは、あくまで「動かそうとしているときは設計しない」ことだ。それを実践するために、こらえて進むか、立ち止まって戻るかに大きな違いはない。

少しわかりづらいかもしれないので、もう少し補足する。この習慣を、こう表現することもできるだろう。

書いてみるとあまりにも当たり前に思えるが、これを守れていない場面をしばしば見かける。
設計の改善への意識が強いほど、かえって「コンパイルやテストが通っていないのにリファクタリングに手を出してしまう」ことが多いのかもしれない。

これらは単純なルールなので、意識づけさえできれば実践できる。

補遺1: 自動テストを書く

ここまでに書いた3つの習慣は、自動テストの存在を前提としている。
動かす前に書くなら、テストファーストだ。設計にも役立つ。そうでなく、動いたあとにテストを書くのでも問題ない。いずれにせよ、これらの習慣は問題なく実践できる。

テストを書くのはスキルだ。なので、3つの習慣は厳密には（自動テストの）スキルがないと実践できない、とも言える。
とはいえ、自動テストを書くこと自体は1年もプログラマをやっていればおそらくできるようになっているだろう。少なくとも、10年を費やす必要はないはずだ。

補遺2: 小さく進める

3つの習慣は、「小さく進める」スキルがあるときに最もよく機能する。
「小さく進める」スキルというのは、適切なモジュール分割であったり、Parallel Changeのような技法であったりだ。

3つの習慣を守りながら小さく進めれば、動作するきれいなコードを、風が吹き抜けるような速さで生み出していくことができる。
事前の設計（兼テスト）、実装、事後の設計と言う3つのステップを、典型的には5〜10分くらいを1サイクルとして繰り返すことができる。

読んでくれた方によっては、全然違った時間感覚を想像されていた方もいたかもしれない。それくらいのテンポの話だ、ということを付記しておく。

逆に言うと、小さく進めるスキルが低い場合、3つの習慣を守っていてもやすやすとコードを生み出すことはできないかもしれない。たとえば、1サイクルに20〜30分くらいかかってしまうようなことも考えられる。
それでも、習慣に効果がないということにはならない。相対的には遅くなるかもしれないが、それでも習慣を守らない場合よりは着実に進むことができる、と思う。

まとめ

この記事では、僕が最近「これって、（習得が難しいスキルとは違って）意識して取り組むだけでたぶん誰でもできるな」と気づいた3つの習慣（と、2つの補遺）をまとめた。

  1. 動かす前に設計する
  2. 動いたあとに設計する
  3. 動かそうとしているときは設計しない

こうして眺めてみると、これって「動作するきれいなコードを速く書く」ための習慣だな。（なので、タイトルもそうつけることにする）

読んでくれた方も、ぜひ一度トライしてみてもらえると嬉しい。

*1:このとき、簡潔なTODOコメントを残してもいいかもしれない

うまいことソフトウェア開発やっていく感じ（後編: 開発、リリース、それから）

アジャイル ソフトウェア

この記事の後編です。

enk.hatenablog.com

前編では、チームが集まるところから始まって、目的を理解し、ソリューションの仮説をストーリーに分解して見積もり、計画を立てるところまで辿り着いた。

最初の計画が立ったら、週次サイクルで開発を進めていく。
週始まりに30分程度のプランニングセッションを行い、週終わりにチームでふりかえりを行う。

日々の活動は、ペア作業をベースに、いい感じにやる。いい感じがどういう感じかは、この記事に書いた。

enk.hatenablog.com

ここからは、上の記事に表現できていない部分を補う形で書いていきたい。

週次のプランニング

週次のプランニングはチーム全体で行う。チーム全体というのは、開発者だけでなく、プロダクトマネージャーやデザイナーを含むという意味だ。*1

プランニングの前半では、手短にバーンダウンを見てペースを確認し、直近のサイクル（週）にどんなストーリーを届けられたかを簡単に確認する。
直近のサイクルで発見したことで、参加者（の一部）に共有できていないことがあれば、共有しておく。たとえば「想定以上に難易度の高い部分が見つかった」であったり、「このような機能もあった方がよいのではないか*2」であったりだ。

後半では、これまでにわかったことを踏まえて、次のサイクルに取り組むことの優先順位を見直す。
見直す、と言ったのは、最初に一定の計画は立てており、また前週までにも見直し続けてきた結果として、優先順位は一応ついているからだ。それでも、毎週状況は変わるので、優先順位も毎週見直し続ける。

最低限、次のサイクルの優先順位は全員でしっかりと確認する。それ以降の計画をどの程度しっかり見直すかは、状況による。
バーンダウンの序盤であれば、全体を大きく見直すことは少ないだろう。まだ見直すに足る情報も集まっていないことが多いからだ。

中盤に差し掛かった頃には、よほど「想定通り」でない限りは、一度全体を大きく見直すことも多い。
見直すといって、すでにあるストーリーの順番を単純に入れ替えることもあれば、すでにあるストーリーのうちひとかたまりを取り除いて、異なるストーリー群を入れることもある。かたまりで取り除くこともあれば、細かく削っていくこともある。

計画づくりとは価値の探究なのだ。
（『アジャイルな見積もりと計画づくり』）

まとめて30分くらいだが、すべて30分ですむかは日々のコミュニケーション頻度にもよる。

プロダクトマネージャやデザイナーが兼任で忙しく、日常的に頻繁なコミュニケーションが取れていない場合は、少し長めに（たとえば45分）必要になることもあるようだと思っている。

単に計画した仕事を終わらせていくための、業務連絡の会話に終始したくない。
こういう新しいことがわかった、もっとこうした方がいいんじゃないか、といった、不確実性を生かして価値を探求する会話を増やしたい。

そのために必要なら、少し長めに時間を取るのもいいと思う。
もちろん理想は、常にそういう会話ができていて、プランニングは便利な一つの区切りにすぎない状態だ。それなら、30分もかからずに終わるだろう。

日々の活動

日々の活動について前掲の記事に書けていなかった部分として、ストーリーの選択や分割がある。

バックログは基本的に優先順位に従って並んではいるが、状況は刻一刻と変わっていく。一週間の中でも、開発を進めることで新たにわかることも多い。

もし4人チームなら、2ペアだ。WIPは最大2となる。各ペアでそれぞれ1つのストーリーを進めていて、片方が終わったとする。次に何をやるか。これは自動的には決まらない。

現状を鑑みて、次に何をやるのが最善かを都度考える。一番重要なのは、価値だ。原則として、バックログは価値の高い順に並べている。作り手の都合で順序を歪めることも時には必要になるが、最小限にしたい。
現時点のすべての情報を考慮に入れたとき、次に何をやるのが一番価値が高いのか、チームでもう一度考える。計画づくりとは価値の探究なのだ。

また、ストーリーを分割した方がよいと気づくこともある。
個人的には、基本的にストーリーはできる限り小さくした方がよいと思っている。その方がフロー効率（価値の流れ）も最大化されるし、WIPが小さくなってエンジニアリングの観点でも都合がよいからだ。

ストーリーを進めていて、あるストーリーが数日間WIPにとどまっていることに気づく。そんなときは、ストーリーを分割できないか考える。そして、ほぼ必ず、分割できる。
あるいは、ストーリーを始めて、まずE2Eテストのシナリオを考え始めた時点ですぐに分割できることに気づくこともある。分割しなくてもすぐに終わるレベルなら、無理に分割しなくてもいいかもしれない。しかし、たいていは分割した方がよいという結論になることが多い。

ストーリーの分割は、隠れていた価値に気づくことでもある。ストーリーや会話の中で明示されていなかったさまざまな価値が実はあったのだ。
場合によっては、分割したストーリーのうち一部には取り組まないという選択もする。価値の大きさと、届けるまでの早さや全体のバランスを見て考える。その場で判断しきれない（また、しなくてもよい）場合は、次回のプランニングに持ち込む。

最近は、出したストーリーはすぐにチームで見積っている。見積もりは1〜2分もあればでき、特に遅らせる理由もないからだ。

週次のふりかえり

週の終わりには、チームでふりかえりを行う。

ふりかえりは、ふりかえりだ。どうすれば、チームとしてよりよくなれるか？　ということをみんなで話し合う。
特筆できることはあまりないようにも思える。

それでも最近思うのは、「チームとしてよりよくなる」という言葉には広く深い意味があるということだ。
今思えば、ずっと前、はじめてふりかえりに取り組んでいた頃は、「どうすればベロシティが上がるか？*3」だったり「チームの雰囲気をよくするには？」といった、狭く、かつ浅いフォーカスを持っていたなと思う。

ここはまだうまく言語化できないんだけど、ふりかえりには無限の可能性があるんだよな、ということを改めて考えている。
またいつか、がんばって言語化してみたい。

リリース

新機能（※既存機能の置き換えを含む）の場合、ある程度のかたまり（いわゆるMVP）で公開する。その単位を1〜3ヶ月のリリースバーンダウンチャートとして計画しているので、バーンダウンが落ち切ったときが公開のときということになる。

公開自体は、ある意味、特になんでもない日常だ。
フィーチャーフラグを使って常に本番環境にデプロイし続けており、最後にフィーチャーフラグを外すだけだからだ。

フィーチャーフラグのついた機能は特定のユーザには公開できるので、関係者には早期から公開しておき、常にフィードバックを得られる状態にしておく。

既存機能の改善の場合は、特に「リリース日」を待つ必要はない。でき次第デプロイし、即時に公開していく。週に数件は新しい機能が公開されていくイメージだ。
ちょっとした機能エリアを増やす場合、ある程度育ててから公開したい場合もある。その場合はエリアをフィーチャーフラグで隠しておき、満足のいくラインまで育ったら公開する。

それから

エンドユーザを含む、周囲からのフィードバックは常に得る。公開前から。公開してからも。
得られたフィードバックには優先順位をつけて、取り組みの優先順位を考える。ここでは特にプロダクトマネージャーが活躍する。

チームが解散しない限りは、一つのバーンダウンが終わる前には、次のことを考え始める。だいたい終わる2週間前くらいには動き始める必要がある。（もちろん、もっと前から少しずつ考えてはいる）

終わる一週間前にはストーリーを出し、見積もっておく。
次のサイクルの初めには、集まる時間を長く取っておき、新しいバーンダウンを引く。

こうして、価値を探究し続ける。

*1:「チーム全体」には本来、ユーザやドメインエキスパート、マーケティングやセールス、そして経営陣までを含む。ただ、週次の活動サイクルに必ず含めるのはプロダクトマネージャーやデザイナーくらいまででちょうどよい、という感覚を今のところ僕は持っている。他のメンバーとは必要に応じて随時連携する。

*2:「機能」といってもとても小さく、1日以内に完了できるくらいの提案であることが多い

*3:これはそもそも問い自体がよくない

うまいことソフトウェア開発やっていく感じ（前編: チームが集まってから見積もりと計画づくりまで）

アジャイル ソフトウェア

最近、だいぶチームでのソフトウェア開発がうまくなってきたなという感覚があって、どうやっているのか書き下してみる。

前提として、主にB2BのSaaSを作っているので、B2Cだったり、SaaSではなかったりすれば、異なってくる部分ももちろんあると思う。

チーム

4〜5人くらいのチームがある。
チームはマネージャーによって集められる。*1

チームの人はそれぞれ得意・不得意もバラバラだし、キャリアも知識もバラバラなので、それをうまく活かしつつ、得意分野も不得意分野もさらに伸ばしていけるように取り組む。

お互いのことを知っているとうまくやりやすいので、ちょっとしたチームビルディングのワークを行う。
最近のお気に入りはValues Cardだ。ドラッカー風エクササイズもいい。
どちらも1時間もあればやれる。

チームビルディングは一度行って終わりではなく、最初の会話をきっかけに、日々の会話や、ふりかえりのような機会で、深め続けていく。

目的

目的がある。
目的はステークホルダーによって定められる。*2

新機能を作ることかもしれないし、既存のシステムを刷新することかもしれない。その中間（両方）ということもあるだろう。
目的をさまざまな側面から捉える。ユーザは誰なのか。ビジネスにとってどういうインパクトがあるのか。時期やアーキテクチャなど、制約条件はあるのか。
はじめからすべてがわかることはない。というよりも、永遠にすべてはわからない、と言った方がいいだろう。重要なことから、少しずつ、噛み砕いていく。

ステークホルダーと話したりしつつ、目的を掴むのにはチームで1日くらいはかかる。

ある程度の目的が掴めたら、計画を立てる。
目標は、長くても3ヶ月以内で達成できる大きさにする。機能としてはごく一部でもよいので、「作りかけ」ではなく、「本当にユーザが使い始められる」状態にこだわる。

既存業務のあるものなら、実際にその業務を行っている人と何度も話しながら、ユーザーストーリーマッピングのような手法で業務フローを分析していく。これから作るソフトウェアではフローが変わる部分もあるかもしれない。そこも含めて、新しいフローの仮説を立てる。

既存業務の置き換え・最適化というよりは新しい業務フローを提案するようなものなら、ユーザと話して、ユーザが今行なっている業務の理解を進めつつ、どうすればそれをよりよく革新できるかチームで考えながら、最初の仮説を立てる。

最初の仮説を立てるのにかかる時間は、短い場合はチームで1〜2日くらいだ。
革新の程度によっては、もっとかかる場合もある。どの段階から始めているかにもよる。僕がいる環境では、ある程度の仮説がある状態でチームが始まることが多いので、長くても1〜2週間もかければ次のステップに進めることが多い。

なお、チームが継続している場合は、前の取り組みの後半から次の取り組み（目的）を考え始めておく。そうすることでスムーズにつながる。

見積もりと計画づくり

大まかな一連のフローの仮説ができたら、小さなストーリー（※タスクではなく、ユーザに届く価値の単位）に分割していく。平均的には、1ペアで1日に1つのストーリーが終わる（着手から本番リリースまで1日）くらいのサイズにまで小さくする。これは平均なので、実際には数時間で終わるものもあれば、数日かかるものもある。*3
このサイズ感は、厳密に考えなくても、経験からだいたいこれくらいだとわかるが、後ほど見積もることで、より正確に検証できる。

ストーリーの分割にかかる時間自体は、1ヶ月分のストーリーで1〜2時間くらいだ。2ヶ月なら2〜3時間、3ヶ月なら4〜5時間といったところだろうか。
ここまでチームで2〜3日くらいかけて理解を深めてきていて、ある程度目的と仮説の解像度があるので、ストーリーの分割そのものは比較的スムーズに進むイメージだ。

分割ができたら見積もりを行う。ストーリーポイントの相対見積もりがとてもよく機能する。ストーリーをチームで砕いてきて、おおむね理解が揃っているので、見積もりはかなり早い。1ヶ月分で1時間程度、3ヶ月分でも2〜3時間程度ではないだろうか。それでも、見積もりの過程で理解が深まる部分もある。
経験的に数日で終わる程度のサイズよりも大きいポイントがついたものは、さらに分割して、すべてのストーリーが一定以下のポイントに収まるようにする。（明らかに情報が不足しているものについては、例外的に保留にし、かわりに情報を得るためのスパイクのストーリーを出すこともある）

見積もりができたらバーンダウンチャートを引いてみる。たいていの場合、3ヶ月やそれ未満の「最初のターゲット日」には収まらないので、スコープを狭める。
最初のリリースに本当になくてはならないものを見極め、ターゲットに収まるようにする。

「本当になくてはならない」とは言ったが、ここで決めたものが必ずしもターゲット日にすべてリリースされるとは限らない。あくまで現時点でそう考えているというだけだ。
頻繁にあることではないが、法的要件等から、文字通り「なくては・ならない」ものであれば、余裕を大きめに持っておく必要がある。

満足のいくバーンダウンチャート（計画の初期仮説）が引けたら、開発を始める。
ここまですべてで、順調なら1週間かからないくらいだ。

デリバリーインフラの整備

新たにサービス（ユーザにとってのサービスというよりは、コンポーネントとしてのサービス）を作る場合、E2Eテストを含むデリバリーインフラ（いわゆるCI/CD）の整備が必要になる。

ここまで1週間かからないくらいと書いたが、実際にはユーザやステークホルダーと話せる時間が限られたりして、すべての時間を効率よく使えるとは限らない。というより、大抵の場合はすべてを1週間の中に詰め込むことはできないので、その間（「空き時間」に近いイメージ）にデリバリーインフラの整備を進めることが多い。
結果的に、チームが集まってから2週間後くらいに、ある程度の自信が持てる計画も立ちつつ、デリバリーインフラもある程度は整備が進んでいる、という状態になることが多い。

なお、前の取り組みからチームが継続している場合は、インフラの整備がそれほどない場合もあるが、その場合は前の取り組みの中で先を見通しながら進めているので、「手隙になってしまう」ようなことは基本的には起こらない。

つづく

ここまで、僕（たち）が普段やっていることを思い出しながら、チームが集まってから見積もりと計画づくりを行い、本格的に開発を始めるまでの流れをまとめた。

普段やっていることなのだから当たり前だが、普通だな、と思う。もっとよくできそうなところもあるな、とも思った。
この「普通」を支えている環境も大きいな、とも思う。ありがたいことだし、環境を維持し、発展させていくこともしないとな、と改めて思う。

後編はこちら。↓

enk.hatenablog.com

*1:と言うとわかりやすいと思うのでこう書いているが、実際はもっと自己組織的な感じだ。記事にとってノイズになると思ったので、そこは省略した

*2:と言うとわかりやすいと思うのでこう書いているが、実際はチームによって見出されていく部分もある。ステークホルダーによって与えられているのは「コンテキスト」と言う方が正確かもしれないが、テンポが悪くなるので、そのへんのニュアンスは省略した

*3:すべてが数時間以内に終わるのが理想だと考えているが、現状はこうだ。すべてが数時間以内に終わるようにするには、ストーリー分割だけの問題ではなく、チームやアーキテクチャ等、色々なものを洗練させ続ける必要がある