規律を求める - ITエンジニアのひとりごと

実装を進めていると、チームメンバ間で細かな価値観の違いにとまどうことがある。どこまで規律で管理し、統一性を作りこむか、の価値観をあわせておくことができると、プロジェクトの成功に近づける。

最近、以下のような提案を受けた。

若手：「JSP化する元のHTMLファイルを見たら、HTMLのタグに大文字小文字が混在しています。どちらかに統一すべきです。」
私：「別に動作に支障は無いし、開発者への見栄えだけなので、こだわらなくても良いんじゃないかな。」
若手：「修正自体はたいした作業じゃないと思います。今はまだ開発初期段階なので、今から修正しておくほうが良いと思います。」
私：「スケジュール上ではもうまったく余裕が無く、厳しい状況だよ。、なるべく余計な作業は追加したくないんだ。後で余裕が出たら、対応することにたらいいんじゃないかな。」
若手：「開発の終了時期なら対応しなくても良いと思いますが、今は開発初期段階です。今のうちに対応すべきです。」
私：「一番大事なのは、顧客に高い品質のソフトウエアを期間内に納めることだと思うんだ。それにはHTMLタグが大文字小文字混在であっても何にも影響は無いと思うよ。」
若手：「顧客に納品するとき、これが私たちの品質です、とは言いたくないんです。顧客が見た時に、このチームはそんな品質も守れていないんだ、と思われてしまうのはイヤです。」
私：「私は、逆に、動作に支障がないものをわざわざきれいにして納品することには懐疑的だよ。たとえば、設計資料をきれいなバインダに閉じて表紙を書籍のように作ったり、納品用CDのラベルをきれいに印刷する、なんて行為は、品質に何の影響も無いので、わざと最低限、わかるようにしか納品しないことが私たちの品質重視の姿勢をアピールできるとも思うよ。」
若手：「でも、私はこの程度は最低限のことだと思うのです。」
私：「了解。他のみんなはどう思いますか？異論なければ、HTMLは大文字か小文字に統一したいと思います。」
一同：「小文字にしましょう。賛成です。」

実に興味深い。今までは規律を求めるのはウォーターフォールでの実績が長いベテランとそのベテランからの教育を受けた中堅以上と思っていた。この若手は3年目。スキルも高く、問題意識も強い。しかし、彼は、自ら規律を求めないと作業が進めない、といつも私に言っている。

若手：「XXXXについては決まっていますか？」
私：「決まっていないねぇ。というか、考えていなかったよ。今決める必要はあるかい？」
若手：「今決めないと、後々戻り作業が大きくなります。決めたほうが良いと思います。」
私：「了解。案を書いて、一応みなに相談し、決定したらWikiに書いておこう。」

こういうやりとりが多いのだ。こまかなステレオタイプごとのクラス名の命名規約、コード体系などなど。聞いていいると、「最初は理想系できちんと作業すれば、開発終盤でもブレは少なく、修正も楽です。」ということのようだ。確かに、最初から何も決められていないと、終盤でのブレは想像以上に大きなものになるだろう。

決めなければいけないことは確かにある。しかし、そのレベルが個人個人でまちまちなのだ。私は、クラス名の命名基準やパッケージ構成、DAOの基準などは決めておいたほうがよいと思う。他にもJavaScriptをどのレベルで作成するか、などは必要だろう。しかし、すべてを規律で縛り、違反を許さない文化はどうなのだろう。

動作や開発のスピード、品質に影響の無いような項目には規約を適用するのは、開発初期段階ではなく、開発終了時で十分では無いだろうか。開発終了時に余裕があれば、やる程度の価値だと思う。また、開発終了時点でその対応をすると、確実で、統一性もまし、将来のメンテナンス性もアップするだろう。

やはり、完璧を目指し、高い理想を持って作業をすることは悪いことではない。が、あえて理想を低くし、「絶対に守らなければいけないこと」だけを守る程度に理想を下げ、それが実現できたらスパイラルのように繰り返して品質アップを図るべきでは無いだろうか。

ただ、若手の高い理想をくじくことはあまりしたくない。高い理想を持っているからモチベーションを高く維持できているのかもしれない。このあたりがチームで作業をする、ということの難しさだ。