最小構成、最大構成
「meddle / おせっかいであること」
色々と思ったこと。
エンジニアのメインストリームはいまだSI系である。
ちょっと前までWeb系エンジニアというものが存在しなかったわけなので、当たり前なのだけども。
SI系は制約条件に基づきつつシステムの安定こそが重要な目標なので、まあ「最小構成」を是とするのは仕方ないことなのだろうな、と。
ってか、受託業務としての性質が強いので、「おせっかい」（＝「余計な仕事」）は単なる損失にしか過ぎない。
そもそも、
「安定したシステムを作る究極の手段はシステムを作らないことだ。」
ところが、リソースの制約が無限大の場合、全く逆のことが言える。
「リソースが無限大の場合、成功する最も確実な方法はいいと思ったことを全てやることだ。」
最小構成、最大構成は相反するものであるのだが、どちらにも成功及び失敗の可能性がある。
例えば、キャノンは「選択と集中」路線にならい不採算部門を整理したことによって成功を遂げたのであり、一方でGoogleはムダを許容し続けることにより「たまに」革新的なサービスを産み出す。
また逆に、零細IT企業は「選択と集中」を余儀なくされているがために永遠の自転車操業を続けるわけであり、役所の仕事は「予算」というリソースが甚大にあったが故にぼんぼんとムダなハコモノを産み出していったわけだ。
そのブレストをするためには、チーム全員が「おせっかいの実現」について真剣に考えることが必要です。誰か一人、「それってウザクね？」と思っていたら、真におせっかいな人でない限り遠慮するのが日本人気質というものです。ましてこういう付加要素的な機能を面倒くさがるエンジニアの「工数かかりますよ」攻撃は、こういうアイディアを無効化する絶対的な破壊的パワーを持っています。
「工数かかりますよ」という言葉に対し、「いいよ」と言えないのが弱さかな、とも思う。
或いはビジネスの価値を共有し、目標を同じにしてもらいたいのであれば、
技術者の目
あとビジネスベースの企画段階から参入させるのもいいのかな。 受託の場合、手っ取り早いのはクライアントとの打ち合わせに参加させて、「温度」を体感させるのもいいじゃないの、とは思う。
ってことが重要なのかな、と思う。
