オラ、焼け野原しんのすけだゾ！ その１ 基本設計＝画面「のみ」設計？

「『燃えない』ゴミの収集日、何でよりにもよって火曜日やねん！」
～ by 千原ジュニア at 人志松本のゆるせない話

あー疲れた。かねてから述べていたプチ炎上プロジェクトがようやく鎮火した（まだ燻ってはいるが）。これでやっと開発フェーズは完了となった。

さて、プロジェクトが一段落ついたら、KPT方式などでふりかえりを行い、仕事をカイゼンしていくといった活動を普通は行うものなのだが…うちの会社はさにあらず。正確に言うと、その文化は全く無いわけではないのだが、弱い。実際、今回のプロジェクトでは実施されていない。プロジェクトが炎上したにもかかわらず、である。プロジェクトが大成功したわけでもないのに、である（てか、成功したとしても必要だ）。

今回のプロジェクトの炎上原因は、見積もりが甘かったとか要件肥大化したなど、よくありがちな要因によるところもあるのだが、最大の原因は、そもそも仕事の進め方・考え方が根本的に間違っていたことである気がしてならない。いや、「気がする」ではなく「間違っている」と断言できる自信はある。
しかし前述の通りふりかえりは行われず。そして（あまり言いたくないけど）周りは殆ど職業プログラマばかりで、議論をして進言して現状を変えていこうという気概のある者がいない…

というわけで、自ブログにて1人でひっそりとふりかえりを行うことにした。
問題の雲散霧消を防ぐためにも、そして自分の考えが本当に正しいかどうかを記録に残しておくためにも。そのうち@IT会議室とかに投稿して、集合知の意見を聞いてみようと思う。

• Problem1：基本設計＝画面「のみ」設計であるという認識
• Problem2：メンバーの成長のために仕事を任せるのは良いが、その仕事に必要な準備・情報が全然足りていない。
  
• Problem3：そんな状態なので、当然いろいろと意見を述べた所、マネージャーは「（悪い意味での）思ってた通りの反応だ！」「もう知らん！」ってな具合になったらしい。
• Problem4：では一体何がいけなかったのか、どう進めていくべきだったのかなどの、フォロー・フィードバックが結局無い。
  ※3の件は、マネージャと同じフロアで仕事していた人から、プロジェクト完了『1ヶ月後』に聞いた。

私が参画したのは詳細設計フェーズから。詳細設計を行うにあたり渡された資料は、画面イメージHTML『のみ』。入出力項目定義や業務フローの資料は一切無い。ER図は一応あったものの、テーブル・フィールド・リレーションどれをとっても明らかに不足しており、明らかに未完成だ。
料理を作るのに、完成図だけ見せて「これ作って」と言われても、何を望んでいるかが分からなければ、お口に合うものなど作れるわけがない。お客さんはどんな料理を欲しているのか、どんな材料を使うのか、そういう情報が必要だ。

基本設計書の有無・DB設計の状況をマネージャーに確認したところ、彼はこう言い切った。
「基本設計工程では、画面『のみ』を設計する。業務フローなどは詳細設計フェーズで行うことだ。」
「テーブル設計も詳細設計と並行して行う」
いやいや、その認識、絶対間違ってると思うんですけど！？
…まあ、よかろう。認識間違いはとりあえず置いておくとして、要は我々に『一般的な意味』での『基本設計』をさせようということですね？ それならそれで問題が多々あります。マネージャー・リーダー陣は「この進め方で問題あるなら伝えてください」と言っているので、以下のような事を伝えた。

• 今回実現する要件を纏めた資料が見つからない。今ある要件定義書は、元々の肥大化しすぎた状態のまま。これでは、我々は結局どういったものを作ればよいかが分からない。
  ※今回のプロジェクトは、元々大手ベンダーが要件定義を行なっていたが、肥大化しすぎて見積金額が膨大となりお客さんが怒ってしまったので、（単価の安い）私の会社が引き継ぎ、要件は取捨選択することとなった。
• 機能毎（詳細設計の単位）で各人がDB設計を行うやり方だと、DB定義に矛盾や重複などが発生する可能性大。
  また、重要度が低い機能は、他の機能の製造・テスト完了後に詳細設計を行う予定となっている。これでは低重要度機能の詳細設計時、その機能の都合でDB定義が変更される可能性があり、もし発生した場合、当然影響範囲の機能の手戻り修正が発生する。これは凄く非効率。
  せめて『DB設計』というサブフェーズを設け、そこで一斉に行うべき。
• そもそも工数が足りていない。『基本設計』も行わせるのなら、それ用の工数も盛り込んでおいてもらわないと困る。

で、マネージャー陣からの回答。

• 「元々の要件定義書から自分で考えること。不明点は質問してくれれば対応する。」
• 「DB定義に関しては、矛盾が生じないように、ちゃんと開発者間で話し合うこと」

…うーん、やっぱり何か違うと思うが。 時間が潤沢にあるなら、もちろん勉強になるので全然こんなやり方でも良いのだが。 てか、やっぱり工数に関しては何にも無しか。

そういうわけで、進め方に関していろいろと意見を述べてたら、前述のProblem3発生ですよ。プロジェクト中は全く知る由も無かったけど。

また要件に関しては、「要件に関しての不明点は質問しろ」と言っているので、（もちろん、ちゃんと考える事を行った上で）遠慮無く質問投げていると、いつしか
「詳細設計レビューでまとめて回答する」
との流れに。いやいや、詳細設計行うのに必要な情報を尋ねているのに、回答が詳細設計完了後に行う工程て… 結果、詳細設計レビューは、（マネージャー陣に対する）要件の確認から始まったため、殆どの機能で1人日を超える工数を消費。そしてそれだけ時間をかけてレビューを行っても、要件漏れ多発。これまたマネージャー陣の『頭の中』にしか無かったもの大半。特にエラーチェック。どういう場合にエラーにするかなんて、要件定義書も概要設計書も無く、お客さんと遣り取りする権限も無いのに、分かるかっ！！
またDB設計も案の定、フェーズ後半で詳細設計着手した機能の都合でそれまでのDB定義が変更され、テスト完了済みの機能で手戻り発生…

＊

このマネージャー、今までもずっとこんなやり方をしてきたのだろうか。だとすれば、よく今までやってこれたなと、逆の意味で感心した次第である。 僕の認識では、以下の設計は基本設計工程で行うものだと思っている。

• 業務フロー作成
• 画面設計（入出力項目定義、画面遷移）
• DB設計

分かり切ってはいるものの一応ネット等で改めて調べてみたところ、僕の認識は間違ってはないと思う。V字モデルでは、総合テストは基本設計と対応するとされているし。これに準じた場合、うちの会社の定義の基本設計だと、総合テストのテストケースは画面レイアウトの確認だけとなってしまう。そんなバカな話があるか。

＊

さて、では上記Problemを解決するためにTryしなければならないことは一体何なのか。

• Try1：システム開発に関して勉強し直してください。もうホントに根本的に間違ってるから。
• Try2：必要な情報を準備してくださいとしか言いようがありません。
  錬金術師をもってしても、『無』から『有』を作り出すことはできません。
  
• Try3：
  Try4：
  何故『見限る』ということになるのか、およそ管理職らしからぬ行動は全く理解できません。我々に不備があったのならば、それを指摘・叱責するなどしてフィードバックしてくださいよ。
  これでは、我々も会社も成長できませんよ。
  

＊

↓大人が観ても面白いと、松本・高須がラジオで絶賛してた作品