内部設計・開発・結合テストまで進んでくると、受注側の請負作業に入ってきます。
よって、それこそお任せで大丈夫と思いたいところです。
ところが一定規模のプロジェクトになってくると、進捗状況だけを確認するわけにはいきません。
というのは、課題・問題が発生した際に、前工程での問題に起因することが多いからです。
前工程ということは、発注側が関与して決定してきた部分が多いため、その意思決定に誤りがあることもありますし、想定外の変更も発生します。
よって、発注側としても当初目的を果たして進んでいるかを注視して確認していくことは重要となります。
内部設計・開発・結合テストでのタスク
内部設計からは、ソフトウェアレベルの対応となりますので、発注側としては状況の確認が基本です。
内部設計により詳細化されたソフトウェアの設計は、作成されるプログラムと紐づけられ、タスクとしては見えやすくなるものです。
内部設計のタスク
外部設計から内部の作り方になってきますので、発注側からすると意味が分からないことが多いです。
ただし外部設計の機能に対して、より詳細化した仕様を決めていくことになるので、成果物数は把握できることになります。
数でボリュームは把握できるものの、特に注意したいのは、より複雑で重要な機能についての設計です。
そのような機能ほど、ビジネス上も拘りがあり、重要な箇所ですので、確実に仕様化されているかも含めて、進んでいるかを確認したいところです。
開発のタスク
開発の段階になるとプログラムや最小機能単位になりますので、タスクという意味では明確かもしれません。
最小単位での、設計、開発、テストという一連のタスク群となります。
ただし、難易度は異なるものになりますので、単純に1本と考えても見た目より進捗が余裕だったり、深刻だったりすることがあります。
結合テストのタスク
結合テストを行うにあたっては、テスト計画、テスト仕様、テスト実施、テスト結果評価という段取りとなります。
テスト計画とテスト仕様の違いは、テスト計画はどのような機能の括りで、どういう環境条件などで、どのようなスケジュールや体制などの計画で実施するかという内容になります。
テスト仕様は、計画で定めた範囲を具体的にテストデータやテストケースを決めるものです。その仕様に従ってテストを実施します。
内部設計・開発・結合テストでのタスクの順序
タスクを把握できたとしてもタスクの順序は設計、開発、テストといった順序になるとは限りません。
個々の機能を見れば順序が保たれていなければなりませんが、全体的には、ある機能はテストまで完了していて、ある別な機能は設計までしか完了していないということもあります。
つまり、すべての設計が終わってから開発し、すべての開発が終わってからテストするということではないということです。
また、結合テストは開発レベルのテストが完了していないとできないものではありますが、タスクとしての順序はその限りではありません。
というのは、結合テストを実施する単位はあるつながりのある複数の機能単位になります。よって関係ない機能群は進捗が異なっていても問題ありません。
また、結合テストを分解すると、計画、仕様、実施、評価となりますので、それらの詳細タスク単位に実施時期は調整されます。
結合テスト計画は、全体の計画となりますので、遅れるとすべてに影響してしまいます。また内部設計ができていれば基本的には計画できるものです。よって開発中に並行して実施されることのほうが普通です。
IT導入・システム開発での内部設計・開発・結合テストのマネジメント方法
内部設計・開発・結合テストの進捗マネジメント
設計が完了した段階で成果物の数が決まっていますし、そのためのタスク（ＷＢＳ）も決まっているかと思います。
進捗はできるだけ定量的に、定期的に捉えて、問題があれば原因を探り、対策を打つ必要があります。
発注先であるベンダーに提出を求め、確認するようにします。
進捗と言っても、品質を伴っていないと意味がありませんので、品質は次に説明します。
内部設計・開発・結合テストの品質マネジメント
設計においては、レビュー回数やレビュー時間といったもので指標が作成されることがあります。
予定されたレビューの実施状況にて、完了したという進捗だけなく、しかるべきレビューを実施の上完了しているか、もしくは仕掛中かを確認します。
開発、テストにおいては、テストケース設定密度、バグ密度といった指標があります。
1本1本は完了しないとわかりませんが、完了時点でテストにおける品質が適切かを確認していきます。
内部設計・開発・結合テストの課題状況マネジメント
内部設計・開発・結合テストにおいては受注側のベンダーでの請負タスクであるため、発注側は発注したものが進捗しているかの確認が中心となります。
ただし、すんなり進むことは少なく、課題が発生していることが多いです。
しかもここで課題が残っていると、既に作り始めているため、影響が大きいです。
課題は前工程と同じように、課題の発生状況と消化状況の数とトレンドを押さえます。
通常はこの時点では収束していることが望ましいです。とはいっても、すべてが完璧に進むことのほうが珍しいため、課題はあるはずです。
課題があまりにも多ければ、根本原因を考えないといけないかもしれません。目的への合致度からみて問題があるのであれば、手戻りも覚悟の必要があります。
内部設計・開発・結合テスト手戻り分再計画
課題が多かったり、解決していない課題が影響の大きいものだったりする場合は、手戻りという判断をすることもあります。
手戻りについては、度合によって対応が異なります。
課題が多すぎる場合は、前工程に問題があるかもしれません。前工程のいずれかの段階からやり直すことになります。
課題は少ないが、影響が大きい課題がある場合は、一部テーマが先送りになってしまった影響が考えられます。
そのテーマの解決が遅れた原因によっては、最悪のシナリオも考えられます。影響が大きいがゆえに、検討が進められなかった結果だとしたら、最悪メイン機能が動かない、すなわち限りなく失敗確定に近いという状態となります。
ここまで影響が大きいケースは少ないとは思いますが、大きな課題が残っていないかは注意すべきです。
課題が少なく、影響が局所的の場合は、その部分を手戻りすることなります。
IT導入・システム開発での内部設計・開発・結合テストにおけるありがちな問題
仕様が重要であるのはわかるが、理解できず、結果間違った仕様となる
当工程は仕様を決定し作り込む工程となります。よって仕様が正しく決まっていないと、正しく動かないシステムとなってしまいます。
仕様というものはロジックを作り込むためのものであり、業務の実態とは似たようでかけ離れたものです。
発注側ユーザが確認するには、少し難解です。
よってコミュニケーション上は、エンジニア側がかみ砕いて説明できないといけません。ところが、作る人はどう作っているかを説明するばかりになってしまうことが多いです。
これは、設計者と作成者が分担されていることにも起因します。また作成者のスキルにもよります。
重要な機能の仕様は正しくできているか、確認が必要です。しかし重要であるものに限って複雑になりがちで、やりたいことに対して裏側にある考慮すべきことが多くなります。
例えば、顧客への販売量に従って価格を変動させるというロジックが、手作業だと困難なためシステム対応されるとします。
その計算するプログラムの仕様は、条件に従って計算することが主ですが、裏側にあることとは、キャンセルがされたらどうするかであったり、顧客が二つの口座になったり、口座を統合したらどうするかといった、イレギュラーなケースをすべて考える必要があるということです。
すべて考慮すべきことを網羅出来ればいいですが、ケースが洗い出せないこともよくあります。
同じ一つでも難易度が違うので、本当の進捗がわからない
進捗を見ていくにあたって、基本的には定量的に把握します。本数単位で何本中何本が終わったかということになりますが、落とし穴があります。
同じ1本でも難易度が異なるため、実は重みが全然違ったということになります。
ある機能は10本中9本終わった、またとある機能は3本中1本終わったということであれば、10本の機能はもうすぐ終わると考え、3本の機能はまだ遅れていると考えます。
しかし、10本のうちの1本が難しくて1本残っており、結果3本のほうに追い抜かれることもあります。
難易度が高いということは難しいため、本来早く始めて欲しいところです。
タスクが多くて入り組んでいるため本当の進捗がわからない
機能ごとに進捗が異なっているのは、当然ということは説明しました。
内部設計が全体として完了したかと言えば、機能ごとに異なっているので、終わっているものもあれば終わっていないものもあるというのが答えでしょう。
ただしそうなってくると全体としての進捗イメージがつきにくくなります。
すべてが同じ工程を進んでいる方が直感的に分かり易いです。
実際は、様々なタスクが入り組んでいますので、一言で進捗を捉えるのは難しいです。
よって、定量的な把握を基本として、その他品質を伴っているか、課題と対策はどうなっているか等を把握することで全体感を見ます。
実態の中味が分かりにくい場合は、タスク（ＷＢＳ）が上手く組まれていない可能性もあります。機能ごとのクリティカルパスを示してもらい共有すべきです。
機能が漏れていたことが後からわかる
機能の漏れというレベルのエラーは、影響としては大きく、痛いです。
機能の漏れは基本設計や要件定義から漏れたこととなり、すっぽり抜けていることになります。
内部設計以降で漏れがあると、気づかずに進んでしまうことがあります。それは、個々の機能に分割され作業が進められるからです。
機能がある程度結合された状態を見ないと、漏れは気づきません。
しかし漏れはよく発生します。よって手戻りとはなりますが、全く手戻りがないということのほうが難しいぐらいのイメージでマネジメントしていったほうが無難です。
テストでエラーが出ないもしくは出すぎる
プログラム単位でのテストは重要です。実務上はあり得ないケースであってもプログラム機能として想定しているケースであれば、テストは実施しなければなりません。
よってテストケースは自然と多くなります。
ところが、結合テストをして問題が多く出る場合は、プログラム単位でのテストに不備があることが多いです。
エラーが出すぎる場合は、作成者の者があるか、設計がそもそも不十分なことが考えられます。
エラーが出ない場合は、OKなのではなく、それはそれで問題です。一定規模の機能であればそれ相応にテストをして、エラーを検出しないと品質が伴っているとは言えません。
エラーが出ていなくてOK扱いしてしまっているケースは、かなり注意が必要です。
仕様はわかりきっているから大丈夫というような評価をしていることもあります。そういうものに限ってシステムテスト段階でエラーが出まくります。
課題対応による並行タスクがあり、工程は見た目よりも複雑になっている
課題はどの段階においても発生しますし、その影響の大小は様々です。
この段階で要件定義や設計段階の問題が発生したとしたら、対策のタスクもそれなりに大きなものになります。
そして、既に進めているタスクに影響しています。
既に計画に従って進めてきたものが、課題対応により大きなタスクが入ってきてしまったことになり、計画は実態として複雑になっています。
実態が見え易く整理されていればいいですが、整理するのは結構なプロフェッショナルなテクニックが必要となります。
よって実態がよく見えなくなっていることはよくあります。
進んでいるように見えるタスクに、実は後から課題対応のタスクが加わり、実態としては終わっていないことになります。
外部から見ているとわからないことも多いため、そのようなことが起きているかもしれない前提で状況を見たほうがいいですし、できる限り実態がわかるよう報告を求めたいところです。
IT導入・システム開発での内部設計・開発・結合テストで本当にやるべきこと
この段階になるとシステム内部の作りの問題ですので、発注側としてはうまく進んでいればそれでいいと思うところです。
ところが、気づくとうまくいっておらず、要求を満たしていないということも起こり得ます。
前工程で不十分であったことに起因していることも多いですが、前工程の問題の場合、受注者は発注者の責任にしてくる可能性があります。そして手戻り費用を請求してくるかもしれません。
前工程の不十分さは発注側の問題とは限りません。むしろ受注側の問題のことが多いとは思います。
しかし、お互い確認してきたのだから、その内容に不備があるので、開発工程がうまくいっていないというのが受注側ベンダーの論理です。
家を作ったときに、ドアを開けたら靴箱にあたってうまく開かなかったらどうでしょう。
設計者は設計書を見ましたよね？その通り作ったのです。と言うかもしれませんが、それはプロとの取引においては通用しないはずです。
他方、発注側に問題があるケースももちろんあります。
課題のマネジメントについてきちんとなされていたにも関わらず、仕様をなかなか決められなかったり、決めても後から変えてしまったりすることです。
きちんとマネジメントされているかは、重要なポイントです。このきちんとマネジメントがなされないことが多いため、結果的にどこに問題があったのかが不透明なまま進んでしまい、お互いがお互いのせいにするという構図がよく出来上がってしまいます。
仕様の決定・変更とタスクは複雑に絡み合っていて、進捗を見えにくくすることがあります。
タスクへの影響をきちんとマネジメントされていれば、進捗も見えてくるはずです。
もし受注側の進捗がよく見えない場合は、タスクのマネジメントに問題があると思われますので、改善を求めたいところです。
コメント