bon now

ありのままの現実を書き殴る吐き溜め。底辺SEの備忘録。
Written by bon who just a foolish IT Engineer.

生産性を計測する

Created Date: 2019/08/09 01:00
Updated Date: 2023/11/05 03:00

はじめに

昨今ではマイクロサービスだとかクリーンアーキテクチャだとか、数十年以上も前からいいよ!いいよ!と言われてきた仕組みがようやく脚光を浴びるようになってきた、と認識している。 もっというと、今まで日の当たらない場所にいた理由が若干気になるところ。それをちょろっと調べると、やっぱり事前に考えたり設計したりする分のコストがモノリスアプリの構築や、 オブジェクト指向に頼った設計・実装などに比べ余計に掛かるという点にどうも理由があるっぽいことがわかった、と思ってる。

どういうことかといえば、日本限定でいうと多くのエンジニアは母数はともかくウォーターフォールやなんちゃってアジャイルみたいな開発がメインだろうし、 ソフトウェア開発においては研究が反映されている様子もそんなにないと思ってて、これらが新しい概念を取り入れるっていうのにブレーキを掛ける要因になってるということだ。 新しいプログラミング言語やツール、ライブラリは喜んでいれるが、抽象的な概念になりがちな設計・取り組みになると途端に「それは必要なのか?ソースは?」っていうやつだ。 でも思考の基準を未来においていた企業たち(Netflix、Google、Amazonなど)は今から10年前の段階でサービス間の依存性を断ち切るようなアーキテクチャの設計に取り組んで現在がある。 もちろんこれは将来の「組織の成長」を見越したうえでの戦略なので、彼らのような企業的な成長を目標としていないベンチャーや中小企業、例えばせいぜい1年に2人程度エンジニアが増える規模だとしたら、 10年後もたかだか20人しか増えないのでそこまで頑張って先行投資する必要があるのかっていう面もある。
まぁそんな感じで現状で利益も出てるしシステムに負債は溜まってるような気はするけどうまくビジネスを成長させているよねーっていう推測なのか憶測から、 平然と見過ごされてきた問題はあったんだろうなと思う。で、その問題は10年後の今少しずつ国内で「やばいね」となっているということだ。

生産性も指標を出すのが当たり前になってくる

クソ長い序文で始まったが、ここでようやく主題の話に入ろうと思う。

成長を続けるシステムと組織の品質、生産性を保つことが困難であることに気づき出したエンジニアたちは、こぞって銀の弾丸を探し出すわけだが、 そんなものは星の数もとい組織の文化やクセの数ほどあるわけで、マイクロサービスやモダーンなプログラミング言語やツールがベストソリューションだと思考停止している人々もたまにいるのが残念でならない。 Railsの生みの親でもあるDHH氏も言うように「モノリスを愛せよ」ということで組織の在り方が明確かつサービスとしてのアーキテクチャがそれなりにきれいであれば、 別に無理してモノリスなサービスを分割する必要はない。むしろその組織で本当に細分化されたサービスをメンテナンス続けていける素地があるのか?ってとこにまずは目を向けなければならないのだ。

Go界隈にちょっとだけ顔を出させていただいたとき頻繁に耳にした言葉が「推測するな、計測せよ」という言葉だった。
これはまんま今回の話にも当てはまるんだけど、要するに生産性だとかシステム品質とか組織の仕組みとかって大体の企業では指標になっていないんじゃないだろうか。 僕が前に務めてた会社の親会社である大手SI企業には生産技術部という部署があって、そこの人たちが組織横断的にいろんなプロジェクトの生産性や品質の尺度を数値化するっていう研究をやってるチームもあった。 なので、その会社にはとりあえずこれを守ってたら問題ない品質だと思われる指標っていうのが存在していて、プロジェクト進捗報告ではテスト工程時の評価数値を、 その指標に鑑みて妥当性があるかどうかっていうことを報告するタスクが存在していた。 これが当たり前のことじゃないって気づいたのは現職に入ってからで、自分の組織のタスクに精一杯なのか我関せずなのかは知らないが、結局誰も本当の指標数値を知らないってのが当たり前だった。

今後のシステム開発は、マイクロサービスだったりクラウドアーキテクチャだったり目の前にサーバーもなければsshで一括でログが取れる状況でもないっていうシステム保守・運用が当たり前になるとして、 みんながObservebility(可観測性)大事だよねっていう意識を持って取り組んでいる。 現にEnvoyだとかIstioだとか、MetricbeatやHeapstarなどのメトリックやログを取るための基盤ツールは鋭意開発されてるわけで、 怖いもの知らずにただAPIかまして落ちたらコンテナを作り直せばええんだよ!みたいなノリの運用は5年もすれば破綻するだろう。 その頃になると「マイクロサービスの罠」だとか「見えざるサービスがシステムを壊す」みたいな感じで、自分らの不勉強と無学を棚上げするような記事が増え、 それを解決するBtoBソリューションとして何某かのサービスが広告として売れだす未来が僕には見える。こうやって経済は回ってるんだなと。

システム・組織が今後も正しい成長を続けるには、やっぱり今僕らが思い返している「アーキテクチャって大事だよね」「見えるようにすることって大事だよね」っていう当たり前の現実を、 以下に人に説明しやすい具体的なもの=数値として語り継ぐことができるかにかかってると思うわけである。 今はまだ組織に指標がないんです・・・ていう人は、以下の記事を参考に自分たちができることを探してみるといい(僕もそうしようと思ってる)
大きな Rails アプリケーションをなんとかしよう。まずは計測と可視化からはじめよう。 -クックパッド開発者ブログ

ちゃんと成長している会社は、ちゃんとやってる。これはアジャイルやスクラムという開発手法でも同じことである。 当たり前のことを愚直にやっているからこそ未来は自分たちがコントロールできるようになるのだ。

local_offer
folder work