昨今、継続的にプロダクト開発していくことが主流となり、Four Keysなどの開発パフォーマンスを測る指標なども出てきており開発生産性を向上させることが注目されています。
しかし、かつての開発現場では今では信じられないような開発生産性を爆下げするようなことをやっていました。
この記事では10年以上前に私が経験した開発生産性を爆下げする事例を書いていこうと思います。
(私が体験したことをベースに書いているので10年前は全てがこうだったということではないのでご留意ください 
)
修正前のコードはコメントアウトで残す
当時、ウォーターフォールで開発していました。
ウォーターフォールでは開発工程とテスト工程が分かれています。
開発工程で一通りコーディングして、テスト工程で動作確認を行いバグを潰します。
問題はここからです。
とある現場では、テスト工程でバグを直すときにコードを破壊的に直すのではなく、元のコードをコメントアウトで残すというルールがありました。
簡単な例を使って説明します。
引数を3倍にして返却するメソッドを実装するとします。
# iを3倍にして返す
def hoge(i)
i * 2
end
上記は3倍にしないといけないのに2倍にしてしまっています。
このバグをテスト工程で見つけた直す場合は下記のように修正します。
def hoge(i)
# 2023/03/15 修正者: ham
# i * 2
i * 3
end
元の実装は削除せずにコメントアウト、その上に対応日と担当者を追記します。
この現場ではコードのあらゆる箇所に上記のようなコメントが散在しているため、コードの可読性がかなり悪いです。
コードは書くより読むことの方が多いので可読性を上げることは生産性向上の第一歩ですが完全に逆行してしまっています。
ちなみに、もしかしてコードのバージョン管理ツールがない時代の話？と思われた方もいるかもしれませんが、CVSやSVNなどのバージョン管理ツールは使っていたので変更履歴などは確認できる現場でした。
IDがついたクラス名
とある現場では画面や機能にユニークなIDをつけていました。
例えば、「DISP001: ユーザー登録画面」「DISP002: ユーザー編集画面」のような感じです。
IDは連番であり、画面や機能を推測できるようなものではありません。
この現場では上記IDをクラス名に使うというルールになっていました。
そのためエディタのツリーが下記のようになります...!
- DISP001.do
- DISP002.do
- DISP003.do
...
- DISP010.do
どのファイルが何なのか全くわかりませんねw
これでは探している画面や機能のファイルを見つけるだけで一苦労で、ファイルを見つけるだけで無駄に時間がかかってしまいます...
クラス名やメソッド名、変数名にわかりやすい名前をつけるのはリーダブルコードの鉄則です！
詳細設計という名の日本語コーディング
ウォーターフォールでは前工程へ戻ることは許されないので、手戻りを減らすために細かく設計することが求められます。
とある現場では実際にコードを書く前に詳細設計という名の日本語コーディングを行なっていました。
日本語コーディングとはどういうものかというと下記のようなイメージです。
みんな大好きExcel方眼紙に処理の詳細を書きます。
特に「詳細」の部分は処理の細かい部分まで書かれており、コーディングすることを日本語で書いているような内容になります。これをこの記事では日本語コーディングと呼んでいます。
これを書くために頭の中でコードを思い浮かべていると思うので、この時点でコードとしてアウトプットした方が圧倒的に効率が良いのは明白です。
また、この粒度で書かれているため、後工程でコードを修正した場合にほぼ100%の確率で詳細設計も修正する必要があり後工程の生産性を下げることにも寄与します。
書いた行数で進捗管理
とある現場では、開発工程の進捗は書いたコードの行数で管理していました。
コードの行数が多いほど進捗が良いということです。
また、見積もり時の工数算出を想定コード量から計算するため、実際にコーディングするときに簡潔に書いてコード量が減ってしまうと見積もりと乖離してしまいます。
見積もりより大幅にコードが少ない場合、工数が削減できたと判断され(実際には削減できているかどうか関係なく）次回以降の工数確保が難しくなる恐れがあります。
それを避けるために、コーディング規約でコード量を削減するような書き方、例えば３項演算子やカッコを省略するif、１行で複数の変数を宣言するような行数が少なくなる書き方は禁止されていることもありました。
生産性を上げるプラクティスの1つはコード量を減らすことですが、コーディング量を増やすという生産性向上とは真逆のことをしていました。
エビデンスを大量に保持。ログやDBダンプ、キャプチャを全部残す
実装した後、動作確認を行うことはどの現場でもあると思います。
ただ、とある現場では1つテストをするごとに前後のDBダンプやログ、操作したキャプチャなどテストをした証跡を事細かに残していました。
しかし、工数をかけて保存している証跡ですが後から使われることはほぼなく、ただただテスト工数を数倍に跳ね上げているだけの存在でした。
実態は品質云々ではなく納品物に含まれているのでやらざるえなかったということなのでしょうが、このように本質的ではないタスクがたくさんあったな〜と懐かしく思います。
デバッガで止めた状態をキャプチャ
1つ前の事細かなエビデンスの時点でツラいですが、過去最高にツラかったのは単体テストのホワイトボックステストで分岐前後のキャプチャを残すというものでした。
例えば下記のようなコードを書いた場合
def hoge(flg)
if flg
p 'flg is true'
else
p 'flg is false'
end
end
-
flg == trueの証跡
-
flg == falseの証跡
のようにキャプチャを残します。
ホワイトボックステストなので数は膨大です。ほぼ全コードのキャプチャをとっているようなもので、控えめに言ってもこのキャプチャを残す・残さないで単体テストの工数は10倍以上増えたと思います。
ちなみに上記は納品物に含まれており、上記のキャプチャをExcelに並べて貼って、見るべきポイントを赤枠で囲い、最後にPDFにするという作業も必要で言葉を失いました。
印刷して納品。Excelの改ページプレビューにやられる
プロダクトを納品するとき、設計書類を印刷してキングファイルに綴じて提出するというものがありました。
ちなみにCDで電子ファイルとしても提出しています！!
このとき「詳細設計という名の日本語コーディング」で登場したExcel方眼紙が猛威を振います。
Excelを印刷したことある方ならほぼ100％経験すると思いますが、Excelの印刷範囲は初期状態ではほぼうまくいきません。
だいたい下記の図のように絶妙にずれますw
(下記は手元にExcelがなかったのでスプレッドシートでそれっぽく加工しています)
これをちまちま修正する必要があり、印刷し終わるまでに余裕で1日かかります。
最後に
以上、昔の話を思い出して書いてみました。
今となっては雑談のネタになるので良い経験だったなと思いますw
そんな私も今では開発生産性をどう向上させるか日々考えながら開発しています。
昨今、開発スピードと品質は相反するものではないということが広まってきているので、本当に必要なものを見極めながら効率よく品質の高い開発ができたら良いなと思います。
Comments
気持ちも分からないでもない。
バージョン管理システムがあっても消したコードは基本二度と参照されるないし、残しておきたい。
画面IDみたいなのもドキュメントやエラー表示には多少便利。自動だとずれがち。
行数は良くないインセンティブになるけど、指標にはなる。
実際やらされたらストレスがヤバし、自動化できそうな点が多いのも事実。
あるある！最近そういう環境にいました。テスト項目はコードのステップ数(笑)の何%～何%の範囲内に収めろとか、テスト成功率は何%～何%に収めろとか（成功率が高すぎてもダメ！）、コメントは英語で書けとか（書くやつ読むやつ全員日本人なのに！）、マヌケな規約のオンパレード。俺は年寄りだから笑ってネタにするだけで済むけど、最初からこれをやらされる若い人は気の毒だよなあ。
人間は知識がなければどこまでも愚かになりえる、という実例ですよねー。
昔Fの現場に居た時これ全部網羅されてるプロジェクトに居たことあります…
IDとコメントに関しては前職が常にそうでした。
慣れるとIDで画面名が分かるようになるし、コメントも慣れ次第では確かにその場その場では見やすいのですが、そもそも慣れないと駄目な時点でよく考えると論外でしたね。
私に関してはバグが多発する年中炎上してるみたいな部署でした。
ご指摘の通り、この手のルールがある場所は鶏が先なのか卵が先なのかみたいな感じの生産性の慢性的な低下が起きているような感じもします。
全部、思い当たる節が…。
あ。でも、「IDがついたクラス名」にはまだ遭遇していない。
基本的に全部メインフレーム時代からの「伝統」なんですよね。
これは、レアケースだと思うけど、プロジェクト内で付けた固有の機能IDというもので会話していて、プログラムIDが何なのか、「台帳」みないと分からないってのが、有りました。
※コメントアウトで残すのは、本当に撲滅したい。
「決まりだから今更やめられない」「昔からそうだったから」と言い訳する年長者がいっぱいいましたね。
これ、昔だけの話じゃなくて今もあるんですよね…
そこそこ大きいところでも、今でもやってたりするという。
（逆に大きいからこそ、それなりの権限が無いと一気に変えるのが難しいのかもしれない…）
酷いところでは、バージョン管理システムすら導入していなかった。
改善したい場合、大体お金が絡むと話通しやすいので、数値で保守コスト〇〇くらい下げれるみたいに話持っていけると、上の人を説得できることもある。あと、自分が改善を牽引する覚悟が必要になる。別に変わらなくてもいいでしょ、と思ってる人の割合が多いと相当厳しい。
納品物に指定されているという所も全く一緒で懐かしく、そして爽やかな気持ちになりました！
これを最初に考えた人は相当な○ホですよね。
恐るべき事に今もこのような慣習がある受託開発の現場は存在します。
ただ，IDをクラス名にする事だけは私は肯定的です。
語彙力もセンスも無い人が作った間違った英語のクラス名を見続ける苦痛が無いため。
画面あるいは機能IDでクラス名を作るは、基幹システム開発だと割と残ってるような・・・。変に一貫性がない綴でクラス名にされるよりいいのかな、とか。
ここに書かれている事、どれもやったことが無いから僕は結構現場に恵まれていたんだなと思わされる。
ただ、他社から納品されたプログラムを見たときに1つのファイルの中で3つくらいの命名規則がごっちゃになってたり、コメントが意味をなしてなかったり等ひどいものは見たことがある
意味をなしてないコメントはこんな感じ
SIer、暗黒ウォーターフォールあるあるですね・・
悲しいことに今年入社した会社が'詳細設計という名の日本語コーディング','書いた行数で進捗管理','デバッガで止めた状態をキャプチャ'以外すべてやっていて入社直後目玉飛び出そうでした…
コメントとして残すのは最初はきっと良かったんだよね
一つ前の履歴がすぐわかるからとか
でもそれが溜まっていくと問題がw
必要なくなったら消せばよかったのに（最初はそのつもりだったけど消し忘れた？）担当者が変わったりすると前任者のやり方として真似するとか、いつのまにかそれが正式みたいになってたとか
今はGit使うから減ったけど、緊急時にサーバー入ってviでちょこっと直す時ぐらいかな、それもあとで消し忘れて残ってしまうことあるんだよね
ワシやないか。
並びを楽にするためにこういうコーディングをしたことがあります。
No01MainScreen
No02SubScreen
No11NextScreen
冒頭を読んで前にいた部署での体験を思い出しました。C言語のソースコードが数万行(1つのファイルで)でしかも大量のファイルに分かれており、実際のソース＋修正前のソース×修正回数のコメントが大量に記載されていました。初版は1990年代中頃なので凄いことになっていました。VSCodeで開いてもVSCodeが認識出来る行数の上限を超えており、途中までしか表示できないという問題が発生したり、同じ様な関数があちこちに実装されていて、1つの修正を入れるのにあちこち直さないと直らない。しかも実態を把握している人が1人(しかもうろ覚え)しか居ないので、その人の記憶と勘で修正レビューをするので、レビューの度に修正指摘が増えていくという有様でした。因みにGitでの管理を導入したものの保守部門の反発でコメントアウトでの修正履歴は今後も継続とかで改善は夢のまた夢でした。正に開発工程が改善されるのが先か、この製品が滅びるのが先かという様な有様でした。
大手によくある話だわ
ぶっちゃけ、修正コメントやコメントアウト履歴なんて2年以上前のものを残しておく必要は無いんだよね。
そこまで遡って、「戻すのか」って言われたら「それは無い」ってみんな言うと思うし、もしやるとしても誰もやりたがらないでしょう。
GUIだと画面の品揃えを一覧にしたり、画面遷移を何らかの形で設計したりはするのでIDがそのままファイル名でもそこまで不都合はないと思います。
もちろん単なる連番ではなく桁別コードを使うとかの工夫は必須です。
（名称で付けるとしてもプリフィクスが決まって後ろに尾ヒレが付くわけで、やってることは桁別コードと同じ）
ステップ実行をテストと言い張るのはレガシープロジェクトあるあるですね……
何十年前の話ですか？
こんにちは。
主原因は、「開発生産性が低い」おかげで、売り上げ（および利益）が保たれることかと思いました。もしも「開発生産性が高く」なると、受注額も水増しできないことになり、そのような生産性に付いていけない人、したがって失業者が増えそうです（欧米社会のように）。
むかし担当したとある化粧品会社のオンラインショップで、この記事に書かれている事象のすべてを網羅したやり方で開発していました。また、アジャイルと名乗りながら納品サイクルが1ヶ月単位のなかなか大変な現場だったと記憶してます。
当時はこれが普通だと思っていました。
これ未だに全部やってます。。。
井の中の蛙とはこのことなんですね。
全部経験しました。。。
修正前のコードはコメントアウトで残す
これは、V型だと仕様変更または結合テスト以降の時は、やっていた記憶があります。特に「修正した証跡を残せ」みたいなことを言われてたような。。。
IDがついたクラス名
これも、昨今もまだまだありますね。ここから、和英変換辞書がPJごとに存在したり、マクロで変換したりしてくれるツールがPJに有ったり、様々ですね。
理由としては、複数ベンダーだったり人の入れ替わりの激しいPJはダブりが許されないから(登録制にすればいいんだけど)あらかじめ割り振っておけばOKみたいなイメージだと思ってました。ログとかも部品のIDが出てきて、そこを起点に調査とかやってましたね。
詳細設計という名の日本語コーディング
これは、もう「納品物(ここに代金が付く)」だからという理由で、今時のPJじゃない限り、大概どこもこんな感じです。
とりわけ、オフショア開発とか、PGの参画が遅れたり、開発ツールや仕組みへの理解が不十分になってしまうと、「日本式の設計書」が通じないが故に、そうなってしまう傾向にあると思っています。
書いた行数で進捗管理
最近はあまり見ませんが、10年前位はありましたね。まだFP法使う人すら珍しかった位の時でした。
エビデンスを大量に保持。ログやDBダンプ、キャプチャを全部残す
テスターへの指示が明確ではない、または、テストのスコープとポイントで何を立証するかが共有されてないときはやたらと残したりしますね。(顧客指示で、その分の期間ももらっているのであれば致し方ないが)
デバッガで止めた状態をキャプチャ
JTestなどステップが見えるIDEがPJのツールとして認められてない時代は相応にデバッガキャプチャありました。
デバッガで止めてしまえるなら、エビデンスの正当性はどこへ・・・？と作りながら思ってました。
印刷して納品。Excelの改ページプレビューにやられる
これは、今も昔も変わらずありますね。
「自分が受け取った商品の説明書が汚かったら」と思って、やっています。
日本のエンジニアはテストコードを書いてからコーディングするという一般常識にたどり着く前に定年を迎えそうだな・・・・。
現在進行形でこの記事と同じ開発をやっています。何を言っても改善することはないですし、知識の更新というものがありません。
つい最近、某企業に3ヶ月参加したところが現在進行形でしたね。
20年近く同じ方法でやってるようで、びっくりしたんですよ。
これ以外の作業も二昔だろ的（レビューやエスカレーションも会議室で）方法でやってた
AI時代せめて、Markdown & Mermaidでお願いしゃっす。
Let's comment your feelings that are more than good