「技術的には可能」は丁寧に紐解いていきたいという話

こんばんは。こにしです。
noteでもようやく実務っぽい実務が始まってきたので、仕事関連の自分のスタンス、日々考えていることとか書いてみます。

今日のお題は「技術的には可能」についてです。
自分は元エンジニアのPMなので、エンジニアとしてこの言葉を使ったことも多々あるし、PMとしてエンジニアとしての会話中に言われたこともあります。

この言葉、表現が良いとか悪いとかは思いませんが、コミュニケーションにおいて注意点や機会であるのでそれについての自分の考え、対応の際に意識していることを書いてみます。

技術以外のどこかに懸念があると考える

これは当たり前な話なんですが、「技術的には」という前置きが付いている以上技術以外のどこかに問題や不明点があるのかなということを意識して確認するようにしています。

自分もこの言葉を使っていたことがあるので、いくつかパターンがありますが例をあげるとこんな感じでしょうか。

「技術的には可能だけど、今これを優先的にやるべきなのかは疑問です」
「技術的には可能だけど、この機能はユーザーには刺さらないんじゃないかと思います」
「技術的には可能だけど、膨大な工数がかかります」
「技術的には可能だけどオペレーションが回らないと思います」

その懸念がどの程度の精度なのかはさておき、きちんと確認していくことは重要だなと思っています。意思決定に関係する重要な内容が含まれている可能性もあるし、納得感を持って開発をしてもらうことにもつながるからです。

例えば、膨大な工数がかかる場合、それでも進めるべき場合もあればそれなら辞めるという判断も場合によりけりであるので、きちんとプロジェクトやメンバーのモチベーションをマネジメントする意味でも適切な意思決定と説明をする必要があると考えています。

懸念を表明することを歓迎する

これまた当たり前の話なんですが、プロジェクト/プロダクトにおいては適切な価値を適切なQCDで開発することが重要ですからそういう意味でこういった開発に伴うリスクの表明は職種問わず歓迎すべきことだと思います。
noteも前職も実装以外のところへも目を向けてくださる方が多く良い環境だなと思っています。

また、岩田さんの「プログラマーはノーと言ってはいけない」という話にも通じますが、リスクはあれどきちんと実現可能性については保証するということについても敬意を表するべきだと思います。

PMとエンジニアが作ってもらう/作るという分断された関係でなく、一緒に問題解決をしていける関係であれるよう努力していきたいところです。

最終的にはリスクを加味して意思決定する

前述の通り、開発プロジェクトはROIが重要ですから実現不可能なことができないのは当然にせよ技術的に可能だからといって必ずしも実施すべきということにはなりません。

こういう場合は、案件の目的自体はぶらさずに、要件やスコープの調整か全く別の手法での解決を図るか諦めて別のテーマに行くかを常套手段常套手段にしています。
この際、実装できるかどうかだけではなく、案件の目的やコスト感なんかの背景情報を伝えておくと逆に提案をもらえる場合があるので意識的に共有するようにしています。

以上、雑ではありますが「技術的には可能」周りのコミュニケーションで意識していることでした。
手を動かすエンジニアではなくなったからこそ丁寧なコミュニケーションを心がけていきたいです。