よくある野良の社内ツールは、開発生産性を向上させるための手段としてスポットで生まれることが多い。
たとえば、定期的に依頼されて手作業でキックしているバッチ処理を誰かがAPI化したり、それがCLIで実行できるようになったり、あるいは不特定多数の人々が手でやっている作業が有志で自動化されツールになるなど。そして社内の口コミや告知で伝搬され、使われていく。
出来の良い社内ツールは、野良だとしても開発チームが普段の開発プロセスのなかで意識したくない複雑性や実装の詳細をうまく抽象化し、認知負荷を下げる役割を果たしている。見方を変えれば、社内ツールはチーム・トポロジー*1でいうところのX-as-a-serviceインタラクション・モードの具象化のひとつだと言える。開発チームと社内ツールを開発する人間を社内ツールがインターフェイスとなって接続している。広い目線で見ると、これはプラットフォーム・エンジニアリングの土壌なのだが、単に野良で行われてそのままになるケースが非常に多い。これを放置せず、プラットフォーム・エンジニアリングに形を変えて開発組織に持ち込めるか否かが、単なる開発組織とそれ以上の存在を隔てるポイントなのではないかと最近は感じている。
インタラクション先として責任を持つチームがいなければ、インタラクション・モードとしての社内ツールは最適化されない。社内ツールをコミュニケーション・インターフェイスとして扱うことでチーム間のインタラクション・モードが最適化されるし、結果的に社内ツールのあるべき姿... 機能、体験、そしてそれ以上、そもそもツール云々ではなくもっと本質的な開発組織が抱えている生産性の課題が導き出される。
誰かが片手間で散発的に作っているような社内ツールは短期的には生産性を向上させうるが、根本的な課題にはアプローチしない。誰もその社内ツールに責任を持っていないので、表面的に物事が楽になればそこで満足して終わる。なんならメンテもされない。本当はそこから社内ツールの成長にフルタイムである程度コミットするチームが生まれるのが理想だが、散発的なままその取り組みを終えてしまう例は多い。
また、個人的な体感として社内ツールは割と雑に扱われがちで、あれば嬉しいが無くてもいいと思われている（でも、なければ我慢して開発をするハメになる）ことが多い印象。雑に扱われる一方、ある程度効果的な社内ツールを作るためには開発プロセスを俯瞰してかつ抽象化する能力が必要なことが多く、それができる／できないの間には大きな溝がある。できる人は言われなくても勝手に良いものを作るし、できない人は絶対にやらない。技術力があったとしても、効果的なツールを作れるとは限らない。このあたりには本能的・経験的な嗅覚の有無*2を感じる。この手の嗅覚を持つ人たちには、先陣を切らせて開発組織の生産性改善をリードさせるべきだ。
いずれにしろ、社内ツールは開発チーム間のインタラクション・モードを最適化するとっかかりとしてヒントを出してくれていると思うことが多い。そういったものに対して「便利だね、作ってくれてありがとう」で終わらせず、深ぼって目を凝らしてみると、新しく見えてくるものはいくつもある。
