失敗できないプロジェクト 〈急所〉

プロジェクトの “急所” 、一つ挙げるとしたらどこでしょうか？　プロジェクト計画、要件定義、設計、開発、テスト

どれも大切ですが、問題が表に出てくるのは “テスト” ですよね。結合テスト、システムテストでこんな問題が起きることがあります。

１．テストに入れない（プログラム がない！、ファイル、テーブル がない）

２．テストに入れない（テスト仕様書がない！）

３．テストに入れない（環境がない！、時間枠がない）

１番目のケース、まさかそんな！と思われますよね。でも開発の遅れで一部プログラムが揃っていないということは経験があると思います。影響のないところからテストをはじめます。またテストを始めた途端、仕様の取り違えが判明しテストにならない、ということもあるでしょう。結合テスト段階で単体テストのバグが出るというケースです。そもそも取りこぼしでプログラムを作っていなかった、リリース期日の間違え、もあるでしょう。

規模が大きくなる程、この手の初歩的なミスが増えます。

プログラムができるまでは、ドキュメントベースで確認するしかありません。要件定義書、設計書など何百ページもあるドキュメントを目検していく訳なので、ベテランであっても一定割合で、ある、なしレベルのミスが発生します。

発生割合ですが、さすがに全体の10%ということはありませんが、0.1%ということもありません。感覚的に１%はありますね。２%前後はあってもおかしくないと考えておくのが相場です。

結合テストからシステムテストと進むにつれ、ある、なし レベルのミスは全体の足を引っ張ります。影響のおよぶ範囲のテストを止めてしまいます。ミスは避けられません。早い段階で露見させるのが賢い対策です。PM（プロジェクトマネージャ）、PMOの真価は課題対策にあります。

“仮組み”

そこで開発中であっても、週の最後に、出来ている分だけ、ある分だけのプログラムを集め、中途半端なデータベースにつないでしまうのですね。私はよくやりました。ポイントは集めるにあります。

ビルドエラーも出ます。マスターのコード定義もありません。初めは動きません。それでも無いものが分かるので

「来週これは作る予定だよね？」

と確認できます。そこでドキッとします。

「忘れるところでした（本当は、忘れていました）」

というふうに。

アジャイルだと、頻繁にビルドをしているので、ある、なしレベルのミスは防止できますね。限られた時間と集中力を設計開発に回せるのは利点です。

“仮組み” はウォータフォール開発や基幹系システムでもおすすめです。「忘れている」というと、担当者に対する落ち度の指摘です。指摘された方は気分のいいものではありません。指摘する側も、言いたくて言っている訳ではありません（言いづらいです）。人間同士お互いの負の感情はコミュニケーションを阻害します。できれば避けたいものです。

 “仮組み” は「ある」「なし」を見えるようにしています。担当者が「忘れていた」ことに違いはありませんが、指摘は、仮組み環境を経由した間接的なものになります。同じことでも人から直接指摘された時のような負の感情は生じないか弱いものになります。

「見える化」とか「可視化」は問題発見の効率化と合わせて、担当者の前向きな行動や、グループのコミュニケーションを維持する効用があるのではないでしょうか。

“仮組み” 試してみてはいかがでしょうか。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

失敗しない要件定義 その１

IT / システム部門の方とお話をするのですが、苦労が絶えないのは相変わらず要件定義のようです。開発になるとパソコンに向かうことが多くなるので技術者という感じですが、要件定義は対人業務です。ストレス解消法も良く話題になります・・

要件定義には、コミュニケーション能力とドキュメンテーション能力（とストレス耐性）が求められます。業務要件を言われた通りに丸写しすればいいというものではなく、システム化、シンプル化のインタラクティブな現場対応が必要です。コンピュータは賢くありません。だからといって闇雲に要望を切り捨てたら使えないシステムになります。実現性、工数などを勘案して、賢くないコンピュータを不便でない程度にブラッシュアップして、費用対効果に見合うようにするのですが、実は要件定義で大方結果が出てしまいます。*

設計フェーズで見直すという考え方もあるのですが、予算が決まっている以上、要件を膨らます訳にはいかないのです。要件精査でもたついたら設計フェーズの時間が削られてしまいますし、そもそも忙しい業務の合間をぬって検討会に参加してもらった業務部門のキーメンバーとの関係にひびが入るなど、デメリットばかりです。

すべては無理にしても要件検討会のその場その場で問題処理をしてしまわないと時間切れになります。データもあいまいでは困るので定義を明らかにしていきます。データ間の依存関係、上下関係も大事です。幹をクリアにしないと例外要件なんかまず出てきません。

プロジェクトは要件定義開始2週間が勝負です。最初の2週間でセッションをリードできれば要件定義をスケジュール通りに進めることが出来ます。失敗するプロジェクトは、要件定義が終わっていないのに時間切れで次のフェーズに進めている場合が多いです。設計フェーズで吸収しよう、ということですが、設計フェーズの方が投入工数は増えるので進捗の遅れのインパクトが大きくなります（工事進行基準廃止！）。要件定義が終了しているモジュールから五月雨式に設計に入ろう、としますが、データモデルを共有している以上、影響が伝播します。結局、設計修正、手戻りが発生し二重コストになります。データモデルが確立していない段階でのアジャイル開発が失敗するのはこの点にあります。MVC ( Model, View, Controler ) のModelについてはウォータフォールに利があります。データモデルを精査するためにはユースケース（システム利用、操作仕様）の理解が必要で、業務シーンではその重要なインプットの一つに業務フロー（業務フロー）があります。

業務フロー図にやり取りされるデータは定義されているでしょうか？失敗しない要件定義の分かりやすい Howto を一つアドバイスさせて頂くとしたら、

業務フロー上のデータを精査

することです。あまりうるさく言われていないようですが、成功のカギの一つです。
大変かもしれませんが、必ず報われる苦労ですので。是非一度レビューしてみて下さい。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します

* 顧客サービスですから、ここをうまくお話ししないと仕事が終わってしまいます。状況をフェアに説明し理解を得て、妥協点に落ち着かせる交渉事でもあります。

システムの費用対効果 〈 スコープ定義 〉

PMBOKではスコープ、システム化の範囲、対象とするもの・対象としないものですね。関係者の合意形成、納得感が大事、ここがしっかりしていると大体プロジェクトはうまくいきます。

ところが、苦手なこと、できないこと、都合の悪いこと、言ってくれません、システムサイドもユーザーサイドも。それでは問題になることが明白なのでベテランははっきり言います。 “EXCELよりも不便になります。” とか、 “システムって賢くありません、 人がやるのが一番いいです。” とか。

一方、断片的な情報から必要な書類を探し出す検索性や、ネットワークさえあればいつでも、どこでも必要な情報にアクセスして、業務を遂行できるのは大きなメリットです。加えてセキュリティーが強化され、紛失リスクが軽減されることも企業として重要です。結果、会社組織全体で業務改善、費用対効果に見合うと判断できればGOです。
繰り返しますが、EXCELより不便になります。罫線一杯の凝った帳票・印刷様式、入力規則を駆使したフォーム、マクロ、要注意です。苦手なことやろうとしたら、お金も時間も性能も犠牲になりシステム化する意味、メリットなくなります。クラウド、ウェッブの特性に合わせフォームとデータ構造をシンプル化してしまいます。条件判断もできるだけ入れません。別口で対応します。 ”EXCELもよかったんだけど、クラウドもこれはこれでありかな。” と現場レベルで言ってもらえれば合格です。

スコープ定義、大丈夫でしょうか？都合のいい勘違いのまま進んでいないでしょうか？
仕切り直しは早いほうがいいです。

永島志津夫

全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します