新規事業開発の実務

どうせすぐ忘れるんでしょ\(^o^)/

DDD推進してる人達と話してきた

どもども。

エンジニアリングの知識は5年前のモデル駆動開発で止まっている直人です。

 

昨日は、社内でDDD(ドメイン駆動設計)を推進しようとする人達の集まりに参加してきました。

 

前述の通り、もはや私の時代遅れな知識はモダンなエンジニアリングプロセスのあるべき姿について語れるようなレベルではないので、ビジネスの要求とシステムへの落とし込みについて感想も含めて書いてみようと思います。

 

集まったのは、社内の各所でDDDやよりアジャイルでスマートな開発プロセスを推進する方々。これまでキャリアを伺うと、前職の超有名企業で最新のエンジニアリングを推進した方や、たくさんの書籍を執筆した実績をお持ちの業界の有名人などなど、そうそうたる顔ぶれでございました。みなさん、各々の担当領域で各種プロダクトの開発に当たりながら、より柔軟で高速な開発プロセスの実現に試行錯誤を繰り返しているそうです。

 

話を聞いていて、今も昔も変わらないと感じるのは、「作り方」や「アーキテクチャ」のような、結果として見えない部分へ、マネジメントやビジネスに携わる人達の関心を向けることの難しさです。

 

めまぐるしく変化する市場の環境やニーズに対応するため、PMやマーケター、ディレクターといったビジネスサイドのスタッフは次々と要求を投げてきます。エンジニアサイドはその要求を最速で実現させながら、増え続けるコードの最適化や共通化、知識の共有といった「攻めるための保守」とでも言うべき対応も並行してこなさなければなりません。

 

後者のような業務は、いわゆる「重要度が高いものの緊急度はそれほどでもない」類のもの。仕事をしていると誰でも経験があることだと思いますが、実際の現場でその逆の「緊急度は高いものの重要度は低い」作業が結構な頻度で発生するんですよね。

 

そんな中、いまいま何か問題があるわけではないが、放っておくと後で問題になりかねない重要なタスクがある。しかも、それに工数をかけても目に見えて売り上げが伸びるようなものではないもの。このようなタスクにどう対処していくべきか。参加したメンバーはそれぞれの組織やプロダクトの事情を共有しつつ、現実的な解を模索していました。

 

いつでも、どんなケースにも対応できる万能なやり方はまだ見つかっていませんが、現場で生み出されたひとつの成功体験として、「人を巻き込みながら作る、非デジタルのモデル図」が挙げられます。

 

社内の機密情報であるため、実際の図は紹介できないのですが、対象のシステムを紙やホワイトボード、付箋を使ってモデリングしていくというものです。ガイドになるのはDDDのメソッドであり、モデリングの過程で定義されるユビキタス言語です。

 

「実際にできるかできないかを分けるのは、やろうという意思。やり方にこだわるりすぎてはいけない。」

 

そんな意見が印象的でした。

 

ミーティングの後、各チームが作ったモデル図を見て回りました。

 

「出来上がったモデル図よりも、その過程で共有された暗黙知にこそ価値があるよね。」

 

「最初から厳密にしようとしないで、全体像から必要に応じて詳細化すればいい。ビジネスのニーズもあるべき姿もすぐに変わってしまう。目的のない作り込みに意味はない。」

 

「細分化された仕様書だと、後から入ってきた人が最初から細部にフォーカスしてしまう。全体を大ざっくりで俯瞰できる世界地図は新人や他チームとの情報共有にもとても役立っている。」

 

そんなやり取りが交わされていました。

 

グリーは私が見てきたWEB系サービスの会社の中でも比較的ビジネスサイドとエンジニアの距離が近い(チームによってはほぼ一体化している)会社だと思います。それでも会社の規模がここまで大きくなってくると、ビジネスを見る実務家とシステムを管理する実務家、両者にはそれぞれ高い専門性が求められるようになり、分業が進んでくるのは当然のことだと思います。

 

両者は同じビジネスのゴールを目指してはいるけれど、フォーカスする領域や追いかけるKPIが異なるため、細かいすり合わせや折衝、妥協というのはそれこそ、日々数限りなく生まれています(エンジニアリングの人達は、このような「妥協」を「腐敗防止層」というレイヤーをかませることで回避している)。

 

今、グリーの社内では、エンジニアリングの人たちを中心に大きく成長したサービスやシステムの整理整頓が行われています。それだけでなく、営業などのビジネスサイドにもアジャイルの研修を積極的に行い、「指示の出し方」や「エンジニアとの会話の仕方」などをより正確にしていこうという動きもあるようです。

 

ひとつひとつの折衝で生まれる小さなミスリードや思い違いも積もり積もれば大きなロスとなる可能性を秘めています。数百万人ものユーザーが使う巨大なシステムを抱えながら、ユーザーのニーズを的確に反映していくための共通言語づくり。地道な活動ですが、こういう活動の積み重ねがよりよい改善につながるのだと感じました。

 

これからも彼らの活動に参加し、積極的に推進していきたいと思います。