要件定義もれを前提とした設計
エンジニアと会話をしていると、いかに漏れの無い設計をするか、漏れの無い要件定義をするかという話はよく聞きます。ただ現実は、その話しているエンジニアが要件定義ダダ漏れの設計を垂れ流していました。漏れの無い設計、漏れの無い要件定義というのが会話に出てくるということは、それなりに自分の課題として取り組んでいる事柄だとは思うが、それでもダダ漏れです。
このような例はいくつでもあがります。むしろ一般的なエンジニアがこういうものなのでしょう。いかにミスをしないかというところに考え方が凝り固まっています。「停止したら数百万単位の損害が出るんだぞ！」なんて脅されながら仕事をしていれば、そうなっても無理はありません。ただ、そう言われたからといって、ミスゼロに固執するのもナンセンスです。完璧を目指すほど抜けが多いというのが現実です。
「だったらある程度のミスを許容すれば」という人も最近は見かけるようになりました。T業界にも最近、こういう変化を感じます。私も、完璧を目指すよりある程度のミスを想定した仕事への取り組み方の方が賢いと思います。ただ、許容するのはいいですが、どうアクションを取るのかという話をすると、まだまだちぐはぐな話しか出てきません。試行錯誤を初めて、しっくりくる回答が見つかっていないような感じです。
インフラに関していういのであれば、一度構築したシステムをリビルドするのは大した手間では無いと思っています。これが難しいと感じるのは、設定項目や構成のデータを整理できていないからです。実際にOSをインストールするにしても、二時間程度あれば作業は完了できます。設定にしても、スクリプトやバックアップからの復元などの機能を上手く活用すればそんなに時間はかかりません。手作業で仕事をしているから大変なだけです。
エンジニアの間で自動化や構造化ということがよく話題にあがります。何のための自動化なのでしょう。私は、高速でスクラップ・アンド・ビルドをするための手段だと考えています。一発で完璧なものを目指す、言い換えれば、試行錯誤を許さないような仕事の取り組み方では、自動化や構造化はむしろ無駄手間です。設計漏れや要件漏れに対する有効な手段はスクラップ・アンド・ビルドだと考えています。これが円滑に行えるようにすれば、設計ミスや要件定義漏れにも対応できるはずです。