【フロントエンジニア編】UI/UXの専門になることがゴールではない。目指すべきは「司令塔」ーシステム全体を見通すための3つの失敗回避術

はじめに

「エンジニア」とひと口に言っても、ソフトウェア、フロントエンド、サーバーなど、その役割によって現場で直面するトラブルはさまざまです。
本連載では、PMO(Project Management Office)として多くの現場を経験してきた甲州が、それぞれのエンジニアが抱える課題の回避策を深掘りしていきます。

第5回目は、システムの「顔」を創り出す「フロントエンドエンジニア」に焦点を当てます。彼らのメイン領域は、パソコンのブラウザやスマートフォンの画面越しにユーザーが体験する領域すべてです。

それゆえに、直感的な「ちょっとした変更」が、コードやシステムの裏側では大規模な再設計を伴う改修に繋がってしまうというケースが存在します。

本記事は、現在フロントエンジニアとしてUIやUXを学習しながらシステム開発に取り組んでいるITエンジニアや、プロジェクト全体の進捗を管理する立場でフロントエンジニアリーダーとどのように役割分担していけばよいかを理解したい管理職の方にも、ぜひ読んでいただきたい内容です。

フロントエンジニアは、単に見た目を整えるだけでなく、バックエンドとの連携やパフォーマンス最適化など、プロダクトの価値を最大化する司令塔へとステップアップできます。チームを牽引するリードエンジニアを目指す方にとって、他部署との合意形成やリスク管理の視点は、必ず役立つ武器になるはずです。

また、現在は指示通りのコーディングを主としている方も、上流工程での意思決定がどれほど現場の負担を左右するかを知ることで、より俯瞰的なキャリアパスを描くヒントにしていただけると嬉しいです。

「デザインは決まったはず」なのに
進まないプロジェクト

私が経験した、あるBtoC向けの新規Webサービス立ち上げプロジェクトでの話です。私はプロジェクトの見直しのタイミングで途中参画しました。

私が参画した時点では、既に要件定義や設計工程は完了し、実際にシステム構築の工程に入っている状況でした。しかし、システムの作り込みの進捗が思ったように進まない状態になっていました。

これまで実施した成果物ややりとりの記録を見たところ、毎週のように打ち合わせを行っており、会議の内容も議題を用意して議論を行い、決定事項をまとめて進めており問題ないように思いました。

しかし、より詳しく見ていき、プロジェクトの会議に参加するようになると、そのプロジェクトのマズさが見えてきました。

• ユーザーにインパクトを与えるようにトップ画像はもっとカッコよく
• 色はコンセプトカラーが◯◯だからこう変えてほしい
• もう少しボタンを大きくしてユーザーが迷わないように

このような記録を見れば一見デザインに関する普通の会話だと思いますが、
打ち合わせではユーザーが使うシステムやアプリケーションの見た目、使い勝手に関する議論が中心で、事業全体や業務をどのように回すか、データをどのように取り扱うか、という会話は行われていなかったのです。

成果物もなく、会議の記録にもこれまで会話された記録はありません。プロジェクト計画書を見てもどのように進めるかの内容は記載されておらず、１か月単位の大まかなスケジュールとシステム会社に発注する総金額が書かれた程度の計画書とは名ばかりの資料だったのです。

そして、「要件定義、設計工程が完了した」と言っていたのは、「システムのデザイン部分、ユーザーが見る画面部分のデザインが完了した」という意味だったのです。

• ユーザーから受け取ったデータはどのように処理されるのか
• データはどのように管理するのか
• 外部システムからはなんのデータを取ってきて、どのデータを渡すのか
• セキュリティ上の暗号化はどうするのか？
• ユーザーの動きとお金の流れ、社内スタッフの業務の流れはどのようになっているのか？
• 開発環境、テスト環境、本番環境などのシステムの環境面の設計はどのように考えているか？

というような、いわゆる一般的な要件定義工程で決定するべき内容は、全くと言って良いほどありませんでした。

この状態を伝えて認識合わせを行ったところ、双方から出てきた内容は以下のとおりでした。

• 発注者である事業者側は、システム会社の言う通りに進めていけば問題なく出来上がる！
• 受注者であるシステム会社はシステムを作るだけなので、そのシステムを使ってどのように業務をするかは事業者側が考えること。そして、システムそのもののライセンス費用やサーバー費用、構築作業は事業者側で行っていただく認識

ここで初めて決めなければいけないことや作らなければいけないものが大量にあると認識し、プロジェクト計画書を作り直して再スタートすることになったのです。

フロントエンジニアとしての専門性は活かしつつ
＜幅＞を広げる

なぜ、このような悲劇が繰り返されるのでしょうか。

先程のプロジェクトのシステム側のPMはフロントエンジニアで、UI/UXのプロフェッショナルではあるものの、プロジェクト管理は行ったことがなくシステムの全体像をとらえられていませんでした。また、事業者側にもシステムに詳しい人材がおらず、システム会社側に任せっきりの状態でした。

最近では事業者側にITの専門人材がおり、プロジェクトを管理することでシステム会社がシステム作りに集中できる体制を組む場合もありますが、全体で見るとまだまだ少ないです。

システム開発においても技術領域が幅広くなり、すべてをカバーできる人材はほとんどおらず、ある分野に特化して専門性を発揮して仕事をしている人がほとんどです。それは、会社単位でも同様で、UI/UXのデザインが専門、データ分析が専門、セキュリティが専門、といったようにそれぞれ会社があります。

今回の例では、フロントエンジニアにUI/UXの専門知識や能力はあるものの、システム全体、プロジェクト全体の視点がなかったことが今回のような事態になった1つの原因です。

専門を持つのは良いことですが、「その領域しか見ません」というスタンスはフロントエンジニアとしての幅を自ら狭めてしまいます。フロント部分の専門領域を活かして、バック・サーバ領域、ハードウェア・インフラ領域、マネジメント領域というように自身の幅を広げていきましょう。

各領域すべての専門家になる必要はなく、会話ができるレベルまで持っていくだけでも一緒のプロジェクトに取り組むときにスムーズな仕事ができるはずです。これができるようになると、初めて一緒にプロジェクトをする関係性でも仕事の進め方や立ち上がりが早くなり、プロジェクトが進みます。

PMOが現場で使える回避術
手戻りを最小化する「合意形成」の技術

こうした失敗を回避するために、PMOは「スケジュールを引く」以上の踏み込んだ介入が必要です。私がもし、フロントエンジニアの立場でプロジェクトに参加した場合は、以下のような点を意識して取り組みます。

プロジェクトの進め方を全体俯瞰できるように計画書を作り込む

まずはどのプロジェクトでも基本ですが、プロジェクト計画書を作り込むことです。

フロントエンジニアであるあなたは、UI/UXなどのフロント部分に関してはより細かく何を決めて何を作らなければいけないかを想像できると思いますが、プロジェクト全体で何を決めて何を作らなければいけないかの想像はできていないかもしれません。

プロジェクト計画書は、網羅的にプロジェクトを全体俯瞰できるように作っていくことが重要です。作り始めると全くわからない領域であったり、お客様にヒアリングしないと作成できない部分が多く出てきます。また、作成しようとしても、プロジェクトメンバのどの関係者もどのようにしていけば良いか分からないという箇所もでてきます。

その時は、ある程度の方向性や決めるための条件などを記載して、作成を保留にしておくことも重要です。プロジェクト計画書の項目としては存在しているが、中身は空欄という状態にしておきます。

これは、プロジェクトを進めて具体化してくる中で決定していきます。プロジェクトを進めていると特定の領域に議論が集中し、プロジェクト全体で決めるべきことを見逃してしまいます。そのために、プロジェクト計画書で決めなければいけない部分は目につくようにしておき、ある程度の情報がそろったら作成していきます。

また、必ずしも自分1人でプロジェクト計画書を仕上げる必要はありません。特定の専門領域を外部の取引先や社内の別チームに依頼することも必要になってくるので、具体化するための前提条件やインプットなどを用意して、作成してもらうように促しましょう。

そして、作成してもらったらその内容を理解できるように確認しましょう。あなたが理解できない内容は他のプロジェクトメンバも理解できません。内容を見ずに流すのではなく、中身を見て理解するようにしましょう。

プロトタイプやフロント要件を起点とした要件の合意

ホワイトボードツールやデザインツールなどで作成した画面イメージの合意だけで要件定義を完了させるのはやめましょう。画面イメージの合意形成や作業するときは有効ですが、それがすべてだと思うとつまづきます。

全体俯瞰できるように画面一覧や機能一覧と連携させ、全体ボリュームを把握します。その上で、画面を起点とした決定すべき要件決定を他のチームや領域担当と使用決定していきましょう。

専門領域ではない部分のすり合わせを他チームと行う必要が出てくるかもしれませんが、フロント領域の要件を起点に話を展開していけば問題ありません。

必要に応じて主要な機能が「動く」プロトタイプを作成し、ステークホルダーに触ってもらう機会を設けながらイメージをすり合わせ、「ボタンを押した後のローディング時間は許容範囲か」「エラーが出た時の表示は親切か」といった、動かさないと分からない違和感などを引き出していきます。

フロント部分の仕様凍結・バージョン管理の導入

デザインの変更はシステムに詳しくない人から見れば、「少し変えるだけなんだから大きく影響しないでしょ？」と思われることが多いです。しかし、ちょっとした変更がデータベースへの影響になり、サーバ処理側の影響になるという大きな影響を及ぼすケースが意外とあります。

ある程度仕様が固まったら、バージョン管理をしましょう。どのバージョンの仕様が現在の最新なのかをプロジェクト内で共通認識できるようにします。そして、プロジェクトの全体スケジュールに、「UIデザイン凍結」というマイルストーンを記載します。

「この日以降のレイアウト変更は次期フェーズ、あるいは追加予算の対象」というルールを事前にステークホルダーと合意しておくのです。

おわりに

フロントエンジニアの仕事は、プロダクトの価値がユーザーに最も伝わる部分に影響します。システムやアプリケーションの目に見える部分で確認しやすくイメージしやすいため、システム要件を決める上でそこのみを決定しておけばシステムが完成するように錯覚してしまいます。

しかし、システムは画面の裏で処理するロジックやデータの扱い、外部との連携によってさまざまな処理がされてはじめて完成します。

フロントエンジニアはこれらの全体を把握した上で、お客様と会話しやすいシステム画面の要件を中心にシステム全体の仕様決定のハブ役として機能するポジションを担うところまで行くことが可能です。

「画面を作るだけ」「UI/UXを考えるだけ」という認識を捨て、そこには高度なロジックと多くのステークホルダーとの調整が必要で、プロジェクトやシステムはその上で成り立っているという視点を持つとフロントエンジニアとしての幅が広がるはずです。

たとえあなたがプロジェクトをリードするポジションにいなくても、今回紹介した視点は、フロントエンジニアとしてプロジェクト参画する際の強力な武器になるはずです。

次回は、システムの土台を支え、整合性の番人として機能する「バックエンドエンジニア」の世界に焦点を当てます。ロジックの迷宮をどう管理すべなのか。お楽しみに。