エンタープライズなシステムはその複雑さから多くの人数が必要となり、
結果さまざまな会社のメンバーがプロジェクトに集まる。
僕もそんな一人だ。
システムの舵を取るプライマリコントラクタは名だたる会社。
そんな会社のマネージャ、リーダーと仕事をすれば安心。。。というわけじゃない。
この人たちとずっと一緒に働きたい！って思うことのほうがよっぽど少なくて、
このプロジェクトはできれば早く終えたいな。。。と思うことがある。
どんなプロジェクトだとそう思うか、思いつきでまとめてみました。
マネージャー・リーダーの人は参考にしてみてください。
チェックが多いほど、プログラマはプロジェクトから抜けたがっていると思います。。。
□プログラムを本数で数える
オブジェクト指向言語が主流の今、プログラムは本数で数えられないんじゃないかな。。。？
クラスは業務や機能から導かれるもの。
担当する業務によって関係するクラスの数も変わればクラスの大きさも変わる。
「今週は何本作った？」みたいな質問は意味を成さないんじゃないかな、と思う。
同種のことにプログラムを行数(キロライン)とか。。。
プログラムを多く書くことがいいことではなくて、
目的の機能を短く読みやすく書くことがいいことです。
□単体テストとは画面を操作してデータベースにアクセスするテストを指す
画面単位のテストを「単体テスト」って考えづらい。
画面から動かせば、プレゼンテーション→ビジネスロジック→永続化と呼び出すことがエンタープライズシステムでは多い。
もはやこれは結合テストでは。。。？
この「単体テスト」で分岐とかすべてテストしようとしても、
単位が大きすぎてテスト仕様書を書くのもデータベースのデータを用意するのも、そして十分なテストを実施するのは難しい。
画面単位であればプログラム単体をテストするのではなくてその機能のテストにしないと、
マネージャーの皆さんはいつまでたっても「単体テスト」の質が低いとか言うはめになります。
プログラマの「単体テスト」がずさんなのではないように考えています。
□設計するSEが「私は業務知識だけでやってきている」と言う
こういうセリフを言ったSEの(詳細)設計で質が高かった試しがない。。。
モノを作ろうというのに材料をまったく知らないというのに等しいんじゃないかな。
きっと建築家でも建物に使える材料は知っていて設計してると思うけど。。。
(詳細)設計とは画面のデザインを載せてこのボタンでデータベースを更新する、
ぐらいのものではないんです。
何を使って作るかを意識してこその設計です。
さらにその「業務知識」も特定のユーザー企業のシステムでの「業務知識」であることが多いです。
□プロジェクトが進むほどテーブルのカラムが増え続ける
□テーブルのカラムが文字列型ばかりである
□テーブル間の関連には外部キーを利用しない
□テーブルのプライマリーキーは複合キーばかりである
DB編。基本を知ってなお今回のシステムではこうする、というのであれば全然OKなのですが。。。
COBOLのリプレースからJavaでのエンタープライズシステムが始まったからか、
正規化はない、カラムは文字列型ばかり、ビジネスキーを組み合わせたプライマリーキーというデータベース設計が非常に多いです。
そしてデータが増えれば1つのテーブルがどんどん巨大になる。。。
これらが実装に与える影響は途方もなく大きいです。
データベースを設計するのであれば、書籍も豊富に出ていますし
データベースの基本は勉強して設計してもらえたらな、と思います。
□工数は画面のデザインを見たマネージャーが勘で見積もる
エンタープライズシステムの構築ではやはりウォータフォールが主流。
その工数見積もりの方法を聞くと。。。
たいていマネージャーが画面を見てその難度から工数を見積もります。
端的に言うと勘なんです。
勘で人生まで振り回されたエンジニアだっています。実際に使う使わないはともかく基本を押さえる意味でも、
見積もるマネージャーは見積もり技法を学んでからプロジェクトごとにアレンジしてもらいたいです。
□進捗会議が1時間以上かかる
進捗会議はどのプロジェクトも必ずあります。
でも、「何を報告しなければならないか」を規定しているプロジェクトは少ないです。
なので会議で話題が広がって時間がかかったり、問題解決の話し合いまで始めてしまったりしてしまいます。
報告することを規定して、全員が会議前にそれをまとめていれば、
考えながら話す人がいないのでスムーズに進み、会議が短くなります。
ほしい情報だけが入り、みなのモチベーションも上がると思います。
□設計書のレビューを実施しない
実装開始の前日夜中、設計書完成。
レビューなきままプログラマへ。
結合テストにてバグが大量発生。
プログラマを糾弾するが、実際は仕様を説明する文章のあいまいさや
機能の記述漏れが原因で。。。
というのを何度も見ています。
プログラマのアウトプットであるプログラムの動作には厳しいのに、
設計者のアウトプットである設計書はスルーされていることが多いです。
プログラマのインプットは設計書。
設計書を超えるレベルのアウトプットは出ようがないです。
□仕様について質問をすると、どんどん仕様を追加されるが工数は追加されない
これをやられてしまうと、プログラマはきついです。
実際、もう質問しなくなる人もいました。
もちろん、後のテスト工程で結局発覚して右往左往するのですが。。。
レビューを実施しないこととも関係していると思います。
設計者同士で設計書を読みあってお互いの不備を見つけていかないと。
後工程に進めば進むほど、修正のコストはかかると教科書にも書いてあります。
