管理者用の手順書
私も63歳の半ばとなり、自分の業務の引き継ぎとして、管理者用の手順書を書く
事になりました。
管理者用の手順書は、
- （一般用の手順書と違い）細かい事を書いて良い、むしろ書け
- 読者は、対象となる開発環境について、中堅レベルの知識を期待して良い
（あるいは、私の今回のシステムは知らないが、中堅レベル以上の知識を
持つ（親方的な）人のサポートを期待できる）
と言う特徴があります。
書いてみると、
書いてみると、
- 対象となる開発環境の概略
を書いた後は、
- トピックベース（（箇条書きで）レベル1の項目も、レベル50の項目も同じに並べる）（「箇条書きが書けない １」参照）
になる様です。
開発について素人の（例えば営業畑の）人間は、箇条書きでレベル1から、せいぜい4程度までを強調しますが、それでは確実に失敗するのです。
「レベルの高いものから（重要度の高い（？）ものから）」作業をしたい、管理職やリーダーにとって、トピックベースの一覧など唾棄すべきものなのでしょう。
（そうとしか思えない態度でした。）
束因果ダイアログで考えると、
この点を束因果ダイアログで考えると、
- ある開発環境で、システムを作ると、
- 束因果ダイアログ中の「原因 → 結果」（以下、射と言う、大量に有る）で、
- 同じ内容の射を全部で1つと数えた場合、
- それら射の、99.9%（感覚的に）は、中堅レベル以上の知識を持った人は、同じに書く
- 99.9%（感覚的に）同じに書く様になる事こそ、全ての開発環境の本懐である。
- なので、そうでは無い少数（0.1%（感覚的に））の射についてのみ、文書化しさえすれば、
- 中堅レベル以上の人間（中堅レベル以上の人間がサポートとして付く）の場合には、必要十分となる。
- 箇条書きの様に、レベル１からレベル４までで切るのでは無く、中堅レベル以上の知識で同じに書く部分を切る。
と言う事なのでは無いかと考えます。
まさに、トピックベースの書き方です。
素人に
他の畑の人間に、文書の書き方を（特に管理者向け文書の書き方を）口出しさせるべきでは無かったのではないかと後悔しています。
結論
これからも「箇条書きが書けない」事でプログラミングが嫌いになる人は存在し続ける事でしょう。
