ID:61619さん

「使われるものこそ機能」・「品質も機能」を追求するプラットフォームエンジニア

AI のおかげで開発速度は非常に早くなり、機能開発のコストは急速に小さくなっている。 だからこそ以下の 2 つが重要である。 1. 「使われるものこそ機能」の追求 競合他社との非常に激しい競争に晒されている中で、とにかく機能を追加する方向に向かいがちである。 しかしマーケティング要素の色が濃い求められない機能（「AI で xxx」のような派手に映るが顧客にペインにハマっていないもの）や求められてはいるが磨き上げられていない機能（使い方が分かりづらい、かゆいところに手が届かない）は大きなアウトカムを産まない。 そのためエンジニアはよりドメインにディープダイブするところに時間を割いて、本当に顧客のペインを解消するのかにフォーカスすることが重要だと考えている。 そして具体的な how として、ドメインにディープダイブすると言うとユーザーインタビューなどが思い浮かび、それも良いが、よりすぐ出来ることとしてドッグフーディングをやることが挙げられる。 開発コストが小さい≒作って捨てやすい状況なので、とりあえず作ってチームで触り、「これは使いやすいだろうか？」・「ユーザーのペインは解消されるだろうか？」を肌で感じていくことでドメインを知っていくことがエンジニアとしてバリューを出せると感じている。 2. 「品質も機能」の追求 機能追加に手を取られ過ぎて品質が疎かになり、機能数は以前より増えたが、比例して障害の数も爆発的に増えてしまい、顧客対応やバグフィックスなどで運用の手間が無視できなくなるケースを肌で感じている。 これは何よりもプロダクトへの顧客の不安・不信を生み出す点で絶対に改善していくべきである。 原体験として、新卒で営業として働いていた頃、新しいシステム導入が全社的に決まった時の話がある。 今まで顧客からの問い合わせを全て電話で受けていたところをシステムに切り替えてメールで対応できるようにするというものだった。 しかしシステムの品質は甘く、導入日はほとんど電話で応対することになり、中途半端にシステムで受け付けられたものはメールで対応になって二重管理になってしまった。 改善のための具体的な how として、捨てやすいところと守るべきところをキッチリ分けて速度と品質のバランスを今以上に取っていくことが重要だと考えている。 例えば API schema や db schema はプロダクトのアーキテクチャの全体にかかるために変更のコストが高いことが多い。 これは設計書を書いたり、チームで詳細にレビューをするなどして品質を担保する必要があると考える。 一方で特にフロントエンドの実装やバックエンドの細かなところは API schema と db schema さえ品質が高ければある程度 AI に任せることができると感じている。 こういったところは組織文化やメンバー構成にもよるが、 PR も review を必須とせずにセルフマージしていくなどのやり方もあると考える。（もちろんチームの規約に基づいた AI review を入れる、 lint 等で一定の品質は自動担保するなどは前提とする） そして 1 と 2 を実現するには、エンジニア個々人の頑張りも重要だが、組織としてレバレッジをかけていくには何よりプラットフォームエンジニアリングが重要だと考えている。 例えば 1 のようなとりあえず作って試すためには local で動作確認できる状態やあるいはブランチ環境などがあるとやりやすい。 また顧客データの分析のためにデータについてのプラットフォームの使いやすさも肝要と考える。 2 の場合は障害になる前にアラートとして検知できる、各種メトリクスをダッシュボードで見れるようにする等があるとやりやすい。 プラットフォームエンジニアリングは顧客が社内の機能開発者であり、機能開発を経験してきた身としてプラットフォームエンジニアリングに挑戦したいと考えている。