【開発哲学_ちょいとブレイク】〜いいなと思う統合のやりかた〜
SECIモデル（『世界標準の経営理論』第15章）
『リファクタリング』が３分の２まで感想書けたので、久しぶりにちょいとブレイクーーーー！！！！！
でも出てきた統合について開発現場にいる人間から一番いいなと思う統合のやりかた。
CODECOMPLETE29章では、
フォール型とインクリメント型を紹介していて、
❌ フォール型
⭕️ インクリメント型
みたいな感想を書いたんだけど、近年の開発現場の動向から、経営学の理論と組み合わせて一番いいなと思うのは、
SECIモデル
を組織全体で導入して、依頼元の部署や顧客ときちんと連携して経験から学んだ知恵を共有ながらプロジェクトを動かすことかなと。
なぜSECIモデルがいいか
フォール型やインクリメント型だけだと、
依頼する側と開発側が分離されてる
👉どちらの方法で行っても、依頼する側とすれば、
納期が守れた上で、出来上がれば良し
になり、次に何かを発注するまでに、前回の発注でどこに問題点があったのか（要求の出し方、時間のかかった理由など）を依頼側が学ばない、学べない。
＝（SECIモデルの）内面化（Internalization）ができない
👉同じ歴史（＝失敗）を繰り返す可能性が高くなる。
SECIモデルで内面化まで行うように統合すると
課題解決や要求実現に向けて行われた経験が
組織に落とし込み（＝内包、インクルージョン）
＊今世間一般で使われてるインクルージョンとはちょっと違う意味かな。
できる。
👉組織の記憶（『世界標準の経営理論』第14章）として定着する。
定着すれば、次の要求を出す時に前回の経験を組織として活かせる。
例えば、
で、「こんなものを作りたいな」「こんなものがあればいいな」「こんなものがあれば売れるな」などの要求が組織で出てきた時に
理想：
① 調査（要求を実現するためにデータの実態や、社内でどのくらい同じように思っている人がいるかリサーチしたり、顧客のニーズはどのくらいあるかマーケティングする）
↓
② 要求（社内で必要性が高いとか作れば売り上げが見込めると調査結果がわかってから、開発依頼をする）
↓
③ 作成（要求に基づいて開発部署で作る）
なんだけど、経験がないか経験から学ばない個人や組織の
現実：
① 要求（データも見ないしリサーチもしてないけど、誰かの思いつきでこんなことができたらいいなで会議をし、がっちり要求を固めて、作ることが最優先で開発部署に依頼）
↓
② 作成（開発部署でプロトタイプを作成している段階で、要求段階で想定しているデータの入り方になっていない、想定外のデータが多数存在など数々の問題が判明し、差し戻しかQAの嵐）
↓
③ 調査（差し戻しやQAを受けて、結局、依頼した部署や会社でデータ全件を洗い直すことになる）
結果的に、
開発者を疑って、組織や会社間でギスギスしたり、開発部署から言われて初めて全体のデータを調査したところ実現不可能とわかったり、マーケティングやリサーチをしてみて、できたところで大した収益が見込めないと判明したり
で結局、要求を取り下げになる。
差し戻したり、QAを返した時にすんなり応じるのはまだマシで
「金を払っている」とか「上司の言うことは絶対」みたいなモラルライセンシング
に毒されたクライアントや管理者だと、
「それでもなんとかするのがエンジニア」
の一点張りで、現実を見ようとしない。
ないデータの統計を取るとか、キーがないのにつなぐとか、物理的に実現不可能なことをよく理解してないから、「なんとかしろ」で済ます。
コード打って人間が空を飛べるようにしてくれと言っているようなもの＝物理的に現在の科学だと不可能ですぜ
なんとか動くものを作れたしても、
発注する組織が何も学んでいないから、理不尽な要求を繰り返された結果、アホらしくなって、取引を次回から受けてもらえないか、優秀な人から会社を去っていき、その段になって初めて学ばざるを得なくなるのが関の山。
・できる人がいれば任せとけばいい。資料なんか必要ない（＝丸投げ、誰かに任せっ放し）
⬇︎
・やってくれてた人が組織を去る
⬇︎
・組織的には何も経験を積んでいない
⬇︎
・ゼロからのスタート＝振り出しに戻る
の悪循環。
今の時代、どんなサービスをしようとしても
必ず何かしらアプリやシステムに当たる
にもかかわらず、コードとか知らないから
開発＝他人事
で自分事として捉えていない人が経営層含め大半
日本の企業がいまいちイノベーションを図れないひとつの要因
担当者に任せきりで、
その担当者の経験を「組織の記憶」として、
社内や組織内に「内面化」できていない
👉SECIモデルの未実施
それだけが原因とは限らないってゆー人もいるだろうけど。
それがSECIで内面化までできると、
最初は、やり方がわからないから時間がかかっても、
次回から他の要求を出す前に、
「前回で結局必要になったから、開発部署に要求する前に、データをきちんと自分達で調べたり、こういうデータパターンだけで間違いないか開発部署にデータ調査依頼を出したり、アンケートやリサーチでマーケティングしよ」
で、理想に近い要求の出し方ができるかなと。
結論
純粋な開発作業としては、
インクリメント手法で統合
プロジェクトに携わるステークホルダー全体としては、
SECIモデルで統合
👉垂直的統合（Vertical Integration）
ここまでくるともはや経営の話だな 笑
所詮、ただの１プログラマの私見であり、持論であり、戯言〜〜〜。
まとめ
💃開発プロジェクトも所詮はマネジメント
マネジメント＝経営理論に問題解決に糸口はあったりする
所詮は全て繋がっている＝色即是空
↓
技術書以外の本を読むのも大事🕺
この記事が気に入ったらサポートをしてみませんか？