ソフトウェアの内部品質への投資を怠ったが故に、その内部品質がビジネスの足枷になってしまった、という失敗はよく聞かれる例だと思う。
そういう場合、「なのでソフトウェアの内部品質を直しましょう！」と言う発想になりがちだし、当然そのための投資を始めることは必要なのだけれど、それ以上に注目しなければならない問題がある、と最近は思うようになった。
「内部品質が落ちたので内部品質を直しましょう」というのは、単なる対症療法である上に「いつんなったら直って内部品質への投資やめられるの」という誤った問いを誘発してしまう。よくある話として、一定の内部品質を達成するために「リプレースプロジェクトです！」と言って書き換えを進めて、それが終わったらまた内部品質は鑑みられなくなるような話があるし、内部品質だけではなく「EOL対応」とかでもそういうケースはまま聞く。
じつは直面すべき課題は「内部品質の低さ」や「依存ライブラリのアップデートが間に合っていないこと」ではなく、そのような状況を生み出してしまった開発プロセスや組織設計にあり、「開発プロセスや組織設計をどう直すか」なのである、というのはこの一年の大きな学びの一つだった。そして、とくに組織設計の話は現場のことをしっかり理解した上でトップダウンで進めるべき仕事で、VPoEとかCTOとか呼ばれる人の仕事だったり、ぼくがいまいる会社で言えばVPoTがやるべき仕事なのだ、と思う。
記事のタイトルを回収しておくと、プロダクトの品質を継続的に高く保つためには、プロダクトに向き合うだけでは足りなくて、それを生み出すプロセスや組織に向き合う必要がある。チームはそれぞれチームに向き合う必要があるし、チームを束ねる立場（これは上下ではなくて役割の違いだ）は各チームの組成をどのように行い、各チームがどのようにコラボレーションするかの設計に向き合わなければならない。
こんなあたりまえのことをきちんと理解するまでに1年以上かかってしまったけれど、理解したからには向き合っていこうと思う。
