フロントエンドには画面を設計するまでの抽象的な設計パターンが確立されていない

現在、フロントエンドには共通した設計パターンというものが確立されていない。
これは、フロントエンドエンジニアがトレンドとなるテクノロジーのみに焦点を置いて開発を行っているため、
テクノロジーの変更とともに、既存のテクノロジーで培ってきたテクニックが使用できなくなるためである。
フロントエンドで共通した抽象的な設計パターンを確立するには、テクノロジーからではなく、抽象的な設計パターンを確立したうえで、テクノロジーを選択しなければならない。

アレクサンドル・スヴェチンの著書、「戦略」から抽象的な設計パターンを考える

ロシアの軍事思想家、アレクサンドル・スヴェチンの著書、「戦略」で運用術を確立するには、以下の手順が必要とされている。
歴史
傾向、予測
運用術の力のスタイル、構造、手段の開発
運用術を適用するコンセプト、文脈、状況
アレクサンドル・スヴェチンの著書、「戦略」の思考パターンに沿って、フロントエンドの画面を設計するまでの抽象的な設計パターンを考えたいと思う。

「戦略」に基づき、フロントエンドの共通した設計パターンを確立する

歴史

• 1995年 日本で初めてのダイヤルアップIP接続サービスが開始
• 1995年 Windows95の販売開始
• 1995年 Javascript登場
• 2001年 NTTやソフトバンクをはじめとする電気通信事業者が、「フレッツADSL」や「Yahoo! BB」などのADSL事業を開始
• 2005年 Ajax技術誕生によるJQueryの普及
• 2007年 appleがiOSを搭載したスマートフォン「iPhone」を販売
• 2010年 仮想DOMを採用したJavaScriptフレームワーク「Angular」登場
• 2013年 仮想DOMを採用したJavaScriptフレームワーク「React」「Vue」登場
• 2016年 日本におけるインターネット普及率が86%を突破
• 2017年 Atomic Designという画面をコンポーネントごとに分割した開発手法が広がる
• 2018年 OOUI(オブジェクト指向ユーザーインターフェース)というデザインにオブジェクト指向を組み合わせた設計手法が広まる
• 2020年 コロナショック

傾向　予測

経済面の環境の変化

コロナショックよって、経済面で変化で、今後以下のような変化が予測される。
・コロナショックに伴う経済活動の縮小
・経済活動の縮小に伴う既存企業の倒産、業界の再編
・業界再編に伴い、インターネット上の既存技術が一つに統合*
・インターネットの技術統合による、安定した環境が誕生
・安定した環境下における経済の低成長時代

戦術面での環境の変化

OOUI(オブジェクト指向ユーザーインターフェース)の今後の広がりにより、デザイナーの間でOOUIをベースとした開発手法が流行すると思われる。
オブジェクト指向がデザイナーに理解されることによって、プログラマーとデザイナー間でオブジェクトをベースとした画面設計の話し合い、調整が行われると予測される。
また、Atomic Designによってデザイナーのタスクの分業化が進むため、画面開発のスピードもより素早くなっていくと推測される。

技術面での環境の変化

技術面の変化として、仮想DOMを採用したJavaScriptフレームワークの登場によって、画面に表示する全てのデータをバックエンドのAPIから取得するという手法は廃れ、
オブジェクト単位でバックエンドのAPIを呼び出し、画面のオブジェクト部分のみデータを書き換えるという手法がメインになると思われる。

Webへアクセスするデバイス面の変化

スマートフォンの日常生活への浸透、依存は、更に加速する傾向にあるため、スマートフォンからのアクセスをベースとしたフロントエンド設計が基本となる。

運用術のスタイル

OOUIをベースとしたレイヤー層の設計

OOUIをベースとして、以下の5つの層にレイヤーを分割
Controller層
Interaction層
Model層
View層
Infra層

Controller層の役割

View層のアクションを管理するためのクラス。アクションとは、画面へ表示するデータを取得し、表示するための機能。
アクション内のロジックは、Interaction層のメソッドの呼び出し、メソッドの返却値の取得などを行う、
アクションはURLによって動作が変更される。よって、アクションのクラスはアクションの種類ごとに生成される必要があるが、クラス内のロジックはURLごとに分岐されなければならない。

Interaction層の役割

Model層とController層の調整を行う層。画面で実現したい要求を記載するロジックのため、機能単位でクラスを作成する。
基本的なプログラムの流れは以下の通りとなる
バックエンドAPIのデータが必要な場合
・バックエンドAPIとの通信
・ Model層のクラスのインスタンス生成
・返却された通信結果をModel層のクラスに設定
・Controller層へ結果を返却

バックエンドAPIのデータが必要でない場合
・Model層のメソッドを実行
・Controller層へ結果を返却

Model層の役割

画面へ表示するオブジェクトの値を格納するクラス。
オブジェクトをベースとして画面設計などが行われるため、フロントエンド側で優先的に設計、開発を行うクラス。
オブジェクトはリスト型を基本するため、リストデータのフィルタリング、リスト内データの該当データの取得、getterメソッド提供などをメインの機能とする。

View層の役割

画面へ表示するModel層のオブジェクトを組み合わせて、画面を作成する。
画面はPC、スマートフォンごとに表示される内容が異なるため、テンプレートはPC用、スマートフォン用と別々に分けて作成する。
アクセスするデバイス、ブラウザの種類はInteraction層で判断し、判断結果に応じたレイアウトを出力する。

Infra層の役割

ライブラリを使用した機能を提供する。主にバックエンドのAPIとの通信を実施する。
チャット機能や地図の表示機能などはライブラリを通して、Infra層へ実装する。

インターフェースを使用して多様性(ポリモーフィズム)を実現

バックエンドが複雑なプログラミングをメインに担当しているが、フロントエンドはデータ表示というシンプルなプログラムを担当している。
アルゴリズムがシンプルかつデータ構造と密接に繋がりを持っているプログラムは、インターフェースを使用して多様性を実現する手法が非常に有効である。
データの表示のアルゴリズムは、処理内容がシンプルなので以下のように抽象化することができる
1.フロントエンド側のAPIと通信を行うかチェック
2.フロントエンド側のAPIと通信
3.フロントエンド側のAPIの戻り値をデータモデルに設定
4.データモデルに設定された値を使用して、画面に表示するデータ構造の文字列を作成
プログラムのメインロジックを抽象化したインターフェースメソッドのみで作成し、インターフェースを実装したクラスにメソッドの実ロジックを記載する。
メインロジックをインターフェースで記述することでポリモーフィズムを実現し、記述するプログラムソースの量を大幅に削減することができる。
運用術の構造にて、詳しい内部構造について記載する。

運用術の構造

運用術のスタイルで5つの層にレイヤーを分割をおこなった。この箇所では、レイヤーの内部の構造に焦点をおいた分析を行う。

View層

画面を以下のパーツ・コンポーネント単位で定義していく。
Material
Monitor
Function
Template

1.Material
View層の最小単位。画面に表示する画像、背景、BGMなどクリエイティブな作業工程が必要なデータを配置。

2.Monitor
Material、UI、ラベル、などを組み合わせて、画面に表示する内容を決定する。
Model層から取得したデータはすべてここに設定する。
Monitorには以下の2種類のデータが存在
静的なデータ・・・ナビゲーション、サイトマップなどリンクが固定されているデータ
動的なデータ・・・Model層から取得したデータ

3.Function
ユーザーの目的を達成するために設計されたデザイン。Templateのエリア内に表示する。
Monitorの組み合わせで構成されている。
<例>
ナビゲーション、サイトマップ、広告

4.Template
最終的に画面に表示されるレイアウト。画面のエリアの設定とエリア内に表示するFunctionによって構成されている。Templateは神秘的なシンボルによって、レイアウトの配置が決定される。
<例>Holy Grail Layout

Controller層

以下のパッケージ単位で定義していく。
Action
Converter

1.Action
画面のUIから呼び出されるメソッドのメインロジックを記載する。
OOUIの設計思想に沿って、従来の画面単位ではなく、UIとUI内に所属するアクションの種類ごとにクラスを作成していく。
<例>
クラス名：タッチパネル
メソッド：スクロール検知
以下の順番でロジックを記載する。
1.UIのアクションを検知
2.呼び出し画面のチェック
3.Converterクラスメソッドを呼び出す
4.Converterクラスメソッドの戻り値で画面のView層のデータ構造を書き換える

2.Converter
画面のUIの引数情報をInteraction層に渡すためのクラス。
Interaction層のロジックはインターフェースを使用して記述するため、
インターフェースクラスに画面のUIの引数情報を渡す。
以下の順番でロジックを記載する。
1.インターフェースのインスタンス生成
2.インスタンス生成時に画面のUIの引数情報を渡す
3.Interaction層のメソッドにインターフェースを引き渡す
4.Interaction層のメソッドの実行結果を戻り値として返却

Interaction層

以下のパッケージ単位で定義していく。
MetaInterface
Interaction

1.MetaInterface
インターフェースを定義するためのクラス。
インターフェースでロジックを記述する際に、フロントエンドのメインロジックのカテゴライズ化とインターフェースで実行するメソッドを決定する必要がある。
フロントエンドのメインロジックを以下のような種類に分類する。
<例>
Search・・・検索処理を実施するインターフェース。
Insert・・・DB登録処理を実施するインターフェース。
Delete・・・DB削除処理を実施するインターフェース。
Upadate・・・DB更新処理を実施するインターフェース。

インターフェースを以下のようなメソッドを実装する。
<例>
constructor・・・画面のUIの引数情報をModel層のフィールド変数に設定
isTranfer・・・バックエンドのApiと通信するか判定を行う
tranfer・・・バックエンドのApiと通信し、通信結果をModel層のクラスにマッピング
create・・・Model層に設定した値を使用して、View層の構造を書き換える文字列を生成する

2.Interaction
フロントエンドのメインロジックを記載するFacadeクラス。
インターフェースに実装されたメソッドを呼び出してロジックを記載する。
画面の要求を実現するためのクラスなので、ユースケース単位でクラスを記述する。

以下の順番でインターフェースロジックを呼び出す。
1.constructor
2.isTranfer
3.tranfer
4.create

Model層

以下のパッケージ単位で定義していく。
DataModel

1.DataModel
画面に表示するデータを管理するクラス。
DataModelはInteraction層のインターフェースを実装するため、画面に表示する値 + インターフェースで定義したメソッドを実装する。

Infra層

以下のパッケージ単位で定義していく。
interface
liblary

1.interface
liblaryのインターフェースを定義するためのクラス。
DI(依存性注入)の考え方でライブラリのメソッドを提供する。

2.liblary
チャット機能やビデオ通話機能などをアプリ追加する際のライブラリを管理するためのクラス。

運用術の手段の開発

運用術のスタイル、構造を通して、フロントエンドの設計の見取り図、内部構造を明らかにすることができた。
続いて、運用術のスタイル、構造を実際に活用する手段について考えたいと思う。
手段とは目的に達成するための「方法」。
目的とは、国家、会社などの特定の団体が設定した政治的な目標
そのため、手段とは、国家や会社の資源に依存した、制限的なツールと定義することができる。
手段には、イギリスの軍事思想家、ベイジル・リデル＝ハートが提唱した、直接アプローチと間接アプローチの2種類存在している。
直接アプローチとは、自分自身が主体となって、目標を達成する手段。
間接アプローチとは、対象をコントールすることによって、目標を達成する手段。
Webアプリを例に紹介すると、ECサイトは直接アプローチ、Youtubeは間接アプローチに分類することができる。手段を準備するには、上層部との政治的な調整、手段を達成する道具の準備、人材の確保などが必要なっていくる。手段は、前提条件、金額、リスク、効果を考慮に入れてうえで、慎重に選択されなかればならない。

運用術の力と手段の相関

運用術の手段の開発で政治目的を達成するための手段を選択した。つづいて、選択した運用術の手段と他者との戦闘力の比較が重要になる。
戦闘力は同一の手段を持つ競合する他業者を対象とし、我を基準として戦闘力の比率を検出する。
<例　対象とする戦闘力のパラメータ>
従業員数
資本金
設備
売上
同盟
戦闘力に差がある場合正面からぶつかることは得策ではないため、他手段の選択、迂回経路の選択などが重要になる。

運用術を適用するコンセプト、文脈、状況

コンセプトとは、運用術の手段を全体を貫く基本的な観点・考え方。
運用術のスタイル、手段は固定的なものだが、コンセプトは会社の政治的目標の達成、対象となる顧客のニーズを満たすために流動的なものでなければならない。
コンセプトを決定するには、コンセプトを適用する手段の外的要因、状況を想定し、健全な発展につながるコンセプトを設定しなけばならない。

アリストテレスの四原因説を使用して、手段のコンセプトを決定する抽象的な思考パターンを設定する

四原因説とは
アリストテレスが自著『自然学』の中で論じた、自然学の現象に関する4種類の原因。以下の4つの因子で構成されている。
目的因・・・物事の終り、すなわち物事がそれのためにでもあるそれ（目的）をも原因と言う。
形相因・・・形相または原型。
作用因・・・新たな結果・成果を産出する意味での作用因。力のスタート地点を表す。
質料因・・・存在するものの物質的な原因。銅像においては青銅が、銀盃においては銀が該当

OOUIのコンセプト
OOUI(オブジェクト指向ユーザーインターフェース)のコンセプトは、オブジェクトを人が見た際に要求が発生すると規定している。
よって、オブジェクトを人が見た瞬間に以下の原因が発生したとみなすことができる。
オブジェクト・・・現実に存在しているものだけでなく、新聞記事やインターネットの情報もオブジェクトに該当する
人的因・・・オブジェクトを見た瞬間に、オブジェクトへの要求が発生する。人ごとに要求はことなる。

四原因説にオブジェクト + 人的因を追加する
アリストテレスの四原因説にオブジェクト + 人的因を追加することで、以下のような連想思考が発生する。
オブジェクト
人的因
目的因
形相因
作用因
質料因
つまり、もの -> 人 -> 要求 -> デザイン ->アクション-> データの順番で画面全体のコンセプトが決定されるということになる。

テクノロジーの選択

運用術のスタイル、構造、手段、コンセプトの構想が決定された後に、構想を実現可能なテクノロジーを選択する。
以下の原則に沿ってテクノロジーを選択する
・シンプル
・テクノロジーの技術思想に一括したコンセプトが存在している
・歴史が長く、資料がインターネット上に豊富に存在している

ナラティブ

「戦略」の思考プリズムを通して、フロントエンドの設計パターンのスタイル、構造、手段、コンセプト、テクノロジーを決定するまでの理論を確立することができた。
しかし、アレクサンドル・スヴェチンの著書「戦略」は戦争を遂行する方法を追求した本であり、経済活動とは無縁である。そのため、経済活動の拡大、促進に繋げるためには「戦略」とは異なる考えが必要なる。
経済活動を促進するには、安全を提供し、未来へのビジョンを明確にするストーリーを作りあげることが重要になる。すなわち、ナラティブが重要な要素となる。
ナラティブは、以下の5つの要素で構成されている。

1.世界観
世界の捉え方、世界がこうあってほしいと願う価値観

2.歴史
世界観が作り上げられた背景、経緯、バックボーン

3.価値観
既存の秩序に存在していなかった理論、常識を覆す考え方、個人の生活パターンを変える新しい考え

4.物語
ストーリー、プロット、登場人物を作成し、登場人物を通して、価値観への共感を広げる

5.展開
価値観に基づく商品展開、パッケージ化、量産化体制の確立

ナラティブは主観的なものと客観的なものの2種類に分類される。
主観的ナラティブ・・・絵、芸能、芸術の分野で働く創造的なもの。個人のセンス、才能、スキルなど属人的なスキルに大きく左右され、理論化することができない。
客観的ナラティブ・・・科学に基づく仮説 + 仮説に基づいてモデル化された社会科学理論。科学の発展によって仮説が更新され続けるため、客観的ナラティブは常に変化する。
ナラティブとは結局のところ価値観の伝達であり、キリスト教の宗派が行った布教活動に近い。
ナラティブの世界観の幅、高さ、深さ、奥行き、柔軟性によって経済活動の限界値が決定される。
ナラティブの世界観をパラメータ化し、他のナラティブと相対化することができれば、良いナラティブと悪いナラティブを見分けることができるようになる。

リフレクティブコントロール(反射的制御)

運用術の手段、ナラティブが用意できた場合、残るはユーザーの行動シナリオを作成する。
マーケティングの世界では、カスタマージャーニー、軍事学の世界ではリフレクティブコントロール(反射的制御)と呼ばれている。
ユーザーの意識決定にネガティブフィードバック or ポジティブフィードバックを発生させ、ユーザーに選択してほしいシナリオへ誘導を行う。
ユーザーの意識決定を以下のレイヤー階層に分けて分析、シナリオ作成を行う。
地理・・・住んでいる場所
文化・・・所属している文化、カレンダーから文化の種類を特定
職業・・・職業の違いによって発生する価値観に焦点をあてる
コミュニティ・・・ユーザーが所属しているコミニュティによって生じる行動パターン
経済・・・経済活動によって生じる行動パターン
意識決定に基づくシナリオの作成が完了後、ネガティブフィードバック or ポジティブフィードバックが発生するイベントを発生させ、ユーザーの行動とシナリオの内容を比較し、シナリオの修正などを行う。

まとめ

2020年フロントエンドの技術は凄まじいスピードで進化している。学んでいた技術が当初は有効な手段だったものが翌年には技術のイノベーションによって陳腐化し、
最終的には時代遅れになってしまう。技術の進化スピードが格段に上がっている現在の世界では、技術レベルで物事を判断するエンジニアの寿命は短い。
今後のフロントエンドエンジニアは技術レベルではなく、UIの構想、チームの全体の能力を向上させる開発手法、マーケティング視点によるUIの開発などに視点を移すべきだ。