コンサル現場より一覧

システム検収の結果、不具合だらけで差し戻し

これはどうみても単体テストレベルで潰せてなければならないバグが頻発するではないですか! さすがにこれ以上検証を進めることができないと判断、ベンダーに『 品質に問題あり 』との結果を伝え、差し戻しとさせていただきました。 結局、本稼働が約二ヶ月遅れとなりましたが、システムの品質を考えると止むなき判断だったでしょう。 納期を重視するあまり、品質確認を疎かに本稼働へ突入するユーザ企業もありますが、仮に、あの状態で本稼働に突入していたら、完全に業務が停止していたでしょう。 システムのでき具合を判断し、本稼働すべきかどうかを見極める事が大事です。

システム開発の成否は、要件定義にかかっているといっても過言ではありません。

システム開発における【要求定義】と【要件定義】何となく似ているようですが、その意味は全く異なります。要求定義は、業務的な視点で何が必要なのかを定義するもので、要するに「〜したい」という利用者側の要求事項をまとめたものです。要件定義は、要求定義により求められる「~したい」を実現するために、システム的な視点で何が必要なのかを定義するもので、要するにシステムの機能として「~が必要」という機能要件をまとめたものです。

SE(システムエンジニア)の資質が変わったのでしょうか?

システム開発プロジェクトにおいて、全くと言っていいほど客先に提言・提案できないSEに遭遇します。客先の業務を知るためには大変な努力を要することは分かりますが、自己学習すれば習得できる一般的な知識を持ち合わせないSEっていかがなものでしょうか?確かに今時のSEに求められる知識は多岐に渡り、客先に満足してもらえるだけの対応をするには、相当の努力をしなければならないとの事情は理解しているつもりです。

冗談のつもりで言った一言、まさか実現するとは思ってませんでした

毎週実施していた定例ミーティング後の反省会で冗談話をしていたところ、本当に山に登ることが現実となってしまったのです。合宿や懇親会などはどのプロジェクトでも行いますが、流石に山登りは初めてでした。でもその甲斐あって、今まで以上にユーザとベンダーの距離がグッと縮まったのか、その後のミーティングでは腹を割った会話が進むようになりました。一時は山登りへの参加を躊躇したのですが、結果からするととても有意義なイベントでした。眉間にしわを寄せるばかりでなく、たまには、こんなお茶目な交流も宜しいのではないでしょうか。

システム開発の現場は、やはり紆余曲折の連続です

提案依頼説明会終了後、やっとここまで漕ぎ着けたとの安堵感。ベンダー各社から提案書が出てくるまでの間、このプロジェクトはちょっと一息。と思いきや、開発段階にある他のユーザ企業のプロジェクトに遅れが目立ち始めてきたのです。ここまで比較的順調に進んでいたのですが、検収段階に入る直前でベンダー側が段取りミスを。ほんの小さなミスですが、結果として全体のスケジュールを見直さなければならない事態に発展してしまい、ユーザ企業の中にベンダーに対する不信の念が芽生えてしまったのです。

受入検収を怠ると、システムを本稼動させた途端に二進も三進も行かない状況になる恐れがあります

標準的なパターンのデータを投入すると上手く業務連携がはかれるものの、データの組み合わせパターンを変えると業務連携が図れないなどのバグがボロボロと発覚。検収段階で、この手のバグが頻発するのは、ベンダー側のテストの甘さと、ユーザの業務をシッカリと把握してシステム開発に活かしていないと言わざるを得ないでしょう。

同業他社で使ってるからと言う理由でパッケージシステムを導入した結果

システム導入は、自社の業務に適合するかどうかを判断し、それから導入へと踏み切るべきです。パッケージは機能が明確なので、スクラッチ開発と比べれば、比較的簡単に判断がつきます。導入するシステムに何を期待するのか。業務要件/機能要件をパッケージの機能と突合(Fit & Gap)。不足機能をアドオンできるか。不適合部分をカスタマイズできるか。最終的に、自社の業務に適合するシステムと成り得るか。という、最低限行わなければならない事をやらなければ最悪な事態に発展します。

社長の思いつきでシステムに機能を追加した結果、使えないシステムに

現場の事は自分が一番知ってるとの自負心より、現場の言うことに耳を傾けず独断で話を進めてしまいプロジェクトを失敗へと導いてしまう経営者もいらっしゃいますが、機能追加について、社長に何も言わなかった(言えない?)システム担当者、ユーザ企業の無謀な要求に対して、何も言わなかった(言えない?)ベンダー担当者、の方が問題ではないのでしょうか?

システム化の予算をどの様に決めてますか?

商品を購入する時、まず性能・機能をみます。自分の要求に会っているか、また本当に必要なものかを判断します。その価格と自分の懐具合をみて、最終的な購買に対する意思決定をします。でも、出来上った商品だからこそスムーズに意思決定できるのではないでしょうか。パッケージソフトであれば、他の商品と同じ購買行動をとる事ができるでしょうが、自社専用のシステムを構築する場合はそうはいきません。かといって、ベンダーに言われたままにコストを掛けるというのは納得いきませんね。ベンダーの見積り積算方法を知り、概算を積算してみるのです。