ソフトウェア開発の「○○駆動開発」は多すぎる。が、フレームワークは先人の英知の缶詰で、何も考えず乗っかった方が手戻りが少ない。同じ発想で TDD・BDD・DDD・XP などを「育児 フレームワーク」に翻訳してみるシリーズを始めます。
○○駆動開発、多すぎませんか。
TDD (テスト駆動開発)、FDD (機能駆動開発)、BDD (振る舞い駆動開発)、MDD (モデル駆動開発)、DDD (ドメイン駆動設計)、TiDD (チケット駆動開発)、CDD (コンポーネント駆動開発)、最近だと AIDD (AI 駆動開発) まで来ました。
言ってることは、分かるんです。
僕も基本はいつも TDD でいきたい派です。先にテストシナリオを書いておきたい。実装の前に、何が「動いた」状態なのかを決めておきたい。
MVP (Minimum Viable Product) を仕上げる段は FDD でいきたい。機能単位で小さく刻んで、ひとつずつ Done にしていきたい。
…分かるんです。分かるんですけど、それはそれとして、○○駆動開発、多すぎませんか、という話です。
ソフトウェア開発において、フレームワーク (framework / 方法論) というのは、先人の知恵と経験がほぼ全部詰まった缶詰みたいなものです。
何も考えずにフレームワークに乗っ取った方が、たいていうまくいきます。手戻りが少ない。判断回数が減る。レビューもしやすい。
チケット管理も、ITIL (IT サービス管理のベストプラクティス集) も、PMBOK (プロジェクトマネジメント知識体系) も、ひと通り読みました。資格も取りました。読みながら「だよねー、さすがだよねー」と言ってました。当たり前のことを当たり前にやることが、結局いちばんの近道だと思っています。
我が家の話に近いことを言うと、料理のレシピと同じです。
プロのレシピ通りに作れば、まあまあ美味しいものができる。アレンジは、レシピ通りに 3 回作ってからにしろ、というやつです。
これを開発以外のメンバーに導入しようとすると、わりとうまくいきません。
「めんどくさい」「うちの案件には必要ない」「そんな硬いやり方しなくても回ってる」。
…内心ね、思うわけですよ。どれだけの英知が集まってる方法論やと思ってんねん、と。
でも、まあ、それはそれで一理あって。
ITIL も、よく読むと「この通りやれ」とは一言も書いていないんですよね。むしろ、案件ごと・組織ごとにカスタマイズして適用しろ、と書いてある。
○○駆動開発も同じです。プロジェクトの規模、フェーズ、メンバーの習熟度に応じて、選んでカスタマイズして使う。フルセットを毎回フルパワーで適用するものではない。
そういう意味では、ビジネスメンバーの「うちの案件には必要ない」も、半分くらいは合っている。残りの半分は、英知の缶詰を知らないだけだったりして。
ここから本題です。
育児においても、たぶん同じ構造があります。
先人の英知 ─ 育児書、保育士さんの言葉、児童心理学のリサーチ、近所のおばあちゃんの一言。あれ全部、形は違えど「方法論の缶詰」です。
ただ、誰も「育児 TDD みたいな考え方」とか「育児 DDD で 4 歳のドメイン尊重」とかでは整理してくれていない。エンジニアの語彙では、育児の英知はまだあまり整理されていない、というのが正直なところです。
そこで、このシリーズです。
エンジニアでもあり親でもある人間の語彙で、先人の英知を「育児 フレームワーク」として並べ直したら、何か見えるんちゃうか、という思考実験です。
TDD なら、子どもに小さく失敗してもらってから学ばせる「失敗確認駆動」みたいな読み替えができるかもしれない。
BDD なら、Given / When / Then で「この時間・この状況・この行動 → こう反応する」と仮説を立てる「観察駆動」かもしれない。
DDD なら、4 歳のドメイン (恐竜は今もそこにいる、エレベーターは生き物) を尊重して、親の世界の言葉で説得しない「子の世界観駆動」かもしれない。
…と、書いてて分かるんですが、これは結構ぶっ飛んだ思考実験です。
うまくハマる回もあれば、ハマらん回もあると思います。ハマらん時は、ハマらんかった理由を書きます。それも先人の英知の使いこなしの一部、ということにしておきたい。
もう一つだけ、シリーズの背骨になりそうな話を置いておきます。
買い物の場面で、女性に「どっちの服がいい?」と聞かれたとき、「どっちでもいいよ」「どっちも似合ってるよ」と返すより、一緒に悩んだ方が買い物時間が短くなる、という話があります (一次ソースは忘れました。何かの研究で出てた気も)。
これ、ソフトウェア開発でいうペアプロ (ペアプログラミング) と、XP (エクストリーム・プログラミング) の精神そのものだなと思っています。
一人で抱えて唸るより、横で一緒に唸る人がいた方が、判断が早い。アウトプットも、ちょっとだけ良くなるし、満足感が上がる気がする。
育児も、たぶんそうなんです。
「自分で考えなさい」と突き放すのも、もちろん一つの方法です。でも、横で一緒に悩んでくれる親がいることのほうが、子の判断速度を上げるんちゃうかなと、最近思っています。
親も、子と一緒に悩むことでアップデートされる。一方通行の教育ではなく、ペアプロです。
XP のように、子と親が一緒に悩み、一緒に成長していく ─ そういう「育児 フレームワーク」を、ソフトウェア開発手法から輸入してみる。それがこのシリーズの全体テーマです。