前回のあらすじ。
DBアクセスロジックに関して、どのように実装するかの方針を開発者全員で打合せを行い合意形成。その後に意見は何も出なかったのでフィックスし、製造フェーズが開始された。
製造フェーズが開始されて数日後、メンバーの1人から「DBアクセスの仕組みを作った」との連絡が。内容を確認した所、致命的な問題も含まれており、そもそもフィックス済みの方針と異なるので、採用できない旨を伝える。その後、了承した旨の返事を受け取る。これで一件落着かと思われたが…
メールの遣り取りがあった次の週、コードレビューが実施された。内容は、コーディング・命名規約等が遵守されているかどうかをチェックするというもので、「ここはこう実装した方がいいんじゃない？」というようなリファクタ目的ではない。
※ちなみにコードレビューは結局この1回限りだけだった。何だかなぁー…
今回のシステムは、大きく分けて画面系とバッチ系に分かれていた。プログラマは全6名で、その内2名がバッチ系担当、その他4名が画面系担当だ。全てのソースコードをレビューする時間的余裕は無かったので、画面系・バッチ系それぞれから代表して1つの機能を抜粋し、それに対してレビューを実施した。画面系の代表は私が製造した機能だ。まず私のコードのレビューを行い、つづいてバッチ代表の番となった。途中まで淡々と進んでいたが、DBアクセスロジック部分で問題発覚。バッチ側のコードが、開発者間で合意形成した決定事項を遵守していない。 先週のメールで遣り取りした「採用できない」仕組みのままだ。
同席していたリーダー（以下、L）が
L「何で分裂しているの？統一してください。」
とごもっともな一言。いや、ごもっともじゃないな、ここは違反している側に対して「規約を遵守してください」じゃないのか？
「統一せよ」ではなくて「違反している側は遵守せよ」が正当である旨と、そもそもこの仕組みは「採用できない」旨を伝えたところ、その仕組みを作った人物（以下、X）曰く
X「致命的な問題は修正したので問題無い。」
との事。どうやら、SQL文実行クラスを、Java標準のものから、フレームワーク標準のDBアクセスクラスに変更した、これで要件満たせるとの事。いや、もうそう言う問題じゃ無いんですけど。約束事を守っていないんですよ。
すると、
L「何でちゃんと話し合っておかないの！とにかく統一してください。」
私「こちらはその話し合った末の結論に従っています。それに、結論出た後も度々『意見があれば言ってください』って伝えてましたが、このような仕組みを作っている事に関して、何も連絡ありませんでした。致命的な問題の修正に関してもそうです。」
約束事は度々破るわ、技術的にも使えるものでは無いわ…折衷案があるような問題でも無いし、こちらとしては全く譲歩する気は無い。その旨伝えた所、
X「こっちの修正は無理。もう大分作り込んであるから。」
…わからん。何ですか、この威風堂々っぷりは。
しかし、もっとわからないのは、リーダー陣はどうもXの方を支持しているらしいという現実だ。
その心は、前回エントリで挙げた
Problem6：技術力はキャリアの長さに比例するという認識。つまり、キャリアが短い者の言うことよりは、長い者の方が正しいという価値観。によるものだ。
5年目の若造よりも、10年以上の付き合いがあって仕事も速く（
※１）て信頼できるベテランの方が正しいと考えてる感がひしひしと伝わってくる。「Xさんが言うなら間違いない！」という台詞を何度聞いたことか。実は、「致命的な問題は修正した」と言っておきながら、相変わらずPreparedStatement使ってなかったので（
※２）、この点に関して突っ込んだのだが、ここでも終始「Xさんが言ってるんだから…」という感じだった（
※３）。
結局、約束事を守っていたのは画面チームの3人で、画面の1人とバッチチームは例の「採用できない」仕組みを利用していた。再度話し合って決定しろという事になったが、そこでの遣り取り・雰囲気を考えると、「話し合え」なんて只のポーズであることは明らかだ。結論なんて、既に決まっている…結局、約束事を守っていた3人が、血を吐く羽目となった。
＊
後で聞いた話だが、バッチチームが独自の仕組みを作ったのは、マネージャーの命令だったとのこと。バッチ系プログラムは、将来的にフレームワークを変更した場合も利用できるように、フレームワークに依存しない作りにしたかったそうだ。
…いやいや、それなら、画面系と統一させる必要なんてないじゃないか…ったく、リーダーは偉そうに「ちゃんと話し合え！」と言っていたが、そっちだってマネージャーと意思疎通できてないじゃないか。
それに、「フレームワークに依存しない作り」なんてものは、顧客は望んでいなかった。一応、
プログラマ・リーダーという立場のため、クラス構成の説明等を顧客に説明しなければならない機会があったのだが、
「何でこんなややこしい作りにしてるんですか？」
「フレームワークに依存しない作り？でも結局フレームワークのライブラリ使ってますよね？」
「ハッキリ言って非常にわかりづらくて、保守しづらいです。」
と、散々だった。はい、全く仰る通りです…
マネージャーはその旨伝えてあると言っていたが、この時の遣り取りを鑑みるに、全然伝わってないことは明確だ。
YAGNIの原則について勉強してください。
＊
さて、今回のProblemをおさらい。
- Problem5：開発者間で決定するように指示した事項に関して、その決定事項の内容確認、及びそれらが遵守されているかどうかを確認しなかった。
- Problem6：技術力はキャリアの長さに比例するという認識。つまり、キャリアが短い者の言うことよりは、長い者の方が正しいという価値観。
これらを解決するためにTryしなければならないことは？
- Try5：
…わからん。確認してもらったところで、Problem6が存在する限り、覆る可能性は常に存在する。 - Try6：
価値観を変えさせるのは非常に困難。よって、「技術力がある」と思われるようになるしかない…のか？
＊
※１確かに仕事は速い。だが質はどうかというと…↓
※２PreparedStatement使わない理由を尋ねると、「SQLがキャッシュされると、大量のSQL実行した場合、サーバーのメモリ食い尽くして落ちる」とのお答えが。いやいや、キャッシュしない（使い回さない）方がメモリ食い尽くすと思うが？それ以前に、メモリ食い尽くす程の量のSQLをPreparedStatement使わないで実行してたら、パフォーマンスの面を絶対クリアできない。
ちなみに、SQLインジェクション脆弱性に関しては、「エスケープ処理は（パラメータ）渡す側の仕事」だそうだ。絶対間違っている。PreparedStatement使う方が、遙かに簡単・安全・確実だ。
※３この遣り取りで、開発チームの誰もがSQLインジェクションを知らないらしいという事実が判明。
＊
懐かし。『ESCAPE』よりは『アネモネ』の方が好きだったなー
