なんだって？！という場面に遭遇
プログラマーをやっていると、そんなことは無いだろうと思っていても、経験することが度々あります。側から見れば微笑ましくも見える光景も、当事者であるプログラマーにとっては笑い事では済まないことも数多くあります。この記事では、思わず笑って許せることから、シャレにならない致命的なものまで、プログラマーならでは、という「あるある」を紹介したいと思います。
ちなみに、これらについては統計をとったわけではありませんので、私個人の主観で過去に経験した、他でもありそうなことを紹介していきます。
参照：プログラマが抱える業務過多を脱するための方法を解説した記事はこちら
第10位 関数名がローマ字
エンジニア理解度：★★☆☆☆
悲しくなる度：★☆☆☆☆
草不可避度：★★☆☆☆
引き継いだプログラムの関数名が何故かローマ字で書かれているということがあります。もちろん、すべて英語にする必要はありませんし、英語だと逆にわかりにくいものであれば良いのですが、「コピー」とか「シェア」とかのスペルが分からない人が書いたのか、「kopii」や「syear」といった関数名で書かれていることが稀にあります。
キッチリとローマ字になっていればマシで、何語だか分からないものや、微妙なスペルミスの場合は、関数を使おうとしたら「そんな名前の関数はありません」というエラーが出て何日も悩んでいたら、原因が呼び出し先の関数名がスペルミスをしていたということもごく稀にあります。
第9位 コメントがポエム
エンジニア理解度：★★★☆☆
悲しくなる度：★★☆☆☆
草不可避度：★★☆☆☆
デスマーチプロジェクトのソースを引き継いだものにありがちなことではありますが、コメントが謎のストーリーになっていることがあります。
例えば、「もう何が原因かわからなくて疲れたので、とりあえずこれで対応した。」とか、「これで正しく動くみたいなので、この変数に○を設定しておく。」といったような何の役にも立たない情報がコメントに書かれていることがあります。
第8位 1ファイルが数万行
エンジニア理解度：★★★☆☆
悲しくなる度：★★☆☆☆
草不可避度：★★★☆☆
ツギハギでプログラムを書いていった時に少しずつ処理を追加していった結果、
メイン処理とか共通処理といったもののプログラムが数万行に達することがあります。
あらゆる場所から呼ばれることに対応するため分岐が多く、大半の処理において分岐の対象外となっていることが多くあります。
例えば、ある処理においては、15891行目から16221行目までしか使っていないという感じとなります。
第7位 暗号にしか見えない
エンジニア理解度：★★★☆☆
悲しくなる度：★★☆☆☆
草不可避度：★★★★★
プログラムがわからない人にとってプログラムは暗号みたいなものですが、言語によっては記号を組み合わせて省略して記述することが可能になっていて、プログラマーにとっても暗号にしか見えない記号の羅列で書かれていることがあります。良くあるのが複数の三項演算子を組み合わせたもの、文字列定数がStringクラスであることを前提としてメソッドを書く、ポインタとキャストを組み合わせて文字列処理をする、といった事例があります。
第６位 概算の見積もり
エンジニア理解度：★★★☆☆
悲しくなる度：★★★★☆
草不可避度：★★★☆☆
プログラマーにとって、仕事の依頼を受ける時に遭遇する話として良く聞くのが、とてもアバウトな内容に対して、どのくらいかかるか聞かれることです。
酷いものになると、「（Amazonのような）ECサイト作るとしたら、どの位かかるか概算の見積もりが欲しいのですが。」というような形の裏の意図が読めないと見積もり金額だけで2桁変わる程度のような形になる可能性もあります。
多少でも経験を積んでいれば、こう言ったことは回避しやすいのですが、その意図を汲み取れなかった場合、概算とも呼べない見積もりを出してしまう可能性もあります。
例えば、「（簡単な）ECサイトなら数十万もあれば作れます。」といった感じです。
そして詳細を詰めていって正式な見積もりが一千万超になっていまい、依頼した人に「概算とは何だったのか。」と言われることになります。
もっとも、この例は極端ですが、これに近いことは経験した方も多いハズです。
第5位 とてつもなく深いインデント
エンジニア理解度：★★★★☆
悲しくなる度：★★★★☆
草不可避度：★★★☆☆
複雑な処理を書いている時に起きやすいことですが、ループや分岐を大量に重ねた結果、インデントの深さが画面の1行の半分以上になっているプログラムを目にすることがあります。
最初から、この形になるのであれば、いろいろ考えることもできるのですが、追加や修正を繰り返した結果として、この形になってしまいますと、綺麗な形に書き直した時に発生するバグが怖くて誰も手を出せなくなってしまいます。
ラスボスと化したプログラムに果敢に挑戦した人が、問題なく解決できればヒーローになるのですが、失敗して問題が発生したりすると、かませ犬のような扱いをされてしまうという悲しい事態になります。
第4位 遅れる前行程と変わらない納期
エンジニア理解度：★★★★☆
悲しくなる度：★★★☆☆
草不可避度：★★★★☆
プログラマーの中には、設計を別の方がやる、というプロジェクトに関わったことがあると思います。仕様を詰める時にありがちなのですが、うまく纏めることができず、どんどん完成が遅れることもあります。
それでも、最終的な納期を変えることができない場合もあるため、酷い時にはプログラマーである自分のところに来る頃には、計画していた実装期間の半分以上が経過していることもあります。
この時に、機能の優先順位をつけて取捨選択することができればマシな方で、酷い場合は「プログラマーの人数を倍にすれば期間半分でもOK。」ということで大量人員を投入して、さらに酷いことになるという場合もあります。
第3位 絶対ではない絶対
エンジニア理解度：★★★★☆
悲しくなる度：★★★☆☆
草不可避度：★★★★★
第4位のものと多少被りますが、デスマーチになったプロジェクトにありがちな話で、この「納期は絶対だ」とか「納期は死守する」とか言われていて、頑張って終わらせようとしたものの、絶対的なボリュームに勝てずに終わらなかった時に、依頼主に納期の交渉に行ったら、「一週間延期できた」ということがあります。
一週間であればマシな方で、酷い場合は1日ずつ延期されていくといったこともあります。
いずれもかかる期間としては、大きな差はない場合が多いのですが、絶対と言われていた納期が数回にわたって変わってしまうと、デスマーチによる疲労感も手伝って「絶対とは何だろうか？」という哲学的思想に逃避してしまうこともあります。
第2位 要らないと思ったけど
エンジニア理解度：★★★★☆
悲しくなる度：★★★★★
草不可避度：★★★★★
巨大なシステムになるほど、どこでどの処理が使われているか見えにくくなるものではありますが、使われていないと思っていたプログラムを整理するために消してしまったら、滅多に使わない処理で使われていて数ヶ月後に致命的なエラーとして報告されることもあります。
もちろん、最近はソースのバージョン管理ツールなども充実してきていて、バックアップからの復旧もできるようになっていることが多いですが、そういったことをしていない場合、泣く泣く消してしまったプログラムを作り直す羽目になります。
第1位 仕様確定、それは罠
エンジニア理解度：★★★★★
悲しくなる度：★★★★★
草不可避度：★★★★★
仕様が確定して、ある程度作ったところで、イメージと違うとか、こういう感じではないとか、確定した仕様が前提から覆される事態がプログラマーをやっていると、時々目にすることがあります。プログラマーとしては、せっかく作ったプログラムが廃棄になることもあるわけで、行き場のない怒りと悲しみがプロジェクトを駆け巡ります。その先にあるのは責任のなすりつけ合いと、下がったモチベーションで生み出される低品質なプログラム、そして呪いの込められたコメントという悲惨な状況が生まれます。
まさに、大魔王の復活と闇の世界の誕生を目にすることになるでしょう。そうなると、もはや勇者の出現を祈るより他にはなす術はありません。
プログラマーにとっては他人事ではありません
こうして、色々なプログラマーにありそうなことを見てきました。若干の誇張表現はありますが、プログラマーをやっていると、こういった事件に、いつ遭遇してもおかしくはありません。仮に遭遇しても冷静でいられるように、日頃から心構えだけはしておきましょう。
もちろん、よくある話は他にも色々とありますし、この記事だけでは紹介しきれないほどあります。また、私の経験したことないようなすごい経験もあるかもしれません。良かったら、あなたのあるある体験も教えてください。
