この記事は前回からの続きです。
自分が何をやるべきなのかもよくわからないまま、1週間が過ぎて全体の進捗会議で、担当しているタスクの進捗が０％なのに、50％とか適当なことをいって、それがK社のエライ人にバレて大目玉をくらい、担当を外され、自社メンバーの雑用係になった。
雑用といっても、みなさん各々のタスクに没頭して取り組んでいるので、ボクの手を借りるようなこともそんなになさそうでした。やっていたのは、資料の整理とか、ドキュメントの印刷ぐらいかな。
他のメンバーや上司のAさんには申し訳ないが、正直、気がラクになっていた。正気に戻った感じすらあった。
そこで、今回の案件がそもそもどういったものなのか、全体像を自分で調べてみる気になり、課長やAさんに、
全体像が分かるような資料があれば見せてください
とお願いしたところ、課長から分厚いキングファイルが数冊渡された。
課長からは「そんなもんみてどうするんだ？」みたいなことを言われた。
このシステムが一体なんなのかを知って、自分なりにまとめてみようと思っただけのことなのだけど、課長も他のメンツも全体像に興味はなさそうだった。
さっそく、資料をじっくりと見て見ると、、、、
冒頭に、この開発案件の目的と内容がちゃんと書いてある！
このとき、はじめて、やっていることの全体像がわかった。
それは、ある基幹システムのシステムリニューアルであった。開発規模はめちゃくちゃでかい。日本国内の大手のITベンダーがすべて参画しているような超巨大プロジェクトであった。
ハードに関しても、汎用機から端末まですべてリニューアル。ソフトウェアも当然のことながら全てリニューアル。かなりのおおがかりなプロジェクトだ。発注元は官。全体を統括しているのは、情報サービス企業としては日本最大のN社。
ソフトウェアはユニットA、B、C、D・・・と分けられていて、ボクらがいた部屋は最大ユニットAであった。
このユニットAの開発に、請負った会社が先ほどのN社とは別のN社でその下請けにさらに4社ほど。その1社であるK社のさらに下請けにうちの会社がいることもわかった。総勢500人ほどが関わっていることもわかった。
開発期間は最終的には5年ぐらい。そのときは第１フェーズの2年目でその終わりの頃で、ユニットA全体が遅延しているようだった。
これで、全体像がわかり、デカイ部屋にいるここの人たちが何をやろうとしているか、漠然だがわかった。
さらに、資料を読み進めていくと、K社が担当ていいるのが、ユニットAの中でも、ユーザーの情報変更や、お金の返金に関わるシステムであったので、かなり念入りにシステムが構成されてることもわかった。
そのキングファイルの中には「要件定義書」「基本設計書」があり、これがわかりやすかった。そこからさらに、「詳細設計書」を読んで、より詳細がみえてきた。最後の方に「プログラム設計書」があって、これが一番分量が多かった。
どうやら、資料には読むべき順番みたいなものがあって、
要件定義書
↓
基本設計書
↓
詳細設計書
↓
プログラム設計書
と、こういう順番で読んでいくことでボクにも理解できた。
システムの開発工程では当然の知識だけど、その時のボクはこういうことは全く知らず、このときはじめて知った。
これで、頭の中がかなりクリアになった。はじめっから、これを説明してほしかったなーっと思いつつ、自分なりにわかるようにノートにまとめ、それをまたExcelにして全体図を書いて整理した。
そして、続けて読んでいくと、、、、
なんと！！！ボクが担当していた「じゅうへん・かごのう・・・」を説明している基本設計書があったのだ！
それを読んで、何をするシステムかもわかった。じゅうへんは「住所変更」、かごのうは「過誤納：間違って多く納付されたときの処理」であった。
やっと、「プログラム設計書」にたどり着き、ソースレベルの一歩手前まで近づけた。
だいたい、1週間ほどかけて、K社が関わっている、詳細設計書レベルまでは読み込んで、うちの社が担当しているモジュールの「プログラム設計書」はすべて目を通した。
つづく。
