まさに今週は、作業に明け暮れる一週間だった。なぜそんな目にあったのかについては語らないが、とにかく延々と作業をやり続けた。
納期も量もシビアだったので、普段は手順書を残すのが当たり前だが、一部簡略化したり作らなかったりした。それぐらいやらないと間に合わないのわかっていた。いろんなショートカットを経てようやく達成に漕ぎ着けた。
この手順書なるもの、なんとなく限界を感じた。それはプログラミングでも感じたことのあることと同様だった。
手順書は、時系列に上から順番で進行していく。プログラムも同様だ。その順番通りにこなせば誰でも最後まで行けるのが手順書だ。手順書の限界はこの性質にある。
なぜその手順を思いつき、その値をそこで選んだのか、という思考が手順書には載ってこない。プログラムを書く人はたまに注釈をつける人がいて、その根拠を残す場合もある。
しかし、いちいち全てのロジックに対して、思考を残そうものなら記載がまどろっこしくなる。ちょっとのことをやりたいだけなのに、手順書を残しその上、注釈まで入れていたらかなり読みにくくなる。
例えば歩行するのに、なぜ右足を出して左足を出して、みたいなことを全て理由をつけようとしたら歩きづらくなるのと同じ理屈である。
手順書は、大きな考え方・哲学のようなものをバッサリと切り捨ててくるのだ。だから、手順書を書きながら思ったのが、考え方を書かずに残した手順は、誰かがこれを真似するかもしれないが、意味も分からずやることになるかもしれない。それはその手順書を使った人の実力になるのかはわからないな、と。
この手順だって、いきなり思いついたわけではなく、いろいろやって経験して、ああこれが良いなと思った内容なのだが、手順書を読む方には伝わらない。重要なのは、大きな考え方を柔軟に活用し、今の状況に合わせて手順自体を作れることなのだが、手順書だけ読んでいてもそうはならないんじゃないか、と思う。
そんな手順書の限界を感じながら、そして納期を踏まえつつ、ああこれは、手順書を真面目に細かく書いて時間を消化するより、大まかな考え方を伝えるような手順書にし、後日読む人がストーリーを理解できるような形にしようと思ったわけだ。
特に、ソフトウェアまわりは、時間か経つと画面も変われば必要な対応もまちまちとなる。だから、手順書自体も賞味期限がある。ただ、考え方自体はバージョンが変わってもそんなに変わらないのが常だ。
最近はAnsibleなど、手順書を作り人が実施するのではなく、コードを書いて手順はシステムがやるような手法も広まっていると聞く。結局は、救うのはコードではなく、コードをどんな考え方で作ったか、の方が大事になるはずである。見よう見まねで、その手順を出来るようになる人はいるのだけど、手順書を逸脱できないのだ。だから、そういう人の仕事は、大きな考え方がまとまっておらず、作業に抜け漏れが生じてしまう。木を見て森を見ず。
どうやって、この大きな考え方を身に着け、手順書に依存しない技術を持てるかという話。むしろ、手順書なんか作らないで、どんどん作業したほうが、本人の実力は付くと思う。いろいろ考えてリアルタイムに試すほうが良い。ただ本番環境ではそんなことはできずらいので、構築をたくさん経験したり、検証環境を触り倒してみるなど、手順書と離れた場所こそスキルアップがある。
きれいな道ばかりガイドブックの通り歩いていたら、世の中の広さを感じられないのと同じなのかもしれない。
