高慢と偏見（6） いつかの誰かのためのドキュメント

スキル | ワークスタイル | 人間関係

» 2010/12/20

　三浦マネージャがプロマネになって2週間が過ぎた。表面上は、それまでと変わらない開発風景だったが、水面下では激しいゲリラ戦が繰り広げられていた。とはいっても、敵、つまり三浦マネージャだけが、それに気付いていなかった。

　三浦マネージャが不在だった月曜日、私たちは「すでにできているクラス」を作るのに全力を注いだ。たぶんムダなメソッドもたくさん作られたのだと思う。普通なら必要になった時点で作成すればいいものを、各メンバーの予測で作ったのだから。私も3つぐらいコミットした。

　火曜日に戻ってきた三浦マネージャは早速、開発のあらゆる局面に口を挟み始めた。メンバーの誰かが平良さんに相談にいくと、横からじっと見ていて、おもむろに、

　「そこは、○○と書いた方がいいね」

とか、

　「それは分かりにくいだろう。後から読む人のことも考えてコーディングしてね」

とか言い出すのだった。

　平良さんは、その場は「そうですね」とか何とかごまかしておいて、あとからこっそりメールで答えを返していた。三浦マネージャの席は平良さんの隣なので、コーディングしているふりをして、素早くメールを書いて送信していたようだ。そうしたメールには平良さんらしくもなく誤字脱字が多かった。

　時々、三浦マネージャが「サンプル」と称してホワイトボードにコードを書くことがあった。そこで特徴的だったのは、変数の宣言を、

String strOrderNo = "";
int iOrderCount = 0;
Date dateUpdateDate = null;

のように、いわゆるハンガリアン記法で書いていることだった。VB6ぐらいまではよく見かけたけど、Javaで書いている人はほとんど見たことがない。三浦マネージャが「クラス」が増えるのを嫌うのは、クラスだとプレフィックスが長くなってしまうからなのかもしれない。

◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

　コードレビューはきっちりと金曜日の午後に実施された。3回目のコードレビューのとき、三浦マネージャはあるコードに注目して襲いかかった。

　「おいおい、これは前回修正中だったロジックだね？」

　そのロジックは2回目でレビュー対象になったが、作成途中ということで今回に持ち越されたものだった。レビュアーになったメンバーは、不安そうな顔で答えた。

　「はい……それが何か？」

　「何かじゃないよ。どこを変更したのか分からないじゃないかね？」

　――は？

　意味が分からないまま、私はロジックのプリントアウトに目を通した。おかしな部分は特に見当たらない。

　――もしかして、変更個所をコメントアウトしとけとか言い出すんじゃないよね？

　「変更した部分は、きちんとコメントにして修正日付と修正者の名前を入れる」三浦マネージャはあきれたように首を振った。「常識じゃないかね？」

　珍しく私の想像が当たったが、少しもうれしくない。

　平良さんが手を挙げて発言した。

　「すみません。ソースの管理には、バージョン管理システムを使うことになっていますが」

　これはこのプロジェクトだけではなく、K自動車内のシステム開発すべてに適用されるルールのはずだ。もっとも、プロジェクトによって、Subversionが動いていたり、Visual SourceSafeだったりとバラバラだったが。新部品調達システム開発プロジェクトでは、理由は分からないがCVSが使われていた。

　「そんなことは分かっているよ。コメントにしてあった方が一目瞭然だということぐらい分からないかね？」

　「Eclipseを使えば簡単に過去の変更履歴が参照できますが」おそらくムダと知っていたに違いないが、それでも平良さんは食い下がった。

　「こうしてプリントアウトして見るときには、履歴が見えないじゃないかね」

　こんな時間のムダでしかないコードレビューなんかやめれば、コードをプリントアウトすることもなく地球にも優しい……という発想は、この人にはないらしい。

　「過去の変更履歴が全部残っていたら、メンテナンスするときに邪魔になるのではないでしょうか」

　「逆だよ。私の長い経験から言うとだね、それまでの変更履歴をたどることで不具合の原因がつかめたりするんだよ」

　――出たよ、長い経験。

　この人が「長い経験」という言葉を発したら、もう誰が何を言ってもムダだということは、メンバー全員が知っていた。

　「これから変更個所はコメントにしておき、変更日時、理由、変更者をきちんと記述しておくこと」三浦マネージャは宣言した。「いいね」

　全員が声にならないため息をついた。こうして余分な作業が増え、コードが汚されていくことになった。

◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

　また、新しく作成する機能の詳細仕様書が強制された。最初、その通達があったとき、

　――クラス図とか書けってことかな。ツールは何を使うんだろ。

とか気軽に考えていたのだが、ほどなくしてメーリングリストで送付されたサンプル仕様書を見て脱力した。

• 第1ページ……テーブルのI/O図が上半分にあり、下半分はモジュール一覧
• 第2ページ……関数一覧
• 第3ページ以降……フリーフォーマット

　最近ではちょっとお目にかかったことがないような仕様書だ。

　「これって共通ロジック経由で使ってるテーブルとか、読み込んでるXMLとか全部書くのかしらねえ」

　アツコさんはうんざりしたようにつぶやいていた。

　私も、これを作ると、どんないいことがあるのかさっぱり分からなかった。

　この通達があったとき、平良さんは早速、三浦マネージャに直訴した。

　「この仕様書は何の役に立つのでしょう？」

　「そんなことも分からないかな」三浦マネージャはバカにしたように答えた。「後からメンテナンスするために決まっているじゃないか」

　「I/O図とモジュール一覧がですか？」

　「どんなテーブル使ってるか分からないと困るだろう。それにその画面がどんなモジュールで構成されているかもね」

　「そうでしょうか？」平良さんは指摘した。「インプットがテーブルなのか、XMLなのか、それともロジックで生成されたデータなのか、可能な限り意識する必要はないと思いますが」

　「意識しないと、いいコーディングなんか作れないよ。そこんとこはみんなまだ経験が足りないようだね」

　平良さんは口を開いたが、すぐに閉じた。

　何を言いかけたか、想像はつく。適切に命名され、正確なJavaDocが記述されているインターフェイスを使えば、その実装の中で何をやっているのかは一切気にする必要がなくなる、と言いたかったのだろう。

　例えば、PartsInfoGetterというインターフェイスに、List<MakerInfoDto> getMakerNameList(String partsCode) というメソッドが定義されていたとして、JavaDocに「部品のメーカー情報一覧を取得する」と記述されていれば、使う側はメーカー情報一覧が、データベースから取得されているのか、XMLを読んでいるのか、妖精さんがアミダで選んでいるのかを意識する必要はない。

　だが、三浦マネージャには、それが理解できていない。というより理解することを拒否しているのだからどうしようもない。ここで、平良さんが改めてインターフェイスの利点を説明したところで「そういう細かいことはいいからいいから」と、はねのけるだけだろう。

　モジュール一覧については言うまでもない。フレームワークで規約が決まっている以上、何を使っているかなんて、わざわざドキュメントに残す必要などまったくないのだから。

　「そうですか」平良さんは、なぜかおとなしく引き下がった。「ところで、作成した仕様書はチェックされますか？」

　「私が？ いや、そんなことはしないよ。さっき言ったように後々のメンテナンスのために必要なドキュメントなんだから。平良さんが簡単にチェックしといてよ」

　「分かりました」

　平良さんらしくない。I/O図やモジュール一覧にどの程度細かく記述するのか、フリーフォーマットの部分をどこまで書くのかを確認するのかと思ったのに。

　ランチタイムのとき、アツコさんにその疑問をぶつけてみると笑われた。

　「だって、突っ込んで聞いたら、そのとおりに書かなきゃいけなくなるでしょうが。曖昧にしとけば、どこまで書くかは、あたしたちの裁量ってことになるでしょ」

　なるほど、平良さんも穏やかな顔をして、なかなかしたたかだ。

　「でも、チェックするのが平良さんなら、後で責められるのは平良さんなんじゃ……」

　「平良さんはそんなこと気にしてないよ、きっと」アツコさんの口調には尊敬の念がにじんでいた。「とにかくプロジェクトをちゃんとソフトランディングさせることしか考えてないんだよ」

　その日の午後、平良さんから「書いた仕様書は私に送ってください」というメールが届いた。仕様書のサンプルが添付されている。ぱっと見には複雑そうに書いてあるが、実際にコーディングしているメンバーから見れば、きわめて曖昧な内容になっていた。これなら作成するのに、30分もあれば十分だろう。もちろん「後からメンテナンスのために見る」という用途にはまったく使えないが、そんなことは誰も気にしないだろう。三浦マネージャが、何かの気まぐれでチェックしようなどという気を起こさない限りは。

　私たちがバカ正直に詳細仕様書を書いていれば、その分実装できる機能の数は減るのは目に見えている。つまり、私個人の実績が上がらないということになる。かといって、詳細仕様を書かない、でたらめに書く、というように公然と反抗すれば、評価は間違いなく下がり、今後の仕事に影響するのは確実だ。エンジニア常駐の単価がどこも軒並み下がっている中で、K自動車だけは比較的高い水準を保っている。ここの仕事はおいしいのだ。うちの会社だって、今回は私1人だけだが、今後の同様な開発プロジェクトには人数を増やして送り込みたいと必死で営業攻勢をかけている。その努力を無にするようなことをしたら、白い目で見られるぐらいではすまないだろう。

　平良さんはそのジレンマから救ってくれたわけだ。平良さんの方に足を向けて眠れない。

　並行して作成を指示されたバグ出現率表にも、全メンバーが心底うんざりした。その基準が提示されたとき、私は思わず笑ってしまった。

• 深刻度「重」のバグ出現率……ステップ数の0.5％以上
• 深刻度「中」のバグ出現率……ステップ数の1％以上
• 深刻度「軽」のバグ出現率……ステップ数の10％以上

　つまり、1000ステップのロジックの場合、重大なバグを5個以上、中程度のバグを10個以上、軽微なバグを100個以上、必ず「発見」しろ、ということだ。

　言うまでもなく、これは21世紀のプログラミングスタイルから完全に逸脱している。今どき、最初から最後まで一気にコーディングしてから、「さあテストするぞ！」なんてやってるプログラマはいないだろう。一部をコーディングしてユニットテスト、バグがあったら修正してユニットテスト、テストが通ったら少しコーディングしてユニットテスト、を繰り返すのが普通だ。そのために、JUnitという便利なツールがあるのだから。

　「大体、ステップ数って何なのよ」アツコさんはランチのときに、ぶつぶつ言った。「ステップ数が多ければ難易度が高いとか思ってるのかしらね」

　最近はランチのときに三浦マネージャ絡みの話ばかりしている気がする。ランチのときぐらい、あのモンスタープロマネから逃れたかったが、1人でランチを食べるのはもっとイヤなので、仕方なしに付き合った。

　「まあ、“クラス”を作るなってぐらいですから」

　「ふん。ステップ数に応じて単価上げてくれるならともかくさ」

　アツコさんの今日のお弁当はドライカレーだ。スプーンごと噛み砕きそうな勢いで、ガツガツと口に運んでいる。消化に悪そうだが、コメントは差し控えた。

　「私のプログラムは非の打ちどころなく完ぺきで、1回のコーディングでコンパイルエラーなし、あらゆるケースを想定してあるので、バグは出現しませんでした、とか書いたらどうなるのかね」

　「それはとても面白いけど、やっちゃダメですよ」私は釘を刺した。もっとも、口調は過激でも芯はクールなアツコさんが、本気で実行するわけはないと分かってはいたけど。

　「当たり前でしょう。やるなら、ここを離れる最後の日よ」

　やりかねないなあ。私は話題を微妙に変えた。

　「ところで、平良さんはバグ表については何にも言いませんでしたね」

　てっきり、三浦マネージャに意見してくれるのかと思っていたのだけど。他力本願なのはわれながら情けないが、多少なりとも対抗力を持っているのは平良さんしかいないのだから仕方がない。

　「そうねえ。でもまともに書く気がないのだけは確かだと思うけどね。っていうか、まともなエンジニアなら、あんなのまともに書くわけないんだけどさ」

　「でもどうしようかな」私は憂うつになった。「今やってる画面が終わったら、バグ表提出しなくちゃいけないわけですよね。もうすぐ終わっちゃう」

　「あたしもだよ」アツコさんは空になったタッパーにふたをすると、別のタッパーを取り出した。保冷剤と一緒に、手のひらいっぱいのブルーベリーの実が入っている。「はい、半分あげる」

　「ありがとうございます。最近、目の疲れがひどくて」

　私はありがたく、いただいたブルーベリーを口に入れた。いかにも眼精疲労に効きそうな酸味が身体に染みていく。

　「まああたしなら、取りあえずでっちあげるかな」アツコさんは何気ない口調で、ぎょっとすることを言った。

　「でっちあげるって、バグ出現率を？」

　「そうよ」

　「でも、それはさすがに露骨な気が……」

　「でも、その数字が正しいかどうかなんて、他人が検証しようがないのよ？ だったら、それらしい数値にしておけばバレないと思わない？ どうせあの人が欲しいのは、グラフの元データだけなんだから」

　確かに三浦マネージャは、すでに何人かが提出したバグ出現率表を何やら加工して、機能ごとにグラフを作って喜んでいた。

　「絶対、他の人もでっちあげてるに決まってるわよ」アツコさんは断言した。

　アツコさんが正しいことは、すぐに分かった。何人かにそれとなく聞いてみると、やはり適当に数値を作り出して提出していたようだ。中には「人間がやるとどうしても同じ数値ばかりのパターン化しちゃうから」とか言って、わざわざ乱数で数値のゆらぎを生み出すプログラムを組んだ人までいた。仕事してるのか？

（続く）

　この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。