私たちはウェブ開発 (Web Development) を生業にしています。現場で仕事をするなかで、ウェブ開発という仕事をどのように捉えるか、どのようにパターン化することで効率化できるか、パターン化のためにどのようなメモが有用かを考えてきました。そしてそれは今も継続しています。
このドキュメントでは、私たちなりに考えたウェブ開発についてをまとめています。ウェブ開発というと、プログラミングが思い浮かぶかもしれませんが、それだけに止まらず、受発注がどのように行われるか、開発プロセスはどのように制御されるかついても扱っています。
ドキュメントは大枠として、全体像、パターン、メモの三回層で整理しています。ブログ形式で記述されているものから、Wiki 形式で記述されているものまで、情報の特性に合わせて管理されています。また、それぞれのトピックについての俯瞰図を用意することで、抽象と具体のピントが合うようにし、全体像を見失うことなく情報を確認できるようにしています。
システム開発は複雑ですが、盤面を把握することで選択肢を管理することができます。ビジネスの羅針盤として活用されることを目指しています。
「プロセス」は、一つの会社内の活動です。一つの会社で発生し、対処するべきイベントと言い換えることもできます。基本的にはウェブシステムの開発プロセスを扱いますが、その拡張としての起業プロセスも見ていきます。プロセスを整理する目的は、事前にどんなことが起こるのか予測するためです。プロセスを整理したからといって、うまくやれるわけではありませんが、自分たちがどの程度複雑なことに取り組んでいるか認識を新たにすることができます。そして、その複雑さがプロセスを同時に取り組まなくてはいけない、同時性にあるということに気づきます。同時性とどの程度向き合うか、どのように避けるかについて考えるきっかけを与えてくれるでしょう。
「受発注」は、会社間の取引を考えます。システム開発では、発注者と受注者でシステムへの見識の非対称性が発生します。結果的に会社間の取引で、意思疎通に齟齬が生まれます。それらを回避するために、システム開発の全体像を可視化します。全体を通して、どのように合意形成を取るのかを考えています。システム開発そのものをパターン化し、カタログ化することに挑戦していますが、その目的は合意形成のためです。見識の非対称性の解決策としてカタログ化、サービス化を推し進めています。
「プロセス」は社内に閉じて話を進めるのに対して、「受発注」は会社間の取引の話をします。
中層では、ウェブシステムを開発するにあたり、よく発生するパターンを整理します。典型的で頻出のパターンを優先的に扱いつつ、できる限り全体をカバーするよう善処しています。いつもどのような仕様書を作っているか、もしくは仕様書を作成する上で基本的に考えているか。どのシステムでも繰り返し実装する機能。ウェブシステムのインターフェースの制約、インターフェースを作る上でのデザイン手法。これらについてパターンを整理しました。
本質的には、システムごとに、どんな特徴のデータを、どのように操作するか考えることにつきますが、少し俯瞰してウェブシステムそのものの特徴を考えることで、特定システムを比較分析することができるようになるでしょう。パターンの組み合わせにより、オリジナルなシステムを構築するイメージを共有します。
下層では、具体的なメモを扱います。メモの蓄積により、パターン化や全体像の構築につながります。ソースコード、専門用語の解説と用語間のつながり、カテゴライズが一概にできない内容のエッセイなども公開しています。
全体像がわかり、パターンがわかったとしても、具体的な引き出しがなければ形骸化してしまいます。上層と中層は下層からノイズを消したものです。抽象と具体を行き来できるように気を使いつつ、実際に現場から出たメモを扱います。真偽不確かで、バイアスのある内容もありますが、現場のリアルとして公開することに意味があると考えています。この点は不誠実かもしれませんが、下層の情報の真偽は各々で判断してください。