技術的負債に対峙するための「最初」と「一手間」

f:id:tsuyok:20171207123115p:plain

技術的負債の問題は全世界でおそらく課題になっていて（笑）皆さん頭を悩ませているんじゃなかろうか。私もずっとそうだ。プログラマとしてもマネージャーとしても、直接的にも間接的にも苦しめられてきた。

そんなこんなで、うまく行かなかったり多少改善したりしつつ、ドメイン駆動設計に出会って、これが突破口になるとは感じて、取り組んできたり研究したりしてきた。とはいえ、目の前の大きな負債に向かうのはモチベーションもわかないし、組織戦略としてどうするかは本当に悩ましい。問題は「技術的負債」と一言で言えるほど単純ではない。組織も人もサービスもシステムもビジネスも絡まり、大きくて複雑だ。

そんなこんなで、増田さんとうなぎを食べに行って、増田さんのその辺の見解を伺ったり、ディスカッションしたりしていたんだが、増田さんが木工職人の例を話しをされていたときに、

「木工職人たちは「一手間」を大事にしていた」

ということをおっしゃってた。我々素人だと一見判別できないし、それが品質にどれほど影響するかもわからないし、欧米的に「合理的な」判断をすると、その「一手間」の工程はおそらく省略されてしまうであろう小さな（ように見える）作業だった。そういうことがプログラマでも必要なのではないか、という風に増田さんはおっしゃっていて、それはすごく共感した。

例えば。

ベンチャーや新規システム開発などでゼロイチをやる場合、できるだけ早くユーザに機能や価値を届けるために、例えば設計のような概念は一旦置いておいて作ってしまうことが多いと聴く。お客さんがいない見えない中でプロダクトを作ることを考えると、何よりもスピードを重視するという意味で、ある一面ではそうあるべきだと思う。

ただ、そのように育ってきたベンチャーのサービスの実態を見てきた感覚から行くと、ゼロイチがある程度成功してから人が入ってきたり投資ができることにより、技術的負債の影響でプロダクトの成長が鈍化する、つまり開発スピードが著しく下がるということが起こっていることも事実だ。

その事実と増田さんの話を伺って思ったのは、ゼロイチの場合でも（あるいはそれ以外でも）エンジニアが木工職人のように「一手間」がかけられるかどうかが重要ではなかろうか。スピードは維持しつつバランスをとりながら、完璧ではなくても「未来の価値のために」誰も見えないところに一手間をかける。それは、設計の工夫や名前付けかもしれないし、境界づけられたコンテキストを意識することかもしれないし、その他かもしれない。それはエンジニアの総合的な設計力を問われる上、できるかできないかでスケールが必要になってからの大幅な（もっというと桁違いの）コストの差を生む。

そう考えて、このように思ったのである。