オイオイオイ書くわアイツ

ほうクソブログですか……たいしたものですね

開発プラットフォーム構想おじさん in 採用プラットフォーム構想会社

これは プラットフォームエンジニアリング―成功するプラットフォームとチームを作るガイドライン, O'Reilly の読書感想文です。

www.oreilly.co.jp

はじめに

オライリーの "プラットフォームエンジニアリング" （以下 "プラエン" ）を読んだ。 おもんねーが、故におもしろく、有意義な本だった。

まず、何がおもんねーのか。 俺が勝手に期待していたものが出てこなかったという点でおもんなかった。 期待していたものとしては、「開発組織フェイズにあわせたプラットフォームプロダクトの具体例（構成と運用含む）」みたいなもの。

では逆に何が出てきたのか。 開発全体における基盤を社内プロダクトとして提供する上での「あるべき論」が出てきた。 これは まず俺が期待していなかった、というか念頭にあんま置いていなかった ので、なんか急に出てきた感じがしておもろかった。 また、 俺がこういうのをあんま意識できていないというのはデカい問題なので、有意義でもあった。 あるいは、読んだ結果俺が負けて「はい有意義です」という気持ちになった。

特に

  1. 俺の最新の失敗
  2. 弊社がやりたがっているプラットフォームビジネス

の 2 つについて、なんとなく気持ちを得られたので、そのような話をする。

俺の最新の失敗

俺はここ数年ソフトウェアテスト屋さんとして金をもらっているわけだが、テスト整備に関して様々な失敗をしている。 以下懺悔:

  • あるレイヤーにおけるユニットテストについて、テスト自体に期待しているものを明確にできなかったので、虚無の mock で埋まった謎のテスト群を爆誕させた
  • property based testing を導入したが、運用整備について支援できなかったので、「test が通るレア arbitrary を引くまで CI を retry する」ガチャゲーを会社に爆誕させた
  • デプロイ前のリグレッションテストについて、テストケースの拡充を優先させた結果、俺以外（認証の問題で）実行できない究極属人テストを爆誕させた

最後の究極属人テストの改善として、最近誰でもリグレッションテストを実行できるようにした。 結果、最新作の失敗として 「Argo Workflows での実行を推奨した結果デバッグ性が悪くなった」 が爆誕した。

こいつの何が失敗なのか？

まず、そもそもの期待としては以下があった:

  • 開発チームがリグレッションテストを実行できるようにする
    • 実行を通じて Playwright の利用知見やリグレッションテストに関する知識を開発チーム内で広く共有する
    • リグレッションテスト実行の属人化解消を通じて DORA メトリクスの改善を目指す

ここで、以下の悲しみが発生した:

  • リグレッションテストが落ちた時に、ソフトウェア開発者が何をすべきかわからず、困っていそうだった
  • （困るので）test fail に関する質問が俺にきており、属人化が解消されなそうだった

変化予算

俺は「テストを皆さんが実行できるようにします」というプラットフォームを提供しようとしていたわけなんで、その立場から言うと

  • テストを実行してくれるアプリケーション開発者が、新しいフローに馴染むために支払えるコスト
    • これをプラエンでは 変化予算 と呼んでいる
  • Argo Workflows 利用による今後の機能拡張性

の両者を過大に評価している。 なので、俺が悪かった。

スモールスタートとしては「シンプルにみなさんのお手元で npx playwright testしてもろて、あとはよしなにコミュニケーションしてくれますか」でよかった気がする。 ので、そのようにドキュメントを編集した。 どうもすみません。

で、こういう失敗はプラットフォーム提供のあるあるですよ、といったことがプラエンにも書いてあり、良いね。

弊社がやりたがっているプラットフォームビジネス

ところで、HERP は採用に関するプラットフォームを作っていますよみたいな話もある。 これは "そういう" （オタクの本で言っているような）プラットフォームではないです、ビジネスのやつです、という話がまずある。 が、 "そういう" プラットフォームとしての側面も勿論ある。 "そういう" プラットフォームを開発・提供していく上での心構えだったり、プロダクト自体のマネジメント上の困難についても、本に書いてあった。 そういう仕事的な意味でも有意義な本だった。

上述の変更予算の話などは、ある程度知見転用ができると思う。 「プラットフォームであるサービスを使っているユーザーにとって、新機能・機能変更への追従は変化予算を消費している」みたいな形で。

逆に、プラエンは社内プロダクトを前提としていて、社内プロダクト故の市場の独占・およびそこからくる傲慢さを戒めるニュアンスがある。そこは（独占が勝利条件めいている事業サイドには）転用できないとは思う。

全体として、内容が「（プラットフォームという）プロダクトをどう作っていくか」という話なのがよかった。 ソフトウェア開発一般にも広げて考えられる内容なので。

おわりに

率直なガキの感想として、俺はこういう話を聞きたいわけではなかった。 仕事の話として参考になったが、おもしれー技術の話ではなかった。 ムカつくぜ。

しかし、同時にそういうガキ-ness に気をつけなさいというにュアンスが結構強い本であり、ガキギレをやりつつ不意打ちでお説教をくらってゴメンナサイするという、アクロバットな楽しみ方ができた。 これは読書体験として楽しかったのでよかった。 知識が役に立つとかどうとか ではない レベルの話として。

ちなみに、いうまでもないが、知識・考え方としては大体全て役に立つので、良いと思った。 本の説明文の セルフサービス型インフラやプロセスを自動化する方法を学びます みたいなところはややズルい紹介の仕方じゃねえかとも思う。

全体としてはワース。あざした。