バグが完全に無い状態でのリリース

最近、あらためて考えてしまったことなのですが、

絶対にバグな無いと保証できる状態で、スクラッチ開発のシステムを、
リリース　または　運用テスト　に入ることは、どれだけの確率で可能なのでしょうか？

「それは出来て当然のこと」と考えられる方は多いのかもしれません。

しかし、私は、それはかなり困難なことで、それを追求し過ぎますと、たいへん高コストになる可能性があると考えています。


もちろん、十分なテスト計画を立て、モレなくテスト項目を洗い出し、万全の体制でテストを実施することを目指す必要があります。

しかし、それも、プロジェクトのさまざまな制約により、１００％満足できる予算、リソース、期間が与えられないことも、実際には多いことと思います。

その上で、よりベターなテスト計画を立て、実行していく必要があるものと思います。


システムの性質や規模、さまざまな利害関係者との関係性にもよりますが、
私は、多少のバグが発見される可能性が有り得るという認識のもとでリリースすることも「有り」だと思っています。

理由は、その方がバグの収束が効率的・効果的な場合も有るからです。

極端なことを書きましたが、いろいろなリスク要因について、
全てを「回避」するのではなく、「軽減」や「受容」をするリスク要因を選択することも必要であり、
またそれが、ＱＣＤ（品質・コスト・納期）のバランスをとるための一つの視点であるように感じます。

そして、テストやリリース判定についても、そのバランスを考慮する必要があり、
それらを顧客企業やユーザー部門に説明しご認識していただく努力も大切なことだと、私は思います。

システム仕様変更と契約変更

開発中のシステム仕様変更について、
私は、規模が大きく、且つ、スケジュールが厳しいプロジェクトほど、認識の不一致などが原因による仕様変更が発生し易いように感じています。

また、契約段階での仕様から変更が全く生じないプロジェクトは、まず無いだろうと思っています。


それらが起因して発生する問題を回避するため、フェーズごと分割契約を実施するべきであると言われています。

私もその意見に賛成であり、よって通常は、
要求定義までのフェーズについては、「準委任」のコンサルティング契約を締結し、
基本設計以降に構築ベンダーのプロジェクトリーダーとして参画する場合は、「請負」でのシステム構築契約を締結します。


要求定義フェーズでのアウトプットの一つとして、コスト明細があります。
あらためて確認しますと、私は、物品等のコスト明細、作業別のコスト明細、その他のコスト明細、という感じで整理してきています。
これは大枠としては一般的な整理だと認識しています。


この作業別のコスト明細ですが、

システム開発費については、私は業務機能要求別コストを必ず整理することにしています。
これは、私自身が構築フェーズに参画する／しないにかかわらず、必ず実施するようにしています。
最終的には「一括値引き」が入るため、合計コストと明細合計とが一致しませんが、お客様ごとに業務機能要求ごとの実施有無や時期を判断いただく際には必須になると、私は考えています。


更に、基本設計フェーズ以降での仕様変更の際にも、スケジュールやコストコントロールのために参照する情報として活用します。

多少の仕様変更は、各仕様変更の「デコボコ」でスケジュールとコストを何とか吸収するよう、私はコントロールします。
まずそれらの検討・交渉時に、業務機能要求ごとのコスト明細は活用できます。

また、追加や取り消しがあった場合ですが、これも、類似の業務機能要求を参照してスケジュールやコストの変更に関する妥当性当をチェックします。
その結果として、スケジュールやコストの変更、つまりシステム構築契約の変更契約の必要性が明らかになる場合があります。


私は、ある規模以下のプロエクトでは、基本設計フェーズ以降を「請負」で契約締結することを推奨しています。
（データー移行や運用テスト支援など、別契約を推奨するプロセスもあります。）

よって、基本設計フェーズが終わる段階で、一旦、実現する業務機能要求、その実現方式を再確定した上で、必要に応じて契約変更もしくは追加契約が締結されることになります。

「それらの精算は後で・・・」とか「以降の開発で先ずは吸収する努力をしてみてから・・・」という感じになりそうな場面もありますが、
私は基本設計の仕様凍結のタイミングで一度、しっかりと契約変更の要否を打合せして合意することと、その期間をスケジュールとしてしっかり確保されますことをお勧めします。

それがお客様と構築ベンダーとの末永いパートナーシップ構築に、何らか良い作用を促すものと、私は考えています。

「それは当然のこと」「そのようには上手く進まない」「基本設計も準委任の別契約で実施すべき」などなど、いろいろな意見があると思いますが、
明確な「方針」「考え方」「情報」の基軸をもって「変更管理」を実施することが大切なように、私は感じているところです。


＜関連記事＞
　要求定義と要件定義
　要求仕様とりまとめのコツ
　〔参考図書〕システム要求定義の基本

　超上流工程からシステム運用テストまでにおける考慮事項

システム開発手法の変化？

「日経ＳＹＳＴＥＭＳ　２０１１年４月号」（日経ＢＰ社発行）において、
「クラウド世代が変える開発の常識」という記事がありました。
その中で、「ファストプロセス」と表現し、「超スピード開発を実現する未来の開発スタイル」の参考？となる考え方、事例が紹介されていました。

また、話は飛ぶのですが、最近、
「従来型のスクラッチ開発のウオーターフォールモデル手法を適用する案件は、減少していく傾向だろう」
という、パートナー企業の方のコメントがありました。


私は、それについて、前面的に正しいとは思えません。

「アジャイル開発手法」が主流になると言われることもありますが、
私の印象では、ウオーターフォールモデルに近い手法が今だ主流だと思っています。


それが誤りなのか？についてですが、
私は（広義の）「要求定義」が絶対に必要であると考えています。

ユーザー企業の要求事項を、何らかの方法で構造化し文書化することは、（部門レベルで利用し、且つ、部門内で開発するケースの他は）絶対に欠かせないと思っています。
なぜならば、システム開発のゴールのイメージについて、ユーザー企業構築ベンダーとの間で共通認識を持つことは一つの重要な成功要因であり、
その共通認識を持つためのプロセスとして、（広義の）要求定義が必要だと思うからです。

そして、その（広義の）要求定義の一部を明確にプロセスとして定義しているウオーターフォールモデルは、絶対に前面否定されるべきではないと思っています。


言い方を変えますと、超上流工程（広義の要求定義）は、
クラウドを利用しようが、アジャイルで開発しようが、戦略課題を実現するためのシステム開発には不可欠なプロセスであり、
そのプロセスの一部を明確に定義しているウオーターフォールモデルは、絶対に前面否定すべきではないと、私は思っています。


ただし、スピード感のあるシステム開発、つまり業務モデル変革の迅速さは、ビジネス上の課題の一つとして重要度が増しています。

それに対応する（狭義の）開発手法の検討は必要であり、
また（広義）の要求定義手法の検討も、やはり必要であろうと、最近、私はあらためて感じています。


＜関連記事＞
　超上流工程におけるＢＡＢＯＫの有効性（その1）
　超上流工程におけるＢＡＢＯＫの有効性（その2）
　超上流工程におけるＢＡＢＯＫの有効性（その3）
　超上流工程におけるＢＡＢＯＫの有効性（その4）
　超上流工程におけるＢＡＢＯＫの有効性（その5）

　超上流工程（広義の要求定義）の基本プロセス（その１）
　超上流工程（広義の要求定義）の基本プロセス（その２）
　超上流工程（広義の要求定義）の基本プロセス（その３）

　要求定義と要件定義
　〔参考図書〕システム要求定義の基本

　超上流工程からシステム運用テストまでにおける考慮事項

リリースかリスケジューリングかの判断

突然ですが、

プロジェクト計画において、スケジュールを立てた後、一切、スケジュール変更が無かった、

という経験を豊富にしているＰＭ・ＰＬはいるのでしょうか？


残念ながら、私が受け持つプロジェクトは、今まで必ずスケジュール変更が発生します。


もともと厳しいスケジュールのものは、どうしても終盤で遅れの取り戻しが現実的にできない、という状況になってしまいますし、

また、ある程度の余裕を持った（予備をもった）スケジュールにしますと、構築ベンダーさんが油断？をし、遅れが発生してしまします。
正しい進捗報告と、その報告から状況をしっかり読み取れればよいのですが、なかなかうまく行きません。


その他、そもそもスケジュールは崩れるという前提で、十分に検討したスケジュールを立てる習慣がない構築ベンダーさんも中にはいます。
「最終的にエンドは合わせます」というスタイルなのですが、その合わせた結果としてリリースされるプログラム等は、けっして満足のいく品質ではない場合が多いように感じます。


更にリリース判定の時期になり、通常ではリリースできないという状況である場合、

・リリース後の対応とリスク対策を決定した上でリリースする。
・リスケジューリングする（リリースの延期）。

という判断をせざるを得ない状況になります。

これは、通常はあってはならないことかもしれませんが、現実的には良くある状況ではないでしょうか？


この判断には、本当に頭を悩ませます。

その判断の結果で、とても苦い経験をしたこともあります。
（しかし最終的には、そのタイミングでリリースしたことで、更に大きな問題の発生を止めることができました。）

本当に頭を悩ませますし、楽しい時間ではないのですが、

そのプロジェクトが終わった後、メンバーへ「ありがとう。あなたの○○のおかげでうまくいきました。」という言葉をかけることをモチベーションにして、何とか対応して行きたいと感じているところです。

システム総合テストの重要性

あるプロジェクトでシステム総合テストのフェーズに入りました。

私は、システム総合テストとは、
「実環境で利用するハードウェアおよび想定量のデーターを準備して実施する、ユーザーの運用テスト前にシステム構築ベンダーもしくは情報システム部門が実施するテスト」
というような位置付けで考えてます。

ソフトウェアの品質のみではなく、システム全体の品質を対象としたテストになります。


そのシステム総合テストにおきまして、私が特に重要だと思うのは次の２つです。
・テストケースを用いたテスト
・パフォーマンスや障害等異常系のテスト

特に新たなハードウェアの導入規模が大きなプロジェクトにおきましては、パフォーマンスや障害等異常系のテストの重要性は更に高まります。


そのパフォーマンスのテストについてですが、
私は「負荷テスト」と「パフォーマンステスト」が合わさった概念でとらえています。
（一般的には分けて考える方が正解だと思います。）

平均的な負荷（アクセス数やデーター量）の状態、想定した負荷上限の状態などを擬似的に作った上でレスポンスタイム等を測定し、
目標とするパフォーマンスに達しているか、使用に耐え得るか等をテストすることになります。

また、更に負荷を増大させていくとで、負荷最上限レベルでのパフォーマンスを参考値として把握します。

私自身は、そのシステム総合テストを計画したり実施したりする立場になることはありません。
構築ベンダーに実施いただくため、それらの確認・チェックをするだけです。
（ただし、私自身が作るテストケースによるソフトウェア総合テストは実施することがあります。）


実は、そのシステム総合テスト計画について、私は今まで、体系化され網羅的なものを、多分見たことがありません。
特に、負荷テストや障害系テストが計画に含まれていないことが多いように感じています。
更には、そのシステム総合テストの計画自体を提出いただくことに、イヤな顔をされる場合もあります。
（ただし、発注仕様書やプロジェクト計画書には、（役割分担を含め）明確にタスクとして記載していますので、最終的には納得していただきます。）

これらは、私が関わるプロジェクトでは、中小の地域ＳＩｅｒさんが構築を請け負うケースがほとんどであるためだろう、と推測しています。
中小の地域ＳＩｅｒさんは、親密性や機動力、低コスト等が魅了であり、これらが中堅や大手ＳＩｅｒさんと比較した場合の強みなのですが、
全てを本番運用開始後の一定期間において「機動力」で調整しようというのはリスクが大き過ぎます。
何とか網羅的なシステム総合テストを実施すること、これが、お客様はもちろん、構築を請け負った地域ＳＩｅｒさんにとっても最終的にメリットは大きいと、私は思っています。


このシステム総合テストのフェーズに入り、その計画作成、テスト手順書の作成などは、やはり発注仕様書やプロジェクト計画書の中に明確に盛り込むべき項目であることを、私は再認識しました。

そのため、今回「システム総合テスト」について記載してみました。
まとまりのない記事になりましたが、共感いただける方がお一人でもいれば、うれしく思います。


＜関連記事＞
　超上流工程からシステム運用テストまでにおける考慮事項

　ソフトウェアの総合テスト
　顧客の受入テスト（運用テスト）