Diary?

2008-06-14
Sat

(00:22)

NTTデータと真昼の対決」を読んで、どうにも疑問に思ったことが一つ。もしかしてみんな、スキルの低いプログラマもルールで縛ればマシなコードが書けると思ってる? 俺、これは確実に効果があるとは思えないんだけど。

これは俺の乏しい経験以外の根拠はないんだけど、出来ないプログラマってのは大抵の場合、何かしらルールが定められていてもその意味までは理解しない。「これはやっちゃダメ」と規約に書かれていたら、なぜやっちゃいけないのかを考えず、字面をそのまま覚えるだけなのだ。これの何がまずいかというと、あるルール A が定められていたら他のルール B が暗黙のうちに成立することもあるんだけど、ルールの意味がわかってないとルール A は守ってもルール B は無視とか、そういうことをやられてしまう。

そしてこれはまだ良い方で、ルールの意義がわかってないからルールその物を無視していても深刻にとらえてないとか、あるいは例外的な状況だから一次請けとかに交渉して特例を認めさせるべき所で、そのまま無理やりルールを適用するとか。そういう事態が結構起こっていたので、ルールで縛ってまともなコードを書かせるというのはあまり良い考えではないと思っている。

じゃあルールで縛ってもダメならどうするかっていうと、やっぱレビューしかない。前の現場ではやたらめったら細かくて厳しいルールの他に、クライアントの検証が入る前に各パートナー企業内でのレビュー、一次請けのレビューと二段階のレビューが設計書にもソースコードにもあって、それでもとんでもないコードが納品されていて基盤技術者の事実上のリーダーだった俺は頭を抱えてたわけだ。

無駄に厳しいルールがやたらと多いと何が困るかって、くだらないチェック項目の検証にも労力が割かれて、本当にヤバい部分を見落とすリスクが高まってしまう。何しろ Excel ファイルの罫線の太さが不統一とか、そんなのでも容赦なく突き返されて、そして組織が全体的に鈍重だから行って返ってに一日かかるわけだ。そしてどこのチームもリーダークラスの人はみんなオーバーワーク気味で、一次請けに至っては上から下までオーバーワークで、とてもじゃないけど万全なレビューなんてものからは程遠い。

そういう状況だとどうなるかっていうと、大体において二つに一つだ:

  • 末端の開発者レベルでもレビューを行って、消耗しつつも品質をあげようとする
  • ボロボロなものを納品して、後の工程で死ぬ

俺のチームは前者を採用して、それでまあ結果どうなったかは散々書いてきたので繰り返さない。でもおかげで俺が離任した後にバカでかい問題は起こっていなかったらしいから、それなりに効果はあったのかな。

というわけで俺のいた現場では、スキルの低いプログラマ向けにルールで縛ったところでそれほど大きな効果はあがっていなかった、という状況だった。もしかしたら効果をあげているところもあるのかもしれないけれど、細かいルールについて何故そのルールが定められているのか理解できているような開発者が集まってるんなら、そもそもルールなんて厳しく運用する必要ないよな。何ていうか、人海戦術だとしても開発者のスキルに最低限の閾値を求めないか。

(23:38)

GUI の OK ボタンは左右どちらに置くべきかってのはこれまた宗教戦争が始まるネタなんだが、これについては OK を右に置く以外に正解はないだろう。例えばファイルを編集した後に「ファイルの内容にに変更があります。保存して終了しますか?」というダイアログを出すとして、そこでは左から「キャンセル」「保存して終了」「保存せずに終了」と出す他ない。何故なら、誤操作の結果編集内容が失われるってのが最悪のパターンだからだ。

もう少しきちんとした言い回しにするなら、メニューの一番左にはユーザが選んで一番問題のないものを置いた方が良い。先の例でいうと、キャンセルボタンがもっとも問題の無いボタンとなる。他二つは、ユーザがダイアログの内容を確認せずについついボタンを押してしまった場合、一体何をやらかしたのかわからないままアプリケーションが終了してしまう。これは明らかにダメだ。もっともキャンセルにしたところでダイアログの内容をわからないまま押してしまったことの不安感はあるだろうから、ウィンドウの下部にステータスバーみたいなのをつけて、そこにメッセージを表示するのが良い (「アプリケーションの終了をキャンセルしました」とかね)。

残念ながら Windows は OK が左にあるのでこれを採用することは出来ないが、次善策としてデフォルトでフォーカスしているボタンを変える、というやり方がある。アプリケーションごとにフォーカスしているボタンの位置が異なるという問題が出てくるが、ボタンの並び方がバラバラよりは幾分マシだ。

もっともボタンの位置よりも問題なのは、最初に出した例に Yes/No で答えさせるアプリケーションなんだが。ボタンに書かれている内容は、ユーザの操作を反映するべきだっつーの。

Creative Commons
この怪文書はクリエイティブ・コモンズ・ライセンスの元でライセンスされています。引用した文章など Kuwata Chikara に著作権のないものについては、それらの著作権保持者に帰属します。