DevOpsDays Tokyo 2023のレポートになります。
初めに、私は社内公募制度で2022年12月に異動してきたため、インフラ・DevOps・SREなどの経歴は浅めな部類に入ります。
そのため、今回の講演を通じDevOpsという概念を体系的に知ることができたと感じています。
特に印象に残ったマイケルフェザーズ氏の講演「DevOps, Development Cadence and the Product Life Cycle」について紹介します。

DevOps, Development Cadence and the Product Life Cycle

このパートでは、アジャイル開発の導入後に発生した課題と、DevOpsによる改善についての講演が行われました。

アジャイルからDevOpsへ

初期のアジャイル開発では、小さな組織ではうまくいった。
しかし、プロダクトの肥大化に対して、大規模なチームではコミュニケーションコストが増大、小規模なチームでは開発に専念しないといけなくなりプロジェクトが滞るという課題に直面した。
この課題に対処するために、チームを細分化し、各チームで開発をする時間と、プランニングをする時間を設けるようにした。
その結果、開発がエピソード的(後述の質疑応答に記載)になった。
ずっと開発をするのではなく、昼働き、夜休むみたいに人間的な働き方ができるようになり、燃え尽きを防ぐことができるようになった。

つまり、開発をエピソード的にするというのは、緩急をつけて仕事をするということであり、この結果細分化したチームが独立して仕事ができるようになる。

  • 停止して再開するを繰り返すことで、DORA(DevOps Research and Assessment の略称で、DevOpsの導入状況と企業のパフォーマンスを調査・結果報告書を行う組織)のメトリクスの効果が増える。
  • たとえば短距離走の選手はずっと走って良い成果を出しているわけではない。休む、トレーニング、走るを何度も繰り返して良い結果を出しているのであり、これと同じことがエンジニアの開発にも当てはまるということである。

プランニングと開発を繰り返すライフサイクルに沿って進めることで、作業が停滞したり障害が起きたりしたときに振り返れるようになった。
また、ずっと開発をするという状況から脱出し、開発者は健康的に仕事ができ、プロダクトの品質の向上につながった。

3Xのフェーズ

プロダクトには、3X(Explore,Expand,Extract)というフェーズがある。

  • Explore 市場を探索する・・・プロダクトを通じ、顧客に価値を提供できるかを調べる。
  • Expand 市場を拡大する・・・このフェーズでは、数ヶ月先に成果を出すためにプロダクト・人材に投資する。機械のように開発者が使われてしまい、燃え尽きないように、エピソード的な開発をすることが重要。
  • Extract 技術的な洞察やプランニングをする・・・プロダクトの成長には限界点があり、限界点に達した時に見直すことが必要。ここで、時にチームのリファクタリングを行う。

質疑応答

忙しくても緩急をつける(=エピソード的な開発をする)コツは？

  • 意思決定をし、チームを必要最小人数に絞る。
  • 忙しい原因を見つけ対処する。
  • 燃え尽きが起きている人がいたら異動する。

などの対処法がある。

エピソード的というのは具体的にどういう意味なのか？

開発、リファクタリングなど振り返って完結性があることをエピソードと言う。
ずっと同じことをするのではなく、なにかやって見直して、またなにかする、のような波のある緩急のあるリズムに沿った作業をさせることをエピソード的と言う。
同じペースで同じ仕事することに問題を感じない人もいるが、大抵の場合エピソード的に作業させた方が良い。(その方が成果を出しやすくなるため)

チームが成熟期に入ってもうまくいくにはどうしたらいいか？

チームを作っては解散することを繰り返すと知識を増やすことができ、解決につながるかもしれない。
これを、チームをコード化すると言う。(コードのように扱う、コーディングとリファクタリングを繰り返す)

集中する部分とゆっくりする部分が必要なのなら、切り替えはどのように決めるべきか？

前ほどクリエイティビティが出ない、問題解決が出ないなどがスローダウンするサイン。
指標を決めた上で意識して、物事がうまくいかない判断基準をわかるようにしておく。
そのために、価値が出るのは何かを明らかにする。
小さなチームにして意思決定権を持たせる。

3Xについて Expandに沿ってプロダクトをどこまでも拡大したい人もいると思うが、Expandと、新しい商品を作るExtraxtの境界を見極める方法はあるのか？

多くの企業はシステムを寿命を超えて生きながらえさせたいと思っている。
しかし、コストなしでこれ以上成長できないという地点が必ずある。
そうするとユーザーが自社の製品から競合製品に離れていってしまう。
つまり、プロダクトには自然のサイクル寿命があるということだ。
このプロダクトの使命は何か、追加しても限界には達していないか、この問いかけが新しい商品を作るためのextractと商品を拡大するためのexpandの境界線である。

感想

DevOpsという概念を体系的に学ぶことができたことに加え、具体的な改善例や質疑応答の内容を交えてDevOpsの実践例を学ぶこともできました。

アジャイルと比べると、DevOpsは仕組みの改善、マネジメントやチームビルディング的なアプローチからの課題の改善、人材のモチベーション維持など経営学的な面でのアプローチが多いと感じました。
DevOpsエンジニアとして成長していくには単に技術的なスキルがあるかだけでなく、技術を使ってどう改善するか、技術以外の方法でも改善できないか、などを考えていけるかが重要そうです。

そして、これからの時代、価値のあるエンジニアになるためには、技術スキル+何らかのスキルを備えたエンジニアになる必要があると思います。
目先の技術スキルを持っているのは当然で、それだけでは時代の流れに遅れをとっている、ということです。

かつてただ単に物をたくさん作って売る時代から、作るためのコストを削減したり売るための経路を確保したりする時代に産業構造が変化したように、エンジニアもただコードを書くだけでなく、技術力とDevOpsなどの知識を活用してどう企業の経営改善に活かしていくか、生かすための思想や哲学などを身につけていく必要がありそうです。

自分自身も、インフラ関連の学習を進めていくこと、それにと並行して以下の取り組みを進めていきたいと思いました。

  • DevOpsに関連する思想や哲学を学び積極的にアウトプットすることで、社内の文化醸成に貢献する。
  • DevOpsに留まらず、その先にあるデベロッパープロダクティビティという思想を学び、今後の時代の顧客に価値を提供する方法について考察する。

プロフィール

T Kato
T Kato
新卒でSIerに入社し、その後メンバーズに転職。
フロント案件を主に経験していたが、インフラ周りのスキルを身につけたいという思いから社内公募制度を利用し、2022年12月に異動。