デスマーチからの脱却

コードをブラックボックスとしていないか？


予定していた動作通りに動けばOK。
それはそれで良いのだけど…

プロジェクトの開始からしばらくの間、
1日の中で30分程、他のメンバーのコードを読む時間を作るようにしている。

書き方の癖が違う場合は相談して合わせることができるし、
良くない書き方を最初に修正できる。
逆に、思ってたよりも良いロジックを発見できることもある。

プロジェクトの「モラル」を保つのに良い方法だ。

また、そのメンバーのモチベーションもコードから見えてくる。
チームのモチベーションが高い時には、
綺麗なコードや考えられたロジックや手法が多いが、
何らかの問題がある場合などには、
その場凌ぎのコードや手を抜いた手法が出てくる。

大切なのは早い段階で問題解決したり、軌道修正すること。

プロジェクトが大規模になった後問題に気付いた時、
その原因を作った担当者を責める前に、
それを防げなかったチームの問題だと考えた方が良いと思う。

個人の責任が重くなることは、
最初の内は仕事に充実感を持てるかもしれないが、
一つ間違うとデスマーチの入り口になることもある。

1日の中で30分も取れる時間が無い！という人もいるだろうが、
その30分が、将来の数時間の節約になると考えることをオススメする。

プロ野球のクライマックスシリーズも終わり、あとは日本シリーズを残すのみ。
両チームの戦力分析などが盛んに行われて始めている。

あなたのプロジェクトチームの戦力は？
監督になった気持ちで考えてみよう。


複数の選手（プログラマー）がいるプロジェクト。

最初に簡単な仕様書をあったとしても、
進むにつれ仕様変更や機能追加が多発し、
結局は開発した人間にしかわからないということになる。

自分の担当した箇所に何かがあると、
休暇中でも急いで対応しなければならない。


…デスマーチに陥る典型的なパターンだ。


解決するには逐一仕様書を修正するしかない！
と思うかも知れないが、予算やスケジュールがそれを許さないだろう。

そこでどうすれば良いか考えてみる。

理想的なプロジェクトチームは、
皆が誰かのバックアップをできるチームではないだろうか。

野球では、どのポジションでも守れる選手のことを
「ユーティリティープレイヤー」と言うことがある。
プロジェクトチームにもそういう選手（プログラマー）を増やせないだろうか？

一つオススメの方法がある。
それは、コードの癖（書き方）を似せることだ。

関数や変数の名前一つとっても、キャメルケースだったりアンダースコアだったり、
同じロジックを書くにも手法が違ったり、人によって書き方は色々だが、
チームのメンバーで、「こういう時にはこうする」といったことを常に相談して、
チームのやり方を揃えておくことに注力してみると良い。

そのうち少しずつ、誰が誰のコードを見てもある程度やっていることが分かるようになる。
休暇中には誰かが代わりに修正をしてくれるようになるだろう。


「自分には自分のやり方があるから、それで良いじゃないか！」
と思う人も居るかもしれない。

あなたに「職人」と呼ばれるような特殊技能があったり、
阪神タイガースの金本選手のように「鉄人」と呼ばれる程休まず働けるなら、
それで良いと思う。

そうでないなら、監督にとって使い易い選手になるよう、
「ユーティリティープレイヤー」を目指してみてはいかがだろう。

本当のプロフェッショナルは、どんなポジションでも役割をしっかりこなすのだから。

タイトなスケジュールで仕事をしている時。
納期直前の追い込みの時。

一番の目標は納期までに作り上げること。

時間を短縮するために、既存の処理や過去のコードを引っ張ってきて、
ちょっとした修正を加えながら組み込んでいくことが多いのではないか。

そこに「モラル」が崩れる瞬間があったりする。

過去のプロジェクトと、今のプロジェクトで扱っている商材が違う場合、
過去の変数名をそのまま使うと、変数名とその内容が違ってしまうことがある。
例えば旅行予約サイトで使っていたコードをECサイトに流用した場合、
「reserve」という変数に注文に関するデータが入ったりする。
後からコードを見た人は意味が分からないだろう。

0,1の二つのデータを扱っている「***_flag」という変数があり、
そこに条件を追加して、0,1,2のデータを扱うようにロジックを変更した場合、
後からコードを見た人は「flag」から二つのデータのみを扱っていると感じるだろう。

前者の場合は「order」、後者の場合は「***_code」に変数名を変えておくだけで、
後々コードのメンテナンスにかける時間を短縮することができる。

また、既存の関数を流用して処理を変更した場合には、
使わなくなった引数や処理を削除すべきである。
余計なものを残しておくと、将来その余計なコードの意味を必死に考えることになるだろう。


目先の納期に追われてスピードを最優先してしまった場合、
早い内に意味の分かるコードに直しておくことをオススメする。

その修正作業に少し時間を取られることになるだろうが、
将来のメンテナンスの時間を大きく削ることができるはずだ。

結局は、着実に歩みを進める者が勝つのだから。

コードの質はプロジェクトの「モラル」のようなものを表している。

度重なる仕様変更や、機能追加により何度も修正がされているコードは、
非常に読み辛かったり、「？」と思う箇所が多々あったり、
手を入れようと思っても、その変更による影響範囲が分かり辛かったり…
保守をするのが非常に困難なことが多い。

「モラル」が破綻しているのである。

では、その「モラル」を保つにはどうすれば良いだろうか？


割れ窓理論（Broken Windows Theory）というものがある。

建物の窓を割れたままで放置しておくと、
そこに気を払われていないというサインとなり、
軽犯罪の多発⇒モラルの低下⇒凶悪犯罪の発生
となっていく。

軽微なことをそのままにしておくのが原因との考え方から、
ニューヨーク市では過去に治安対策として、
地下鉄の落書きを消すことから始め、徹底的に軽犯罪を取り締まり、
凶悪犯罪の数を大幅に減少させることに成功したのだ。


プロジェクトの「モラル」でも割れ窓理論を適用できないだろうか？


コードの軽微な「モラル」違反を取り締まるために、
例えば次のようなことに気を配るべきである。

　　■コードのネストの位置を揃える
　　■命名規則を守る
　　■既存の処理をコピー＆ペーストした際には不要な箇所を消す
　　■使わなくなった処理、プログラムを削除する
　　■共通処理は一箇所にまとめる（二重化の防止）

あなたが既存のプロジェクトに途中から参加する時、
綺麗に整えられたコードであれば、その「モラル」を保持しようと思うだろうが、
汚いコードだと読む気すらなくなり、「モラル」を維持するより、
「その場凌ぎ」の対応を選んでしまうのではないか。


汚いコードに文句を言う前に、
まずはそのプロジェクトの「モラル」を回復することに注力してはいかがだろう？

思っていたよりシンプルなコードに収まったりするかもしれないし、
チームの士気も回復してくるのではないか。

週末の夜。幸せな気分で…

なんてとんでもない！

納期を間近に控えつつ、仕様変更の要求に耐えながら、
必死にコードを書いている人も多いのではないか。

「エンジニアとはそんな仕事」と諦める前に、
仕事の効率を上げる方法を考えてみてはいかがだろう？


プロジェクトが上手く行かない時、次のようなことが起きてはいないだろうか。


　■度重なる仕様変更、機能追加によるコードの複雑化

　■過密スケジュールによるバグの多発

　■前任者退職などによる詳細が不明な引継ぎ

　■非常に複雑な要件定義


詳細な仕様書を作れば問題は解決しそうだが、
その仕様書を作るのに膨大な時間がかかり、本末転倒になりかねない。

では、他にどのような方法があるだろうか？
その答えは、プロジェクトを極力単純なものに保つこと。
KISS （Keep It Simple, Stupid） の原則を守り、複雑化を未然に防ぐことだ。


次回以降、仕事の効率化のための手法を、具体例を挙げながら述べていこうと思う。
デスマーチに陥らないように、もっと楽しい仕事を！