初めまして。グッドパッチでプロジェクトマネージャーを担当している星と申します。
私は前職がソフトウェアメーカーで、QA（製品テスト）を担当したり開発組織のマネージャーを務めたりと、エンジニアと近い領域で仕事をしてきました。
そんな背景があり比較的開発寄りの案件にアサインされることが多く、以下のようなプロジェクトを担当してきました。
- ヘルスケアサービスの立ち上げ（UX・UI設計、アプリ実装、プロモーションサイト実装）
- 大手保険会社のコーポレートサイトと顧客向けサービスサイトのリブランディング
- 医療業界の求人サービスのグロース（サイトリニューアル、アプリ改善）
- 建設業界の新規事業創出
- HR業界のSaaSリニューアル
- 自社のマーケティングサイト立ち上げ
エンジニアと一緒に日々働くことが大部分で、エンジニアと共に戦い共に創り上げる喜びを知っているプロマネ、と自称していいかなと思っています。
今回はTechBlogにお邪魔しまして、非エンジニア視点から頼りになるエンジニアとはについてお話しさせていただきます。
プロジェクトを成功に導いてくれるエンジニア
さてそんな私が4年ほど開発案件を担当してきた中で、
プロジェクトを推進し成功に導くという観点
で特に重要だなと思う要素を挙げてみたいと思います。
プロジェクトで一緒に働いているので完全客観というわけにはいかず半客観くらいの立ち位置ですが、近い仲間かつ非エンジニアからみて
「こういうエンジニアがチームにいてくれると頼もしい！」
と思える要素とはどんなものなのか。
TechBlogで非エンジニアからの視点というのは少し珍しいのかも。
視野を広げたり、何かのお役に立てればと。
デザインへの参画意識を持つエンジニア
あるアプリ開発プロジェクトでは、UIデザインへの強い興味を持つGoodpatchエンジニアが体験設計フェーズから伴走し、共に悩みながらゼロからサービスとアプリを作り上げていきました。
そのエンジニアは、体験設計やUIデザインはお任せします、という姿勢ではなく
- 「私は体験設計のプロではないけど、実装に優しいのはこういう設計です」
- 「私はUIデザインのプロではないけど、Human Interface Guidelinesだとこういうのが推奨されてて。どっちか迷うなら、こちらに寄せていいんじゃないでしょうか」
など、エンジニアならではのサポートやアシストを送り込んでくれる姿勢。
デザイナー陣は実装に詳しくはないので、よかれと思って描いたものが実装上の不都合を生む、なんてことが起きる中、このスタンスのエンジニアがいてくれたおかげで、自然と相談もしやすくなり、デザイナー達の実装の知見も深まっていきました。
デザイナーへの口出しは遠慮しとる より
デザイナーに実装観点をインストール
といったところでしょうか。 はい、韻を踏んだつもりです（笑）
ロジックの使い途
エンジニアの得意領域、というより基本スキルの一つにロジックの積み上げがあるかと思います。
AならばB。BならばC。
実装においては必須の思考・技能ですし、デザインにおいても、よいデザインはロジカルに説明がつくものだったりします。
ロジックは正義です。
なのですが、日常のやりとりやプロジェクトの全体進行など、全てにおいてこの正義が立ち行かないシーンがあったりします。
正義を乱すリクエスト
サイトリニューアルプロジェクトの実装を進めていたある日、ステークホルダーから合意と異なるリクエストが舞い込みました。
AとBという材料から導き出した実装方針C。ならばCに沿って進むべき。
関係者全員がロジカルに正しく仕事をしていればこの正義の連鎖でうまくいくはず、ですね。
ところが、情報伝達不足や、プロジェクトとは別の要因（企業全体の状況変化）などでそのロジックの前提が崩れたりします。
ステークホルダーとしてはPdM、UX、UI、少し離れてPOやCEO、さらに離れて販売を担うセールス部門などがありますが、これらの関係者が完全に同じ情報量を持ち、常にシンクロし、アップデートし続けられるわけではありません。
プロジェクト側からの情報が適切に伝達できていたとしても、セールス部門側での状況変化などもあります。
頼りになるエンジニアの対応
さてここでは、この構造的な課題解消自体ではなく、こういった事態に直面したときにエンジニアが取ってくれた頼りになる振る舞いとはなんだったか、にフォーカスしてみたいと思います。
合意と異なるようなリクエストに対し、あるエンジニアは感情的に反応するのではなく
「私たちの前提はXXXでした。
それを元に実装を進めてきていますが、YYYとしたい理由を教えてください。
対応するなら意思決定が必要で、◯◯さんとお話するのがいいと思いますがいかがですか」
のように対応してくれました。
ロジックを武器として使い要求を突っぱねる対応も可能な状況ではありましたが、
- 状況の的確な把握と整理
- リクエストの背景理解
- ビジネスの成功に寄与する、解決の道探し
というスタンスでいてくれたことで、感情のもつれや議論の空中戦を生まずに的確に課題に向き合うことができました。
え？そんな神みたいな人いるかって？ ええ、いるんです。いろいろなプロジェクトで、多くの神対応、複数の神々に出会ってきています。
（クライアントのエンジニアにも多くの神々がいらっしゃいました！）
ま、全てのシーンで100%神対応ってわけにはいかなかったり、お酒を飲むと邪神に化けたりなんてこともありますが（笑）。
考えてみれば、合意形成もプログラミングも、前提を整理し、ロジックを組み立て、必然の答えを導き出す行為と考えれば、共通する部分があるとも言えそうですね。
ロジックを武器に戦わず
ロジックで優しく導いて
あ、字数を揃えるのに気を取られてて韻を踏み損ねました（笑）
まとめ
今回お伝えしたポイントをまとめると以下です。
- デザイナーに対し実装の知見を伝えることは、エンジニアが思うより効果大
- 適切なロジックで導けば、人もプログラムも適切に作動
エンジニアにとっての当たり前がデザイナーにとっては神がかった知見だったり、
いつもの論理展開が、もつれた状況を解きほぐす鍵だったり。
Goodpatchエンジニアの一言がプロジェクトを大きく促進する場面を数多く見てきました。
会議が終わったあと、「さっきの一言のおかげで救われました！」と伝えると、照れながら「いやいやあの場面ではああかなと思ったんで。全然大したこと言ってないです。もっとうまく伝えられたら良かったんですが」なんて言うエンジニアが多いのですが。
Goodpatchエンジニアの皆さん、いつもありがとうございます！
本記事を読んでいただいているエンジニアの皆さん、その持てる力を普通に出していただくことがプロジェクトを成功に導いてくれます。どうぞ遠慮せず、積極的に！
