作ること自体を目的にはしていません。何をもって成功とするかを先に具体化し、その成功に必要な範囲だけを実装する。予算と目的に応じて、設計の深さは変わると考えています。

完成度を最初から最大化するよりも、まずは動く形をつくり、使い、検証し、必要であれば作り直す。捨てやすさを前提にすることで、過剰投資を防ぐことができます。

フェーズという考え方

いきなり最適解を固定するのではなく、第一フェーズで最小構成をつくり、現場での運用を通じて課題を抽出する。必要であれば第二フェーズで構造から再設計する。その循環の方が現実的だと考えています。

技術も価値も変化し続けます。考え得るすべての機能を最初から搭載しても、完成した頃には前提が変わっていることもあります。だからこそ、速度を設計に含めます。

時間をつくるための装置

システムは効率化のためのものというよりも、本当に大事なことに時間を割くための装置だと捉えています。入力、確認、集計、転記といった作業を減らすことで、人が判断や対話に使える時間を増やす。そのための設計を行います。

運用コストと吸収範囲

理想としては、人がシステムに合わせるのではなく、システムが人に合わせる形が望ましい。ただし、その分だけコストが発生します。

運用コストは、現場のリテラシーを上げるか、システム側で吸収するかの判断で大きく変わります。教育で揃えれば初期開発は軽くできますが、継続コストが増えやすい。システムで吸収すれば初期開発は重くなりますが、運用は安定しやすい。

目的と予算に応じて、どこまでをシステムで吸収するかを設計。

立ち上げという局面

立ち上げ期や、中小規模の環境で力を発揮します。形が固まっていない段階ほど、設計の自由度がある。

成熟した大規模システムの長期安定運用は、組織の方が合理的な場面も多いと考えています。役割は局面によって変わります。

社会の成熟度と変化の速度

理念をそのままシステムに落とすと、今までにない構造になることがあります。新しい構造は、新しい操作、新しい感覚、新しい価値を伴います。

操作は慣れで解決できることが多い。しかし、価値観の変化は簡単ではありません。人の心は制度よりはるかに遅い。世代を越えなければ変わらないものもあります。

正しさと受け入れやすさは別問題です。社会の成熟度と接続しながら設計することも、設計の一部だと考えています。

理想を掲げ、少しずつ引っ張っていく。