理系学生日記

おまえはいつまで学生気分なのか

"What I Talk About When I Talk About Platforms" にプラットフォームを構築する上でのすごい良いことが書いてあった

最近、"プラットフォーム" というものについて考えることが多いのですが、martinfowler.com にすごい良い記事があがっていました。 記事の内容を忘れたくはないので、(自分にとって)大事だなーと思うことをこのエントリに残しておこうと思います。

ぼくがどこまで正確に理解しているのかは分かりませんので、正確な内容を知りたい方は、以下の記事を参照してください。

それでは。

まずはプラットフォームとは

ここでのプラットフォームの定義っていうのは、「ファイルシステムやセキュリティとかの再利用可能な機能をもったアプリケーションの動作環境」ってことになっています。 ThoughtWorks では、Digital Platform ってのを定義していてこの内容は多岐に渡るんですが、ここでのスコープは、その中の Delivery Infrastructure ってヤツが対象です。

何が問題なのか

著者が過去に経験したプロジェクトだと、インフラ・運用が技術でチーム分けされていたそうです。DBA、ミドルウェア、セキュリティ…というように。 もちろん個々のチームの中では、改善もガバナンスもコスト削減もなされるわけですが、全体としてはそれがなされないっていう問題がでてきます。

何か顧客の要望があったとしても、これは DBA チームに、これはネットワークチームに、といったチーム横断の依存関係が発生してしまって、小さな変更要望すら数ヶ月かかることもある有様。 さらに、エンジニアにもマネージャーにも、「本当に必要なことしか変更を受け付けない」というような雰囲気も蔓延してしまっていたようです。これにより、品質改善もリファクタも行われないから、さらに時間がかかるようになって…という悪循環。

どこもありますよね、コンウェイの法則だったり、"組織の壁を超えるのはオレの仕事じゃない"っていうパターン。いわゆるサイロ化が発生してしまっていました。

著者は、自己組織的なチームの動きを阻む一要因は "backlog coupling" であると述べています。 これは要するに、特定のチームに「ここをこうしたい」っていうバックログがあったとして、それを実現するには他のチームに一々依頼しなきゃいけない状況です。

どこぞの企業では、この backlog coupling が起こったときの生産性悪化は実に 10 - 12 倍に達したそうです。

やっぱりよくありますよね、こういう状況。依頼作業とか、そもそもその依頼の仕方を探すとか、そういうことに滅茶苦茶時間がかかるヤツ。 リードタイムを鑑みてスケジュールをたててみると、あれ、開発作業ってこんな短期間で実施しなきゃいけなかったんだ…とかですね。

プラットフォームが目指すべき方向

既に長くなりましたが、というわけで、「良いプラットフォームの特徴は、backlog coupling の量を減らすこと」というのが記事の趣旨だと思います。

そのためには、(他チームに)チケットを起票してアサインするみたいなことではなく、チーム自身で面倒を見れるようにすべきだし、そういう self-service のための機能をプラットフォームが提供すべきって話になっています。 これは決して固定的なインフラのテンプレートを提供するだとかで権能を開発チームには渡さないというわけではなく、開発チームに責任を持って判断してもらうということです。

個人的には、以下の記載がグッときました。

We call this type of approach a ‘superficial private cloud’ - re-labelling existing virtualisation platforms for use by delivery teams in a very constrained way, with no real intent to reduce the amount of centralised control.

(意訳) 我々はこの種のアプローチ -- 集権的コントロールを減らそうとすることもせず、デリバリチームに非常に制約された方法でしか触れさせないような、単なる「仮想基盤」のラベルを替えただけのインフラ -- を "表層だけのプライベートクラウド" と呼んでいる。

何が犠牲になるのか

AWS なんかそうだと思うんですが、機能はしっかり提供するから、アプリチームで作って動かして (You build it, You run it) っていう思想のプラットフォームの提供。

こうすることによって、アプリチーム自身が技術スタックに習熟していきますし、プロダクトの所有意識や責任感の醸成、チーム間の依存の排除などに寄与するようになり、 また、プロダクトに責任を持ち、かつ、難易度の高い問題解決に喜びを感じるエンジニアに、そのチームや企業が魅力的に映るようになるとのこと。

このあたりはピープルウェアにもあった。

一方で、アプリチームには、開発し運用する上でのあらゆる分野の判断・決断が必要になります。誰かがよろしくやってくれるから、おれは知らね、みたいなことは許容されにくくなります。これって結構でかいオーバヘッドで、 そもそも判断に足るスキル・知識を個々のアプリチームに用意できるのかってことや、いちいち判断してたら逆にスピードが出ないんじゃね?みたいなことになります。 アプリチームに要求されることって、多くなるんですね。

このため、生産性をあげていこうとすると、アプリチームが標準で使える「標準インフラ」を整備しようということになります。あれ、これってアプリチームの自律性を損なわせることにならね???

というわけで、この「自律性のもたらす多様化」と、(逐一考えさせるというオーバヘッドを減らすための)いわゆる"標準"をつくることのバランスをどうするかが一番難しいポイントであり、事前にはとても分かりません。 そして、そのバランスを見出していくためには、プラットフォームを使うことが魅力的でなければならないとされています。魅力的なプラットフォームはどういうものかっていうアイディアも書かれてはいるんですが、 結局は「自分でつくるよりも、提供されているものを使う方が良いよね」と開発チームに思ってもらうことが重要とか。

というわけで、成功のために必要な前提は 3 つ。

  1. プラットフォームの開発と運用を担当する長期的なチーム体制があること
  2. 中央集権的なオペレーションやサポートから離れ、多くの責任をアプリケーションチームに移譲することを真に願っていること
  3. アプリケーションチームへの自由と責任の移譲は、一貫性を犠牲にするということを理解していること

プラットフォームつくるのって大変だなぁと改めて思ったのでした。