スポンサーリンク

システム開発する前に知っておくべきこと83項目

企業システム戦略

【企業システム戦略】の目次

 システム開発する前に知っておくべきこととして、基本的な作業の流れとポイントを説明します。特にDX(デジタルトランスフォーメーション)の推進に有効とされる内製化をやるなら、過去の同じ失敗を繰り返さないためにも必ず知っておくべきことです。

「戦略策定」編

最小の投資で最大の効果を生むシステム戦略

 できるだけ少ない投資で最大の効果を生むようなシステムを構築するには、どのように考えれば 良いでしょうか。システム戦略を考えるとき、どんなことに留意すべきでしょう。IT導入でソリューションを 鵜呑みにしたり必要以上に多くの機能を詰め込みすぎたりして、結局、使われないシステムに多額の投資 をしてしまうことを防ぐためにIT導入の基本的な考え方は?、様々な注意事項は?、投資対効果や 優先順位付けは?、どう考えれば良いのでしょう。
◆IT導入の基本的な考え方は?
◆「ソリューション」の意味するところは?
◆「自動化」による業務効率化の注意事項は?
◆「ペーパーレス化」を推進する時の注意事項は?
◆「統合データベース」のメリット・デメリットは?
◆「パッケージソフトと自社開発」」のメリット・デメリットは?
◆海外製パッケージソフトを導入するときの注意事項は?
◆「レガシ・システム」を再構築する時の注意事項は?
◆ナレッジマネジマントで効果をあげるには?
◆情報共有を阻害する日本文化とは?
◆SCM成功のポイントとなる日本文化とは?
◆システムを業務に組み込み、確実に使いこなすには?
◆システムの投資対効果は利益だけか?
◆システムの投資対効果を正しく評価するには?
◆システムの投資対効果を最大化するには?
◆システムの投資回収を早くする開発方法とは?
◆システムを長期的に活用するためのポイントは?

短期戦を戦うシステム開発体制

 短期に最小の投資で最大の効果を生み戦いに勝つための体制は、どのようなものでしょう? 開発期間が長引いて投資が大きくなり、効果を生むのが遅くならないための対策は? 手段が目的化しないようにしたり、目的を関係者に周知したり、有識者を活用するには?
◆プロジェクトの目的を明確化するには?
◆プロジェクトの目的を周知するには?
◆目的を達成するために必要なものは?
◆コンサルタントをうまく活用するには?
◆開発体制におけるキーマンの役割は?

「要件定義」編

自社に必要十分な要件定義

 最小の投資で最大の効果を生むシステムは、要件定義の段階で半分ほどが決定されてしまいます。 要求仕様書作成以降は、システムの要件を実現していくための詳細化(HowTo)にすぎません。 システムに対する要件とは、ビジョンを実現するための必要最小限の要求事項(What)です。 多過ぎず少な過ぎず「過不足無く」要件を決めるには、どうすれば良いでしょうか。
◆情報処理の基本とは?
◆要件の妥当性を検証するには?
◆確実に効果を得られる要件とは?
◆複雑な要件を整理する時のポイントは?
◆要件定義はどこまでやればよいか?

急がば回れ、質の良い要求仕様書の作り方

 システムの要件が決まったら、これを具体的な仕様書に落とし込んでいきます。仕様とは、 要件を満たすための具体的なシステムの機能・性能に対する要求事項です。 このあたりからベンダに丸投げするケースも日本では少なくないのですが、それでは成功しません。 「急がば回れ!」です。しっかり時間をかけて、後からの設計変更や改修を最小限にしましょう。 質の良い仕様書を作成するにはどんなことに注意すればよいでしょうか。
◆要件を確実に伝える質の高い仕様書とは?
◆読み手に親切な分かりやすい表現とは?
◆要求機能が多過ぎる場合の対処方法は?
◆適切な応答時間を設定するには?
◆新技術を使用する場合のメリット・デメリットは?
◆例外処理も漏れなく要求仕様化するには?
◆後工程での手戻りを防止するための取り組みとは?

「システム開発」編

リスクを緩和する上手な予算の使い方

 さて、要件定義も固まり、仕様書もできたら、いよいよシステム開発です。ここで仕様書は決して 完璧ではないということを忘れてはなりません。いざ、システムが完成して実際にリハーサルなどを 繰り返すうちに、あれこれ仕様が漏れていることが発覚します。その時に、予算オーバや期間延長、 予定遅れとならないようするにはどうすればよいでしょう。
◆想定外の予算オーバーに対処するための方法は?
◆必ず発生する仕様変更への対策は?
◆反復型開発での注意事項は?
◆部品化や構造化での注意事項は?

もっと安くなる見積りの取り方、商談のしかた

 システム開発では費用がどのように決まるか御存知ですか。提示された見積もりの妥当性を どのように判断して契約をしていますか。一式いくらでなんとなく契約していませんか。 しっかりとした仕様書があれば妥当性について納得行くまで交渉が可能です。その方法とは?
◆もっと安くなる見積りの取り方は?
◆リスクを緩和する分割契約とは?
◆失敗しない発注先ベンダーの選定方法は?
◆人月による見積もりの問題とは?
◆改修費用の妥当性をチェックするには?
◆ハードウェアの見積もり妥当性をチェックするには?

後悔しない契約書のチェック・ポイント

 システムではベンダとのトラブルも少なくありません。主な原因は、発注側の「目的の不明確、 要件の不明確、仕様の不明確」と、受注側の「勝手な思い込み、勘違い、理解不足」による コミュニケーション・ミスです。いざというとき後悔しないための契約書のチェック・ポイントは?
◆納品時に作業分担で失敗しないためには?
◆著作権や所有権に対する注意事項は?
◆仕様変更を考慮した契約での注意事項は?
◆検収時にトラブルを起こさないためには?
◆検収後のトラブルに備える瑕疵期間とは?

早め々が肝心、進捗状況をこまめに確認

 システム開発では、スケジュール遅れとなることが少なくありません。開発スケジュールの遅れは 最終的に実用開始が遅れ、目的達成ができなくなる恐れがあります。システムを発注した後もベンダに 任せ切にせず注意すべきことは?
◆進捗状況をタイムリーかつ正確に把握するには?
◆レビューの意義、重要性とは?

いよいよ納品、検収のチェック・ポイント

 システムが完成するといよいよ納品です。納品後は、速やかに受入検査を実施し、検収しなければ なりません。要求どおりにシステムが作られているかどうかのチェック・ポイントは?また、検査で プログラムの欠陥や要求事項の漏れなどに気が付いた場合にはどうすればよいでしょう。
◆機能面での検収チェック・ポイントは?
◆性能面での検収チェック・ポイントは?
◆保守性での検収チェック・ポイントは?
◆ドキュメントの検収チェック・ポイントは?
◆瑕疵とは?その対応方法は?

紛争勃発!

 受入検査で発見した問題が明らかにプログラムの「欠陥」であると判定できる場合は問題ないの ですが、システム開発では発注側と受注側で意見が衝突することもあります。発注側が欠陥と思っ ても、受注側は仕様書の不備なので仕様変更であると主張します。このような場合に、できるだけ 禍根を残さずに両者が納得できるような形で解決するには、どうすれば良いでしょう。
◆仕様変更か欠陥か問題の切り分け方は?
◆その要求仕様は常識?それとも非常識?
◆双方が譲らない場合に和解する方法とは?
◆欠陥防止に向けた発注側の対策は?

強きをくじき、弱きを助ける正義の味方を探せ

 建築では欠陥住宅を防止するために第三者の建築士による工事監理、もしくは建築検査を実施すること が推奨されています。システム開発でも有効な同様の欠陥防止対策とは。
◆第三者による監理、助言の重要性とは?

「運用試験/実用展開」編

実業務に使えるか?運用試験のチェック・ポイント

 システムは導入や構築が目的ではなく使用して効果をあげることが目的ですから、運用試験から 実用展開こそが重要です。運用試験の目的とは?実施体制やテストデータなど準備作業での注意事項は? 仕様の漏れや実業務における運用上の問題が発生した場合の対策など、確実かつ速やかに実用開始する ためのポイントとは。
◆運用試験/実用展開に必要な体制、キーマンとは?
◆運用試験に準備すべきテストデータは?
◆仕様変更など追加発注での注意事項は?
◆運用試験で業務マニュアルを使用する意義は?
◆システム活用の促進に必要な教育は?
◆安全で確実な本番移行の方法は?

これからが本番、儲けてなんぼの実用展開

 運用試験が完了すればいよいよ実用段階です。カットオーバはゴールではなく、スタートと考えましょう。システムを活用して確実に効果をあげ、所期の目的を達成するための施策とは?
◆確実に効果をあげる実用展開戦略は?
◆ビッグバン/順次拡大のメリット・デメリットは?
◆投資対効果を正しく評価するには?
◆投資対効果を多面的にバランス良く評価する指標は?
◆改善を加速する適用拡大の方法は?

「プロジェクト管理」編

ウォークスルー(舞台稽古)でイメージ合わせ

 発注者としてプロジェクト管理で注意すべきポイントはどこでしょう。ウォークスルーとは舞台稽古 のことで、舞台に立って本番さながらに行う稽古のことです。これにならって、システムを具体的に イメージして、要求仕様を確認するために行うものです。実施にあたっての注意事項とは?
◆業務フローをリアルにイメージするための方法は?
◆入出力情報を具体的にイメージするには?
◆ウォークスルー(舞台稽古)に必要な参加者は?

ドキュメント・レビュー

 有識者を集めてレビューすることで発注後のトラブル発生による手戻り等を未然に防止します。 より多くのリスクを抽出し、レビューを効率的、かつ効果的に実践するために必要な注意事項は? また、主要なドキュメントの具体的なレビュー・ポイントは?
◆失敗を防ぐ要求仕様書のレビュー・ポイントは?
◆合意に向けた見積書のレビュー・ポイントは?
◆品質を確保する設計書のレビュー・ポイントは?
◆良くあるレビューの間違いは?効果的・効率的なレビュー実践法とは?

リスク管理

 何をするにもリスクは付き物ですが、システム構築は成功率が30%と言われるほどリスクの 高い投資です。そのリスクに無頓着で、業者に任せっきりにするのは、保険に入らずに車を運転 するのと同じくらい危険です。システム構築における主なリスクと対策は?
◆要件定義の取り違えなど認識的リスクとは?
◆要員スキルや人間性など人的リスクとは?
◆カタログどおりに動かないなど技術的リスクとは?
◆トップのリーダーシップなど組織的リスクとは?

コメント

タイトルとURLをコピーしました