Contents

よくある問題とその解決策──少しレベルの低い話

人間は「できる」と思うとできるようになる1。 オリンピックの新記録が立て続けに更新される現象も、これと関係しているんだ。 僕らノンプログラマも、「もっとよい働き方ができる」と思えば、それまでの限界を超えられるはずだ。

/images/slip.jpg

とはいっても、課題に対する解決策を自分ごととして具体的にイメージできないと効果はない。 「プログラミング」とか「AI」とか、大きい主語を使っているうちはだめだ。 まずはよくある問題を、具体的にどのような手法で対処すべきかを見ていこう。

「最終」は訪れない

「最終版その2.docx」

「最終版_改.xlsx」

見たことあるんじゃないかな。 みんな大好き「最終版」だ。 あとからプロジェクトに参加したメンバーは、困ってしまうよね。 恐らく作った本人さえ、後になって困るはずだ。

他にも、「ファイル_20210123.xlsx」というものも見たことがあるだろう。 この方式の問題点は、粒度が荒すぎることだ。 1日の作業が失われても大丈夫だろうか? じゃ、「ファイル_20210123_0845.xlsx」にしたらいいんだろうか? 今度は、フォルダの中がファイルだらけで大変なことなるだろう。 そもそもこういった方法は、一覧したときに、それぞれの版を作成した理由がわからない。 なるべく早く卒業しよう。

これを解決するのがバージョン管理だ。 開発者たちが日常的に使っている方法で、ノンプログラマの僕らも、知っておいても損はない。

開発者たちは、ファイル名を常に「[何をするファイルか].xlsx」に保つ2。 ファイルをバージョン管理システムに登録したら、作業結果をどんどん上書きしていく。 上書きは抵抗があるかもしれないけど、大丈夫。 作業がひと段落するごとに、作業内容をバージョン管理システムに登録するんだ。 この方式なら、何年経とうとファイルは一つ。 フォルダ内をきれいに保ちつつ、バージョン管理システムの力を借りて、詳細な作業履歴も確認することができる。

実例を見てもらおう。 東京都の新型コロナウイルス感染症対策サイトの、あるファイルの履歴だ。 こんなふうに見える。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
[2020-05-15 06:45:21 +0000]  : Add changes
[2020-05-15 15:36:42 +0900]  : widthを固定
[2020-05-15 06:34:47 +0000] 🔖 v1.5.222 : BOT; UPDATE DATA (#4182)
[2020-05-15 06:34:41 +0000]  : BOT; UPDATE DATA (#4181)
[2020-05-15 06:34:37 +0000]  : BOT; UPDATE DATA (#4180)
[2020-05-15 15:19:52 +0900]  : フォントサイズを明示
[2020-05-15 14:53:23 +0900]  : Merge branch 'development' of https://github.com/tokyo-metropolitan-gov/covid19 into add_paging
[2020-05-15 14:52:44 +0900]  : プルダウンメニューの横幅の最小値を変更
[2020-05-15 14:50:20 +0900]  : 無駄な空白の削除
[2020-05-15 12:32:37 +0900]  : 列見出しと注釈の修正
[2020-05-14 14:30:55 +0000]  : Translate /assets/locales/ja.json in zh_CN (#4174)
[2020-05-14 14:04:46 +0000]  : BOT; UPDATE DATA (#4173)
[2020-05-14 14:04:45 +0000] 🔖 v1.5.221 : BOT; UPDATE DATA (#4172)

このファイルに対してどのような作業がなされたのかを一覧することができる。 それぞれがどのような変更だったかを知りたければ、それぞれの作業の内容を深堀りしていけばいい。 また、いわゆる「バージョン番号3」はバージョン管理システムのタグという仕組みによって表現されており、上の例では 🔖 マークで示されている。 このタグは、必要ならば他の作業結果に付け替えることができるので、よくある「提出版」といった情報を扱うのに都合がいい。

ノンプログラマは、ここから何を学べるだろう?

何より、最終なんてものは訪れないということ。 これさえ理解していれば、変更履歴を管理する必要性は自ずとわかるだろう。

添付漏れ

「資料をお送りいたします(添付ファイルなし)」

これも見覚えがあるはずだ。というか、僕もやったことがある。 最近のメーラは本文に「添付」を含む場合に警告を出してくれるようになったが、 このような過保護なツールに囲まれていると、根本的な考え方の間違いに気づけないことがある: メッセージを主体とし、そこに資料を添付する、という考え方そのものがおかしいんだ。

資料を送るときに大切なのは、何よりも資料そのもののはずだ。 つまり、資料を主体とし、そこにメッセージをつければ、資料は忘れようがない。 どういうことかというと、そう、自動化を利用するんだ。 資料の更新が検知されたら、 ファイルにメッセージを添えて 送信すればいい。 確かに受け取り手から見ればメールに資料がついていることに変わりはないが、処理としては資料が主体となっている。

もちろん、更新内容の重要度はさまざまだろう。 例えば、誤字一字を直すたびに通知が来るようではたまらない。 複数の更新をひとまとめにして、一区切りの仕事としたいこともあるはずだ。 バージョン管理システムを利用していれば、重要な変更があったとき──例えば作業ブランチがマージされたときや「タグ」がついたとき──にチャットメッセージやメールを送ることができる。

「再発のないよう、ダブルチェックを徹底してまいります」

ミスが発覚した時、こんな無意味な精神論が聞こえたら、赤信号だ。 ダブルチェックだろうとトリプルチェックだろうと、人は見落とすときには見落とすもので、これは「忘れ物はありません」という宣言が馬鹿げているのと同じだ。 そもそもダブルチェックは所詮、「自称」に過ぎない。 チェック完了時に確認印を押すルールになっていようと、そんなものは目をつぶっていくらでも押せてしまう。

そもそも、顧客が欲しいのは有事の責任追求先ではなく、欠陥のない製品だ。 どうしたら、ミスの再発を防止できるだろうか?──テストを書こう。

テストとは、成果物に期待される状態を確認するプログラムのことで、一度書いておけば何度でも実行できる。 例えば、 xy の和を求める add(x, y) という関数を作ったとしよう。 add(1, 2) は 3 になるはずだし、 add(3, 4) ならもちろん 7 だ。 テストの書き方はプログラミング言語によっても異なるが、例えば assert add(1, 2) equals_to 3 などのように書ける。 「私の仕事は足し算のような単純な仕事ではない」と思うかもしれないが、世の中のソフトウェアは、結局こういった単純なプログラムの集まりでできている。 どんなテストが書けそうか思いつかないとしたら、恐らく仕事の仕方そのものを見直す必要がある。

──乱暴にいいすぎた。 確かに、テストを書けないような、高度で抽象的な仕事もある。 政治家や芸術家たちの仕事はまさにそうだし、一般のビジネスマンの仕事の中にも、企画や考察などの高度な仕事が含まれることはある。 テストによる補強は、人間がこういった創造的な仕事に集中するためにするものだ。

「ダブルチェック」という言葉を使っている組織は、当たり前品質を担保するために人的資源を使いすぎだ。 乱暴に言えば、こういった組織では、成果物にミスが無くても単純に喜ぶことはできない。 ミスの少なさは、潜在的損失──つまり、ダブルチェックという非生産的な仕事にと多くの時間を費やしたことを意味するかもしれないからだ。

「ダブルチェックを徹底」と言いたくなったら、テストを思い出そう。


  1. いや、ならないこともある。 ↩︎

  2. 開発者たちが Excel を使うかどうかは、この際おいておこう。 ↩︎

  3. セマンティックバージョニングという。 ↩︎