開発エンジニアにはドキュメントにもシナリオを描くスキルが必要、なのです


システム開発をしていると決めた期限までリリースして、システムを運用担当へ引き継ぐか、devOpsのように開発者自身が運用をしないといけません。そりゃそうです、システムは自立しているわけではないので、システム運用で定常運用としてのメンテナンスや異常時運用を必要な時に必要なだけしないといけないからです。


で、システム開発をしているときは、業務要件からシステム要件を抽出して、システムを実装することになるんですが、どうしてもシステム要件のうちほぼ全部を業務で使用する機能に割り振るので、非機能の一つである運用設計は隅っこに追いやられてしまっているんじゃないかと思うんです。どうですかね。そんなことないですか。


SIerがデリバリするシステムとしての総合試験を実施するのはあくまでもシステムの面から見た総合試験であって、そこにはそのあと実務で使用するときの運用観点が入ることは稀です。なぜなら、自分たちで運用しないから。顧客が顧客の業務としてどんな高度基準でシステムと業務の折り合いをつけて運用するなんて顧客の立場でなければわからんです。


そこに、開発系のエンジニアが及ばない思考の領域があるじゃないかと思うんです。そのスキルを持っているのはやっぱり運用を経験しているエンジニアではないかと。


devOpsでなければ、運用するエンジニアから見れば実装された機能はブラックボックスとしてしか扱えない。だって、システムの仕様の決定に携わっていないんだもん。それを追えというのは現実的でないし、実際、仕様が決まった経緯なんてわかるような資料は残っていない。たとえ議事録が残っていたとしても、その仕様が決まった場の温度までわかるわけがない。だから、ブラックボックスとしてでしか扱えない。


だから、運用するエンジニアは、手元に入る情報だけでどう運用するのか、仮説を立てながら業務というシナリオを描くんですね。そこが運用するエンジニアの長けているところです。


でも、その運用するエンジニアに情報を提供する側の開発をするエンジニアには、そうした経験が少なかったり全くなかったりするから、なぜ、そうした情報が必要なのかの必要とする理由が理解できないんですね。


状況を想像すれば誰だって、アレもコレも根掘り葉掘り聞きたくなりますよ。だって、運用に引き継いだ途端、トラぶったら運用するエンジニアに説明責任まで移ってしまうんですから。


なので、ドキュメントを作るときに、日ごろから機能単位のシナリオとして

  • なぜ:何のために
  • いつ:その機能を使用するタイミング
  • だれ:どの機能が


の観点を意識して整理して作るようにすれば、システムの設計をするときも運用担当に引き渡すときも、慌ててシステム運用を深く考える必要もなくなるんです。なぜ、いつ、だれを意識すると、個々の機能もまとめたサブシステムになっても整合性を取りやすいんです。それは、それぞれのふるまいが荒くても整理させているからです。