TOPSoftware > 開発者向けの社内プラットフォーム、構築のポイントは(中)

Software

開発者向けの社内プラットフォーム、構築のポイントは(中)

2021/04/07

Scott Carey InfoWorld

 現在、Two Sigmaの社内プラットフォームは、コードのビルド、テスト、レビューのためのGit環境と、そのコードをコンテナにパッケージ化するための内部実行環境で構成されている。運用、モニタリング、コンプライアンスなど、背後にある事柄について、開発者は意識する必要がない。

 「何より重要なことは、プロダクトという観点でアプローチすることだ。エンジニアは、社内向けのツールをプロダクトと捉えなかったり、ツールの連携について考えなかったりする場合がある。社内プラットフォームのチームは、その部分でつまずくことが多い」

 社内プラットフォームチームが発足すると、次に必要となるのは、開発者たちが抱えている主な問題を探り、例えば操作性の向上や、デプロイの負担軽減など、どんなメリットを打ち出せば開発者たちの関心を引いて導入を促せるのかを見極めることだ。十分なトレーニングとサポートのもとで、プラットフォームの利用へといざなう。

 また、技術的負債の問題もある。「社内プラットフォームに簡単に置き換えられないレガシーシステムに関して、多くの課題がある。社内のコードを全面的に書き換えさせたりすることなく、新たなプラットフォームに移行してもらうにはどうすればよいか、開発チームと力を合わせて方法を考える必要がある」

Twitter:IDPで目指すは2倍の生産性

 米Twitterは2011年にビルドチームの一元化に乗り出した。その後、2014年には、社内にEngineering Effectivenessチームを立ち上げ、開発者の生産性と満足度を高めるための取り組みを始めた。

 同社のプラットフォームリード、Nick Tornow氏は、「まずはベロシティを追求するところが始まりだ」と話す。「ここでのベロシティの定義は、エンジニアが所定の時間内に提供できる機能の数だ。それを2023年末までに倍増したい」

 これだけ野心的な目標を大規模に達成することは、実力派のエンジニアを大勢抱えるTwitterのような企業でも簡単ではない。IDPを扱っている多くの企業と同じように、対処可能なサイズまで問題を細分化することが鍵となる。

 「共通の特徴や、エンジニアが対応を迫られている共通の問題を探る」とTornow氏は言う。プラットフォーム指向の多くの企業と同じように、開発者がたどるべき道筋を用意するのがIDPだとTwitterは考えている。テストにBazelを使ったり、データパイプラインにKafkaを使ったりといったように、オープンソースソフトウエアで既に用意されている道筋があれば、なお可だ。「独自路線で行くのは、代わりの選択肢がない時だけだ」

翻訳:内山卓則=ニューズフロント

↑ページ先頭へ