大手電機メーカーに就職しものづくり実習を終えた2年目の私

その後のCOBOLのWEBアプリケーションという変な仕事で泣かされた後(その際の記事:COBOLを使ってWEBアプリケーションを開発)、パッケージを適応するプロジェクトに参画しました。

教育系パッケージソフトの導入概要

このプロジェクトは導入期間;6か月、工数換算ではベンダー分を含めて30人月くらいです。

パッケージにしてはやや大きいかと思いますが、かなりのアドオンと外部連携機能の開発をしているのでこのような数値になりました。

このプロジェクトは、自身が主担当となり動いた初めての案件であり、多くの事柄を学べました。

結論から先に言うと、

  1. 各工程で実施するべきこと
  2. 残すべき成果物
  3. スケジュール調整
  4. 懸案事項の処理
  5. システムの品質確保

このあたりについて、実際に失敗を重ねながらノウハウを吸収していきました。

お恥ずかしい話ですが、トラブルが発生し、プレッシャーから初めて嘔吐したのもこのプロジェクトです。

この仕事は、教育システムの構築であり、企画・予算取りが終了した要件定義から参画しました。

適応したパッケージはリシテアという日立ソリューションズ(この際は、日立システムアンドサービス)のものであり、他に海外ベンダーの人事ソフトウェアやSAPとフィット&ギャップをやっています。

 

プロジェクト計画

まずは「プロジェクト計画」について述べます。

企画工程でやりたいことは大体決まっていたので、

  1. 業務のヒアリング
  2. 取り扱うデータ、及び量の確認
  3. アドオンの必要性検討

が、メイン作業となりました。

 

最初の頃は会議に参加し、話を聞いているだけであまり意識をしていなかったのですが、今振り返ってみるとユーザから要件を引き出すベンダーのやり方がとても参考になりました。

ヒアリング⇒提案⇒合意形成

仕事の基本的な流れはこれだけです。

ただ、これをうまくやるには、業務知識、プロジェクト経験、コミュニケーションや管理の能力など様々な素養、そして何よりそれを維持していくための絶え間ない努力が必要です。

当時は何となく参加して見ているだけですが、ベンダーがどのように会話し議事録を作り、プロジェクトを回していたかを目で見て学ぶことができた貴重な経験でした。

 

要件定義

教育系パッケージソフトの導入はプロジェクト計画を1ケ月程で終え、要件定義フェイズに入りました。

実際には、課長が裏で値切り交渉や予算調整をしていたとても重要なフェイズがあるのですが、当時の私はこの部分には関与させてもらえませんでした。後日製薬会社に入社し、このあたりの交渉を行うようになりましたが、この時もっとよく見ておくべきだったと後悔しています。

 

要件定義の内容

主な作業は、業務フローを作成しどのような業務を実際に行っているか確認を取りながら、必要な機能を画面レベルで洗い出していきます。

今回はパッケージ適応なので、

「この要件ならこれが使えますね。」

「これはちょっと無理があるのでアドオンが必要ですね。」

といった調整がメインとなります。

教育系システムといってもデータマートみたいなものなので、凝った機能はほぼ不要で、すんなりと話が進んでいきました。

多少、実業務とマッチングしない部分がありましたが、そこはBPRの名の下に見直しを行ってもらい、費用を抑えつつ具体化していきました。

大体はこのフェイズで工数を消費し進捗に遅れが生じるので、個人的にはプロジェクトの難易度を示す最大指標は「要件の複雑さ」にあると思っています。逆にここが容易だと、その案件はすんなりと事が進みます。

 

要件定義で考慮すべきリスク

後々になって露見しますが、このプロジェクトでは組織変更対応・人員情報との連携が大きなネックになりました。

恐らくは、要件定義できっちり議論しておくべき内容なのですが、小規模システムということで上司も甘く見ていた、私も経験値がなかったこともあり、実際に火を噴くまで問題の大きさに気づきませんでした。どんなシステム開発でも、この部分がほぼ課題として挙がってきます。

 

この時の知見を基に要件定義で考えるべきものを纏めますと、以下のような内容をキチッと固めることがコツかと思います。

  1. 業務フローを作成し要件をできるだけ洗い出す(全ては無理でしょう。必ず、後で何かが出てきます)
  2. 必要な機能を具体化する
  3. データボリュームを議論する
  4. 組織変更対応について検討する
  5. 利用者の登録方法・権限を定義する

 

基本設計

要件定義にて機能レベルまで要件を引き出した後は、実際にどのような画面を作るかを議論・設計していきます。

 

基本設計の流れ

バッチ系の場合は、どのような処理内容が必要かジョブネットレベルで考えます。

オンライン系の場合は、1機能毎に幾つ画面が必要か、どのような遷移をするかを固めていきます。バッチ系の場合は、ジョブネットレベルでデータの流れを書き、ジョブネット毎に幾つ処理が必要となるか、洗い出していきます。

両者は「データを表示・処理する」という点では同一なので、いずれにせよユーザが入力する、若しくは外部から提供されるデータの定義を固め、具体的にどのような値が入ってくるかも議論・決定した上で、定義書を作成します。その後、定義されたデータをプログラム上でどのように表示・処理するかを考えて設計を進めます。

大体は、「このデータはどこから取るのか?」という点で悩むことがほとんどです。

ユーザの入力が必要な場合は、本当にその処理を業務として行ってくれるのか、外部連携する場合は意図したデータが希望する頻度、質で貰えるのかが課題です。

想定が覆されてしまうと、もはやシステムとして機能しなくなるため、この部分は議事録、書面などで徹底的に合意させ責任の所在を明確化しておく必要があります。ちゃんとやると、大体1画面につき、設計から導入までに3人月くらいかかるものです。

 

データ定義の重要性

以上の事から、設計はデータ定義ありきと言えます。

反対に言うと、データ定義さえできてしまえばやるべき事は8割方終わったようなものなので、あとは粛々と設計を進めるだけです。…

とあっさりと書いてますが、要件の複雑度が高い場合には一筋縄にはいきません。難しいプロジェクトでは、大体本工程にて炎上し、残業200時間オーバーなどの過酷な現場へと早変わりです。

今回のプロジェクトの場合は、画面系のアドオンをベンダーが、バッチ系の開発(外部連携)を自社にて実施しました。後者は自社と言ってますが、結局私が全部作りました。

「このデータはここから取れるだろう」

と要件定義時から随時検討していたため、データの連携先はすんなりと見つかり、データ定義自体は簡単に実施できました。その後の、プログラム本数の見積も容易に進み、まあこんなものかと思いながら設計を終えました。

 

基本設計で気を付けるポイント

実は、ここでデータの中身について具体的に吟味していなかったことが後々問題となりました。

基本設計では、実際に中身に目を通し、本当に意図した形式になっているか確認が必要です。例えば、定義書では10桁となっているのに、20桁のデータが入っていたり、書式が全く異なるもの(体重のフィールドに身長が入っていたりするなど)が平然と入っていたりします。

そのようなものについては、データクレンジングやプログラム処理の工夫で対応しますが、前者はそのための工数確保、後者はプログラム本数の見積変更が必要となります。コンマによるデータ溢れなどの問題まで議論する必要があるかどうかは疑問ですが、考えうるリスクはできるだけ洗い出しましょう。

基本設計まとめ

纏めますと、以下程度のことは必ずやるべきかと思います。

  1. データ定義を確定する
  2. 必要な画面・プログラム数を見積もる
  3. データの中身を吟味する(リスク対策)

詳細設計・開発・単体テスト

教育系パッケージソフトの導入は詳細設計・開発・単体テストに入りました。

これらの工程は基本的には同一人物が行うべきだと考えていますので纏めてしまいました。

また、場合によっては、基本設計と詳細設計の間に機能設計と言うフェイズを挟むことがあります。

 

詳細設計の流れ

詳細設計では、基本設計にて落とし込んだ要件をプログラム処理レベルに落とし込みます。イメージとしては、詳細設計書を読み全く同じ通りに作ったものがプログラムになるという感じです。

このフェイズの手間は、基本設計書がどれだけしっかりしているかに左右されます。
というのも、プロジェクトの方針や設計者のマメさにもよりますが、基本設計書がざっくりしており、それなりに行間を読み取らなければいけない場合があります。反対に、基本設計書が細かく書かれていると、ほとんど丸写しした上でプログラム開発に入れてしまいます。

個人的には、詳細設計とコーディングは今後海外にシフトしていくと考えているため、その直前の基本設計書は読み違えることのないレベルまで仕上げておくことが理想化と思います。基本設計が手抜きだと、成果物をレビューした際にとんでもないものが出来上がっており、検収不可能な状態になることも考えられます。

今回のプロジェクトでは、基本設計を細かく行っていたため、設計書自体はあっさり終了しました。続いての開発作業もバッチ系なのでこれまたあっさり終了しました。

…ところが、問題は単体テストにて発覚しました。

 

単体テストの流れ

単体テストでは、実際に連系する予定のデータをテストデータとして利用したのですが、ここで想定していない書式のデータが混在していたため、意図通りに変換がなされなかったり、想定外の動きをしてアベンドするなど、データの中身に起因する問題が多発しました。

内容を見てみると、クレンジングで何とかなるレベルではなかったため、結局プログラム側にて色々と処理をするよう改修するはめになりました。ここでも手戻りがかなり大きく、

 基本設計書の修正⇒レビュー⇒詳細設計書の修正⇒レビュー⇒開発

という手順を再度繰り返すこととなりました。

品質に厳しい会社だったため、手を抜くわけにはいかず、かなり必死になりながら作業を続けました。残業で吸収したので、工程上は遅れがないように見えますが、終電近くまで残る日々が続き、あまりに悲壮すぎたので原因不明の病気を患うなど精神的なダメージはかなり大きかったです。

テストでは、境界値・型チェック以外にもC0・C1メジャーの網羅がポイントとなります。

プロジェクトの予算にもよりますが、C1メジャーは100%、C0メジャーも80、90%などできるだけ高い値となることを目標にすると良いでしょう。

どこまでテストするかはプロジェクト内でPMが決めることが多いため、指示に従って淡々と進めることになります。概して地味な作業です。

 

ユーザテスト

教育系パッケージソフトの導入はユーザテストに入りました。

ユーザテストの流れ

このフェイズではユーザに実際にシステムを操作をしてもらい、業務要件を満たしているかを確認してもらいます。ベンダーによって多少呼び方が異なり、総合テストがこのフェイズの位置づけになっていることもありますし、ビジネステストと言うような場合もあります。

この段階では、システム的な不具合はほぼ解消されており、プログラムの品質が担保できていることが大前提です。ユーザにはあくまでも「業務要件を満たしているか」といった観点から、確認をお願いします。
ただし、あまりにも炎上しているプロジェクトだと、この時点で品質が全く追いついていないこともあり、お話にならない程バグが発覚することもあります。問題外の話ですが、意外と多くの現場でこのような状況になっているのが、日本のシステム開発の現場です。

 

意外なトラブル

今回の場合はパッケージ適用だったため、致命的な問題はほとんど発覚しませんでした。
軽微なバグが2点、仕様の誤認による設計不良が1点であり、いずれも既定の期間内で修正することができました。

しかし、問題はデータの方で発生しました。
今回は多くの外部連携を行っていたのですが、実際に連系されたデータを詳しく見ると、以下のような問題が発生しました。

  1. 想定していたデータフォーマットで送られてこない
  2. 区分などの項目に想定外のものが入っている
  3. 重複したデータが存在する
  4. 値の持ち方が想定外でありパッケージ側でエラーが起こる

いずれも、システム屋を長くやっていれば定番のネタなのですが、あまりに大量の問題が同タイミングで発覚したため、現場(私)は火の車となりました。
今回のプロジェクトでは、サンプルデータをある程度事前に受領しており、そちらを見たところでは特に問題がなかったのですが、大量データを入手してみると、その中に上記のような問題を引き起こすものが含まれていました。

データ確認作業は本来もっと早い段階で実施しておくべきだったのですが、初心者だったこともありユーザテストの前後で行ったため、最終局面になって慌てることとなったのです。
データパターンの確認、変換プログラムの修正、クレンジング対応などの対応を必死で行いました。何とか納期には間に合ったものの、レビューやダブルチェックが手薄になり、システムのカットオーバ―後に移行漏れが発覚することがありました。

ちなみに、データの問題が発生した場合、パッケージ側かバッチ側のいずれかのプログラムを修正して対応させることが考えられます。
パッケージソフトの場合、テーブル定義などや内部処理を変更しようとすると、オプションとして纏まった費用を取られることが一般的ですので、大体の場合はバッチ側で対応します。

今回は、余分な費用を甘く見ていたプロジェクトでしたが、意外なところで失敗をし、深く反省すると共に、大変多くの事を学ぶことができました。

パッケージ適用のポイント、それは

移行データの早い段階での精査

これに尽きます。

稼働後フォロー

教育系パッケージソフトのカットオーバ直後から、稼働後フォローフェイズに入ります。

厳密には、このような工程は定義されていないのですが、システム稼働直後は必ずトラブルが起こるので、即座に対応できるよう、人員とスケジュールを調整しておきます。
期間はシステムの規模にもよりますが、1週間~1ケ月程度で良いと思います。その後は、通常の保守運用体制の中でカバーしていくこととなります。

システムの規模にも依りますが、大規模システムの場合は稼働直後からバグの数がうなぎ上りになります。私がこれまで参画した数億オーダーのプロジェクトですと、大体数百個以上のバグが発覚しております。

今回の教育系パッケージソフトの場合は、仕組みが単純だったのでWEBの操作面でのバグは発生しませんでした。問題となったのは私が担当したデータ部分の方で、連携されたデータに想定外のものが混じっており、それがうまく変換されずにシステム内に入ってしまった、というケースが多かったです。

対策は、「SQLを実行して修正」といきたいところだったのですが、たまたま本システムは監査対象サーバーに導入してしまい、安易にSQLが実行できない環境でした。そこで、手順書やバッチ実行形式のSQLファイルを都度作成し、運用部隊に説明した上で実施してもらう、といったひじょうに手間のかかる手順で修正していきました。

 

プロジェクトから学んだこと

1.前工程の重要性

ここで学んだこととして、開発工程の際にきちんと問題を発見し対応しておけばそれほど手間なく片付いたことが、後工程になるほど何倍もの工数を要してしまうということでした。また、リリース後にトラブルを起こすと、ユーザからの信頼度が大きく下がってしまうため、商売の面からもあまり好ましくありません。

きちんとした手順でプロジェクトを進め、良い品質で納品する。
これこそが、あるべき姿であり、お客さんから強い信頼を得ることができます。

当たり前の事ですが、これが出来るようになるには相当の経験・スキルが必要となってきます。

私が思う優秀なSEとは、経験に裏付けされたスキルとお客様目線で動き信頼を勝ち取ることができる人を指すと考えています。

辛いうえに報われる事の少ない仕事ですが、上記の事項を習得できるよう腐らずに努力し続けることが鍵です。

 

2.稼働後の打ち上げは大事

教育系パッケージソフトの導入後、色々とユーザからクレームを受け謝りながらも何とか安定稼働にこぎつけました。

この段階になると、1つやっておいた方が良いことがあります。
それは、ユーザさんとの飲み会(打ち上げ)です。

「当たり前だ」という方は経験が豊富な方かと思います。
ベンダー側が主催することもありますが、間に入っているIT部門が音頭を取ってやるのが良いかと思います。

飲み会では、IT部門とユーザさん、できればベンダーさんにも参加頂き、杯を乾かしましょう。
この席で、ユーザさんから労いの言葉の1つでも頂ければ、苦労も報われるというものです。また、反対に今回受注案件を頂いたこと、導入に際しては多大なご支援を頂いたことに感謝しておきましょう。

 

3.お客さんとの関係の作り方

システム導入にはトラブルは付き物ですが、事情を知らないユーザの立場では、

「お金払ってるんだから、もっとうまくやってくれよ」

と不満に思うことが多いです。

そのような状況ですと、表面には出さなくても、

「次回はもう頼まないでおこう」

といった気持ちになっていることもあります。

そこで、この席でお礼を述べると共に、自分達の苦労話もさりげなく伝えておきましょう。
こうやって、システム開発の内情を理解して頂くことが、次回以降のプロジェクトで仕事を進めやすくなる秘訣になります。

一番良くないことは、システムの導入に際して思いのすれ違いが起こり、以後のやり取りが疎遠になってしまうことです。

 

まとめ

システム導入では、システムを作ることも大事ですが、本当に大切なのは「人間関係を作ることです。」
どんなに優れた技術を持っていても活かす機会がなければ意味がありません。

「最後は結局 人」

という言葉がありますが、本当にその通りだと思います。