はじめに
簡単に自己紹介いたします。
フロントエンド・バックエンドのエンジニア、マーケティング担当として広告運用やSEO対策を行い、Webディレクターとしてサービスの成長をサポートしてきました。
これまで、行政が利用するシステムの開発、大手ベンチャー企業が運営するサービスの開発、数千人規模の事業会社の社内システムの開発と運用を経験しました。
エンジニア時代は、コードを芸術と信じて取り組んでいました。
これまでの経験の中からいくつかのエピソードを紹介しますので、似たような経歴を持つ方々の参考になれば幸いです。
エピソード1 コードに命をかけた元エンジニアの教訓
私はエンジニア経験が長く、大手ベンチャー企業でコードの書き方や効率に非常にこだわって、それなりに信念をもってやってきました。
『コードは芸術』
これは私が実装しているとき、常に意識していたことです。いかに読みやすく、いかに効率的に書くかを追求していました。ここで言う「芸術」は、変数名やクラス名の命名といった表面的なことではなく、処理そのものの設計や責務に関する部分です。
もちろん、書くコード量が少ない方が不具合の発生場所も少なくなりますし、当時は「コードそのものが設計書だ」という文化の中で働いていました。そのため、メンテされないコメントよりも、動くコードに命をかけていました。
月日は流れ、いつの日かプロジェクトマネジャーといった立場（PdMという言葉がまだなかった時代）で、それは起こりました。
これもっと効率化できるよね？
エンジニアは自分の仕事に対して丁寧に取り組むべきだと考えていたので、コードは書いた本人が丁寧に仕上げるべきだと考えていました。
できあがったコードを見て、『これってここをこうして、こっちに切り出して、こうあるべきじゃない？どういう設計方針なの？？』と実装面に関して、指摘をしてしまっていました。
ユーザー（利用者）に対しての価値は変わらないが、芸術性を追い求めるあまり、チーム全体の効率や協力を考えずに行動してしまったのです。
エンジニアとしての信念も大切ですが、チーム全体の調和と効率を考えることも重要だと学びました。
エピソード2 UMLで会話するのが最も確実だった
もちろん、エンジニアによって業務知識の深さはさまざまです。丁寧に背景を共有したつもりでも、いざ具体的な機能の話になると、意図せず認識が食い違ってしまう場面もあります。
UMLを使ってみた
たとえばユースケース図で誰がどのような操作を行えるのかを視覚的に理解できる、かつ要求事項の整理にも使えるのでここから意識を揃えにいくのが早かったりします。
（サンプルとして銀行のATMを事例に説明します）
利用するデータに関してもこのようにシーケンス図を起こして扱う情報や条件についてもイメージを伝えるとすんなり意識を合わせられます。
ただし、この通り実装をお願いするのではなく、あくまでもイメージになるため、現状の実装状況をもとに適切に判断してもらうことも事前にすり合わせておいた方が良いです。
まとめ
大事な部分としては、お互い役割があり、それぞれの領域に責任を持つことだと思います。
互いの領域に踏み込みすぎることなく、共通言語を使ってコミュニケーションを取りながら、関係性にズレが生じたときに修正できる。
そのような関係性でプロジェクトを進められることが、エンジニアとPdMの「ちょうどいい距離感」だと考えています。
町田聡史 Satoshi Machida
プロダクト&マーケティング事業本部 クライアントプロダクト本部 プロダクトマネジメント統括部 PdM2部
パーソルキャリアに入社後、プロデューサーといった立場で「doda」のサイト/アプリ、新規サービス、社内DX領域のシステム開発における企画・推進を担当。
