エンジニアを疲弊させる、「やりません」「できません」を言わせない開発チームとは

Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』
こんにちは、谷口です。

開発をしていて、「いま本当にこの機能が必要か？」「この納期でその機能作るのは無理だろ」などと思った経験はありませんか？

新人の頃は何も考えずに上に言われたものを作っていた、もしくは作ろうとしたけど無理だった案件があったという人も多いでしょう。上の立場の相手に「この機能、本当に必要ですか？」なんて、言いたくてもなかなか言えないものです。

しかし、現場の開発者が「これ要らなくない？」「これはできません」と思っているのにそれを口にできないようなチームって、よい開発チームとは言えないのではないでしょうか。

今回は、エンジニアが「やりません」「できません」と言うことについて考えてみました。

■それ、本当にいま必須の機能ですか？

ユーザー「あー顧客情報を一覧で見れたら便利なのになー」

ディレクター「ユーザーからいっぱい要望来てるから、顧客リストを一覧で表示できるようにしよう」
エンジニア「そうしましょう」
ディレクター「じゃあ君は顧客リストからさらに探したい顧客情報が検索できる検索ボックスを作ってくれ！」
エンジニア「え、（検索ボックス？それ今の段階で必須か？まずは顧客を一覧表示できる機能だけ実装してリリースしたらよいのでは？）あ、はい……」
ディレクター「それからあの機能も…」
エンジニア「…………」

「今その機能いらなくない？」って思ってるのに、なぜ言えないんでしょうか。

上からの指示に対して「やらない」「できない」なんて選択肢ねーよ！という人も多いと思いますが、実際に作る人が「これ、やらなくていいでしょ」と言ったら、下手すると「やりたくない・面倒くさいだけなんじゃないの？」と受け取られてしまうかもしれない……、それを避けるために「（思うところはあるけど）はい、やります」と言ってしまうこともあるでしょう。

◆そもそもこれってどういうプロジェクトなんだっけ？

多くのプロジェクトでは、最初から詳細な要件があるものではないかと思います。

最初はブレストから始めて、夢のようなアイデアがたくさん出たとしても、具現化の際にはまずMVP（Minimum Viable Productの略で、検証に必要な最低限の機能を持った製品のこと。『リーン・スタートアップ/エリック・リース著』より）を作り、リリースして検証をする必要があります。

そのためには「目的を果たすために最低限の要件」が必須になってきます。まずはその要件を満たしたもので検証等をして、どう追加・改善していくかを考えていった方が建設的でしょう。

上の例で言うと、ユーザーは顧客情報リストを一覧したいと思っているわけですが、もしほとんどのユーザーの顧客リストが10件以下で、リスト表示さえできれば一覧できる状態だったとしましょう。検索ボックスは特に必要ないですよね。

それなら、検索ボックスよりもリスト表示機能だけを作って早くリリースした方が、早くユーザーの満足度や来訪率を向上させられて、あれもこれも盛り込んだものを実装するよりずっとメリットが大きいかもしれません。

最初にプロジェクトの目的という軸を明確にして、チーム全員で共有しておかないと、後から「あれもやろうこれもやろう」と要件が肥大化してしまいがちです。

あれもこれも盛り込もうとして、結局できたものがよく見る下図のような「顧客が本当に必要だったもの」からはかけ離れていた場合（しかも謎に時間かかって作った人もボロボロになってたりなんかしたら）、目もあてられませんよね。

リーン・スタートアップ

オレゴン大学の実験 (SD選書)

itpro.nikkeibp.co.jp

■「やらない」提案をするのに必要なのは「やらない」メリット

エンジニア「検索ボックスって不要じゃないですか？」
ディレクター「何で？」
エンジニア「え、えっと…」
ディレクター「作るの面倒くさい？」
エンジニア「い、いえそういうわけでは……」

前述のとおり、作る側の人間が「やらない方がいい」とだけ言ってしまうと、変なバイアスがかかって「やりたくないだけ」に見えてしまうリスクもあります。「やらない」ことによるプロジェクトとしてのメリットをきちんと提示しましょう。

そのためには、やはり最低限の要件を満たすものを作るにあたって、なぜこの機能やサービスを作るのか・誰がどう使うのかといった本来の目的を理解しておく必要があります。本来の目的を把握していれば、「やらない」提案をする際に、「やらない」ことによるメリットが説明しやすくなります。

エンジニア「今は検索ボックス作る必要ないと思います」
ディレクター「何で？」
エンジニア「そもそもの目的って、顧客リストを一覧できるようにすることですよね。現在、ほとんどのユーザーの顧客リストは10件前後で一画面で一覧できる量ですから、余計な機能をつけるよりもッ今回はリスト表示機能の作成だけにした方が、その分早くリリースできて、ユーザー満足度も早く向上させられるかと思います。現時点での登録顧客数の増加率から考えると、検索機能の追加を検討するのは来月以降でよいかと思います」

このようにプロジェクトの目的や方向性を理解できていれば、「やらない」ことのメリットを説明することができるかと思います。

■「やらない」「できない」ときに代替案って必須ですか？

仕事における「やらない」「できない」の話をすると、よく「代替案を出すこと」を要求する人がいます。が、代替案というのは必須ではないと思います。

「代替案がなければ否定してはいけない」と当たり前のように言う人もいますが……代替案を考えるのって、場合によってはかなりハードルが高いのではないでしょうか？

一番まずいと思うのが、代替案を必須にしてしまうと「思うところはあるけど代替案が思いつかない…」といった場合に、結局何も言えなくなってしまう状況です。また、開発チームとしても「代替案もないのに否定的な意見を言うな」「流れを止めるな、文句を言うな」というような空気はあまりよくないものだと思います。

もちろんいつも「これは何となく嫌だからやめよう」と言う人ばかりでは問題がありますが、例えば「この機能のここの部分ってユーザーに嫌がられそうな気がする」とか「このイラストってよく見たらなんかきもくない？ユーザーの印象が不安だなあ」とか「たしかにちょっと気持ち悪い感じするかも、リリースしたらユーザーの反応見てまた考えよっか」とか、そういった「なんとなく自分の感覚ではこう思う」レベルの意見も気軽に言い合えるチームの方が建設的な話し合いができるのではないでしょうか。

■もし自分がマネジメント・ディレクションする立場になったら

チームで開発をする際は「やりません」「できません」と言う人が一方的に悪いわけでもなければ、何も考えずに「やります」と言って全て請け負ってしまう人が素晴らしい部下というわけではありません。

本来ディレクションやマネジメントをする立場の人は、チームが「要件決めてただ投げる人」と「ただコーディング作業する人」という分断された状態にならないよう、企画段階から開発者を巻き込んでいくために目的や最低限必須の要件をきちんと共有し、その上で「やるべきことを絞り、やらないことを切り捨てる」判断が求められるポジションであると感じます。

開発者にあまり裁量のない現場だとしても、どんな業務に対しても「やります」と言うしかないような空気の現場は、いずれみんな黙ってみんな辞めていってしまいます（それも優秀な人から…）。開発チームとして長い目で見た場合、その方がリスクが大きいのではないでしょうか。下に丸投げするだけなら誰でもできますしね……。

↓ちょいちょい出てきた画像の漫画はこちら↓

■まとめ

ハーバード大学のマイケル・ポーター教授は「戦略とは何をやらないかを決めることである」と言い、ドラッガーは「自らの強みに焦点を合わせ、強みでないことは他社に任せなさい」という発言を残し、スティーブ・ジョブズも世界開発者会議にて「焦点を合わせるということは『ノー』と言うことだ」という旨のスピーチをしています。

「こんな機能があったら便利じゃない？」と思うケースは多々ありますが、初めの目的を見失った機能の実装をしたところで、それがめざましい成果を生み出すことはないでしょう。

エンジニアが「どこを捨てるべきか」を検討・発言できるチームが、本当に良い開発チームと言えるのではないでしょうか。

okaymac.com

ドラッカー 時代を超える言葉―洞察力を鍛える160の英知

---

paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。

「paiza転職」は、自分のプログラミング力が他社で通用するか（こっそり）腕試しができる、IT／Webエンジニアのための転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。

まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。

また、paiza転職をご利用いただいている企業の人事担当や、paiza転職を使って転職を成功した方々へのインタビューもございます。こちらもぜひチェックしてみてください。
詳しくはこちら