【アプリケーションエンジニア編】“シンプルなはず”が機能だらけに。炎上を防ぐ鍵は「可視化」

はじめに

第2回目にスポットを当てるのは、アプリケーションエンジニアです。アプリ開発現場につきもののトラブルと言えば「機能インフレによる炎上」。最初は「検索と電話予約だけできればいいです。お客様の利便性が上がれば十分なので」。そんなシンプルな要件でスタートしたプロジェクトが、いつしか「決済」「マイページ」「自動連携」…と要望が膨れ上がり、制御不能に陥ってしまう。

こうした事態を「仕方ない」「いつものこと」とあきらめていませんか。実は、炎上の大きな要因は「アプリケーションエンジニア自身」にあることが多いのです。そして、その事実に気づけば仕事がもっとスムーズになるだけでなく、今後のキャリアにも良い変化をもたらす可能性があります。

今回は、一緒に事例を追いながら、炎上の原因と解決策をひもといていきましょう。

ホテル予約アプリの失敗事例
──シンプルだったはずが、気づけば機能だらけ

あるホテル予約アプリの開発に参画したときのこと。営業部門からの依頼で始まったプロジェクトで、予算も少なく、3カ月でリリース予定。「空室検索をして電話がかけられるアプリ」、当初はそんな非常にミニマムな構成でスタートしました。

ところが、社内でプロジェクトを共有した途端、状況が一変したのです。

次々と降ってくる要望に、システム会社のエンジニアは「できますよ」と答え続けます。気づけば、当初3カ月だったスケジュールは1年に延び、搭載予定機能は数えきれないほどに。とうとう誰も、プロジェクトの全体像を説明できなくなっていました。

これはアプリ開発現場で頻発する、機能増殖による「迷宮入りプロジェクト」の典型と言えるでしょう。

炎上の火種① ーエンジニア側の2つの思考パターン

実は、この失敗にはエンジニア特有の思考とプライドが関係しています。

「できます」の裏に隠された前提条件

私自身も元エンジニアなのでよく分かるのですが、エンジニアに「これできますか?」と聞くと、技術的に可能であれば、ほぼ100%「できます」と答えるでしょう。しかし、その裏には「お金と時間をかければ」「仕様をはっきり決めてもらえれば」という前提が隠れていることまで伝えられるエンジニアは少ないと思います。エンジニア側からすればいわば「当たり前」の前提も、クライアント側にはそうではありません。

そのため、これらの前提をきちんと伝えずに快諾してしまうと、クライアントは「エンジニアができると言っているのだから、良い感じにパパっと作ってくれるだろう」「なにせ、システムやITのプロなんだから。さすがだなぁ」などと捉えてしまいのです。言葉をそのまま受け取って「簡単に、すぐできるんだ」と誤解し、要望はさらに加速します。

「できない＝無能」という思い込み

もう1つ根深いのが「できない」と答えると「エンジニアとして無能だ」と思われるのではないか、という恐怖心です。

気持ちは分かりますが、真に優秀なエンジニアとは安易に首を縦に振る人ではありません。プロジェクトの成功を念頭に置きつつ「本当にそれは必要か」を常に問い直し、ときには「やらないほうが得ですよ」などとブレーキをかけられる。そうした人こそが、プロフェッショナルのエンジニアだと私は考えています。

炎上の火種② ー充実しすぎな標準機能

最近のアプリ開発では「標準機能」が充実しており、それが逆に仇となることもあります。

「決済機能は標準で備わっているので、それを使えば良いですよね」という提案は、一見スマートです。しかし、実際には標準搭載の機能では自社の業務フローに合わず、大幅なカスタマイズが必要になることが多々あります。すると、見積もりを見て初めて「標準機能なのに、なぜこんなに高くて時間がかかるのか」というすれ違いを招くのです。

また、エンジニアが機能単体に集中しすぎて「影響の連鎖」を見落とすことも問題です。「決済機能」をカスタマイズするなら、必然的に「会員情報管理」や「マイページ」もカスタマイズ必須になるというようなケースがあるでしょう。この連鎖を予見せず、着手してから「あ、やっぱりあれもこれも必要だ」と後出しになることが、現場を混乱させる大きな要因となることもあるのです。

こうして、はじめは魔法使いのように扱われていたエンジニアの信頼は、ガタガタと音を立てて崩れていきます。

【トラブル解決策】PMOはデモアプリと遷移図で可視化する

それでは、このような炎上に直面したPMOは、どのようにトラブルを解決に向かわせるのでしょうか。キーワードは事前と事後の「可視化」です。

事前対策：デモアプリで、実際に見てもらう

最も効果的なのは、机上の議論だけでなく、実際に「動くもの」を見せることです。例えば、プロジェクトの可能な限り早い段階(プロジェクト開始前や遅くとも要件定義段階)で、クライアントに標準機能を組み込んだデモアプリを確認してもらいます。

デモを触れば「アレルギー情報の入力欄がない」「決済までのステップが多すぎる」といった具体的な課題が即座に共有されるでしょう。そして「ならば、カスタマイズが必要だね」「運用でカバーしよう」といった建設的な議論も可能になります。

事後対策：遷移図で「複雑性の現在地」を示す

既に機能が膨れ上がっている状態なら、サイトマップや画面遷移図を作成し、全体像を可視化しましょう。例えば「当初は3画面だったのが、今はこれだけ複雑になっています」と現状を提示するのです。優先順位を決めるのはクライアントですが、そのための判断材料(複雑性のリスク)を提示するのはエンジニアの重要な仕事です。

「炎上を防ぐための防衛線」チェックリスト

ここまでの内容を踏まえて、アプリケーションエンジニアとしてトラブルを未然に防ぐために押さえるべきポイントは以下です。

「本当に必要か?」と問えるエンジニアであること

そして、アプリケーションエンジニアとしてあらためて思考を整理しましょう。「できますよ」と答え続けることが、あなたの仕事ではありません。それよりも「これは本当に必要ですか?」と問える視点も持つことが、あなたの大事な役割なのです。

また、必要だと判断された際も「実現にあたっては、このような前提条件を想定しています」といったことまで、きちんと掲示する姿勢も重要です。

そうした視点や姿勢を意識するには、ユーザー視点を持つことが大切です。自分が開発に携わっているアプリを、実際に使ってみてください。ホテル予約アプリなら、実際にホテルを予約してみる。すると、使いづらい部分や分かりにくい部分、現状のままでもよい部分などが見えてくるはずです。

「いや、私はお金を稼ぐためにエンジニアをしているので」というドライなタイプの方も、一度で良いので仕事と割り切ってユーザー体験をしてみましょう。もしあなたが「本当に良いものを作りたい」というパッションを持っているなら、そのパッションを思い出してください。

おわりに ー視座を上げるとキャリアが変わる

エンジニアはどうしても「依頼に答えること」や「いかに美しく実装するか」という技術的な追求に没頭しがちです。しかし、もう一段視座を上げ、プロジェクト全体を見渡せるようになると、あなたの価値は劇的に変わります。

「お客様の要望をそのまま実装すると、アプリとして破綻する」。そう気づけるエンジニアは単なる作業者ではなく、PMOのようなプロジェクトを成功に導くキーパーソンになれます。

「できますよ」と言いたくなる気持ちが湧き上がったら、そこで一度立ち止まってデモを見せ、チェックリストを埋めていく。自分自身の思い込みも含めて冷静に俯瞰し、必要性を考えてみる。

そうした勇気はトラブルを回避する一番の近道になり、さらにあなたのキャリアをも変えていく可能性は十分にあると思います。ぜひ、これからのプロジェクトでも、今回のポイントを意識してみてください。