最近の記事
◎プロが選んだ防犯&防災グッズ!
◎防犯ブザー、防犯フィルム、補助錠、センサーライト、
防犯カメラ、ドアホン、盗撮防止、盗聴防止、護身用品
◎地震、火事対策、非常食、保存水、家具固定転倒防止、
災害用簡易トイレ、避難セット、防寒、火災報知器
地震対策万全ですか?
↓↓詳しくはクリックを↓↓
安心安全の専門店 TSSP.jp!!


【お薦めサイト】 
PMBOKやITプロジェクト管理を解説!
↓↓↓↓↓↓
プロマネも人生も段取り八分

2009年12月27日

システム導入プロジェクト(はじめに)

私がはじめてシステムというものに携わったきっかけは1991年最初
に就職した企業が情報処理産業(ソフトウェア産業)であったからでした。
なぜ、ソフトウェア産業を就職先に選んだかというと、その時は、次世代を
担う産業として注目されていたことと、完全に文系(法学部)でコンピューター
の「コ」の字も分からない状態、、、今後、どの産業でもコンピュータの知識
が必要になるのではないか、、だったらその産業自体に飛び込んでしまえ!
という安易な考えでした。
その当時はすでにバブルは崩壊していましたが、ソフトウェア産業の求人意欲
は旺盛で、最後のバブル社員として(笑)、すんなりと大手ベンダー系
ソフトウェア企業に入社することができました。
実際入社してみて同僚の社員たちが新人研修を行うこととなりましたが、
この安易な考えを心底後悔するのにそれほどの時間はかかりませんでした。
なにせ、多くの理系選手たちと、もともと文系で卒論でワープロを使っただけ
の人間では、前提条件が違いすぎました。
受け入れてしまった企業のほうも大変だったでしょう。(本当に感謝いたします)
また、職場に配属されてからは、より後悔を深めることとなりました、
最初は先輩が設計(この当時は口頭がメイン)を元にプログラミング作業
(C言語)を行い、ポインターに悩ませれ(***pって誰? p->ってどこ?)、
るという、あまり社会とは関係なく、コンピュータという密閉された世界での
この作業を、深夜残業に耐えながら行っていました。
午前0時に帰ろうとすると、「今日は早いね!」と声を掛けられ、
朝早めに出社すると給湯室で先輩が髪を洗っている始末。
「あれは、ママレモンじゃないのか?」
こうゆう状況で数年すぎ、徐々にプログラミング設計、システム設計、
要件定義と上流行程を担当することになっていきました。

それから、18年間転職しながらいろいろなシステム開発に携わってきて、
当初の自分の悩みがわかるようになってきました。
システマティックに物事を考える能力がなかったのです。
一応、法学部で論理性がなかったわけではないと思うのですが、
(いや、私はアホー学部でした)論理、定理が数式という記号に変化すると
苦手になるように、コンピュータ世界で表現する論理性になれていなかった
のです。(それがわかるのに18年かかってしまいましたが)

私がシステムコンサルを行う中で、数多くのシステム導入時の要件定義で顧客の
ほとんどの方がたが自分たちが毎日行っている業務をシステムとして表現できない
という壁にぶつかっているように感じます。
『私が最初にぶつかった壁と同じものだ。』

よく「コンピュータは分からないという管理職の方がいらっしゃいますが」、
顧客に高度なコンピュータシステムの知識が必要なわけではありません、
そのような知識はそれを仕事としている人間に任せておけばいいのです、
ただ、自分たちの業務のシステム化は自分たちでできなければなりません、
自分たちの業務をわかっているのは、自分たちであるからです。

これから、システム導入に必要な顧客の知識をいろいろ記述していこうと
思います。
顧客として、どんな準備が必要なのか、どうすれば格安で安心できるシステム
が導入できるのか、、、、
御社のシステム導入の一助となればと存じます。

さあ、システム導入プロジェクトを安心して進めていきましょう!

posted by 近藤SCO at 15:53| Comment(0) | プロジェクト管理 | このブログの読者になる | 更新情報をチェックする

システム導入はどのように進んでいくか?

まず、社内でシステム導入が決定したら、以下のような
大体のシステム導入は以下のように進んでいきます。
各工程の呼び方は若干ベンダーによって違う場合がありますが、
内容はほぼ同じです。


(0)導入前作業(顧客側作業)

   ・RFP(Request For Proposal)の作成:
     提案依頼書のこと。
     発注者がこんな提案をして欲しいと条件を提示するもの。
     顧客側が作成します。
     この段階でベンダー、SI企業、コンサルタントなどに参加して
     もらい作成する会社もありますが、まず、自社で作成することを
     考えるべきです。
     
   ・ベンダーの選定
     RFPを基にして、ベンダーに見積もり依頼をして、
     数回の打ち合わせののちベンダーを決定します。
     複数の会社に見積もり依頼をして、コンペとすることが多いでしょう。


(1)要件定義

   ユーザーの業務内容を調査し、これから開発するシステムが
   どのような要求を満たすのかを明確にする工程です。

(2)外部設計(論理設計)

   要件定義書に基づき、ユーザーの視点で(業務の面から)システム
   を設計する工程です。
 
(3)内部設計

  外部設計で決めた仕様をコンピュータ上で実現するために、
  開発者の視点で(コンピュータ処理の面から)システムの内部構造を
  設計する工程です。

(4)プログラム設計

  内部設計書をもとに、プログラム内部構造を設計する工程です。

(5)プログラミング

  プログラム設計で作成したプログラム構成図をもとに、個々のモジュール
  を作成する工程です。

(6)テスト

 「結合テスト」「システムテスト」「運用テスト」という3段階のテスト
  を実施し、システムが仕様に沿って作られていることを確認する工程
  です。

(7)運用・保守

   導入したシステムの稼働状況を監視し、不具合が発生した場合に対応
   したり、必要に応じて機能を変更・拡張する工程です。



  (段階的詳細化)トップダウンアプローチ
【基本設計】 →【外部設計 】→【内部設計】→【PG設計】→ 【PG】
                                ↓
【運用・保守】←【運用テスト】←【システム ←【結合テスト】←【単体
                  テスト】          テスト】
  (段階的統合化)ボトムアップアプローチ


これから、一つずつ見ていくこととしましょう。

posted by 近藤SCO at 15:58| Comment(0) | TrackBack(0) | プロジェクト管理 | このブログの読者になる | 更新情報をチェックする

2009年12月28日

プロジェクトって何?

【プロジェクトって何?】

 システムを導入する場合、プロジェクトが立ち上げられます。
 プロジェクトってなんでしょう。

 あの数年前のNHK番組「プロジェクトX」の「プロジェクト」
 です。

 プロジェクトとは、標準的には、
  「特定の目標・目的を持ち、その目標・目的を決まった期間に有限
   のリソースを用いて完遂するための形態」

  @プロジェクトには、必ず「ステークホルダー(利害関係者)」がいる。
  Aプロジェクトの目的は、「オーナーの要求」を満たすことである。
  Bプロジェクトの使命は、既存の組織機能で効率的に成しえない
    目的を達成することです。
  
  「なぜ、既存の組織があるにもかかわらず、プロジェクトという名
   の新しい組織を起すのでしょう。」

   企業の既存組織は、企業・組織、「組織人」の安定
   のために、ほぼ決まった業務を遂行するという責務を果たしている。
   しかし、このことが逆に、目的達成のための最大の阻害要因となり
   ます。

  Cプロジェクトは、既存組織への負荷を最小限にして、目的を実現する
    「有期性」の機能組織である。

  私も経験から、プロジェクトは『冒険』であると感じています。
posted by 近藤SCO at 07:46| Comment(0) | プロジェクト管理 | このブログの読者になる | 更新情報をチェックする

プロジェクトの成功率ってどれくらい?

【プロジェクトの成功率】

プロジェクトは、定型業務ではない分、不確定要素も多く、
実際に失敗プロジェクトも多いです。

コンピューター系の雑誌によく「動かないシステム」として特集して
ありますね。
私も20代から30代にいくつか経験したり、友人から聞いた話しも
ありますので、おいおい書いていきます。

まず、一般的に失敗プロジェクトについてどう考えられているの
でしょうか。

『7割占める失敗・中止案件過大な要件が原因』

 プロジェクトの7割は失敗・中止のプロジェクト。

 米国では、調査会社のStandish Groupが4万件に及ぶ米国企業と政府関係
 のITプロジェクトを対象に、失敗(中止には至らなかったもののスケジュール超過、
 コスト超過、低品質、機能不備を起したもの)/成功/中止プロジェクトの
 割合を調査している。
 2000年でも65%のプロジェクトが失敗または中止プロジェクトになってい
 る
 
 では、どういう要因で失敗しているのでしょうか、
  
  米国のコンサルティング会社SPR(Software Productivity Reserch)が、
  6700件のITシステム開発プロジェクトに関するデータから抽出した

 『失敗要因』:
  @「技術的失敗要因」
    「過去のソフトウェア計測データの欠如」
      特に多い。
      ITプロジェクトに関する基礎的情報の収集と「共有」が遅れている。
      システム開発が「エンジニアリング」になっていない。
      実直にPDCAを繰り返すことで、プログラムの品質はマネジメント可能
      となる。
    「効果的なアーキテクチャの不使用」
    「複雑さが過大」
    「ユーザー要求の増大が約30%以上」
    「データベース定義の不履行」など

  A「環境的失敗要因」
    「スケジュール短縮への過度の圧力」
    「自社の経営者による見積もりの変更」
    「顧客との軋轢」
    「経験の浅い上級マネージャ」
    「不適切なプロジェクトマネジメント」
     
    *いずれも、プロジェクトのステークホルダー(利害関係者)に
     かかわる失敗要因である。


  B「通常のマネジメント領域を超えた失敗要因」
    「多数の国、都市、企業がかかわるプロジェクト
       (国の文化、企業文化が関わる場合)
    「ステークホルダーが複雑な関係のプロジェクト」
    「リアルタイム/ミッションクリティカルなプロジェクト」
    「技術的要素を無視し、営業的要素のみで契約されたプロジェクト」など
  
  これらの発生率は、20%に満たない、まれな失敗要因です、
  だが、プロジェクトにこれらの要因が入り込むと、
  80%の割合で重大な問題が起こると想定できます。
  20:80の法則(パレートの法則)がプロジェクトの失敗要因にも適用
  できるのです。

posted by 近藤SCO at 07:54| Comment(0) | プロジェクト管理 | このブログの読者になる | 更新情報をチェックする

2009年12月29日

プロジェクトの成功率(2) 現在の失敗要因


 ・プロジェクト失敗の原因は時代とともに変遷してきています。
  確かに20年前のオープンシステムへの移行期には、システム技術側の
  問題も多々みられたが、最近では、過大要件やステークホルダーとの利害関係
  などシステム技術以外の問題点がシステム導入の致命的な要因となっています。
  システム導入の問題は、技術ではなく、過大要求や利害関係など、業務、
  人間系の問題に遷移してきている。
  ということは、システム技術に詳しい、詳しくないは、システム導入
  成功への決定的な要因ではなく、顧客側でコントロールが可能な
  業務要件、導入体制構築が重要な要因となっているということです。
  これは、顧客側に確立した体制と、明確な要件があれば、システム導入の
  成功する確率が高くなるということになります。
  技術的な問題ではどうすることもできませんが、要件の問題であれば、
  十分な準備で対応することができます。
  ここで必要なことは、自社の業務をシステム的思考で考え、なにを実現
  したいのかを明確にする能力ということになります。
  それほど難しいことではありません、DFDなど簡単な記述方式で、
  自分たちの業務を記述していけばいいだけです。
  システムは電子媒体にかかれた、コンピュータプログラム(命令)の集合
  ですから、紙(記述)にできないものは、システムにはできません。
  いかにシステムエンジニアに要望をつたえるか、これが、システム導入の
  重要な要素となるのです。

【DFD(データフローダイアグラム)】
  データの流れに注目して業務内容をモデル化する手法。

posted by 近藤SCO at 01:00| Comment(0) | プロジェクト管理 | このブログの読者になる | 更新情報をチェックする

【おすすめリンク】
テストステロンを増やす+免疫力アップでモテる男性力を仕上げる
一目置かれる人、仕事ができる人に必要なリーダースキルとは
乳酸菌道場!症状(免疫力アップ、便秘)に合う乳酸菌を選ぶ!

人気ブログランキングへ