• 開発の目的は、未実装機能の構築である。
• 運用の目的は、不具合機能の修正である。

何もないところから、作り上げていく作業と、すでに存在するものを分析する作業である。そして、それぞれの業務において、

• スピード
• コスト
• 品質

という異なる視点が、違いを明確にしていく。開発時に見つかった不具合は、得てして少ない箇所の修正で終わらせる傾向にある。同じロジックを複数持たせないという考え方だ。運用においては、共通処理に手を出さない。

例えば、1ヵ所の修正で、関連する機能が100本あった場合、100人体制のプロジェクトであれば、数時間で終わるだろう。運用は、2人、3人という体制で、100本の検証はあり得ない。共通処理に手を出す場合は、共通処理をコピーし、個別に対応する。不具合機能が10本であれば、10本の検証で終わる。

リリース当初によくある問題として、類似不良が洗い出せない事がある。同じ記述になっていれば、わかるだろうと突っ込みたくなるのだが、実際はそうではない。

Aチームと共通チームで開発が進んでいる中、Bチームが後から参画した。Bチームは共通処理の問題点を見つけ、共通チームに告知したが、後発というコミュニケーションの問題から共通機能で解決する事はなかった。仕方がないので、Bチーム内で共通機能＋αで回避する事にした。一方、Aチームのaさんは気づいており、自分の担当プログラムだけ直した。そんな中、共通チームのhさんは、共通機能２という改定機能を新たに生み出していた。これを利用したのが、Cチームだったが、aさんと仲の良かったcさんは古い共通機能を利用していた。

こんな事は開発の中ではよくある事だ。参画タイミング以外に開発ボリュームがAチーム：60%、Bチーム：30%、Cチーム：10%と異なる事により力関係も変わってくる。そして、タイミングも、製造工程で発覚すれば、問題ないが、あるチームは結合テストで気づき、あるチームは総合テストで気づいた場合、修正する時間とパワーが残っているか。そして、共通機能の問題が、それを利用する全ての機能に影響するのか、という根本的な問題がある。

これらの事を理解し、全ての機能においてあるべき姿に持っていくには、技術力と体力が必要になる。絡み合った状態を、devoptの改造してリリースするルーチンを短縮化するのも、難しいだろう。

クラウド＋APIの公開が広がりつつある。これは何かというと、何もかも、異なる環境のプログラム同士が結合し、個々のAPIに影響する範囲は提供機能のみである。機能が限定されれば、テストの自動化も容易になり、小さな規模の自動リリースも、またしかりである。

devOptは、改造、自動テスト、自動リリースと、自動化する事で、個人の私感を排除するとともに定量的な品質を提供する思想である。自動化ツールは提供されてきているが、機能の実装、提供方法も、考えなくてはならない。