Contents

働き方を変えるには

ソフトウェア開発には、ビルドという概念がある。 この概念に出会ったノンプログラマは、仕事に対する考え方を根底から変えることになるだろう。

/images/build.jpg

ただの自動化では不十分

ノンプログラマが手作業の自動化に挑戦する場合、書籍にしろウェブサイトにしろ、初学者向けの情報を参照することになる。 まず四則演算を学び、変数への代入、そして関数の使い方へと進んでいく。 仕上げに for 文や if 文などの制御構文を学べば、たいていの業務はいちおう自動化できるだろう。 これは確かに大きな進歩だ。 仕事を再現できるようになったのだから。 しかし、手作業をプログラムに直訳しただけでは、働き方を根本から変えることはできない。 生産性はすぐに頭打ちになるだろう。

プログラマたちの働き方は、手作業を速くしただけの働き方とは根本的に違う──彼らは、情報を知識として使える状態に保ちながら働くのだ。

情報にはメンテナンスが必要

情報は、多いほどいいわけではない。 買い足した工具を乱雑に放り込むだけでは、道具箱はかえって使いにくくなっていく。 これと同じように、情報を知識として使える状態に保つには、日々のこまめな投資が必要なのだ。 情報の例としてわかりやすいのは、締め切りなどのスケジュール情報や顧客の連絡先などのリストだが、 そのほかにもファイル名やフォルダ構造など、あらゆるものを情報として認識しておく必要がある。 言うまでもなく、プログラムの各行一字一句も情報だ。

プログラムを書くとき、プログラマはメンテナンス性や再利用性、そしてコミュニケーション効果に注意を払う。 これらの概念を入門書から学ぶことはできないが、プログラミングを仕事で使うことを想定しているなら、早い段階から注意を払う必要がある; いま書いたプログラムは、同僚にも理解してもらえるだろうか。 あるいは自分で、数ヶ月あるいは1年後に読み返しても理解できるだろうか。 同じような処理をいろいろな場所で繰り返し書いていないだろうか。 正しく動いていることを保証できているだろうか。 そして、自分の「意図」までもが伝わるようになっているだろうか──。 プログラマはコードを追加するだけでなく、過去に書いたコードも改善しながら仕事をする。 彼らが通った後の道は、以前よりも少しきれいになっているのだ。

どうしてプログラマたちは、忙しい日々の中で、こまごましたことに注意を払えるのだろうか。 カギは、彼らが毎日繰り返し利用しているテクニック: ビルドだ。

ビルドとは

率直に言えば、ビルドとは動く手順書のようなものだ。 ビルドを実行すれば、ソフトウェアを組み立てるすべての作業──外部プログラムへの依存の確認、コンパイルと動作テスト、ドキュメントの生成──が完了する。 料理に例えるならば、これらはそれぞれ材料と手順の確認、調理と味見、盛り付けのようなもので、ビルドの成功は、プロジェクト全体がうまくいっていることを意味する。 報告書の執筆業務でいえば、データ集計と計算がうまくいっていて、報告書が読める状態に整ったことの証明だ。

「プロジェクト全体がうまくいっている」という表現は曖昧だが、とても重要だ。 とりあえずビルドしてみれば、まったくの新人でも、問題があるかどうかすぐに調べられる。 ビルドとは、プロジェクト固有の知識をプログラムとして形式知化しておき、その整合性を一気に確認することなのだ。 この利点を理解できるかどうかが、ノンプログラマにとって働き方を変える分かれ目となる。 以下で、報告書の執筆業務を例に、ビルドの概念をつかんでいこう。 ここではテストとドキュメント生成について解説する。

テスト

プログラムを書けば、何らかの方法で動作を確認したくなるだろう。 テストとは、プログラムが期待通りに動いているかを確認するプログラムのことだ。

ノンプログラマの報告書執筆プロジェクトには、品質検査を目視チェックだけで乗り切る文化がある──テスト文化がないというべきかもしれない。 目視チェックのみに頼った品質検査には再現性がない; 検査の精度は、担当者の性格や疲労度合い、またどれだけ時間的猶予があるかによっても左右されるだろう。 しかし一番の問題は、チェック中には、仕事がまったく進まないことだ。 ダブルチェック、トリプルチェックは、生産性を下げる最たるものだろう。 品質検査はもちろん不可欠ではあるが、できるだけ短時間で行う必要がある。

品質検査をテストとして表現しておけば、自動テストというしくみを使えるようになる。 それまでに書きためてきた数百、数千のテストを、コマンドひとつで一括実行できるのだ。 品質検査、つまり「このプログラムはこう動くはずだ」という期待は、広い意味では知識だ。 プロジェクトを長期的に維持管理していくためには、知識をテストいう「動く知識」として積み上げていく必要がある。

プログラムがすべてテストを通過したら、いよいよドキュメントを作ることができる。

ドキュメント生成

計算結果を含んだ報告書は自動生成すべきということを知らなかった頃、私は当然のように数値をベタ打ちしていた。 計算にプログラムを使っていても、結局は出力結果を手貼りしてしまっていた。 ベタ打ちや手貼りは、プロジェクトの生産性を下げる効果的な方法の一つだ: 計算結果が更新されるたび、報告書の数値も書き換えないといけない。 置換すればよいという考え方は大きな間違いだ。

ノンプログラマの報告書執筆において、もう一つ重大な問題がある──非効率な工程だ。 手作業で執筆していると、前の工程が完了しないと後の工程を始められない: 計算が終わるまでは図表を出力できないし、とうぜん、報告書に貼ることもできない。 図表を貼れなければ、説明も書けないのだ。 報告書が完成するのは、たいていプロジェクトの後半になる。 それから目視チェックをするわけだが、計算の誤りが発覚したり、方針が変更になったらやり直しだ。

報告書を自動生成できれば、プロジェクトの生産性は大きく向上する。 プロジェクトを健全に保つためには、報告書の生成は計算や自動テストと分けずに、一括実行するのが望ましい──報告書のビルドだ。 プログラマが報告書を書くならば、プロジェクト初日から、一日に何度も報告書をビルドしながら作業を進めるだろう。 もちろん、はじめのうちは報告書はほぼ白紙だが、完成度は日を追うごとに高まっていく。 数値や図表は自動で埋め込んでいるので、更新漏れは起こりようがない。

報告書執筆プロジェクトにとって、ドキュメント生成は「便利なもの」ではない。不可欠なものだ。

確実な仕事のために

報告書をビルドしていても、目視チェックはもちろん行うし、実装ミスに由来する誤りが見つかることもある。 しかし報告書を読めたということは、プログラムがすべてのテストを通過し、ビルドが成功してしまっていたということだ。 こんなときプログラマは、望ましくない結果についてのチェック担当者の知識が、テストとして表現されていなかったと解釈する; プログラムに実装ミスがあるのだから、このビルドは、本来は失敗しなければならなかったのだ。 プログラマがとりかかる最初の仕事は、望ましくない結果を検出するテストを追加し、ビルドを失敗させることだ。 こうすることで、テストがチェック担当者の知識に近づくわけだ。 確かにミスをすぐに修正することもできるが、そうするとテストに穴が残ったままになるため、将来的プログラムを書き換えた際に、同じ原因による誤りが再発する可能性がある。 プログラマは、まず知識を積み上げてからプログラムを修正し、ビルドを成功させる。 数値が修正された報告書を読めるようになるとともに、プロジェクトは一つ強くなったのだ。

ビルドには大きなメリットがある。 計算やテスト、ドキュメント生成を一括して行えるということは、「動く知識」を積み上げながら働けるということだ。 どんなに疲れていても、どんなに忙しくとも、ビルドを実行しさえすれば、全工程がもれなく完了する。 当たり前品質の再現をビルドに任せられるおかげで、プログラマは、リソースを魅力品質の向上やこまごました改善に割くことができるのだ。

ビルドを理解すれば、効果的な働き方に対するノンプログラマの認識は数段高いレベルへと押し上げられるだろう。