はじめに

こんにちは！開発エンジニアのクリスです。

実は今、私たちが働く東京本社が移転することになり、それをキッカケに新しい社内システムを開発するプロジェクトが動いています。

プロジェクトの紹介はこちらの記事をご覧ください！

#副社長と社内開発｜生成 AI フル活用、アイレット “超本気” 内製化革命の軌跡 〜ゼロメンテという壁を越えろ！若き精鋭たちの壮絶な闘い〜

今回は、私がそのプロジェクトで「初めての要件定義」の打ち合わせに参加した際、PMでもある副社長からビシッと指摘され、非常に勉強になった「エンジニアのスタンス」について、実体験をシェアさせていただきます！

なぜ作る？「会議室が予約できない」問題

今回私たちが作っているのは、「会議室予約システム」です。

背景にあるのは、オフィスワーカーなら誰もが一度は経験するであろう、あの問題。

  • 「Googleカレンダーで会議室を予約したのに、誰も使っていない（カラ予約）」
  • 「本当に使いたい時に限って、会議室が全部埋まってる！」

まさに「困る！」という状況ですよね。

この問題を解決すべく、総務担当の方から依頼があり、私たち開発チームが立ち上がりました。

緊張！初めての「お客様」との打ち合わせ

現在、プロジェクトは「要件定義」のフェーズ。

お客様（今回は総務担当）が「何をしたいのか」をヒアリングする「要求定義」を経て、それを「どう実現するか」の仕様を固めていく大事な段階です。

先日、その第一回目の打ち合わせが行われました。

参加メンバーは、お客様（総務）、PM（なんと副社長！）、そして私たち開発メンバー6人。

この打ち合わせが結構特徴的で、私たち開発メンバーがそれぞれ担当部分（プロジェクトの目的、機能要求、非機能要求など）をお客様にヒアリングした直後、その場でPMの副社長から「良いね！」「良くないね！」と即フィードバックが入るんです（笑）

副社長からの「愛のツッコミ」と衝撃の学び

緊張の中、私のヒアリングの番が回ってきました。

私はシステムの「非機能要求」について、特にコスト面を意識して、こう質問しました。

私：

「コスト削減のため、利用者がいない夜間帯はシステムを停止しますか？ それとも、少しスケールダウン（性能を落とす）だけして、24時間稼働させますか？」

完璧な質問だ…とまでは思っていませんでしたが、コスト意識もできて良い質問では？と思った瞬間。

副社長：

「良くないね。」

（えっ！）

副社長は続けて、なぜ良くないのかを具体的に説明してくれました。

「『どっちがいいですか？』ってお客様に聞いちゃうと、お客様も『え、どうしよう…』って困っちゃうよね。」

「コストのことなんて、できるだけ考えたくないのが皆の本音。そんな、お客様が迷ってしまう質問に時間を使うのは勿体無いよ。」

確かに…！

良かれと思って聞いた質問が、逆にお客様を悩ませる「丸投げ」になっていたのです。

エンジニアがすべき「提案」

では、どうすべきだったのか？ 副社長は「こう提案してあげるとベター」という助言もくれました。

助言（提案パターンA）：

「調査した結果、夜間停止によって月額X万円の大幅なコスト節約が見込めます。利用実績から見ても夜間利用はほぼ無いため、夜間停止を強く推奨します！」

助言（提案パターンB）：

「調査した結果、24時間稼働させても夜間停止しても、コストは月額数百円程度しか変わりませんでした。ですので、いつ必要になっても使える利便性（UX）を優先して、24時間稼働を推奨します！」

なるほど…！

選択肢をそのまま投げるのではなく、エンジニア側で事前に調査・分析し、「だから、こっちが良いと思います」という「提案（誘導）」をしてあげることが重要だったのです。

（ちなみに、「夜間のスケールダウンという発想自体はとても良いよ」と褒め言葉もいただけたので、嬉しかったです！）

エンジニアの「本当の価値」

正直、これまでお客様やクライアントと直接打ち合わせをする経験がほとんどありませんでした。

だから、このプロジェクトに参加して、この実体験ができただけでも本当に良かったと思っています。

今までの私は、「エンジニアの価値＝すごいシステムを（黙々と）作ること」だと思っていました。

でも、そうじゃなかった。

お客様のニーズ（時には本人も気づいていない課題）を掘り起こし、技術的な知見をもって分析し、最適なシステムを「提案」してあげる。

問題そのものを解決することこそが、本来のエンジニアの仕事なんだなと、まさに「ザ・エンジニア感」を感じることができました。

さいごに

いかがでしたでしょうか？

エンジニアが初めての要件定義で、副社長から「提案」の重要性を学んだ話でした。

このプロジェクトは始まったばかりで、まだまだ学ぶことが多い予感がしています。

また何か大きな学びがあったら、記事にしたいと思います！

この記事が、同じように初めて顧客折衝に臨むエンジニアの方にとって、少しでもヒントを得られるものになれば幸いです。