手順書Night 第1回 (connpass) 登壇時にオンラインで寄せられた質疑への回答を載せています。

Last updated: Mar. 31, 2022

Kohji MATSUBAYASHI <[email protected]>

(1) (旧来の)手順書が自身の分身であること、教育的役割非常に理解できます。 私はよく旧来の手順書に「魂を実装した」、といった表現を個人的に使っています。 それらを自動化やコードに持っていった時に、「魂」=経験則・技術的な理由に基づいた処理の理由など、自然言語で伝達できていたノウハウを別の形で伝える必要があると考えていますが、実際の経験談などあればお伺いしたいです。(対技術者での技術継承の観点で)

まずもって、「『コード化（＝自動化）』と『手順書』は敵同士ではない」「片方はもう片方があれば必要なくなるわけではない」といった点が重要と考えています。手順書の中にもコード片/コマンド列が現れますよね。それらコード片/コマンド列だって立派な「自動化」の最もシンプルな例です。

「自然言語で伝達していたノウハウを別の形で伝える」のでもなく、「自然言語を撤廃する」のが主眼でもないのです。自然言語でしか伝達できない（自然言語の方が人間に対して伝達に適している）情報は、手順書が使われるシーン全体でもたくさんあるのは当然ですよね。

当日お話しした通り、手順書は「自然言語で書かれた」「人間（＝手順書を使って作業を行う人）へのプログラム」と見なすことができます。その「手順書」の最も根幹部分である「作業手順の列挙」そのもの自体には、おっしゃる「魂」を込める余地はありません。その作業手順をコード化（＝自動化）しても同様です。

「魂＝経験則・技術的な理由に基づいた処理の理由」と書かれたものは、「作業手順の読み解き方」「作業手順の意味を理解するのに必要な背景知識や過去の失敗から学んだ経験則」などに属する、と考えると、手順書にまつわるさまざなな情報、つまり

• 純粋な「作業手順書」、限界まで削ぎ落として手順やコマンドなどを時系列に書いたもの
• その「作業手順書」の後ろに秘められた意味（なぜプランAではなくプランBを行うと書かれているのか、なぜここで別のコマンドで確認しないといけないか、そもそもこの用語はなにを意味するのか、このコマンドはそもそもどんな機能があって、他のコマンドではなくこのコマンドを使うのはなぜか、そもそもOSやコンピュータアーキテクチャに対する基礎的な理解があるか、などなど膨大）

の2つを、手順書を書く人・読む人が分類し理解できていない、あるいは書く時に論理だてずにごっちゃに書いてしまうために手順書の読み手が混乱してしまう、などが、ここでの問題と言えるでしょう。

そのような意味で、「教育」が必要です。手順書の読み手にも書き手にも。