#122 まず「できない」って言わない
組織の中のコミュニケーションがうまく取れていないと起こる現状としてエンジニアの 「できない」という言葉によって生まれる現場のハレーションを多く見てきました。
PdMやデザイナーがプロダクトを良い方向性進めるために「こんな機能があったらいい」「この機能をユーザーインターフェイスにしたらもっと良くなる」といった思いをもったとき、それらを実現するのはエンジニアです。相談ベースで「これできそうですか？」と言われたときに「ちょっとできないと思います」「ちょっと厳しいと思います」と返答したことはないでしょうか？
これは両者に課題はあるにしろ関係性の恐怖から起きる現象の1つでしょう。
エンジニアから見れば、それを追加修正すると納期・リリース予定日に間に合わなくなるし、その分残業するのもしんどいし、タスクの優先度変更をPMへ相談するコストもあるし、納期の遅れを承認できる立場でもない人に言われたときにどうすればよいかわからないなど複合的な要因から「とりあえずできない」という文脈で若干否定的な物の言い方をすることもあります。
しかし、裏には以下の理由があります。
- 他のタスクをしているので「できない」
- いまの機能では「できない」
- 何かしらの制約で「できない」
- 時間がかかるので「できない」
- いまのチームスキルだと「できない」
- やるべきではないと思っているから「できない」
1. 他のタスクをしているので「できない」
これは優先度の話です。もしくは順番の話です。
差し込みとして要望が来た場合には、日々バックログアイテムの完了の定義に紐づく見積もりに対しての完了日を意識しながら実装しているエンジニアにとって、途中に何か急ぎの依頼が入ってくることはコンテキストスイッチがかかってきます。さらに優先度の問題やリリース日への逼迫感もプロジェクトであればあるかもしれません。
一方、依頼や相談をする側はエンジニアリングチームが どのぐらいリソースが余っているのか、逆に逼迫しているのかが見えていない限り、そのような事情はわかりません。時には、業務とは関係ないことをしている姿を多く見たり、雑談している姿を見ていたりすると心情的には良いものではありません。
そういった意味では、きちんと優先度判断ができるツールをチーム外にも公開して「何が、いつリリースされる予定で、いまどのぐらいの進捗率なのか」を把握できれば、依頼する側も状況がわかるでしょう。
余談ですが、プロダクトチームで1つプロダクトバックログを扱っている場合、往々にして「ちょっとした作業を依頼したいけど、バックログを見ると優先度がきっちりつけられていて依頼しにくい」といった 遊びがないチームが出来上がってきます。当然状況によっては全リソースを集めて成果物を作っていくフェーズはありますが、組織デザインとして、もう1つのチームを作り既存のバックログとは関係ない施策（ちょっとしたグロースの施策や他チームからの依頼を捌くチーム）を行うとスムーズに組織全体で見たときに駆動することが多いです。
また、似てはいますが「優先度」ではなく「順番」のケースもあります。
クリティカルパスとして現在行っている前工程が終わらないと要望のそれに着手できないケースです。
2. いまの機能では「できない」
これはシンプルに要望に対して、いまの機能やシステムにはないので「できない」というものです。開発すれば「できる」になります。
例えば、ECサイトの検索エンジンの中で特定のジャンルごとに検索をさせたいという要望があったとして、現状だと検索インターフェイスはあるが商品データにタグ付けがジャンルごとにされていないためデータ登録から始めないと行けないので現状だと「できない」という風になりますが、商品データにタグ付けをして検索エンジンをその使用に適合させていけば「できる」になります。
3. 何かしらの制約で「できない」
例えば、要望を実現するのに法令に引っかかるケースが多いでしょう。
景品表示法にひっかかるため、そういったキャンペーンの実装はしてはいけない。また、モバイルアプリだとAppleやGoogleのプラットフォーム規約にひっかかりRejectされるためできないといったことが多々あるでしょう。
または、連携先会社や他チームのシステム改修が必要なため「できない」（厳密に言うと自分たちの操作可能範囲ではできない）というのも多いでしょう。
4. 時間がかかるので「できない」
1.の他タスクをしているので「できない」にも近いですが、単純に要望として期待されるスケジュール感に対して時間がかかりすぎるので「できない」という理由になります。Webサイトのパフォーマンスを悪く（例 : ページが開く速度が遅い）、ユーザーが離脱しているので来月ぐらいにはどうにかしてほしいという要望があったとします。対策として、画像の遅延読み込みを実装しようとしたが長年の技術負債が多く影響範囲が多岐にわたるため、来月には「できない」という判断をすることもあります。
5. いまのチームスキルだと「できない」
対象チームの技術レベルによる「できない」です。
例えば、通常のWebアプリケーションのエンジニアたちに「２ヶ月後にAIを使ったサービスを作るぞ！」というのは時間をかければ可能ですが、通常開発している環境と違うので多少のキャッチアップの時間がかかります。そのため今まで通りのスケジュール感だと難しいため多少学習の時間も込みで工数・工期を考えていかなければなりません。
6. やるべきではないと思っているから「できない」
これは、あまりエンジニア側が良くない例でプロダクトや機能としてエンジニア自身がやるべきではないという判断を言葉を変える形で「できない」と言っている例です。要望を出す側ががきちんと機能の裏にあるユーザーニーズや数値的な改善幅を共有せずに受託の関係になっているとよく見るケースになります。
とはいえ、これらすべてが「できない」ではなく、何かしらのハードルがあって 「難しい」 と言い換えられます。
つまり難易度の問題、もしくは時間の問題です。できないことなど相当な制約がない限りはソフトウェア開発においては存在しません。
つまり「できない」は何かしらの条件をクリアすれば 「できる」 と置き換えすることもできます。
理由は置いていても、こういったことが相次ぐと提案者は かなり冷めてしまいます。
ゆえにそのチームに「忙しそうだから何言ってもダメ」というレッテルが貼られてしまうと提案もされなくなります。
すると、そのチームは周りからの目が薄くなるので改善が進まないか、改善速度が遅くなります。
システム動いてるから良いよねという状態になり、最終的に何も仕事がなくなって価値がないチームとしてイメージがつけられ、成長していないことを理由に離職が相次ぐ。その過程で改善が進んでいないプロダクトというのが浮き彫りになり、且つ俗人化していて捨てて作り直す、もしくは捨てたというトップダウン判断が続くなど、悪循環が生まれるかもしれません。
PdMからすると「他社でできているのに、なぜできないのか？」または「なぜ、こんなに工数がかかるのか」と疑問を持つでしょう。
もしエンジニアから「できない」と言われた場合「乗り越えるべき問題が多い」と考えた上でPdM自身がどう解決していくべきか 一緒に考えていくのがいいのかもしれません。
理想のコミュニケーションとしては以下の様な形です。括弧の中は 対策するべき「できない」 の項目です。
===
- PdM : ユーザーが検索窓での離脱が多いからジャンルで検索できるようにしたいのですが、さくっとできそうですか？
- エンジニア : ユーザーも使いやすそうですし、CTRの数値も伸びそうで良いですね！実現するためのハードルとしてはいくつかあります。
- 現時点での機能にはないので追加実装となります。（2. いまの機能では「できない」）
- 今やっている〇〇というタスクが今週リリース予定ですが、これを最優先でやるとなるとそれをずらす必要がでてきそうです（1. 他のタスクをしているので「できない」）
- もしくは、このあたりに知見があるBさんに担当を変更すればもっと早くできるかもしれません（5. いまのチームスキルだと「できない」）
- 修正内容としては、データにジャンルのタグをつけるところから始めてアプリケーション側の修正にはいるため2人月程度を超概算工数として認識してもらえればと思います。詳細な見積もり（コミットメント）はPRD/DDを作成するので来週中には出します。（4. 時間がかかるので「できない）
- ざっくりの所感としては、もしかしたらデータ更新時にメンテナンスをかけるかもしれないので多少のダウンタイムが発生し、検索が使えなくなる時間があるかもしれません（3. 何かしらの制約で「できない」）
- 個人的には、できるだけメンテナンスを挟まないようにしたいのと、データ更新についても一気に行うと障害の危険性もあるので1つジャンルを試して検索できるようにして徐々に適応していきたいです。（6.やるべきではないと思っているから「できない」）
- PdM : 了解です、詳細にありがとうございます。では、リスクを鑑みてデータ更新はとりあえず1つのジャンルから始めましょうか。工数やタスク優先度も了解です、
===
関係性の恐怖をなくしていくためには相手に色々と理解してもらわなければなりません。
そのために、まず否定から入るのを止める ことをやめることから始めるのが良いと思います。
エンジニアは、依頼を受けた段階で瞬時に頭の中でどう実現するべきかを考えているため、やるべきことが頭の中を駆け巡る中で、一言目に否定（やハードル）しがちになりますが、それはエンジニアとしてあまり格好良いものではありません。
どんなに難しいことでも、心持ちとしては「とりあえず、いくつか壁はありますができると思います」「ちょっと考えてみます」という前向きな姿勢を一番はじめに見せることで一緒に仕事をしていて気持ちが良いチームになるでしょう。
一度考えた上で、前述した6つの観点で乗り越える壁を説明してその上でいつやるべきなのかをPdMと一緒に考えられる組織が良いでしょう。
また、気をつけなければいけないのが、理由がきちんと述べられたとしてもエンジニアの言葉に専門性があると、実はPdMやPMがきちんと理解しておらず、結果として「エンジニア側が遅れると言っているので難しいです」という抽象的なものがレポートラインが上がってしまうということが起きます。
そのため、できるだけ該当パートで述べた通り相手が欲しい情報を的確に伝える（工数や工期等）ことが大事になってきます。
参考
