オラ、焼け野原しんのすけだゾ！ その２ 技術力∝キャリア？（前）

「燃えるゴミのほうに燃えないゴミ入れたらダメですよ。
でも燃えないゴミのほうに燃えるゴミ入れるのは別にエエやん」
～ by 松本人志 at 松紳とか放送室とか

松ちゃん、それは屁理屈だ。

さて、前回に引き続き、ふりかえりを行う…って、1ヶ月近く経ってるじゃねぇか。この間一体何してたのかというと、ロシア状態ですわ、また…

• Problem5：開発者間で決定するように指示した事項に関して、その決定事項の内容確認、及びそれらが遵守されているかどうかを確認しなかった。
• Problem6：技術力はキャリアの長さに比例するという認識。つまり、キャリアが短い者の言うことよりは、長い者の方が正しいという価値観。

詳細設計フェーズも終盤に差し掛かった頃、DBアクセスロジックの実装の規約・方針を決めておくように上から指示された。

Java言語（というよりオブジェクト指向言語）でDBアクセスといえば、DAO・DTOと呼ばれるクラス群（＋ORマッパー）で行うのが一般的だ。開発を何年も行っていれば、どこの会社も大抵はプチフレームワークとでも言うような仕組み・パターンを構築しているものだろうが…うちの会社はさにあらず、全社標準の規約というようなものは存在しない。コーディングは疎か、仕様書のフォーマットなども、プロジェクトによってまちまちだ。外部から参画している1人のメンバーは「（全社標準規約的なもの）無いの！？駆け出しの会社じゃあるまいし、普通作るよね…」と呆れ顔だ。
※規約が無い事もさることながら、その現実に対して何ら疑問を持ったり改善しようとしてこなかった古参社員にはもっと…

閑話休題。さて、話し合い、今回のプロジェクトではどうするか…ぶっちゃけ、特に話し合うことなどは無かった。どういう事かというと、

1. 当プロジェクトで利用するフレームワークのライブラリに、DBアクセスクラスは用意されている。
   ※SELECT・FROMといったSQLの要素をプロパティとしてセットし、それを元にSQL文を生成し、SELECT文であれば検索結果をHashMap的なオブジェクト（の配列）で返すといったクラス。
2. このフレームワークのシステムでは、1.のクラスを用いるのが一般的というか当然。
   同じフレームワークで構築した他のシステムにおいても、勿論上記クラスを使用している。
3. 1.のクラス使用すると、ログ出力・主キーにセットするシーケンスの採番等、『おまけ』処理も自動で行ってくれる。
4. 3.のおまけ処理に関して、顧客から要望が挙がっている。つまり、顧客も1.のクラスを使用するものだとの認識でいる。つまり、「1.のクラスを利用する」ことは、暗黙的ではあるが顧客の要件である。
5. 作ったシステムを保守するのは顧客自身。顧客（情シス部門）はSIerと異なり、保守的なスタンスであり、あまり新しい事にチャレンジしたり覚えたりしたがらない。
   よって、2.で述べた他の既存システムとあまり外れた方法をとるべきではない。むしろ揃えるべき。

と、言うわけで、選択の余地など無い。DAOやらDTOやらクラス設計どうするというような大規模な取り決めなど不要。こちらで出来ることと言えば、上記DBアクセスクラスをラッピングすることくらい。
結局、上記5項目を全員に伝えた上で、どういう単位でラッピングするかという事だけで終了。話し合いは意見が衝突するようなこともなく、「意見は？」の問いに誰も挙手せず。話し合い終了後も意見は出ることもなかったので、フィックスし、数日後に製造フェーズは開始となった。

製造フェーズが始まって数日、あるベテランプログラマから連絡が入った。
「DBアクセスを行う仕組みを作った、概要・使い方を説明したいので、時間取れないか？」と。
…はて、フィックス済みだが。ユーティリティー的なものを作りましたってことなのか？でもそれにしては「時間取れないか？」って大袈裟だよな。
この時点で進捗に遅れが発生していたこともあり、あまり時間をかけたくなかったので、とりあえずソースコードを見せてもらった。

…結果、絶句。 本当に仕組みを0から作ってやがる。
SELECT・FROMといったSQLの要素を引数で渡し、それを元にJava標準のStatementやResultSetを使用してDBアクセス、SELECT文であれば検索結果をHashMap（の配列）で返すといった仕組みだ。
前述の1.のDBアクセスクラスと、内容どんがぶりである。激しく無意味だ。そして、無意味なだけでなく、致命的な問題点も含んでいる。

• 致命的な問題
  • 顧客の要件を満たせない（ログ出力等）
  • PreparedStatement使用していないので、SQLインジェクション脆弱性が存在！
• 致命的では無いが…
  • インターフェイスをテーブル単位で作成する必要があるなど、クラス数が増大する。 今までのやり方と異なる事もあり、顧客からクレームが来る可能性大。
    ※フレームワーク標準のDBアクセスクラスは、DB情報は設定ファイルから取得するので、このような余計なクラスは不要。
  • SQLの要素を渡す手段が引数だと、その組合せの数だけ引数違いのメソッドを用意しなければならない。
    ※SELECT、FROM以外は必須じゃないからね。必要無い場合はNULLで渡すなんてイケてないし。
  • そもそも、この仕組みで行えることは、フレームワーク標準のDBアクセスクラスで全て実現可能。しかも、より簡単かつスマートに。

PreparedStatement使ってないのは本当にビックリした。『いろはのい』だぞ？何年やってんだ…
上述の通り、採用できないのは明らか。加えて、そもそも既にこれに関してはフィックス済みで、その決定内容で製造フェーズが開始されてしまっている。このような案があるなら、何故事前に連絡をくれなかったのか？
そのような事も添えて、この仕組みは採用できない旨をメール送信。ここでも「意見があれば言ってください。」の一文と共に。結果、「了解した」との素っ気ない返事。ちょっとイラっとしたが、取り敢えず一件落着…と思っていた…

そのような遣り取りがあった次の週、我が社では珍しく（というか恐らく初の）コードレビューが実施された。 そこで明らかされたのは、開発者間打合せ、上記のようなメールの遣り取りを経たにもかかわらず、決定事項が守られていないという現実…しかも、6人中3人も。

思ってた以上に長くなったので、エントリ分ける。つづく。

＊

ちなみにCoccoで一番好きな曲は『寓話。』です。