デスマーチからの脱却

ITエンジニアが「3K」と呼ばれるようになっている。

「きつい、厳しい、帰れない」職種であることは否定できないが、
新卒の学生がITエンジニアを選びたがらないことを寂しく感じる。

開発の仕事の際、人月工数で価格が決まることが多く、
どれだけ働いても儲からないという状態から脱するために、
マネージャーやコンサルタントへのキャリアアップが推奨されているが…


ITエンジニアってそんなに嫌な仕事なの？


自分の作ったサービスやシステムが多くの人に使われて、
それで喜んでくれる人がいたり、世の中に貢献できたりする。
そんな仕事ってなかなか無いと思う。

だからといって、人月工数の問題を叫んでも何も変わらない。
自分の仕事に価値をつけていくしかない。

効率の良い手法を日々探ることで、
早くてバグの少ない開発をしていくことはもちろん、
ただ言われたこと、決まったことをやるだけでなく、
良い方法があれば提案することもできるし、
行き届いていない所は言われなくても改善したりする。

「○○さんに頼むと違いますね！」

と言われるように、自分の仕事に価値をつけていき、
成果に対する報酬を貰えるようにしていけば、
人月の壁を超えることができる。

私の知っている優秀なエンジニアの人々の仕事には、
必ず「○○さんっぽいね」と言わせる何かがある。


顔の見える仕事には価値がある。
そんな仕事を目指して欲しいし、そんな評価を受けられる仕事というのは、
すごく素敵な仕事だと思う。

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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


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


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

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

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


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

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