Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
Semelhante a 20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1 (20)
20160710_PMI日本フォーラム2016_講演資料_ITI小久保v1.1
- 2. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 2 プロフィール • ⼩久保 久⼦（こくぼ ひさこ） • 株式会社アイ・ティ・イノベーション コンサルタント 【略歴】 独⽴系システムインテグレータにて、主にオープン系システムの開発 プロジェクトの提案、プロジェクトマネージメント、要件定義、デー タベース設計、実装等に責任者として関わり、プロジェクトの企画・ 構想から開発、インフラ構築、移⾏、運⽤保守に⾄るまで、幅広い実 務経験を重ねた。 ２０１２年より株式会社アイ・ティ・イノベーションにおいて、⼤規 模プロジェクトのプロジェクトマネジメント⽀援、トラブルプロジェ クトのＱＣＤ問題発⽣の原因分析、現⾏分析（業務、データモデリン グ）、システム化構想の⽀援等を⼿がける。
- 3. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 3 Agenda １．トラブルプロジェクトの経験はありますか？ ２．トラブルになりやすいプロジェクトについての考察 ３．トラブル対策としての“計画”の取り扱い
- 4. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 4 トラブルプロジェクトの経験は ありますか？
- 5. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 5 トラブルプロジェクトの経験はありますか？ ＩＴのプロジェクトはトラブルに陥ることが多いと⾔われています。 トラブルプロジェクト： ・何らかの問題が発⽣し、その解決が困難な状況を抱える プロジェクト トラブルとなったプロジェクトを経験、あるいは遭遇したことがあり ますか？
- 6. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 6 ＩＴプロジェクトのトラブルの事例 こんなことを経験してます。 【トラブルのパターン 症状例】 ４.⼈間関係の崩壊・⼈材損失 １. スケジュール ２. コスト ３. 品質 ⼤⽇程がメンテされず、半年後の計画がわからない。 仕様変更の多発などで、当初予算の倍どころか、Ｘ倍に・・・・ ボタンクリックして、結果が表⽰されるまで30分・・・ ある⽇突然出社しなくなるメンバー・・・
- 7. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 7 トラブルプロジェクトがたどる経過 ＩＴプロジェクトでよくみられるトラブル発⽣とその経過 ちょっとずつ 遅れが表⾯化する。 突然、⼤きな問題が 表⾯化する。 対策会議 ＆ リカバリー 案の策定 残業 リソース 投⼊ スケ ジュール 延⻑ 収束 無限 ループ化 ＰＪ予算 枯渇 追加予算獲得 ＰＪ中断 再炎上
- 8. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 8 トラブルがトラブルを⽣み⼈間関係崩壊に⾄る悪化パターン例 スケジュール、コスト、品質のどれかで問題が起こると、連鎖して他の領 域で問題が発⽣します。通常業務と並⾏して対応にあたる現場のＰＭ、担 当は⾼負荷となり、それが続くと、些細なきっかけで⼈間関係が崩壊する ことが結構な頻度で起こります。 ⼈間関係の崩壊 スケジュール が遅れる 想定した コストを 超過 追加要員 投⼊ 品質 チェック 漏れ プレッシャー ストレス 疲労・不満 の蓄積 ミスの 発⽣ マネジメント 負担増 管理が 不徹底 課題 滞留 負担増 （残業） ⽣産性が 落ちる 感情的な 対応 課題増 状況悪化
- 9. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 9 リソース投⼊で、トラブルが⼤きくなることも トラブル解決には、問題を解決できるスキルを持つ要員と解決の為の時間 が必要なのですが、重⼤プロジェクトほど、解決を急ぎ、⼀度に⼈を 増やして、逆に泥沼に陥ることがあります。 【⼈を増やしてもトラブルが解決しない理由】 ・増えた要員が⾜⼿まといになり 問題解決に集中すべき要員＝現場のキーマンが問題解決に着⼿できない。 ・無駄な成果物が増え、情報が⾒つけにくく、⾒える化が遠ざかる。
- 10. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 10 ⽴て直しの定⽯ 【トラブルプロジェクトの⽴て直しの定⽯】 ：ＰＪ継続、開発体制拡⼤、ＰＭチームが問題解決 ：ＰＪを中断、計画⾒直し ：ＰＪ継続、別働隊で現状の⾒える化、計画策定、⽴て直し 困難 安全
- 11. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 11 トラブルになりやすい プロジェクトについての考察
- 12. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 12 過去に経験したトラブルになったプロジェクトの特徴 こんなタイプのプロジェクトは、経験的にトラブルに巻き込まれがち パターン２ パターン１ ⼤規模システム再構築（ハード保守切れ）× 多段階リリース “標準システム”の開発プロジェクト
- 13. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 13 パターン１ ⼤規模・多段階リリース ⼤規模システム再構築（ハード保守切れ）×多段階リリースプロジェクト ・ハードの保守切れ対応必須のレガシーシステムの再構築 ・基本構想後、開発プロジェクトを分割し、段階リリース（⼀部並⾏開発） ・再構築範囲全体の検討 ⇒ 分割後の個々のＰＪの検討 このタイプ特有の失敗パターンがあるのでは？
- 14. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 14 ⼤規模・多段階リリースで発⽣するトラブルを予想してみてください 【基本構想】 細かいことは個々で検討？ Ａ機能の開発プロジェクト ⼤枠の検討 Ｂ機能開発プロジェクト Ｃ機能開発プロジェクト あるべき姿 Ａ機能 Ｂ機能 Ｃ機能 【個別プロジェクト】 ここの部分の 乗り越え⽅に注意 ？どんな問題が 発⽣したと思いますか？
- 15. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 15 ⼤規模・多段階リリースのトラブル発⽣の背景 ・新旧並⾏稼働期間の対応の検討不⾜ or 検討タイミングの遅れ →移⾏設計が完了できない。移⾏できない。 ★プロジェクト分割するタイミングが問題だった 基本構想後、機能範囲で分割し、並⾏開発に着⼿した。 ⇒段階的詳細化を⾏ってから分割しないと、 分割後のプロジェクト間で機能の漏れが発⽣するリスクがある。 割り当てられた範囲を対象とするため、割り当てられてない グレーゾーンの存在に気が付かない。 トラブル
- 16. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 16 ⼤規模・多段階リリースのトラブル発⽣の背景 【基本構想】 分割単位の 妥当性が 判断できるまで 検討を詳細化 すべきだった Ａ機能＋ｘの開発プロジェクト ⼤枠の検討 Ｂ機能＋ｙの開発 プロジェクト Ｃ機能＋ｚ開発 プロジェクト あるべき姿 Ａ機能 Ｂ機能 Ｃ機能 【個別プロジェクト】 移⾏期の 検討は 全体視点が 必要 新ＡＡ Ｂ Ｃ 新Ｂ 新Ｃ 新ＡＡ Ｂ Ｃ 新Ｂ 新Ｃ 新ＡＡ Ｂ Ｃ 新Ｂ 新Ｃ 【詳細検討】 全体詳細化 現⾏機能改修、移⾏ 共通機能など・・ 検討が遅れた要素 ここを スキップ
- 17. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 17 利⽤イメージ 多段階リリースが難しくするのは新旧仕様の差 業務機能 基盤 運⽤保守体制 保守運⽤で 必要な機能 システム機能 ⽬的・狙い ここだけ？ ここまで 考える 利⽤イメージ システム機能 利⽤イメージ システム機能 移⾏期の検討の難易度が⾼い 難易度を落としリスクを 下げるには？どうすべき？ ・新旧仕様の差を吸収して移⾏ ・新旧両⽅のＩ／Ｆ ・旧機能の理解
- 18. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 18 難易度を落としリスクを下げるには？ 【基本構想】 第１プロジェクト ⼤枠の検討 第2プロジェクト 第3プロジェクト あるべき姿 Ａ機能 Ｂ機能 Ｃ機能 基本構想⾒直し ×詳細化×開発 基本構想⾒直し ×詳細化×開発 基本構想⾒直し ×詳細化×開発 ・範囲を狭め、少しずつ進める。 ・並⾏開発を⾏わない。 代案 ・旧仕様をそのまま移⾏
- 19. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 19 パターン２ “共通システム” “共通システム”の開発プロジェクト “共通システム”の開発プロジェクト特有の失敗パターンが あるようです。 ・グループ会社、関連会社で共同利⽤する“共通システム”の開発 ・各社への展開 個別の要件を機能追加
- 20. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 20 “共通システム”で発⽣するトラブルを予想してみてください 【基本構想】 細かいことは個々で検討？ 共通機能の開発プロジェクト ⼤枠の検討 Ａ社向けのプロジェクト あるべき姿 共通 システム 【個別プロジェクト】 ここの部分の 乗り越え⽅に注意 Ｂ社向けのプロジェクト 個別の要件 個別の要件 ？どんな問題が 発⽣したと 思いますか？
- 21. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 21 “共通システム”のトラブルの発⽣の背景 ・標準機能の範囲、仕様決定責任者不在。要求仕様が固まらず。 ★そもそも標準システムの開発⽬的があいまい。 ・各社の固有要件と共通機能がフィットせず、 保守や追加開発のコストが膨らむ。 ・展開途中、展開後の運⽤、保守も含めたイメージを 構想時に検討しておらず、リリース間際に無理やり機能を追加した結果、 保守、運⽤が困難、コスト負担が重くなる。
- 22. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 22 Ａ〜Ｃ社で共通システムを 利⽤しているイメージ “共通システム”のトラブルの発⽣の背景 業務機能 基盤 運⽤保守体制 保守運⽤で 必要な機能 ⽬的・狙い ここに着⽬？ ここまで？ Ａ社 利⽤イメージ システム機能 どうアプローチ したらいいと思いますか？ Ｂ社 利⽤イメージ システム機能 Ｃ社 利⽤イメージ システム機能 個別の要件 全展開後の 最終イメージ 共通 機能 共通のマスタ、共通基盤 共通・個別の各モジュー ルの管理⽅式 検討が遅れた要素
- 23. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 23 Ａ～Ｃ社で共通システムを 利用しているイメージ 難易度を落としリスクを下げるには？ 業務機能 基盤 運⽤保守体制 保守運⽤で 必要な機能 ⽬的・狙い ここまで 考える 業務を標準化 ・対象範囲を絞り、 業務の標準化を先⾏ ・標準業務をもとに、 必要な機能仕様を決定 （エンドユーザに協⼒を得て、個別要件を削減） 共通システムの 仕様決定 Ａ社 利⽤イメージ システム機能 Ｂ社 利⽤イメージ システム機能 Ｃ社 利⽤イメージ システム機能 個別の要件
- 24. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 24 共通システムの開発の失敗しにくいアプローチ 【基本構想】 細かいことは個々で検討？ 共通化＋Ａ社導⼊プロジェクト ⼤枠の検討 Ｂ社向けのプロジェクト あるべき姿 共通システム 【個別プロジェクト】 ここの部分を 乗り越えやすい 成功ＰＪ Ａ社 Ｂ社 Ｃ社 Ｄ社 現実にあるものから 構想するので、 漏れが発⽣しにくい
- 25. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 25 利⽤イメージ 機能ではなく、 “稼働後の姿”を想定すること 業務機能 基盤 運⽤保守体制 保守運⽤で 必要な機能 システム機能 ⽬的・狙い ここだけ？ ここまで 考えないと 動かせない、 ぶれる ざっくり イメージ あいまい よくわからないし 後で考えよう ＩＴ系の開発ＰＪでは、しばしば、移⾏や運⽤の検討が後回しになったり、 漏れたりします。最初から想定していれば簡単な要求でも、漏れや認識の ずれが稼働直前に発覚すると、簡単に解決できません。 多段階リリースや、共通システムを複数の展開先に適⽤する場合に問題が深刻化 するのは、もともと要件が難しく、広範囲に及ぶ背景があり、⼈海戦術で解決する レベルを超えてしまうため。
- 26. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 26 ＩＴのプロジェクトの成功は基本構想 1. 要求の取りまとめ 1.1 ビジネスの ⽅向性を 理解する 1.2 現⾏の業務・ システムを 把握する 1.3 業務・システム の要求を 概括する 3. 実現シナリオの策定2.業務・システムの概要定義 2.1 業務プロセスと データの概要を 可視化する 2.3 技術的な アーキテクチャ を定義する 3.1 実現のシナリオ を策定する 3.2 企画の承認 を得る トップダウン 視点 ボトムアップ 視点 2.2 業務運⽤の 体制を定義する 2.5 ソリューション候補を評価する 2.4 移⾏を 検討する ＨｏｗＷｈｙ Ｗｈａｔ 基本構想の検討不⾜は、後のトラブルにつながります。 （基本構想時の予算、体制等の枠組みを、後から変えることは難しいため） 基本構想をちゃんとやることが⼤事です。 弊社の（IT構想・企画方法論）：ModusIP
- 27. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 27 トラブル対策としての “計画”の取り扱い
- 28. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 28 そうはいっても、⽬の前にあるプロジェクトをどうすれば？ 計画策定 基本構想は終わってしまっていて、⽬の前のプロジェクトをどうにかしない といけないのだけど・・・
- 29. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 29 トラブルプロジェクト化回避のための“計画のトリセツ” 深刻なトラブルプロジェクトに巻き込まれない為の計画の扱い⽅について、 気にしていることを“計画のトリセツ”としてまとめてみました。 ＰＪ実⾏前 ＰＪ実⾏中 ＰＪ実⾏後 計画 計画 計画 計画 計画 計画 計画 計画 計画 計画の⾒直しは 必要なこと 過度な罪悪感を 抱くのはやめる。 実績は経験、 ノウハウの塊 計画はチームを 導く航海図 ⽬的地にたどりつける 地図を作る
- 30. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 30 計画のトリセツ ①わからないところを深堀り プロジェクトにはリスクやチャレンジが伴います。限られた時間の中で精度 の⾼い計画を⽴てるため、ポイントを絞って深堀りをします。 【計画作り、⾒直しのコツ】 ・わからない箇所、経験のない箇所ほど深く分解しタスクの内訳や 作業内容を具体化する。 経験がある場合は分解のレベルが粗くても致命的な問題にはならない。 細かくしすぎず、管理しやすいレベルにとどめておく。 →この逆をやってしまうことが多い。
- 31. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 31 計画のトリセツ ①わからないところを深堀り そうは⾔っても、わからないところをどうやって深堀りするのか？ ・わからないところは、前提を置いて考えてみる。 ・イメージ図を書いてみる。 ・わかっている数字はないかチェックする。 ・⼀⼈で考えない。専⾨家や実⾏担当者からアイディアを引き出す。 ・まったく分解できない場合は、調査や試作のタスクを追加
- 32. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 32 計画のトリセツ ②保留事項と段階的詳細化のタイミング 保留事項と段階的詳細化のタイミングを定義 【計画作り、⾒直しのコツ】 ・計画のどこが“保留中”なのかを表現する。 ・保留中の事柄が、いつ決定状態になるのか、担当責任者、 マイルストーンを決めておく。
- 33. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 33 計画のトリセツ ③理解しやすく、状態が把握しやすいレベル感 計画はプロジェクトマネージャ、実⾏担当者だけでなく、プロジェクトオー ナや業務部⾨のリーダなど、多くのステークホルダー間のコミュニケーショ ンのベースになります。理解しやすさ、わかりやすさを意識する。 【計画作り、⾒直しのコツ】 ・全体が俯瞰でき、プロジェクトの構成要素が読み取れること Ａ３で1ページが⽬標 ・作業分担、成果物との対応を明確にする。 ・⾔葉の選択に気を使う。 ・厳密な規則性より、わかりやすさ ・進⾏途中をイメージし、途中経過がわかりやすく⾒せられかも 考える。
- 34. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 34 計画のトリセツ ④計画の範囲を⾒誤らない 計画を⽴てるときは、計画しないといけない範囲をちゃんと確かめます。 ＩＴプロジェクトの失敗パターンで多いのは、作りたいシステムに着⽬し すぎ、システムが動くのに必要な準備作業が漏れてしまうパターンです。 【計画作り、⾒直しのコツ】 ・範囲のちょっと外側を意識すること 運⽤開始後の姿をターゲットにする。 時間軸に沿って、プロジェクトの状態やターゲットの姿を イメージする。
- 35. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 35 計画のトリセツ ⑤丸投げ禁⽌ 集めてコピペが楽だけど 実⾏担当者に担当分の計画を⽴案させ、それを寄せ集めれば全体の計画にな るという訳ではありません。 担当間の整合性チェックは全体が⾒えているプロジェクトマネージャの責任 であることを忘れない。 【計画作り、⾒直しのコツ】 ・実⾏担当者と⼀緒に、範囲の⾒落としがないか、依存関係の洗い出しが できているかチェックすること ・成果物の内訳が全体を網羅できているか確認 ・実⾏者に分解、⼯期、⼯数の⾒積を依頼した場合も、⾒積の構造、 裏付けを理解し、状況が変わった場合に、プロジェクトマネージャが シミュレーションできるようにしておく。
- 36. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 36 計画のトリセツ 番外 ツールを使ってみよう ツールを使いこなせるようになる！ 条件を変えて、依存関係の⽭盾や、リソースの負荷の偏りのチェック等は ツールを使えば時間を短縮できます。 本当に考えなくてはならないことを考えるため、計画ツールの⼒を 活⽤しましょう。
- 37. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 37 計画のトリセツ ⑥⾒直し、変更は必須 計画は関係者全員にとって頼りになる信頼できる情報源であり、地図ですが、 達成すべき⽬標ではありません。 ⽬的地に到達できるルートが他にも存在しているかもしれませんし、 遠くからはわからなかった近道が⾒つかるかもしれません。 計画時点で⼊⼿できる情報には限界があり、変化が速いＩＴ業界では、 ⾒込みがはずれることもあります。 過度な罪悪感を持つのはやめ、前向きに、タイミングよく適切な打ち⼿を 繰り出せるスキルを磨くべき。
- 38. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 38 最後に・・・計画変更の履歴はノウハウの宝庫 当初計画から、プロジェクト実⾏中の変更を経て、完了に⾄る計画の 履歴から得られるものはたくさんあります。 より安全で、より早く、より多くの投資効果を得られるアプローチは ないか、⾃分なりに考えてみましょう。
- 39. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 39 ご参考
- 40. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 40 ＩＴＩ⽅法論・ シリーズ 『 』シリーズは、⻑年アイ・ティ・イノベーション社が実務を通して蓄積したノ ウハウを体系⽴て、そして実⽤的にまとめた⽅法論です。企画、プロジェクトマネジメント、 ＭＤＭ（Master Data Management）、⾒積り、開発、テスト、運⽤、⼈材に関する８つの ⽅法論があります。 ※ （モーダス）＝ラテン語で「⽅法(論)」の意味。 システムの開発規模や⼯数を⾒積るためのフレームワークを提供する⽅法論です。 （⾒積り⽅法論） ＩＴにかかわる⼈材の育成や能⼒開発、⼈材管理のための考え⽅やプロセスを体系的にまとめた⽅法論です。 （⼈材戦略・⼈材育成⽅法論） システム開発プロジェクトをマネジメントするための考え⽅やプロセスを体系的にまとめた⽅法論です。 （プロジェクトマネジメント⽅法論） システムを構想・企画するための考え⽅やプロセスを体系的にまとめた⽅法論です。 （IT構想・企画⽅法論） システムによるサービス提供を維持・管理していくための考え⽅やプロセスをまとめた⽅法論です。 （SLA・SLM⽅法論） （システム開発⽅法論） 分析、設計、プログラミング、テスト、移⾏といったシステムの開発⼯程全般について体系的にまとめた⽅法論です。 テストの計画、設計、準備、実施、およびマネジメントのための⽅法論です。 （テスト⽅法論） 企業システムにおけるMDM環境を設計・構築するための考え⽅やプロセスをまとめた⽅法論です。 （MDM設計構築⽅法論）
- 41. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 41 ＩＴＩ⽅法論の体系 要件 定義 外部 設計 内部 設計 プログラ ミング 単体 テスト 結合 テスト システム テスト 運⽤テスト 移⾏ ⽴上げ 計画 実⾏、監視コントロール （進捗管理、品質管理、変更管理、リスク管理、構成管理、外部委託管理） 終結 IT構想・企画 運⽤・保守 (運⽤、保守、ｻｰﾋﾞｽﾚﾍﾞﾙ) ⼈材育成計画、トレーニング、評価、改善 戦略・企画プロセス ⼈材育成プロセス 株式会社アイ・ティ・イノベーション ⽅法論－Modusシリーズ 情報システムマネジメントプロセス プロジェクトマネジメントプロセス 経営戦略 事業戦略 IT戦略 BABOK®に準拠 PMBOK®に準拠 （⾒積り⽅法論） （⼈材戦略・⼈材育成⽅法論） （プロジェクトマネジメント⽅法論） （IT構想・企画⽅法論） （SLA･SLM⽅法論） （システム開発⽅法論） （テスト⽅法論） ＭＤＭ（Master Data Management）構築 （MDM設計構築⽅法論） システム開発プロセス
- 42. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 42 アイ・ティ・イノベーション 会社概要 会社名 株式会社アイ・ティ・イノベーション （IT innovation, Inc.） 所在地 〒108-0075 東京都港区港南4-1-8 リバージュ品川5階 設⽴年⽉⽇ 1998年7⽉1⽇ 資本⾦ 1億円 代表取締役 林 衛 従業員数 45名（2015年6⽉末現在） 売上⾼ 8.95億円（2015年6⽉期） 事業内容 １．ビジョン・戦略策定⽀援 ・ビジョンの策定⽀援 ・IT事業戦略・中期計画策定⽀援 ・⼈財戦略／⼈財育成のための仕組み、⾒える化⽀援 ２．ITアーキテクチャ⽀援 ・⽅法論の導⼊と定着化⽀援 ・プロジェクトに対するマネジメント実⾏⽀援 ・プロジェクトマネジメント⼈財の育成⽀援 ３．BA（ビジネスアナリシス）⽀援 ・⽅法論の導⼊と定着化⽀援 ・IT構想・企画書作成⽀援 ・IT構想・企画⽴案⼈財育成⽀援 ４．PM（プロジェクト・マネジメント）⽀援 ・⽅法論の導⼊と定着化⽀援 ・プロジェクトに対するマネジメント実⾏⽀援 ・プロジェクトマネジメント⼈財の育成⽀援 ・ホームページ http://www.it-innovation.co.jp/ ・ITプロジェクトの現場で活躍するPMの為のブログ 「ザ・グローバル・イノベーターズ」 http://www.it-innovation.co.jp/blog/
- 43. Copyright (C) 2016 IT innovation,Inc. All rights reserved. 43 ＥＮＤ ご清聴ありがとうございました。 株式会社アイ･ティ･イノベーション 〒108-0075 東京都港区港南4-1-8 リバージュ品川5F Tel： 03-5783-2811 / Fax： 03-5783-2813 URL： http://www.it-innovation.co.jp ※ は、株式会社アイ・ティ・イノベーションの登録商標です。 ※ Modusは、株式会社アイ・ティ・イノベーションの登録商標です。 ※ 本⽂中の会社名、商品名は各社の商標または登録商標です。 ※⽅法の如何を問わず、全部もしくは⼀部の無断での複写・転載を禁じます。 IIBA® 、BABOK® 、およびBusiness Analysis Body of Knowledge® は、 International Institute of Business Analysisの登録商標です。これらの商標は、 International Institute of Business Analysisの許可を得た上で使⽤しています。