デザイナー／アーキテクトのプロジェクト参画時期と手戻り不可逆点の認識ギャップ
ソフトウェア製品の開発を念頭に、少しだけ悩みを書いてみます。綺麗なオチはないかもしれません。
ソフトウェア開発におけるアーキテクトの役割
時既に遅し
経験上、サービス要件や業務要件を詰めている段階には既にUIのナビゲーション基本設計に着手し始めていないと、プロジェクトとして手遅れになる可能性が高く、この辺りの感度と認識のズレをどのようにして解消できるのだろうかというような課題感がありまして、どれだけ案件を経験しても毎度難しいと感じます。
私はある職務上ではアーキテクトと名乗り、主にソフトウェア製品のUIの構造設計やアーキテクチャ構築を支援する仕事もしています。クライアントワークにがっつり取り組んでいた時期には、マネージャから呼ばれて現場サポートに赴いた時点ではもう既に基盤となる設計は終えているか、決裁者による承認を終えてしまっているかしており、要するに「デザインにおける手戻り不可逆点」を1つ越えてしまっている状況が私にとってのスタート地点になることが大半でした。
『一応もう基本設計は終えていて、ここからはusagimaruさんの腕によってUIをいい感じにしていってもらいたい』
などとオンボーディングを受けるわけですが、時既に遅しというか、私が入るべきは実際にはその基本設計段階なのですよね。その基本設計に綻びが目立ってしまっているので、私としては実装していない今のうちに手を入れて十分に堅牢かつ拡張性・柔軟性のある構造を作っておきたいと考えるのですが、これはもう手戻り不可逆点を越えてしまっているので、私からの“大きな改変を伴う提案”は受け入れられないことが多いのです。
“大きな改変”を提案して現場を混乱させるために参画しているのではなく、そうならないようにあらかじめ中長期の目線で設計を考え、正しく評価する役割を担うつもりでいるのですが、現実はそううまくはいかないものです。
情報構造の構築と、その発展可能性に責任を持ちたいはずが…
参画時期が遅過ぎたプロジェクトにおけるアーキテクトが実際にできることとは、仕方なく負債的なものを抱えた状態でのなるべくベストな形を目指せる提案（＝マイナスへの振り幅を極力ゼロに戻すもの）をするにとどまってしまいます。
まだ実装もしていないのに負債的なものと付き合わなければならない（と自身では捉えてる）のは、なかなかに歯痒い思いがあります。仮にそれが法律だとかユーザーの生命に関わるようなことならクリティカル案件として強くストップをかけにいくこともありますが、そこまででもないならわざわざプロジェクトを止めて大きく後退・手戻りさせるような戦いに挑めるほど、私は強い精神の持ち主ではありません。
もうちょっとだけ早く呼んでくれれば、低コストでかなりいい形にもできたんだけどなーー。とモヤモヤした気持ちになること多しです。こういった場面で責任を持って戦える方はかなり強いと思います。
具体例を挙げてみます。
アーキテクトとして次のような“若干”破壊的提案をすることがありますが、私がプロジェクトに参画した時点で既に1つの「手戻り不可逆点」を越えてしまっていることにより、提案を諦めざるを得ない場面が少なくないのです。
「この情報構造では一つのユースケースしか想定していないので、将来の拡張性が低い。機能拡張の際に苦労するので別の形にした方が良い」
「この情報構造ではUIがモーダルに寄った表現になりやすいので、ユーザビリティに問題が生じる。今からでも作り直してモードレスにできる余地のある形を目指すべき」
「この情報構造は、一般的にiOS / Androidの仕組みとは相性が悪いので、モバイル前提ならば形を変えるべき」
情報構造というのは、例えばAとB二つの概念があったとして、仮にAがグループだとしたらBはグループの子要素、それら二つの関連はどう表せるか。別の概念Cを追加したらどういう関係になるのか。みたいな感じのものです。これを概念モデルなどと呼んだりもします。親子関係だと自ずとAがBを内包する関係になるのですが、デジタル表現では必ずしもAが上でBが下である表現に固執する必要もないのです。
表現の可能性をあらかじめ広げておくことが構造設計や情報設計で目指す一つの目標だと考えているのですが、構造設計の段階に専門家であるアーキテクト職が不在であると、それ以降の設計や表現の幅は大きく狭まり、綻びも生じ、製品として成せる可能性が大きく限られてしまうかもしれません。これは非常にもったいないことだと思います。
アーキテクト役が価値を発揮するのは、具体的な制作業務（FigmaでUIコンポーネントを量産する等）よりももっと前段階であることが多いです。制作業務ではどちらかというと成果物の評価が主体になります。
『構造設計とかってUIデザイナー1人では担えないんですか？』
アーキテクトがわざわざ専門職として一般のUIデザイナーとは別に存在している意義を問われることもしばしばありますが、私は「エンジニアリングがフロントエンドとバックエンドで区別されているように、デザインにも表と裏（※比喩表現）があります」とプレゼンすることが多いです。
追記：ならばと早い時期に参画するチャンレジをしてみるが
プロジェクト参画時期が遅いなら早めれば良いという単純な話もあるので、早い時期にプロジェクトに参画できるように政治をはたらいてみました。そこにはいくつかの乗り越えなければならない課題がありました。
まず予算の問題。こういうのは人月でお金がかかるので、仮にアーキテクト職を一名3ヶ月前から追加となると、その請求をクライアントに送らなければなりません。その交渉で躓くことがあります。また、潤沢な予算があっても交渉がうまくいかないパターンというものもあります（要はプレゼンが失敗する例）。
仮にうまく参画できたとしても、当初から3ヶ月限りと区切られた契約でプロジェクト進捗が遅かったりすると、本来価値を発揮すべき時期に離脱しなければならないこともあったりします。継続交渉を頑張るかどうかです。
それからプロジェクトの性質もあります。機能改修系のプロジェクトの場合はやはり根幹の設計は維持したまま追加実装するみたいな話になってくるので、できることは限られてきます。（当たり前ですが）
あとは運みたいなものもあるんですけど、早く参画したからといって絶対にうまくいくわけでもなく、そこいらはクライアントとの付き合い方やコミュニケーションの仕方によるかなと思います。私の経験でうまくいった例で多かったのは、意思決定が迅速（例えば現場に理解のある社長や取締役の方が直接MTGに参加されている等）で、かつ我々を信頼してくださっていて、作り方含めこちらからの提案にも耳を傾けてくださる方々がパートナーだと、非常にやりやすく成功確度も上がりやすいように思います。
UIの下地設計における手戻り不可逆点
影響が大きいか小さいか、挿げ替えが効くか効かないか
改変の際の影響が広範囲に及ぶものは、実質的に不可逆点として捉えられます。例えばモバイルappを作りますとなった時に、ネイティブ技術を使うかWebベースのものを使うかといった判断は、不可逆点の1つです。後から変更するにはあまりにも影響が大きすぎるためです。
（この例では、昔FacebookがモバイルappのアーキテクチャをWebベースからネイティブ技術に移行した例があります。）
挿げ替えが効きやすい要素とそうでない要素も見極めポイントです。UIではスキン（あるいはアピアランス、ダークモードなど）と呼ばれる仕組みが備わっていることがありますが、そのようなスタイルセットのプラグイン機構のようなものは構造さえ作ってしまえば、後からいくらでも追加のものを実装できます。しかしその「複数のスタイルセットを扱える構造自体」は設計の根幹である可能性があるため、この部分の改変には要注意です。
概念オブジェクト・概念モデルの組み立て
UIの下地設計とは、ワイヤーフレーム設計やナビゲーション設計よりももっと前の段階の「情報構造を構築する段階」を指しています。情報構造といってもパッとイメージが浮かびにくいかもしれませんが、UIで扱うコンテンツを概念オブジェクトと見立ててそれを定義していくやり方になります。
私が勧めるやり方は、モデルベースにUIを組み立てるデザインプロセスです。このやり方は、UIの見た目を形作るのではなく、UIで扱うコンテンツ、概念の形を作るところから始めます。
ナビゲーションとはUIにおけるユーザーが辿る経路を示すものですが、それらの経路は「画面」の遷移過程ではなく、実のところは概念オブジェクト同士の関連性と、状態遷移で表せます。ナビゲーションを「画面」で捉えると、まず「画面」のワイヤーフレームの方から先に作らなければと考えてしまうのですが、そうではなく、画面を構成する要素としてどのような概念オブジェクトが存在しているのかの定義から行なっていきます。
因果をまとめると、UI設計としては、ワイヤーフレームの前にナビゲーションがあり、ナビゲーションの前には概念オブジェクトが必要です。概念オブジェクトは概念モデルで表されます。
概念モデルが今後すべての設計図の下地になるため、一旦こいつを作ってしまえばあとは部品を組み立てるようにして作れるのですが、概念モデルを作る作業は非常に労力が必要になるため、この作業は手戻り不可逆点となり得ます。
こういった「手戻り不可逆点」は、ソフトウェア開発においてはいくつか存在し得ると思いますが、特にデザインの手戻り不可逆点として一番大きなものはこの概念モデリング等の下地設計です。
UIのナビゲーションはいつ作るべきなのか
理想論として語ります。まず述べたようにナビゲーションとは概念オブジェクトとその状態遷移を辿る経路なので、構成要素である概念オブジェクトの形をまず表さなければなりません。概念オブジェクトの設計図が概念モデルです。
概念モデルの設計はサービスの形や要件的なものを検討している段階には既に着手しているはずですから、UIのナビゲーションも大体同時期か、少し後くらいには設計し始めていないと手遅れになります。具体的なローカルナビゲーションの単位までやる必要はなくて、大まかにグローバルナビゲーションの方向性くらいが定まっていれば十分です。UIのワイヤーフレームを作ってからナビゲーション設計に着手する手順では、遅過ぎます。
グローバルナビゲーションの設計を手戻りさせるのは至難
適当なタブナビゲーションベースのモバイルappを想像してみて欲しいのですが、タブナビゲーションの設計を後から作り変えることは現実的でしょうか。それをやるとして、どのくらいの影響が生じそうか考えてみてください。特にエンジニアの方であれば苦い顔をするかもしれません。
変更の影響が大きい割に緊急性は高くないタスクというものは、優先度が低く設定されるものです。とりあえずバックログには積んどくけども、いつかやる。でもいつやるのかは今は決めない。くらいの扱いです。事実上の放置宣言なんですよね。ですからそういった負債を初めから作らないことが理想ではあるのですが、現実にはよくあることです。
こういった根幹を担う設計というのは一度作ったら後から直すことは非常に難しくなる「手戻り不可逆点」なので、最初の設計は慎重に行なった方が良いものです。例えばアンチパターンとして知られている「ホーム」タブを作ってしまいそうになったら、一旦立ち止まって、ホームではないメタファと役割を考えてみるのが良いと思います。一度建てられてしまった家は取り壊すのにも苦労します。
理想
最後に私の経験則からわかっていることを列挙します：
・作業の手戻り不可逆点は必ず存在するので、プロジェクトとして観測する仕組みにする。
・手戻りの芽となり得るものは予測できるようにして、先に潰す。
・UIのナビゲーション設計は、ワイヤーフレームよりも前に作る。概念モデリングやサービス設計と同時か少し遅れたくらいから着手する。
・ナビゲーションの基本設計は手戻り不可逆点として捉える。
・サービス設計段階からアーキテクトが関与する。
・作り方を提案する。相手の作り方にただ合わせにいくと、少なくともデザインの成功確度は下がる。
締めの言葉はありません。
この記事が気に入ったらサポートをしてみませんか？