システム随想 – 〈第 8 回〉 いそがば廻れシステム開発


システム随想

執筆:代表取締役社長 佐藤

〈第 8 回〉 いそがば廻れシステム開発

プログラマとして 5 年間、プログラミングや設計に従事してきたシステム開発部 P 君は、「K 社勤務実績管理システム」の開発プロジェクトに参加することとなった。システムは社の企画部門主導で要件定義、外部設計を終えており P 君は内部設計からのものづくり中心の作業となる。

外部設計書によればシステムは 3 つのサブシステムに大別でき、組織上の上司である S 次長をリーダに P 君および協力会社である L 社、 M 社とで内部設計以降、結合テストまで分担することになっている。総合 / 運用テストは再び企画部門とユーザが参加して実施し最終検収へと進む手はずである。

社は今、大規模プロジェクトを抱え技術者がフル稼動している関係で、P 君が内部設計に従事できる唯一のプロパー技術者である。ユーザとの仕様の詰め、機能分割、データ設計さらに進捗工程管理など P 君が中心となって作業を進めなければならない。プロジェクトリーダーは S 次長であるが、他にトラブルジョブもあり多忙このうえもない。

本システムにおける、サブシステム単位の作業分担表を下記に示す。

サブシステム 機 能 担 当
基本情報管理 労働条件、社員情報、給与条件などの入力、変更など。 協力会社 L 社
勤務実績管理 日々の勤務時間の入力、修正、休暇取得管理。 P 君
集計管理 日時集計、給与計算、各種帳票の出力。 協力会社 M 社

<内部設計〜結合テストの開発分担表>

内部設計着手から 1 ヶ月経過したが、どうも進捗が芳しくない。華々しく動いている大規模プロジェクトや火事場で目の色を変えているトラブルジョブに押され気味で、このプロジェクト全体のモチベーションもいまいちである。

P 君および L 社、 M 社のリーダで週 1 回の定例ミーティングを実施し、進捗報告、問題点の検討、決定事項などについて話し合っている。しかしおのおのシステムのとらえ方のアンバランスが否めない上に、メンバーおのおのが初顔合せによる共同作業ということもあって遠慮もあり意思の疎通もしっくりしない。メンバーの危機意識の希薄さも問題である。

このままではトラブルジョブになることを憂慮した P 君は、リーダ S 次長への報告の中で次のような意見書を具体的な事例をあげて提示し解決策を相談した。

S 次長殿
「K 社勤務実績管理システム」設計上の問題点について

199x.1.17 P


メンバー全員ベストを尽くすも、以下の状況下にあり仕様確定、進捗に不安が否めません。
早急の対処が必要と思います。御検討をお願いします。

(1) システムイメージが統一されていない。
担当分については理解するも、担当外はほとんど知らない。知ろうとしない。

(2) 画面 / 帳票などヒューマンインタフェース部分に統一性がなく、運用のとらえ方もちぐはぐである。

(3) サブシステム間のインターフェースとして重要となるデータ設計 ( 編成方法、レコード構成 ) が
システム全体的な見地から進められていない。従って性能、効率上の問題の発生が憂慮される。

(4) 障害発生時の検知、通知、回復などの信頼性対策への配慮が希薄と思われる。


( 以上 )

S 次長は、大きなトラブルジョブを抱えたのだが対応は早かった。今まさに悪戦苦闘している現行のトラブルジョブの原因が SE 間のシステム認識のずれからくる設計ミスであったこともあり、 P 君の意見に大きな危機を感じた。

早速 S 次長は、社の研修所での 4 泊 5 日の集中合宿による外部設計書ベースでのシステム認識のレベル合せ、設計フォローを迅速に実施した。当然ユーザや企画部門も強制参加である。

集中フォローの日程は次のとおりである。

日程 内 容 参加メンバー
1 日目 外部設計書からの機能ベースの全体を把握 S 次長、P 君、L 社、
M 社、企画部 SE
2 日目 入出力イメージ、ファイルイメージの確立 S、 P、 L 社、
M 社
3 日目 運用の点からのヒューマンインターフェースイメージの確立 S、P、L 社、
M 社
4 日目 エンドユーザとの課題の解決、確認 S、P、L 社、M 社、
ユーザ、企画部 SE
5 日目 現在までの内部設計成果の確認と評価、手直し、方針の確立 S、P、L 社、
M 社

この合宿の成果は大きかった。システムに対するとらえ方、価値観が同一レベルとなったばかりでなく、メンバー相互がよく知り合えたうえに信頼感も生まれた。外部設計の担当 SE 、ユーザ担当者とともに内部設計を意識しながら外部設計書を徹底解読したことにより、内容のミス、記入もれが副次的に発見できたことも大きい。その段階では遠回りをすることになったが、結果的には何らトラブルを生むことなくシステムが完成し、無事 K 社に納品することができた。

事前に危機を察知し、対策のための効果的な意見を答申した P 君への社の評価は高まり、さらに P 君、S 次長への協力会社 L 社、 M 社からの信頼は絶大となった。

問題点と解決策

  1. 共同設計作業における SE メンバーのシステムイメージのレベル合せと設計方針の確立
    1. 集中的に同一土俵で外部設計をレビューする。
    2. インターフェース、運用を中心とした設計規約、標準を決める。
  2. 外部設計書には意味不明、矛盾、抜けがある
    1. 外部設計書はそのまま信じない。
    2. 外部設計 SE 1 名以上は継続参加させる。

今回のプロジェクトで大きく成長した P 君は外部設計書をどう読みこなすかを内部設計と対比させたテクニカルメモを作成した。

今回特別に P 君から公開の承諾を得ることができたので下記に示す。読者は運がいい・・・。