orangeitems’s diary

クラウド専任の40代インフラエンジニアが書くブログ。新規事業マネージャー。20世紀末の就職氷河期スタート時にIT業界に文系未経験で入りこみそのまま生き残った人。

構成資料は図か文章か、というより、そもそも書きたくないんだが

f:id:orangeitems:20220412123950j:plain

 

ITの仕事は、手を動かすことと、構成資料作りの両面で成り立っている。

手を動かすことが好きな人が多いのは理解している。私もその一人だ。コンピューターが好きでこの業界に入ってきている人は多いのだから、コンピューターであれこれしてそれこれできるひとときは、楽しさが含まれている。

一方で、構成資料作りは正直言って苦痛でしかない。どのような実装をしたのか、文書で残さなければいけない。文章かもしれないし図かもしれない。どちらにしろ、第三者がわかるかたちで文書を残し、何を為したのかを表現しなければならない。

構成資料がなければ、手を動かした人しか何を実装したのかわからない。それは困る。手を動かした人が実装したものと一緒にいてくれる保障はないからだ。そして実装した人も忘れるのだ。私も、構成資料のないシステムをさわって、おおこれよくできてるな、と思ったら自分が実装したホストで、そりゃ自分のロジックを実装してるから相性もいいよねと思ったものだ。

図がいいのか文章がいいのかなんて、そんな大した話じゃないのである。どちらにしろ作成するのもめんどうだし、それをまたメンテナンスして最新化するのも大変なのである。読む人はありがたいのかもしれないが、実装した人からすれば負担でしかない。

今日はどこやらのサイトでエンジニアは図をもっと書くべし、みたいな話が盛り上がってるみたいだけど、図は作成コストがかかる。完成したら誰かに伝わりやすくなるのかもしれないが、その図が正しい理解をした人が作ったか保障がない。さんざん時間を使って図を書いた挙句、間違っとるやないかい、となると時間ばっかり消費するので、それより文章を書け。文章だったらまず無理解では書けないし、人に説明する時は文章なのだから、説明の訓練にもなる。図に頼らないと説明できないのは、いろいろつらいぞ。で、まあ正しく理解できているのなら、図も使いようはある。だから図を書く訓練をするぐらいなら、ちゃんとした理解をするために時間を使おうね。まともな文章が書けるようになるようにしようね、というアドバイスとなる。

ちょっと話は逸れたが、結局のところ構成資料を作成するのに、この業界は時間を使いすぎのように思う。実装した内容は、リアルタイムに構成資料が生み出され、かつ時間軸とともに更新されないものか。

そもそも現在のソフトウェアは、無数に設定箇所があるのである。その設定箇所を全部エクスポートして表計算なんぞの二次元に落とし込もうとするから、構成資料作りはどの現場でも辟易しているのだ。だいたいの実装では、設定変更箇所なんて仕様全体のごくごく一部だ。だから変更した部分だけを構成資料にして出す場合もあるが、そうすると将来的に保守の中で変更する場所について構成資料に反映するときまた、フォーマットをさわる必要がある。

したがって、作業の度に、ボタンを押すと最新の構成資料がチャカチャカチーンって出てくれるようにどのソフトウェアもハードウェアもしてくれるといいなと思ってる。

なんで構成資料から離れられないかって、システムリプレースや構成変更のときに、今の設定をシステムの中に入らなくても欲しいからだよね。結構今のソフトウェアって管理画面がWeb化してて、構成情報もデータベース化されていることが多い。であれば、文書を作成するのも自動化できるはず。

もっと実装者は、実装に集中したいわけ。設計書は書きますよ。「なぜそうやって実装したか」は別の視点だよね。でも事細かく、ソフトウェアの変数すべてを抜き出してドキュメントにするのはそろそろ勘弁してほしいと言ったところ。