型が、4つから7つになった
前の記事で、教訓を52件並べて4つの型にまとめた、と書いた。
そのあと、記録を全部数え直した。教訓は71件あった。
業務に寄ったものを除いて69件を整理し直したら、型は7つになった。
失敗のほうも数えた。半年分のチャットから拾い出した失敗は223件。
1件ずつ読んで分類したら、教訓とは別のデータなのに、同じ7つの型が出てきた。
そして、いちばん多かった型は「書いてあることが、実物と違う」だった。
41件。223件の18%。2位に9件差をつけていた。
ついでに書いておく。前の記事で「第38版」と書いた引き継ぎ文書は、いま第49版になっている。
教訓は52件から71件、やらないと決めたことは11件から25件に増えた。
「たぶん完成しない」と書いたとおりになっている。
型が増えたのではない。数が増えたから見えた。52件では、4つにしか見えなかった。
記事①の続きではない
最初の記事で、こう書いた。
資料には「インターネットに接続しない」と書いてあったのに、実際には外部通信が3系統あった、と。
あれは、この41件のうちの2件だった。
残りの39件は、外部通信とは関係がない。
引き継ぎ資料、手順書、プログラムの中のコメント、残タスクの一覧、記録に書かれた件数や行数や日付。
それが全部、現物とずれていた。
あの記事を書いたとき、私はあれを事件だと思っていた。型だった。
資料は、実物と違う
「標準ライブラリのみ」と、3点に書いていた
資料3点すべてに「標準ライブラリのみで構築」と書いてあった。
実際には、外部のライブラリを2つ使っていた。標準は21種。
なぜそう書いたのか。実際のコードを確認せず、以前の記述をそのまま引き継いでいた。
発覚のきっかけは、AIに想定質問を作らせたことだった。
「使っているライブラリの一覧は」という質問が出てきて、答えようとして気づいた。
説明の当日に聞かれていたら、その場で矛盾を突かれていた。
直し方は、全部のソースコードから読み込みの宣言を機械的に抜き出して、実測することにした。
4か所直すつもりが、20か所古かった
技術資料の「記録機能の説明を1か所書き換える」だけの予定だった。
通して読んだら、データの保管場所が移行前の古い場所のまま書かれていた。
実装済みの機能が「未実装」のままだった。実際には存在しないファイルが2つ載っていた。
当初直す予定だった箇所は4か所。実際に見つかった古い記述は20か所。うち重要度が高いものが3件。
なぜこうなるのか。機能を改修したとき、資料をそのつど直す運用になっていなかった。
改修は記録が残る。資料の更新は、誰にも催促されない。
部分修正をやめて、全面改訂に切り替えた。
部分的に直すと、直した箇所と古い箇所が混ざって、「どこが最新か分からない資料」になるからだ。
手順書に、存在しないボタンが2つあった
改訂した手順書に、画面に無いボタンの名前を2つ書いていた。画面の名称も違っていた。
実際の画面を見ずに、旧版の記述をそのまま引き継いだためだった。
スクリーンショットを8枚もらって、1つずつ照合して直した。
3件とも、資料を書いた人は嘘をついていない。
書いた時点では正しかったか、正しいと信じていた。
一覧は、実態と違う
残タスク7項目のうち、実在は2項目
片付ける対象として、3日分・7項目が一覧に並んでいた。
実際に残っていたのは、1日分・2項目だった。
片付けたものが、一覧から消されていなかった。
別の一覧には「2本保管」と書いてあったが、実在は1本だった。
改修リストに無い不整合が、13件出てきた
改修リストにある項目だけを直すつもりで、資料を開いた。
通して読むと、リストに無いずれが資料ごとに複数見つかった。
運用引き継ぎ書で9件、手順書で2件、別の手順書で2件。合計13件。
改修リストは「前回気づいたこと」の集まりだった。資料全体の整合性を保証するものではなかった。
資料に書かれたフォルダが、存在しなかった
引き継ぎ資料に「最新版は現行フォルダで管理」と書いてあった。
そのフォルダは、無かった。
資料一覧には16種類が載っていたが、その階層には0件。
手順書は3週間前の版のまま、引き継ぎ資料は18版ぶん古いものが置かれていた。
資料に運用ルールを書いた。実際のフォルダに適用しないまま、版を重ねていた。
確認事項に残っていた資料は、そもそも存在しなかった
棚卸しの一覧から漏れていた資料を探した。見つかったのは、名前の似た別物だった。
作ったことは覚えていた。現存するかを確かめないまま、確認事項として引き継がれ続けていた。
一覧は、作った瞬間の実態を写している。その後の実態は、写していない。
記録は、現物より古い
ここまでは、まだ分かる。時間が経てば古くなる。
分からなかったのは、次の話だった。
6分後に、古くなっていた
引き継ぎ記録に「資料Bは完成済み・空欄なし」と書いてあった。
その記録が作られた6分後に、資料Bが加筆されていた。
ファイル名は変わっていなかった。
だからファイル名だけを見ていたら、記録と現物のどちらが新しいか判断できない。
気づいたのは、前後の画面に写っていたファイルサイズと更新時刻を突き合わせたからだった。
26KBが31KBになっていた。更新時刻は11時43分から12時31分。記録が作られたのは12時25分。
6分。
午前に直したものが、午後に古くなった
前の版の引き継ぎに、こう書いてあった。
「7項目のうち3項目は、同日午前の修正で片づいている可能性が高い」。
現物を開いたら、3項目とも未対応だった。7項目すべてが残っていた。
資料が誤っていたのではない。
同じ日の午前に正しく直した内容が、午後の作業で古くなっていた。
午前の時点で正しく書いたバージョン表記が、午後の差し替えで上がった。
午前に片方の章だけ直し、もう片方まで手が回らなかった。
午前に「復旧する方針」と書き、午後に「復旧しない」へ方針を変えた。
教訓として1行足した。「対応済みかもしれない」は、必ず現物で確かめる。
記録どおりにメールを作ったら、7か所ずれていた
引き継ぎ文書に、送信済みメールの文面が転記してあった。それを見て、催促メールの案を作った。
資料の参照ページが5か所、書き出しと署名で2か所。
実際に送ったものと、7か所違っていた。
転記した時点では正しかった。そのあとに資料の版が変わり、記録だけが古いまま残った。
そのまま送っていれば、受け取った側が資料を開いても、該当箇所に行き当たらなかった。
送信済みメールの現物ファイルを出してもらい、そこから作り直した。
元資料の誤りが、下流に伝染していた
チェックリストの前書きに「印つき4つ」と書いてあった。表の下の注記にも「4項目」。
表の現物を数えたら、印は5つあった。
そして、引き継ぎ用の文書が、この誤った数字をそのまま引き写していた。
記録は、書いた瞬間から古くなり始める。
「そのうち古くなる」の話ではない。書き終えた6分後には、もう違っていることがある。
コメントも、疑う
コメントどおりにやると、ツールは開かない
設定ファイルを作り直すために、現物を読んだ。
手順のコメントが「このファイルを書き換えて再起動すれば反映されます」で終わっていた。
そのとおりにやると、ツールは開かない。
運用を「再起動後に手動でプログラムを起動する」方式に変えたとき、設定ファイル側のコメントを直していなかった。
手順を4ステップから8ステップに書き直した。
プログラムのコメントも、同じだけ古かった
資料の裏取りのためにプログラムを読んだら、そのコメントにも、存在しないファイルからの起動方法が書かれていた。
実装済みの窓口3本が、一覧から漏れていた。
ある関数のコメントには「複写しない」と書いてあった。実際のコードでは、複写されていた。
引き継ぎ文書のほうが、間違っていた
引き継ぎ文書に「手順書のボタン名が誤って書かれている」という申し送りがあった。
現物を確認したら、手順書は元から正しかった。誤っていたのは、申し送りのほうだった。
コードのコメントは、コードの一部に見える。資料と同じだけ、古くなる。
なぜ、こうなるのか
41件の「なぜ起きたか」を並べた。出てきたのは、だいたいこの5つだった。
- いちばん多かったのは、現物を見ずに、前の記述を引き継いだこと
- 次が、片方だけ直したこと。スライドと台本、章と章、資料と資料
- 改修したときに、資料を直す運用が無かったこと
- 書いた瞬間から古くなること。6分後と、午前と午後。件数は少ないが、これがいちばん見つけにくい
- 「完了」の定義が揃っていなかったこと。改訂は終わったが配布が残っている、を「完了」と呼ぶかどうか
共通しているのは、1つだった。
書いた人は、書いた時点の実態を書いている。実態はそのあと動く。資料は動かない。
ずれるのは、資料が悪いからではない。時間が経ったからだ。
前の記事で「書いてあるものを疑え」と書いた。
疑う相手は、資料ではなかった。資料を書いたときの、自分だった。
何を変えたか
41件の「どう直したか」から、繰り返し出てきたものを5つ。
① 直す前に、通しで読んで数える改修リストの項目だけを見ない。語の出現件数を数えて、洗い出してから直す。リスト外の13件は、これで出た。
② 記録からは作らない。現物を出してもらうメールの文面、ボタンの名前、ライブラリの一覧。記録は現物の写しであって、現物ではない。
③ ファイルサイズと更新時刻を見るファイル名は嘘をつかないが、何も語らない。6分のずれは、時刻でしか見つからなかった。
④ 「対応済みかもしれない」は、その場で確かめる午前と午後で変わる。記憶は根拠にならない。
⑤ 直せないものは、「特定できない」と書いて残す加筆前のファイルが上書きされていて、何が消えたか分からなかったことがある。
確認できた8点を書き、削除箇所は特定できないと明記した。
分からないことを分からないと書くのも、記録のうちだ。
5つとも、資料を正しく書く方法ではない。
資料がずれていることを前提に、ずれを早く見つける方法だ。
前の記事で「エラーが出ない失敗」を書いたときと、同じ結論に、別の道から着いた。
おわりに
41件を並べて分かったのは、資料は完成しない、ということではなかった。
完成した瞬間から、古くなる。
だから資料を疑うのをやめて、「この資料は、いつの実態を写したものか」を先に見るようにした。
前の記事の締めは「会話を残すな。決定を残せ」だった。それは変わらない。
ただ、決定を残しても、決定はあとで変わる。
残した決定に、日付を付ける。それだけで、疑うべき順番が分かる。
資料は、書いた人の記憶より早く古くなる。6分で。
この記事は Zenn にも掲載しています。