ソフトウェアを構築するときに作り方（ウォーターフォールとかアジャイル開発とか）などに注目されがちだが、むしろ注目すべきなのは構築するソフトウェアのサイズなのではないかと最近考えている。というわけで、ざっくりと小さいほうからプロダクト、システム、エンタープライズシステムズという区分でソフトウェアのサイズについて考えていることを書きだしてみた記事。
ソフトウェアのサイズ
ソフトウェアのサイズとザックリと表現してしまうのも乱暴だけれども、何かのソフトウェアを作る時には大きさというものはある。
ただし、ソフトウェアは物理的なものではないので重さとか体積のような形でサイズを測ることはできない。ひとつの指標としては、プログラムの行数というものもあるが、これもよくわからない。というわけで本記事は（いいたいことを言うためにも）ザックリ3つにサイズを分類して論じてみたい。3つとはこれだ。
- プロダクト：わたしたち消費者がつかうサービス／アプリ。個人で作る人もいるね。ものすごく複雑な場合もある。
- システム ：組織でお仕事を処理するために構築するソフトウェア。動かなくなると、ビジネスに影響が出る。
- エンタープライズシステムズ：いろいろなシステムの組合せで実現される企業の仕組み。でかい。
1. プロダクト
わたしたち消費者がつかうサービス／アプリ。個人で作る人もいるね。
ものすごく複雑な場合もある。
- プロダクトといってもいろいろあるが、ここでは「あたらしいToDo管理サービス・アプリ」程度のものをイメージしながら書く
- プロダクトの最大の特徴は組織（会社やチーム）の外側にユーザー（利用者、消費者）がいることだ。つまりユーザーに「要件」を直接確認することはできない
- ゆえにプロダクトを作る際に要件定義を実施したり、ウォーターフォールのような計画駆動の開発アプローチを実行することは難しい。何を作ったら正解（売れるのか）がわからないから
- アジャイル開発、そしてリーンスタートアップに代表されるアプローチが発明されて、プロダクト開発は非常にやりやすくなった。試行錯誤することが正しいということになったから（ただしアプローチを変えても正解に達するかどうかはわからない。ただし早い段階で方向転換や撤退ができるようになった）
- プロダクトは概念的には小さい。つまり「構造」にあまり注意を払わなくても構築することができる。つまりITアーキテクトのような役割の人が気を配らなくても破綻しにくい。そして拡張していく中でうまくいかなくなったら、作り直してしまうことも可能
- 品質要求は厳しめ（ユーザーが外部にいるので、使い方が既定できず、品質が悪いと利用されなくなってしまう）
これがプロダクトだ。でも世の中はプロダクトばかりではない。より大きなサイズのシステムというものがある。
2. システム
組織でお仕事を処理するために構築するソフトウェア。
動かなくなると、ビジネスに影響が出る。
- 一般的には組織の目的（ビジネス）などを効率よく達成するために作られる、プロダクトより大きなソフトウェアがシステムである。人事システムとか会計システムとか、いろいろある
- システムの最大の特徴は組織（会社）の内側にもユーザーがいるということだ。なおプロダクトのように外部にユーザーがいる場合もある（例えばECサービスにはいる）が、いない場合もある
- いろいろなユーザーが使用するということは、さまざまなユーザーの要求があるということだ。Aさんの要求とBさんの要求が相反するという場合もある。よって要求を整理する必要がある、すなわち要件定義をやったほうがシステムは構築しやすい。要件定義を省略したり手を抜くと、ハウルの動く城ができてしまうこともある（「要望どおり動きますがなにか？」）
- システムは概念的には大きい、つまり「構造」に注意を払った方がうまく構築できる。よってITアーキテクトのような役割の人が気を配ったほうがよい。もしくは標準的なプラットフォームを用意してそれを利用するルールなどを制定するという手もある
- 構想（要件定義をやっていたらソレ）に従って構築することになる。作り方はウォーターフォールのような計画駆動でもアジャイル開発でもよい。ただし構想や構造や標準が不明確な状態でアジャイル開発で作ると香港にあった九龍城砦のようなシステムになってしまうこともある（「住めます、ちょっとカオスだけど」）
- 構築後も使い続けるためにコストがかかる。諸説あるが使い終わる（廃棄する）までに２～３倍のコストが（期間で合計すると）かかる。出来が悪いとこのコストは増える
- 品質要求はプロダクトよりは緩め（多少の問題があっても、運用で回避することができる）
これがシステムだ。世の中で多くがこのシステム開発に関わっている。このシステムが組み合わさると、エンタープライズシステムズになる。
3. エンタープライズシステムズ
いろいろなシステムの組合せで実現される企業の仕組み。でかい。
- 現代のビジネスはデジタルと人が組み合わさって成り立っている。というわけで企業などの組織は複数のシステムと複数の部署で成り立っている。その集合体がエンタープライズシステムズだ
- この全体像をうまくコントロールする適切な手法は存在しない。エンタープライズアーキテクチャという方法論があったが、定着はしなかった。舵取りは経営者や、システム部署の担当部長や、経営に近いエンジニアが工夫してやっている
- とはいえ何とかしてコントロールする必要がある。コントロールするためには構造を整理しなければならない。この構造とは技術的なものというより、都市計画に近いものになる。うまくない構造はトラブルや非効率（重要な機能の欠落や重複）を生む
- エンタープライズシステムズの視点に立つと、たくさんの利害関係者が協調して活動するための全体の大方針や中長期の計画まで必要になる。このレベルではアジャイルにやるという考え方は適用しにくい（脱予算経営とかホラクラシー型といった方向性はあるが、誰でもできるようなものにはなっていない）
- 全体像をコントロールするにはシステム（もしくはデジタル）の知識が必要だが、それだけではない。企業全体のルールや統制から、組織開発まで話は及ぶ
構築するソフトウェアのサイズによって考えることは違う
つらづらと思うところを書いてきたが、言いたいのは構築するソフトウェアのサイズによって考えることが違うということだ。
それはひとことでいえば「関わる人が増えるほどに、考えるべきことが変わる（増える）」ということでもある。
多くの人を動かすためには規律が必要で、その規律が
と言い換えられるのかもしれない。
でも、まず先に考えるべきは構築しようとしているソフトウェア（と、そのサイズ）であって、規律ではないはずだ。というのがわたしの意見なんだけど、皆さんはどう考えるのだろうか
