スループットではなくレイテンシーに注目せよ
「Jenkins」開発者が語るソフトウェア開発を進める上で大切なこと

生産性のための先行投資をどうするか？

川口耕介氏（以下、川口）：僕の記憶では10年、20年前ぐらい前は、もっとソフトウェア開発というのは個人の職人技のように思われていたと思っているんです。

最近はプログラミングもソフトウェアエンジニアリングもチームでの作業になってきていて、コードレビューとかペアプログラミングとかもいろいろありますけど、そういうのも個人の頭の中で何かを留めないという姿勢を反映した結果なんじゃないのかなと僕は思っているわけです。

それから、チームが長生きするという設定があるからこそ今度は今後の生産性の改善のために今投資をしようという合理性、そこに経済的な合理性が生まれるということが言えると思うんですね。

この辺でだんだん例えが苦しくなるんですけど、自宅を買ったら自宅の改造とかそういうスケールの大きい、家族のために自宅を改造するみたいなそういうスケールの大きい投資ができるようになります。例えば家政婦さんは家事のプロなんですけど、家政婦さんを呼んでくるとその家政婦さんが自宅のキッチンの壁を壊すことによって家庭内の動線が良くなるかとか、そういうことを家政婦さんができるかというとやっぱり難しいと思うんですね。

こういう違いがあるんじゃないかなと思っていて、日本であちこちのソフトウェア開発に行っていくつか現場の人たちの話を聞いておもしろかったのが、例えばテストとかみんなやりたいと思っているし、リファクタリングなりCI/CDなりなんでもいいんですけど、そういう人はみんな現場の人がやりたいと思っているわけなんです。

だけど、その契約の構造上「〇〇のこういう機能をこれぐらいの時間まででいくらで作ります」となっています。そこにテストを書くとかCIプロセスを作るというのは、今後育児をしていく過程が楽になるから今時間と費用と手間を使って作ろうという話ですから、契約上、そこではお金が取れないとなっていたら確かに難しいなというのは想像がつきますよね。

そこの人たちはマネージャーがたまたま理解ある人だったから、適当にごまかして「はい」と入れてもらえるという感じでなんとかかんとかやっているみたいな感じだったんですけど、そういう個人のウルトラCに頼らないといけなかったら、産業としてそういう仕組みにはならないだろうなというのもまた容易に想像がつく。

だからその辺が僕にとっては、例えばJenkinsとかそういったものが日本でより広くソフトウェア開発の現場でより広がっていくという1つの阻害要因になっていたんじゃないかなと思っているところです。こういうのでテストの自動化とかCI/CDとか、みんなこのいわば生産性のための先行投資ということをずっと考えていました。

スループットではなくレイテンシーに注目する

あとはもう1つは、スピードを上げていくためにはこういう育児の行動でプロダクトを取り囲む周りのチームがどうやってスピードを上げていくかというと、「できるだけ待ち時間を減らさなきゃ」となりましたよね。つまりその目先の変更が大事なのでその小さい変更をできるだけ早くできるというのが大事なので、そうするとスループットに注目するんじゃなくてレイテンシーに注目すると言ったほうがいいんでしょうか。

何かやりたいぞと思ってから、それがプロダクションにリリースできるスピードのほうが大事で、「やりたいぞ」と思ってから実現するまでには時間がかからないんだけど、同時並行でたくさんのことをやりたいぞというものが進行しているのが、どちらかというとスループットの話じゃないですか。なんとなく今までの大きな企業というのはレイテンシーよりはスループットにフォーカスしていた気がするんですよね。

例えば縦割りで組織を作ってデザインのプロやソフトウェア設計のプロが最初上流で設計して、実装のプロが実装して、オペレーションのプロが動かしてみたいな。そういうベルトコンベア方式というのはスループットを最大化するように想定されているような気がするんですよね。

そうじゃなくて「アジャイルに」と言葉として紹介しているわけですけど、小さな変更を思い立ってからいかに実行するかということをやるためには、むしろ個々のチームが独立に動いていて、できるだけその中で連絡を凝縮してその間を疎にすればということになる。

そういう論理的な考え方の秘訣から自然と、いわゆるフルスタックとかDevOpsとかDevSecOpsとか、そういうのがみんなここから自然と演繹されてくる考え方ということになるじゃないですか。そういうふうにしてこちらではいろいろなキーワード的なものが1つの根底につながっていると僕は思ったわけです。

スピードと品質のあんばいがどこかにある

チームが独立化することによって、あるいはチームとチームの境界が疎結合になっていくことによって、そういう働き方を支える、そういうソフトウェア作りを支えるために技術的にどういうことができたら便利なのかというのが自然と今までと変わってくることになりますよね。だからここ5年ぐらいのタイムスパンの流行りものをいろいろ考えると個々のチームの「コンウェイの法則」でしたっけ？

組織というのはオーグチャート、組織図が結局ソフトウェアのアーキテクチャのかたちになるみたいな話があるじゃないですか。まさにそれですよ。例えばマイクロサービスとかの技術で見ると、要するに「個々のチームがコンテナの中を作るんでしょ？」という話だし、サービスメッシュとかいうのはチームとチームの間の結合を疎にするために外部からという話だし。

という感じでいろいろなその働き方を支えるために技術が改善されて、その技術が改善された結果としてこの働き方により大きな合理性ができるみたいな、そういう正のフィードバックループが起こってどんどんこういったやり方がもてはやされ、かつ成功しているように見えるわけです。

ちなみにこの辺の話をすると、もう1個僕が最近非常におもしろい考え方のシフトだなと思っているのは品質保証に対する考え方みたいなのが随分変わってきて、例えばGoogleのSRE本にサービスレベルオブジェクティブという話が出てくるんですよね。

今まで品質保証といって、僕もアメリカ来てからSun Microsystemsという会社で働いていたんですけど、そこでの品質保証とは何かというと、ソフトウェアを作ったものがテストが通るか通らないかをできるだけ高い壁を立てて、完全でない品質のものが壁を通り抜けないようにするというのが考え方だったわけですよね。

でもそのSLOというのはそうではなくて、ある程度開発のスピードを最適化する、あるいは顧客満足を最適化する。スピードと品質の塩梅がどこかにあるはずだという話なので、そもそも品質が高ければ高いほど良いとは思わないという話じゃないですか。そういうのはけっこう革命的な話だとは思うんですが、なんでそういう発想が出てくるかと言ったらそれは横割りのチームじゃなくて育児は親のチームなので親が1か所に集まっているかという話ですよね。

勉強していればいいのかと。そうじゃないだろという話ですよ。確かにその点数が良いほうがいいけど、人生それだけじゃないから他のことでいろいろなバランスを考えないといけないよねと。それが例えば家庭教師のプロの方が来てその人の勉強を見て、もう片側から体育の先生あるいはジムの先生が来てオリンピックを目指すとかになったらその間で競合するプライオリティをどうするの？　という話になるじゃないですか。

被害を小さくする方法にいろいろな仕組みを用意する

そういうのがまさに品質保証の世界でも起こっていて、それとまたチームが横割りになって必要な職種が1か所にワッと集結するようになると、品質保証についてもテスト以外にも多面的な取り組みが可能になって、今実際にそういうことが起こっていると思うんですよね。

だから最近いろいろなおもしろい品質保証関係の技術があるじゃないですか。そういうのは結局縦深防御というか複合的に仕組みを守っていこうという話で、つまり今までが障害を起こさないということに注目するならば、例えば東京証券取引所のarrowheadとかはたぶんそうして作っていたんじゃないかと思うんですよ。

とにかく何年もかけて作って、そのあと何年もかけてテストして、問題を起こさないことを確認してからリリースするんじゃなくて、いろいろなところで問題が起こってもその被害を極力小さくする。金融だったらそういかないかもしれないんですけど、被害を小さくする方法にいろいろな仕組みを用意する。

だから建物とかでも例えばビルだったら火事にならないように設計するわけですけど、火事になっても例えば防火壁みたいなものを作って延焼を防ぐための仕組みとか、避難通路みたいなものを設計して、その周りだけ燃えにくいようにしたりとか、smoke detectorみたいな煙の探知機があって火事が起こっても素早く検知できるようにとか、いろいろな仕組みがついています。

火が付いたら終わりみたいにはなってなくて、まさにそういったことがソフトウェア産業でも起こっていると思うんです。だからこうなってくるとQAというのは1つのジョブファンクションじゃなくて、アーキテクチャとか設計とかによって品質を担保していくという話になるので、今思えばユニットテストが流行り出したときも同じようなことがあったんですよ。

そのときにクラスの設計の仕方とか、「このデザインパターンはテストしやすいけどこっちはしづらいから」とか、そうやってそのソフトウェアの書き方自体もユニットテストがいろいろな技法の影響を及ぼしているじゃないですか。

そういうことがもうちょっと広い範囲で今は起こっていて、これからもっと続いていく流れだと思います。これがまた、さっきの正フィードバックループという話をしたんですけど、こういうことをやる技術がどんどん確立されていろいろな知見が溜まっていくとますますメリットができてと、今まさにそういう時期ですよね。

こういうことをうまく活用していくにも結局その横割りのチームじゃないと難しい。だから人々の、僕らのコラボレーションの仕方に合わせて技術が進化しているので結局そこが変わっていないと、それがあっていないとこういう技法だけを取り入れてもうまくいかないんじゃないの？と思うわけですよね。

高頻度リリースの先へ

それからもう1つ最近時々あちこちのエンジニアリングブログとかで、データベースを停めないままに大きな変更をやりましたとかそういう記事がいろいろ載っています。リリースの速度が上がってくると、あるいはリリースの頻度が上がってくると初めてできるようになる種類のプラクティスがいろいろあるんですよ。

自転車は止まったままだと乗れないみたいで、例えばデータベースの無停止変更みたいなものはまさにその最たる例で、頻繁にデプロイしてちょっとずつ今の書きかけのソフトウェアをリリースし、その挙動を見ながら小さな切り戻しと、小さな前進を繰り返していけるということが前提になっているからできるプラクティスみたいなのがあるじゃないですか。

そういうものがまたいろいろな国の知見が溜まっていて、これが今僕の中でおもしろい分野の1つです。これがもっといろいろな技術が確立されたらこの速度がどんどん上がっていくはずだし、そうすると取り残されている人たちと先に行っている人たちの格差がどんどん開いてきてしまう。そういうことがあるので僕としては危機感がなくもないという話です。

あとはチームが独立してとか、自発的に・自律的にという話をしているんですけど、でもチームが完全に自律していたらそれはたぶん村文化で江戸時代の日本みたいに、隣の藩に行くとしゃべっている言葉がぜんぜん違うしお金も違うと、そんなふうになっちゃう。もしそうなっちゃったらそれはスケールメリットというか規模の経済が効かなくなっちゃうので、それは決していいことではないと思うんですね。

必ずそのこういう文化のどこかのタイミングで標準化とある種の垂直分業みたいなのが必ずやっぱり必要で、だから縦割りダメなんだ、横割りバンザイみたいな話かというとやっぱり必ずしもそうはなっていないんですよね。それがおもしろいところで、だからこちらであちこち行って思うのは会社としてソフトウェア開発がうまく回っているところは縦割りと横割りの引き方がやっぱりあるんですよ。

それがうまくいっているか・うまくいっていないかで大きな違いがあるんですよ。たぶんこの話のわかりやすい例の1つはGoogleみたいな会社だと思うんですけど、モノリポとかいろいろ言いますけど、会社全体のソフトウェア開発のやり方としてこうやるんだというのが決まっていて、あるいはそれができあがっていて、そうすると村文化にならないですよね。

僕らの働き方が変わると取り巻く技術が変わる

ある種の共通になっている部分がある。それを使ってデベロッパー、プロダクト開発者の生産性を向上するとなっている。なので、この垂直分業のより戻しに合わせて、それに相当する技術の作られ方みたいなのがあります。基本的に今日の僕の話のテーマは全部それで、要するに僕らの働き方が変わると取り巻く技術が変わるんだぞという話です。

こちらでよく見る2つのパターンの垂直分業は、1つはよくDeveloper Productivity Engineeringと言うんですけど、ソースコードを書いたあとの見えない後ろのブラックボックスを司る人たちがいるんですよね。

たぶんイメージとしてはGitOpsみたいな感じで、開発者の人たちはソースコードリポジトリをいじってプルリクエストとかを作ってマージしたりしているだけなんですけど、その後ろでそのGitとあるいはプルリクエストみたいなものをブレンドして見えないところで巨大なさまざまな自動化を施されたパイプラインとかCI/CDインフラとかがあるわけじゃないですか。

それを作っている人たちがいて、その人たちがいい仕事をしているとアプリケーション開発者の人はすごく余計なことをやらずに効率よく開発できます。これは大事な垂直分業の一例だと思います。あともう1つはSRE的な仕事で、ここも責任の分担の境界線があってそれは何かというとコンテナの中と外みたいな話ですよね。

だからコンテナの中は横断的チームが作って、コンテナの外はSREが面倒を見てという。そのチームの境目が疎結合にできないといけないので、そのために技術的な担保としてサービスメッシュみたいなのがあったらSREチームはコンテナの外でネットワークのレイヤーでいろいろできるし、マイクロサービスチームは、子育てチームはその中でやりたい放題できるし。

昔の基盤チームがTomcatのインスタンスを作ってその上にWebアプリをデプロイするみたいなのと何か似ているんだけど似ていない。やっぱりそういう分業のバウンダリが動くと技術のバウンダリがそこで動くんですよ。

こういう垂直分業によるスケールメリットが組織の生産的資産と呼んでいるんですけど、開発者のスピードを加速するためのインフラみたいなものを社内に積み上げていくということを可能にしています。今いわゆるソフトウェア開発が超絶できている会社とぜんぜんできていない会社の何が違うのかといったら、まさにこれに尽きると僕は思うんですね。

（次回につづく）