冒頭に少し長く、
エンジニアリングをマネージメントするとは何か、のような話があって、
プロジェクトマネジメントしようと思うんなら設計をするんだ、
ということだと思うんですよね
とおっしゃってて、
つまりは、開発プロセスと、アーキや設計は密接に絡み合っているもので、
どっちもいっしょに考えないとダメだよね、という話で。
なんかこれがすごくすとーんと落ちて、
『あ、だから「エンジニアリング」と「マネージメント」が切り離しできないんだ』
って思えて、すごくうれしかったです。
少し前に会社の中で
「プロジェクトリーダとプロジェクトマネージャ」ってことを話ししてて、
私は、区別わかんないし、区切れないし、みたいにずっと思ってたので、
今回のこのお話は スッキリ! という感じなのでした。
さて、その冒頭からの、設計だ、抽象だ、という話がずっと続くんですが、
抽象構造があとからわかるか、はじめからわかっているか、
という話がすごくおもしろくって、
以下、広木さんのツイートを引用して、今日はおしまいとするのだ。
ソフトウェアのパラダイムとしてある抽象構造が、自明のものとして先験的に存在し、それを分析しながら、それらをツリーによって分類可能であろうとして、再利用可能なコンポーネントに設計するというOOP初期に描かれた継承による抽象の考え方を僕は、「オントロジー的抽象」と表現していて、
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2019年6月19日
対して、抽象構造は事後的に発見され機能やビジネスの目的によって蒸留されることによって姿が見えてくる、それらはツリーではなくセミラティス構造になって発見されStructual SubtypingやDelegation/Composition、Mixinなどにより表現されることの多い抽象を「テレオロジー的抽象」と表現している。
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2019年6月19日
この抽象を先験的に発見しようとする試みが、「設計フェーズ」で、ウォーターフォール的な思考とアーキテクチャを関係づけるものになる。
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2019年6月19日
その逆に一度機能実装された後に事後的に見出されることを「リファクタリング」と考えるとアジャイル的な思考とアーキテクチャを関係づけるものになる。
また、これは「要求していたもの」の不確実性の高さにも関連する。
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2019年6月19日
かつては、業務に関わる知識があれば、十分なレベルでソフトウェアを設計するに足るドメイン知識になると考えられがちであったため、事前に設計することが可能であると考えられがちだった。
目で見て、業務に取り入れながら初めて顧客のニーズがわかってくる。これは事後的に本当の目的が発見されることによる。これがテレオロジー的な抽象で、あり、これを発見していく過程がアジャイル的開発フローの示唆するところなわけだ。
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2019年6月19日
オントロジー的抽象では、さんまといわしがあるとき「魚」を先験的に見出す。
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2019年6月19日
テレオロジー的抽象では、さんまといわしから
「夕飯のメイン具材」を事後的に見出す。
その後、豚肉が作られたら、
「魚」という抽象は、空虚なものになって、YAGNI原則の違反に見える。