CDD (CV駆動開発) とは

CV駆動開発とは、自分の履歴書 (CV) をよりよく見せることを優先して設計や開発などの意思決定を行うソフトウェア開発プロセスである。

CV Driven Development (CDD) is a software development process which prioritises design and development choices that will enhance the implementing programmer’s Curriculum Vitae over other potential solutions, regardless of how rational that choice is.

CV Driven Development (CDD)

CV駆動 (としか思えないよう) な技術選定を目の当たりにしたエンジニアも多いのではないだろうか。

特にマイクロサービス。「なぜマイクロサービスなのか?」という質問をしてまともな答えが返ってきた試しがない。

• そもそも何をサービスと呼んでいるのか?
• サービスの永続データの整合性はどうするか?
• サービス間のI/Fの合意をどのような開発プロセスで行うか? サービスはどのようにテストすればよいか?
• そこまでして解決したい問題は何か?

このような質問を投げかけていくと、当の本人には

• 実はマイクロサービスアーキテクチャをよく知らない
• 過去にマイクロサービスはおろか、分散システムの経験もない

ということが多々ある。 モチベーションが問題解決ではなく自分の技術的好奇心あるいはCVに向いているのだろう。 知らないことは決して悪いことではない。 しかし、知らないことを知らないまま会社の重要な意思決定行うことは誠実でない。

私はかつて超巨大なBtoBプロダクトでマイクロサービスを経験した。 そのプロジェクトはモノシリックアーキテクチャからスタートした。 しかしコードベースが肥大化するにつれ、CIビルドは半日近く (つまり所定労働時間の殆ど) かかるようになり、それがソフトウェア品質にも影響を及ぼすようになったことでマイクロサービス化を決断した。

しかし、マイクロサービス化にも多くの苦難を伴った。

• サービス間での永続データの整合性
  • ラムダアーキテクチャの採用
  • 最新でないデータをユーザーに表示しても良いか? (一時的な不整合を許容しても良いか?) あるいはユーザーに対してどのような注意書きがあれば良いか?
• サービス間の連携
  • メッセージパッシングによるイベント駆動アーキテクチャを採用したが、MQのメカニズムはat least onceなので、同じ業務トランザクションを重複して処理しようとしていないかなどの考慮が必要
• ビルドオーダー
  • 各サービスのルーティングやエンドポイントの情報 (specと呼んでいた) を別モジュールに切り出して最初にビルドすることで、循環参照を防いだ

マイクロサービス化により発生しうる問題の殆どは計画段階で予見されていた。 しかし、将来的にはマイクロサービスに移行するメリットが上回ると考えてマイクロサービス化に踏み切ったそうだ。

ソフトウェアのアーキテクチャ1つで、開発プロセスにこれだけの副作用がある。 それを自分のCVの見栄えを優先して意思決定してしまうのは不誠実だと私は考える。 もっとも、CDDを「不誠実だ」と批判したところで、やる本人は自分に得があれば実行する。 なので私はCDDは買い手側 (つまり会社側) のリテラシー問題だと考える。