今日から二日間DevOpsDays Tokyoに参加しています。
1日目はめちゃくちゃ楽しみにしていたMichael Feathersの基調講演を聞いたので、その様子を書いていこうと思います。
アジャイル開発の誕生
最初は導入として、アジャイル開発の歴史をたどっていきました。
アジャイル開発以前のソフトウェア開発では、何かを開発して他のチームに引き渡しするとプロセスがスローダウンしてしまいデリバリー速度が遅かったことに対して問題意識を持っていたそうですが、この問題意識に対応する形でアジャイル開発が生まれ、この状況が好転することを皆が期待していたという話がありました。
アジャイル開発×大規模開発
しかし、実際にアジャイル開発に取り組んでみると、アジャイル開発は小規模ではないPJ(7名を超えるようなPJ)にはコミュニケーションパスの増加問題から適応できないことが分かったということでした。
この状況を受けてMichael Feathersは「アジャイルを6名以上のPJでどのように適用したらいいのか？」をKent beckに聞いたそうですが、「6人でできるような部分だけ自分に任せて。あとは他のチームにやってもらおう」とこのときに言っていたそうで、アジャイルは大規模なプロジェクトに対応するものではないことを実感したそうです。
成熟したプロダクトで重要なこと
アジャイルの簡単な歴史を辿ったところで、それでは成熟したプロジェクトで大事なことはなんだったのか？アジャイル開発はここにどのように関わってくるのか？という話に移っていきました。
大規模なプロジェクトは往々にしてプロダクトが成熟している状態であることが多いため、チーム数, プロダクト数, 曖昧さ...など考慮が必要な変数が多くなると同時に、市場からのフィードバックが遅くなるということです。
こうなってくると、フィードバックサイクルを回す間に「開発チームをフルタイムで働かせないとだめ」という考え方が出てきやすいのですが、その考え方に従うのではなく、より人間的な考え方(フルタイムで稼働する時期とゆとりを持っている時期の緩急をつける考え方)こそが大事になってくるという話がありました。
自然で人間的な働き方
フルタイムで稼働する時期とゆとりを持っている時期の緩急をつけるのが重要だという話から、それがアジャイルやDevOpsとどのように関わってくるのか？という話に移っていきました。
最初にアジャイルとの関連性ですが、これは初期のアジャイル開発で重視されていた「開発者が燃え尽きない」という考え方と、プロダクトのデザインを自己完結型のチームが裁量を持って行うという考え方と関連してくるということでした。
持続可能な働き方は人それぞれではありますが、チームや個々人で持続可能な働き方について検討し、話し合いをしていくことが重要だということです。
次にDevOpsとの関係性ですが、これはコードを頻繁に書いてコードを頻繁にデプロイすることに着目しすぎないことが重要だという話でした。
常に高いデプロイ頻度を保つことよりも、緩急をつけるタイミング(緩やかに働いているときからフルタイムで働こうとするタイミングに移行した時)で、どれだけ早く高速なデプロイ頻度に組み込めるのか？が大事だということです。
3Xモデル
最後に、Kent beckの3Xモデルの話と持続可能性のお話がありました。
最初のExploreでは市場を探索するフェーズにあたり、ここではまだプロダクトバックログが生み出されることもなく、燃え尽きるようなことも起きにくいそうです。
その後のExpandでは、小さな実験をして活動に価値があることを見つけて方向づけするのですが、ここでは技術的なバックログと未来への投資をするバックログが作られ、徐々に開発者がフルタイムで常に働くフォースが強まってくるということでした。
最後のExtractでは、より大きなバケットに提供できるようにスケールアップをしていきますが、ここでは機能を追加するためにひたすら開発するようなフォースが働きやすく、(自己完結していないチームでは特に)燃え尽き症候群や開発者の疲弊が発生しやすいということです。
このモデルは、開発者がコーディングにとどまらずに様々なスキルの向上をしていくことが重要になってくることを示唆していて、様々な開発者の力を集結させてエピソード的にプロダクトを作っていくことが重要であるという話がありました。
質疑応答
トークの後は質疑応答がありました。以下、内容を常体で記載していきます。
今日の話の中ではリズムの話がたくさんあったが「適切なリズム」とはなにか？
人によって食事の回数が異なるように、大まかには一緒でもプロダクトによって全然違ってくるので、個々人やチームが考える必要がある。
そんなことを考えることが無駄だと考えてしまうのはもったいない。
チームが自己完結していることが重要だし、アジャイルはそのためにもある。
最後のまとめでお話いただいた「チームが自己完結している」というのはどういう状態と捉えれば良いでしょうか？
チームが独立していること。Team Topologyの考え方が参考になるかも知れない。
すべてのチームがストリームアラインドチームになるのが理想的だが、そうでない場合はチームが独立できるようにチーム分割を検討した方がよい。
ゆっくりする部分がなぜチームにとって必要か、燃え尽きるリスクになぜ対応しなければいけないのか、を(スタートアップような)「将来、燃え尽きてもいいから、今、開発者に毎日コードを書いてほしいステークホルダー」にどのように説明すればいいのか良いアイデアはあるか？(英語にした結果ニュアンスがうまく伝わっていないとのフィードバックがあったので回答がややずれている可能性あり)
前提として、分かっている人も分かっていない人もいるのは仕方ない。
顧客をよりよく理解してコードをよりよく理解するのが重要になってくる。「スタートアップから」だからではなく、同じものとして捉えることが重要。*1
一般的に日本の多くの会社は兼務をしており複数PJに関与しているが、その際にどのようにフルタイムで働かず緩急をつけて働けるようにできるのか？
まずは互いに教育しあえていたり共通の価値観を共有できていることが重要。
その上で認知的負荷の考え方が大事になってくる。自分のやるべきことに集中できるようにするのが大事。
燃え尽き症候群が出てしまった場合
知識の格差が出てくるのも仕方がない。一つのレバーで何かができることはないので、何が起きているかを観察するのが重要だが、燃え尽きが始まってしまったなら例えば異動を検討したりすることが大事。
「エピソード的」という概念があまり理解できていないので補足が欲しい(参考書籍などはあるのか？)
自分(Michael Feathers)が書こうと思っていたくらいなので書籍は出ていない。
営業は、顧客に売ることができれば嬉しい。同様に開発者もコードをきれいに書ければ嬉しい。
でも、開発者はコードを書けたとしてもそれが価値につながっているのかは分からない。だからこそ、コードを書くことやたくさん働くことに注目するのではなく、一塊で価値を捉えることが重要だと思っている。
チームが成熟期に入ってExtractに入る時チームのコラボレーションは必要不可欠だと思っている。プロダクトを切ってなるべく小さくというアイデアはあるが、プロダクトを切ることは現実問題としてできないこともある。こういう場合にチームでコラボレーションするためのアイデアはあるか？
まずは難しく感じないことが重要。
ダイナミックルーティンがいい方法の一つだと思う。
あまりよくわからないものは自分で手を動かしてみることが大事なので、数ヶ月単位で様々な側面を見るなどが一つのアイデアとしてはある。
エンジニアはお金と政治の話は疎いところがある。でも一つの会社としてやっていくならどうしても必要になってくる話だし、この場にいる人はエンジニアを超えないといけないと思っている。Michael Feathersはどのように思うか？
昔のSF小説で、「未来はここにある」という話があった。それぞれ望む仕事のスタイルがあるし、それぞれ違う指向を持っている。
以前Michael Feathersはアジャイルカンファレンスに参加した時、その考え方を広めようと思ったが、仕事を給料をもらうための手段としてしか捉えていない人にはアジャイルは相性が悪いことが分かった。
なので、どの仕事のパスを選ぶのか？というのは重要だと思っている。皆が質問があったような人になる必要はないかもしれないが、質問にあったような考え方を持った人たちが集まって仕事をすることが大事だと思っている。
開発にリズム（つまり緩急）がある場合にはどのように 4 keys を測り、どのように良し悪しを判断すると良い？？
どういう風にうまくいった/失敗したという判断をしたいという話なら、
- チームの健全性
- 人や組織の特性
- プロダクトのステージ
などを基に考える必要がある。
集中する部分とゆっくりする部分が必要と言うことだが、切り替えるタイミングはどの様に決定するべきか？ゆっくりするタイミングを見つけることができず、疲れてしまう事が多い
自ずと決まってくる(続けられない)こともあるし、問題解決の速度低下という形で出てくることもある。
プロダクトの意思決定をチームが行うようにすることが重要。小さな自己完結したチームが意思決定を行うから、適切な判断ができる。
異なる技術スタックを統合する際に何をやっていくのが大事か？
Active knowledgeが重要な考え方になる。
チームが移動しても成立するようなエコシステムだったりフロンティアの考え方、「場」を作るための考え方などがポイントになってくるが、詳しくはActive knowledgeを見てほしい。
プロダクトをどこまでも Expand したいと思う人もいると思うが、どこが Extract との境界か見極める方法はあるか？
聞きたくない人も多いと思う回答だが、多くの企業が寿命を超えてシステムを続けさせようとしている事実がある。
コストなしではこれ以上に成長することができなくなるタイミングになると、競合製品に離れてしまうような段階になる。
プロダクトには自然なサイクルがあり、成長期は続くものではない。「機能は作れるけど、これを追加してもこのプロダクトとしてはもうしょうがないな...」と思えてしまう段階が一つの目安になると思う。
*1:回答の冒頭には「レガシーコードにまつわる質問をなぜ私にするのか？他の人にしたほうがよいのでは？」という冗談がありました笑
