はじめに

これからの時代のものづくり

• 個人や小チームがシステムを作ることが当たり前になりつつある
• 専門的なエンジニアだけでなく多くの人が仕組みを作る側に回っている
• その結果として従来の設計前提では成立しない場面が増えている
• 誰でも作れるようにするための設計が必要になっている

本記事の目的

• 「ちゃんと動くものを作る」とは何かを整理する
• なぜ作れそうで作れない状態が発生しているのかを明らかにする
• その問題に対してどのような構造を持てばよいかを提示する

原理と解決策

ものづくりにおける三つの課題

ちゃんと動かない問題

• 作ったはずのものが想定通りに動かない状態が頻繁に発生する
• 条件分岐や状態遷移の抜けによって一部のケースで破綻する
• 最後の詰めの段階で問題が顕在化しやすい

性能の問題

• 機能としては成立していても処理が遅い状態になる
• データ量や利用量の増加によって動作が劣化する
• 初期段階では問題が見えず後から顕在化する

作りやすさと変えやすさの問題

• 最初に作るまでのコストが高い
• 変更を加えると別の部分が壊れる
• 構造が固定化されて柔軟に変えられなくなる

なぜ今この3すくみに向き合うことが重要か

• これまでは一部の専門家がこれらを解決していた
• 今は多くの人がこの問題に直接向き合う必要がある
• ものづくりが一般化したことで設計の重要性が増している

これまで人類はどう解いてきたか

抽象化による対応

• 人類は低レイヤの操作から高レイヤの表現へと段階的に移行してきた
• クラスや関数といった構造によって複雑さをまとめて扱うようになった
• 人間が理解しやすい単位に分解することで扱いやすさを向上させてきた

分割と構造化による対応

• システムを小さな単位に分割することで管理しやすくしてきた
• 責務ごとに分けることで変更や再利用を可能にしてきた
• 大きな問題を小さな問題の集合として扱う方法が取られてきた

それでも残った問題

• 抽象化が進むほど全体像が見えにくくなる
• 分割された結果として全体の挙動を把握しづらくなる
• 実際にどう動くかや性能の問題が見えにくくなる

問題の本質

人が作れない理由は実装ではなく認知にある

• 多くの人はコードを書く段階ではなくその手前で止まっている
• 何をどう作るかのイメージが成立していない
• 実装手段があってもそれを使う前提が整っていない

想像が成立しないときに起きていること

• 対象を自分の言葉で捉えられていない
• 何を一つの単位として扱うべきか分からない
• 操作や変化のイメージが持てない
• 結果として実装に進めない

命名とイメージが前提条件である

• 人は名前とイメージを通じて対象を理解する
• 命名が曖昧だと対象の境界も曖昧になる
• 操作や設計の単位も不明確になる
• 良い設計はまず認知できる単位を作ることから始まる

「8割できた」が想定していた現実にならない理由

• 頭の中では動いているつもりでも状態が整理されていない
• 条件の組み合わせや例外ケースが抜け落ちている
• 最後の段階で複雑性が一気に顕在化する
• 残りの2割にそれまでの何倍ものコストがかかる
• 結果として作れそうで作れない状態が生まれる

あるべき創造インフラ

共通バックエンドという前提

• データ処理や状態管理は一つの基盤に集約できる
• 正しく動くロジックを分散させずに管理することが重要である
• 動作保証や整合性はバックエンド側で担保されるべきである

個別認知に合わせられるGUI

• 人ごとに理解しやすい形は異なる
• 同じ構造でも見せ方や切り方を変える必要がある
• GUIは単なる表示ではなく理解を補助する役割を持つ

個別化可能なオブジェクトハンドリング

• 同じ対象でも人によって異なる名前や意味づけが存在する
• 扱う単位や操作の切り方も個人ごとに異なる
• それらを許容しながら内部では一貫した構造を保つ必要がある

GUIと自然言語の中間としてのUI

• GUIは制約が強く安全だが柔軟性が低い
• 自然言語は柔軟だが曖昧さが残る
• その中間として意図を保ったまま操作できるUIが必要である
• 構造として確定できる範囲で柔軟性を持たせることが重要である

想像と実際に動くものを往復できること

• 画面単位の試作だけでは意味がない
• 実際に動くシステムとして成立している必要がある
• 想像した内容をそのまま動作する形に落とせることが重要である
• 動かしながら再び想像に戻ることができる
• この往復が成立すれば誰でも作るための想像行為が可能になる

この構造によって可能になること

一つのバックエンドから多数のプロダクトを作る

• 処理やロジックは共通のまま維持できる
• UIや操作の違いだけで異なるプロダクトとして成立させられる
• 一つの基盤の上に100や200の単位で展開することが可能になる

UIの探索を実際に動く形で行える

• 抽象的な検討ではなく実際に動かして試すことができる
• 仮説をすぐに実装し検証することができる
• 使い勝手や設計の良し悪しを高速に判断できる

試作と本番が分断されない

• バックエンドが共通であるため状態やデータが連続する
• 試作段階で扱ったデータがそのまま残る
• 正解に至るまでの試行錯誤がそのまま資産になる

想像と実装の距離が縮まる

• 自分の言葉で考えた内容をそのまま扱える
• 想像したものをすぐに動く形にできる
• 最後の2割にかかる負担が大きく減る

これがあるから作れるし作りたい世界

単純な利便性

顧客ごとに最適化された仕組みを民主的に作れる

• 同じバックエンドの上で対象ユーザーごとにUIを最適化できる
• 高齢者向け、子供向け、専門職向けなど解像度の高い設計が可能になる
• 誰か一人にとって分かりやすい形をそのままプロダクトとして成立させられる

UIの違いによって複数の市場に最適化できる

• トップページや文字サイズや情報量を自由に調整できる
• ユーザーに不要な情報を削ぎ落とすことができる
• 同一機能でも市場ごとに異なるプロダクトとして展開できる

おもろい価値

一つのテーマを全ての人に開くことができる

• 一つの課題に対して複数のUIを用意できる
• それぞれのユーザーが自分に合った入口から入れる
• 同じテーマを全員が異なる体験で扱うことができる

UIが異なるまま同じ世界に参加できる

UIは人を選別している

• 一つのUIは特定の人にしか適合しない
• UIが固定されると参加できる人が限定される
• 結果としてコミュニティやプロダクトの多様性が失われる

同じUIを前提とすることの違和感

• 異なる背景を持つ人が同じ操作体系を共有する必要はない
• UIを統一すること自体が制約になっている
• 参加の前提としてUIを合わせる構造になっている

UIが違っても同じ活動に参加できる構造

• 見えているものや操作方法が違っていてもよい
• 裏側で同じ状態やデータに接続されていればよい
• 協力や参加や交流がUIに依存しなくなる

共通バックエンドによる合流可能な世界

異なる体験が同じ基盤に接続される

• ある人はゲームとして体験する
• ある人は業務ツールとして体験する
• しかし裏側では同じ処理やデータに接続されている

UIが異なるまま協力や交流が成立する

• 異なるUIでも同じ目的に貢献できる
• 同じ世界に対して異なる役割で関与できる
• UIを揃えなくても関係性が成立する

一つの世界に多様な入口を持たせる

• 一つのプロダクトではなく一つの基盤を共有する
• 入口が複数あることで参加障壁が下がる
• 結果としてより多くの人が関与できる

インターフェースの違いを許容する経済圏

言語と同じ構造

• 言語は人ごとに異なるインターフェースである
• しかし翻訳によって相互理解が可能になっている
• インターフェースの違いを前提にした接続が成立している

UIも同様に扱うことができる

• UIは操作のためのインターフェースである
• 個人ごとに異なってよい
• 共通バックエンドがあれば接続が可能になる

合流できる世界や経済圏が生まれる

• 異なる体験を持つ人が同じ場に参加できる
• 新しい価値や文化が生まれる
• 一つの形に統一しないことで多様性が維持される

この考えの核心

UIは分断ではなく接続のために設計されるべきである

• 従来はUIによって対象ユーザーが限定されていた
• これからはUIを変えながら同じ世界に接続する
• そのために共通バックエンドが必要になる

一つのプロダクトは一つの世界を制限してしまう

• 単一UIは単一の価値観を前提にする
• その結果として多様性が失われる
• UIの数を増やすことで世界の広がりを維持できる