■

先日、健康診断がありました。去年は採血担当の看護士さんが下手で青くなったのですが、今年はそもそも採血がなかったので何事もなく終了しました。何事も無く終了しましたが、身体測定で出た体重に異議あり。僕の身長の伸びは中三で止まりました。あと5cm欲しい165cm。同時に体重もほぼ固定化されました。52kg近辺。冬場は54kgくらいで、夏場は51kgくらいというのがここ10年間続いてます。ところが、今日の測定では49kgでした。おかしい。絶対おかしい。最後に計ったとき、たぶんここ半年以内、の時は53kgはありました。それが急に-4kgって…。結果を見てからすぐに計りなおそうと思ったのですが、あいにく近くに体重計がありません。う〜ん、久しぶりに銭湯に行こうかな。もし計り間違いでいのであれば結構やばいです。デジタル土方をやってるので、少なくともあと5年くらいは体力勝負の仕事が続きます。マスターアップ前の忙しい時期に倒れたりしたくない。仕事で体壊したくない。体力づくりしなくちゃ。

健康診断の待ち時間の間、新聞を読みました。「ネットニュースよりも新聞の方が読みやすい」と思っていたのですが、久しぶりに読んでみると、大きすぎるので広げにくいし、タイトルがサイズもレイアウトもばらばらで見つけにくいし、読みたい記事に限ってすごい隅のほうで文字が小さくて読みにくいし…なんとも読みにくいメディアです。　しかし、記事のごちゃ混ぜ感、というと少し語弊がありますが、一つのジャンルに特化せず、様々なものを適度な深さで伝えるメディアとしては素晴らしいと感じました。ネットニュースだと、タイトルに目を通して興味があるもののみ詳細を読みます。読んでいる途中で気になる情報があったらそれをググって、さらにそこから張られているリンクを飛んで…なんてことがよくあります。その結果、知りたかったことに関する詳細な情報は手に入るのですが、それ以外のものはからきしです。深く知ることができるけど浅く知るには向かないといった感じ。もちろん浅く広く情報を集めることもできるのですが、それを意識しないと狭く深くなりがちな気がする。そして大体の場合、深く知ってもしょうもないことばかり深く追ってしまうので、「手に入る情報の価値」としては新聞の方が高いのではないかなと。…とは言え、新聞をとる気にはなれません。社会人になって1年半ほどはとっていたのですが、結局読まずに積んでいくことが多く、しかも会社泊りが続いて久しぶりに疲れ果てて帰ったときに溢れている新聞を見たときの悲しさが辛く、もう二度と新聞をとるものかと誓ったので。新聞のように広く浅く情報を集めやすく、それでいて新聞のようなわずらわしさのないメディア、そんなのが出てくれないものでしょうか。今のところ僕の中では電子BOOKが有力。電子BOOKが普及して、それで新聞が読めれば万事解決！

洋書を買いました。英語の勉強が全く進まないので。単語本なんで読んでてもちっともおもしろくありません。おもしろくなければ続きません。先週の日曜に買った単語本、まだ3ページしか進んでません。これはいけない。この調子じゃ結局何もしないまま終わってしまいそうだ。そんなわけで技術系の洋書を買いました。本当ならば小説などの方が良いのでしょうが、アリスレベルでも僕には厳しくて…。技術系の場合、難しい文法を(おそらく)使っておらず、そのうえ知らない単語や文法が出てきても、その前後の用語や見知ったアルファベットの並びから文章が頭の中で補間されます。何度も同じ知らない単語が出てきた場合のみ、「これは重要な言葉っぽい」ということで辞書を引けばよいのです。小学生の頃、小説を読むときもこんな感じだった気がします。読めない漢字や言葉は字面だけ覚えて、文脈から意味を推測して、言葉を覚えていた気がします。だからこれできっと大丈夫。それにこれなら、英語の勉強だけでなく技術の勉強もできて一石二鳥！ …そう信じてがんばろうと思います。

その洋書を読んでいる時に、うんうんと大きく頷いてしまうものがありました。スクリプトをプログラマー以外の人に書いてもらう場合の方針だとか注意点だとかに関するもので、「低レベルなコマンドは経験豊富(技術力のある)なデザイナーにのみ提供し、そうでないデザイナーがいる場合は高レベルなコマンドで提供しよう」とかそういったもの。スクリプトの保守担当のプログラマとしては、低レベルな命令を数多く提供して「あとは勝手にやってね」というのが楽だけど、それをうまく使いこなしてもらえないんじゃ意味が無い。先日、そういったことで同僚の先輩と口論になった。先輩としては、「仕様の追加が多すぎて自分の作業が遅れているから、低レベルなコマンドを実行できるようにしてデザイナに対応してもらう」で、僕としては、「それは後から大きな問題が起きる可能性があるから怖い。プログラマが責任を持てる形にすべきだ」という意見。僕にとっては当然過ぎる「自由度が高いと想定外の使い方をする可能性があるから怖い」という考えが、先輩には全く通じなかったのがショックでした。「注意して作れば問題は起きないのだから大丈夫なはずだ。問題が起きたらその時に対処すればいいのだから、その前に可能性を考慮しすぎてプログラマが苦労するのはおかしい」というのが先輩の弁。デザイナが調整をするのはプロジェクトの末期も末期。その時に問題が起きても対処が難しいんですが…。
結局、僕が折れました。なんというか、これが「経験の差」なのかなと思って。僕はこれまでのプロジェクトでそういった場面に遭遇してきました。遭遇というか、僕自身がその問題を起こす側でした。とある特殊なデータが必要になって、それ用のコマンドの追加を担当プログラマにお願いしたものの中々作ってくれず、しかし上司からは早く作るよう指示が来るので、試行錯誤してコマンドを組み合わせして作りました。なんとなく危ないなとは思いましたが、提供されている機能なのだから想定ないだろうと思い、それで動いたので良し、と。ところがプロジェクト末期になってバグが発覚。上司からは何故こんなバグをと言われ、プログラマはこんな使い方は想定外だから責任はデータを作った側にあると責められ…そんなのどこにも書いて無いじゃん！ってか、ドキュメントすら作ってくれないから僕らがプログラム解析してドキュメント書いてデータ打ってるんだけど！？ それ以来、「自分がプログラマになったら、そんな理不尽なことはしたくない」と強く思い、「サポートできないものは機能として提供してはいけない。どうしても必要な場合は、ドキュメントにその危険性を記述する」というのがプログラマの僕としての不文律となったのでした。
僕の経験は、もしかすると極端なものだったのかもしれません。一般的にはそういった問題が起きない、または、問題が起きたとしても適切な対処がされているのかもしれません。だとすれば僕の不文律は見直す必要があります。しかし、そうでなければ、先輩にも同じような経験をしてもらい、同じ意識を持ってもらいたい。そのための試金石にしたいと思って、折れました。とは言え、心の中では後者になることを望んでいます。うちのチームはあまりにもデータ側の負担が大きい。プログラムを適切にすれば直るものを、バグが出た場合はデータ側の原因としてデータを無理やり修正する場合がある。または、適切なツールを作ればデータ修正が容易になったものも、データ側の体力任せで修正していた。今までは新人がデータ打ちをやっていたからそれでもなんとかなったけど、今後はそうも行かない。できるデザイナというのは普通のプログラマなんかよりもずっとずっと貴重で、しょうもないデータの修正になんかに無駄な時間を使わせてはいけないのだということをわかってもらいたい。そのためにもそう思う仲間を増やしたい。そんな魂胆があります。もちろん、末期になってそれが原因のクリティカルなバグが出た場合は先輩だけでなく皆困るので、最低限のテストをしてもらうようお願いはしてあります。あとは、なるようになるさ。

そんな、僕にとっては4年かけて得た貴重な経験を、この本ではさらっと数ページでまとめているのですから恐ろしいものです。先達が作った車輪があるのであれば、それを利用して車を作り、さらなる高みを目指すのが僕らの役目。その役目を果たすためにも、こういった既知の知識は貪欲に吸収していかなくては。…でもゴール思考と有限状態の違いからして既にさっぱりです。あー、1を聞いて10を知るような頭脳が欲しい今日この頃。