＜バグをなくすために仕様書を作る＞
コメント規約で思いっきし分かりにくくなったソースたちを目の前に僕らは、崖っぷちでした。
バグがあまりに多く、そのための対応として、修正ソースをコメントアウトして残しました。ADD、MOD、DELというコメントですべての履歴を残すことになり、結果、ソースがコメントだらけになったのです。
ある程度の年数、同じソースに向き合っていると愛着がわくもので、それを自分たちで汚してしまった後悔の念と、これからのことを考えて絶望していたのです。
けれど、仕事をそこで放棄できない僕たちはみんなが感じている問題点を列記することとなりました。
その中の仕様書について、まず僕たちは話し合いました。
仕様書に関しては、昔に先輩が1行の仕様書を僕に渡して「よろしく」と言いました（僕は新人でした）。その瞬間、時の流れが止まった感覚を覚えました。この時からその仕様書のことを僕は「1行仕様書」と呼ぶことにしたのです。それ以外では、クライアントから要望がない限り、仕様書はあったりなかったりでした。もちろん共通フォーマットってものも存在していませんでした。
悪い習慣を絶ち切って仕様書から始めようと僕たちは「プログラムを作る前に仕様書を作る作業」を徹底することにしたんです。
僕も、この時に仕様書を作ることから始めていなかったので、作っては内容が足りないとPMから怒られる毎日でつらかったです。そのPMがたまに出してくる「1行仕様書」のダメ出しをしてみた時の痛快な思い出は、僕の心にささやかな勝利の記憶として残っています。
ちなみに「1行仕様書」の例は以下のとおり。
例：○○帳票にチェックボックスを追加して、得意先ごとに改ページができるようにする。
まあ、確かにそうですよ、間違いないですよ。経験者であれば、問題なくやるでしょう。そして、そのチェックボックスが積み重なり、画面中チェックボックスだらけになるでしょう。そして、単純なタブ順もおかしなことになり、クライアントから、tabキーで移動できないとクレームになるのです。
僕は、感じたのです。1行仕様書の恐ろしさを……。
確かに、そのドキュメントを見ればものすごく改修は簡単そうですが、ベースとなる処理や、その他もろもろの課題は1行に内包されているので、どのようにしてチェックボックスを追加して何に注意して実装したのかや、その時の問題点は忘れ去られます。何年もすれば、なぜ追加したかも1行の中からは読み取れず、どのような理由で存在しているか分からないチェックボックスに悩まされるのです。
そんなわけで「1行仕様書」はやめようということになりました。最初は画面設計から処理説明がメインだったけど、そのうちIOや項目定義も追加して……という具合に、段階的にやっていこうという話になったのです。
最初は、仕様書を書く時間が結構かかりますが、やはり多人数で行う作業になると、相互理解の意味も含めて仕様書は大切ですよね。プログラムは1人で作るのが一番早いといわれていますが、納期には限界があって、結局多人数になります。ただ、人が増えて、単純に作業時間が短縮されるわけではなくて、純粋に個々の時間だけ考えれば、2倍の時間になると聞いたことがあります。なので、相互理解をしっかりやっておかないと、余計に時間がかかったり、品質が落ちたりする。人を増やしたらやれるでしょと結論を出してしまう人もいるので困ります。そんな単純な作業ではないと思うんだけど困ったものです。
その後、ER図を作ったりと進展していきましたが、やっぱり、仕様書は必要だと感じてます。会社によって、あるいは案件の種類によって、仕様書の内容やフォーマットはさまざまですが、仕様書作成のレビューなどで仕様理解が不十分だったり、無理な仕様変更した場合のプロジェクトは、よくトラブルが発生しているのを思い出します。
もちろん、プロトタイプを作って早々にレビューする場合とかは、仕様書は後回しでいいと思いますが、無駄に多くてもいけないし、少なすぎてもいけないのが、仕様書とテストのような気がします、言い換えると無駄と無理をしないというのかな、矛盾のない手順とドキュメントが必要ですよね。
仕様書っていろいろ考え方があったり、会社によって違いはあると思うけど、もう「1行仕様書」は見たくないし、後輩にも見せたくないと感じました。それは今も感じています。
]]>「効率化」が嫌いなのに、VMware Serverで開発環境を構築して、コピペでできる開発環境で構築時間を短縮することで、新プロジェクトに取り掛かる際の効率化（時間短縮）になればと思ったのだ。ライセンスはかかるため開発コストの圧縮まではできなかったが……。
ただ、たまにどこに何が入っているか分からなくなった時、効率化したつもりが非効率的になっている気がして、げんなりする。結局は運用まで検討しなければ、効率化にはならないのですね。目先の対応はいけません。
＜重なるバグ＞
僕は、いつもと同じように、MSプロジェクトに書かれた自分のスケジュールを確認して、コーディング作業に入っていた。
いつもと同じ、変わらない作業。変わらない日常。
ただ、電話が鳴りやまない……。
リンリンリンリンリンリンリンリン！！！！！！
朝一番で発覚したユーザーからの電話によるバグ報告で、僕の同期はデバッグ作業に集中していた。
当時はリリースすれば、バグ発生の状態が続いたことがあった。ぷよぷよで言えば5連鎖、6連鎖。パッケージソフトとして展開していたので、1つのバグ報告で多くのクレームが舞い込む。
原因としては、バージョンアップによって既存機能がおかしくなる（いままでと違う動きなど）というバグだ。今も昔も多いバグだと思うが、特に基幹システムのバージョンアップでは多いような気がしている。
正直にいうと、同じ個所の修正を僕がやっていれば彼と同じようにバグを出していた確信があった。僕は運が良かっただけだ……。心の中でものすごく悲しかった。自分の仕事もあって手伝えなかったが、必死にデバッグしている彼を見て、僕は心が痛かった……。
僕の同期はとっても素直ないい子だった。もう何年も付き合っている彼女のことを大切にしている。僕としてはあまり見たことのない純粋な子だったのだ。通常だったら助けたいなんて思いもしない僕だけど、彼に対しては違っていた。
ただ、すぐに僕も後を追うことになったので、お互い「慰め合い」「励まし合い」「助け合う」ことでなんとかプログラマを続けていた。彼がいなければ、バグに過敏になりすぎて、人間不信に陥るところだった。
2年目にはずいぶんベテラン風になってしまい。中途採用の人に2年目だといったら驚かれたのを覚えている。
「え！！ ○○さん、まだ2年目なんですか」彼女はその1週間後に会社を辞めた。
それでも、徹夜とかはなかったので、いい会社だったと思う。今考えると環境に甘えていた。
その後に労働基準局が入り、残業でもめたので、次期リーダー候補となる人も、そのいざこざでやめてしまった。
僕たちは、とにかく作ることをだけを目標にされ、社内ミーティングも禁止になった。
どんどん頼る人がいなくなり、残業問題で社内でのミーティングもできなくなり、全体で話し合う機会もないまま、時間だけが過ぎていった。
ある時、バグ発生数を数えることをやめてしまった僕たちに上司が切れた。
「なんなんだ、このバグは、どうにかならんのか！！」
地獄のような会議を終えて。みんな顔が疲れていた。
長年改修を続けているパッケージソフトなのでどうしても、改修を入れた場合に、予想外の動きをする個所がある。すべてを把握してプログラムする必要があったが、工数2～3日では結局そこまでできなかったというのが、当時の僕の本音である。
そんな中、開発チームでミーティングを実施した。みんな真剣な顔で悩んでいた。そんな静寂の中突然マネージャが口を開いた。
「開発をやめればいいんだ」
みんなも、
「そうだ、そうだ、やめればいいんだ」「ナイスアイデア！！」
みんな変なテンションでした……。
＜コメントの嵐＞
そんなことが、解決策じゃないってみんな知ってたけど……みんな病んでいたのだ。
そこで立ち止まれないので、バグに対して、みんなで考えた対策を実施していこうという話になった。
まず最初に実施したのが、コメント規約の変更。僕はこれには反対だった。マネージャも反対していたような気がする。
修正前のソースをそのままコメントアウトしてDEL、追加はADD、修正はMODとしてコメントを残していく。かつ修正番号を振ることで、バグ発生時にすぐに修正個所が発見できるという話だった。ただ、この対応以降、猛烈にソースが読みにくくなった。
最初の修正でバグが発覚して、対応者が検索ですぐに問題を見つけれたのがいけなかったんだろう。もう、なんだか「すぐに対応できるぜ！！」という勢いになってしまったのだ。
もう2、3カ月したらコメントの嵐ですよ。
何年もやっている僕がソースを読むのがつらいのに、新人はどうするんだよと僕は思った。当時Teamsourceでソース管理していたので、そっちで修正個所を見ればいいのだ。
この対策では、バグを見つける効率を上げるために取った対策が、後々のソースコードの複雑さにつながった。ソースはシンプルできれいな方がいい。それまでも心の中で感じていたことだが、確信した瞬間だった。
]]>「効率化」、いろいろな諸問題を明確にして、現代社会のプレッシャーを現場レベルで格段に上げた代物だが、良い点もあれば悪い点もある。効率化という言葉だけですべてが潤滑に回るわけではない。
効率化とはまた別の話になるが、会社にはノルマというものが存在する。
数字で表せば、人はその数字を達成するべく努力する。一方、それにかかるコスト意識などでがんじ絡めである。結果、たとえ仕組みが悪いせいで到底達成できない数字が目標と掲げられていても、数字を達成していない人が悪い、という結論になってしまう。この場合、本当に悪いのは、数字の根拠になっている基準である。基準があいまいであれば、数字なんて何の意味も持たない。
ただ、基準がしっかりしていれば、ノルマは大切である。人間というのは、1つ設定された数字について自然に「達成したい」という気持ちになるらしい。数字でノルマを表せない場合は、評価もされにくい。そういう意味で数字は大切である。
効率化も同じだと考える。基準があれば、効率化というキーワードは常に意識に入れておく必要があるが、基準もないのに効率化ばかりに注力して、後々の非効率的な作業が増えてしまう点については見逃されている。
コラムでは、プログラマが一般的に行う「コードを効率化・部品化して納期を早く仕上げること」以上に、「他人が見て分かりやすく再利用しやすいコーティングが必要ではないか」ということを書いていきたい。あくまでプログラムについて考えた場合、過剰な効率化による分かりにくいプログラムは好きじゃない、ということを一番言いたい。
どんなに高度な計算処理や効率化も、いきなり入った新人にとってはただの難解な小説で、改修すれば即バグが発生してしまう代物になりかねないということだ。
プログラムにおいて、難解なプログラムを読み解いて答えを見いだすのは、なかなか骨が折れる作業になる。
昔のプログラムによくあるパターンとしては、ドキュメントもないし何年も改修を続けていて、新人が怖くて改修できないプログラム。これはなんの意味があるのだろうか。
ここで私が新人の時の話をしてみたい。
＜つらかった駆け出しプログラマ時代＞
僕は大学を出て、なにかモノを作る職業に就きたいと考えていた。ただとびきり優秀なわけでもなく、なんとなくシステム開発という道を選んだ。深い考えは……正直なかった。とにかくなにかを作ってみたかったのだ。そして、とある東京のシステム開発をしている会社に入社することになり、入社前の研修でプログラムの演習をはじめて行った。
初めて作って、正しく動いた時はうれしいものだった。
いろんなプログラムを自分で作れるようになりたいって思って入社を迎えた。ある意味で希望を持って入社した。
入社した当時は、仕事に対して「ああだのこうだの」なんて不満もなく、ただ目の前にある仕事に対して一生懸命働くことになる。中小企業では、早めに実践投入されるのが当たり前で、納期がゆるい仕事は最初の1～2案件だったと思う。すぐ実践に投入されて、コーディングに突入、もちろん仕様書もないし、口頭と手書きの指示で、「習うより慣れろ」という、摩訶不思議な言葉のもと、プログラムを作成して提出する。
そこで、運良く先輩のレビューでコーディングミスなどが発覚するとする。その時に口癖のように「なんでこうしたの？」と聞かれて困る。2～3案件こなすうちに、そんな先輩のレビューも漏れて、朝礼の場でバグ発生者血祭りの宴が始まってへとへとになる。
＜納期の厳しさ＞
そうして、プログラムの納期の厳しさを入社して半年で味わうことになる。ただ、私は最初に納期の厳しさを知って良かったと感じている。何社か経験していく際、この感覚が甘いと、自分の会社ではよくても他の会社では通用しない。納期に甘いのはプログラマとして致命的だ。
もちろん、いろんな事情があるのは理解しているが、それを加味しても、与えられた納期にあがきもせずに、文句ばっかり言って案件を頓挫させることは、本人にとって良い影響を与えないと思う。
ただ、いろんな問題は現場に山積しているので、現場では文句を言い合ってストレス解消をして、納期に対しては工夫を怠らないのが大切だと思う。コストをかけて、諸問題を適切に処理してくれるマネージャは、経験上あまりいない。現場から、本当に納期・品質の必要性を考えて努力し、結果を出さなければ、納期・品質に関しては解決しない。
結局、解決できるのは技術がある現場だけだと思う。
現場にいない人間の方法論を受け入れるほど、現場の人間は心が広くも余裕があるとも思えない。
この点がある程度、納得できる職場にいる人は幸せだと思う。先輩や過去のマネージャ職の人たちの努力や学習の結果だと思う。ただ、私がいた現場はそれほど、恵まれた環境ではなかったように思う。
＜そして10年たった＞
そうして、実践にてプログラムを進めていくことになるが、そこで感じた違和感を十数年たった今でも感じている。プログラムが難解すぎて改修できない……またはしたくない。
変数に変数が入り乱れ、無限とも言えるfor文で、どの値がどのようになるとOKで最大値がいくつかも分からない、こんな処理をなんの疑問もなく懸命に読んで、改修をしてバグを発生させる。このパターンが何年も恒例の行事のように、はたまたなにか大人になる試練かのように繰り返される。
これは正しいのか？
コメントに｛＊この処理はこうかも？｝と、いかにも自分が原因ではありません的なコメントがついてしまうような処理があると、プログラムをどう正当化すればよいのかが分からない。それが、いかに正しいアルゴリズムで正しい計算処理を行っていようと、難解であればアウトだ。
鬼のように何人ものコメントが入っているプログラムも汚くていじる気にもならないし、どうすればよいのか分からない。
<プログラムはクイズではない！！>
そんなわけで、分かりやすいプログラムを記述していくことでのメリットと、結局はたどり着くことのないであろう「理想の開発」ってなんだろう？ ということを一度じっくり考えてみたいと考えるようになった。
]]>