プロジェクト の変更点
Top/プロジェクト
- 追加された行はこの色です。
- 削除された行はこの色です。
- プロジェクト へ行く。
- プロジェクト の差分を削除
プロジェクトとは何であるか？また、どのように関わるべきか？ ここでは、各フェーズの進め方/考え方について、新規導入をベースに背伸びして語ってみる。 ---- #contents ---- * 概要 [#w5942979] プロジェクトとは何か？ 昔或る人が''「始まりがあり終わりがあるという有機性（有期性）があり、唯一無二であること」''と言っていた。 前半はその通りだと思うが、後半については「ある時系列にやるからこそ、唯一無二」と言えるケースもあり、この定義はそぐわないかもしれない。 そこで、ここでは''定義した目標を、限られた予算・要員・期間の中で達成することを目的としたイベント''と定義する。 ** プロジェクトの成功とは？ [#ab0267d4] これは、端的に言えば''プロジェクト目標を達成したか否か？''に尽きる。 論拠は、基本的にYesかNoかで判定できるものしか目標として掲げるべきでないので、YesかNoかで判定可能な目標を達成したか否かに過ぎない、という背景から。 しかしながら、例えば予算が10万円超過したとしよう。これは失敗なのだろうか？ つまり、目標は定量的に立てるべきであるが、評価は必ずしもそうでなく、定性的な判定が入る余地があったり、定量的に判断できなかったりする。 これについては、導入後まもなく導入側と被導入側＝顧客に採点してもらうほか評価の方法はない。 ただし、一面的な評価を鵜呑みにしてしまわないよう、トップマネージャだけでなく現場レベルからも収集する必要がある。 ** 取り組むにあたっての姿勢 [#gd50f686] *** ユーザ側としての、在るべき姿勢 [#k9d04ca1] まず、''ベンダを信用しないこと。'' 彼ら、特に営業は仕事を取るためであれば美辞麗句を謳うことも厭わないし、結果として嘘となる発言もする。 現場の技術者も悪い人間ばかりではないが、基本的には「NoでなければYesと見做す」というスタンスで臨んでくるため、[[議事録>成果物/議事録]]を含めて各種[[成果物]]や説明資料の内容には必ず目を光らせること。 よくあるのが、ユーザ側でミーティングが終わった後「○○って、××じゃない？△△だと思っていたんだけど。」なんて内輪で話したりするが、そう思ったらミーティング中に言うべきであるし、本当に××の場合にもベンダ側は○○を前提に進めてしまって貴重なプロジェクト工数を無駄遣いすることになる。 無駄な時間と引き換えにして出来たはずの他のタスクができなくなってしまったり、完了が遅れたり、品質が下がってしまってはどうしようもない。 とにかく、受け身でなく能動的であることが肝要であり、全てのActionが望み通り行かないかもしれないが、それでも黙ってイライラしているよりはずっとマシなはずだ。 叶わぬ要望であっても、その理由が真っ当で、ベンダが「ちゃんと考えてくれて」「ちゃんと説明してくれたならば」、それはそれで信頼感が生まれるもの。 逆に、真っ当な理由づけもなく、こちら側が納得できる説明もなく、「できない」「難しい」という発言をするベンダは決して信用してはならない。 技術的なことや背景がわからなかったので質問しづらい、だなんて考えは捨てること。 わからないのはベンダの説明不足に起因すると割り切って((そこは、「こっちは客なんだから」と割り切ってok))、どんどんツッコミを入れて、バチバチに火花を散らす協議をしよう。 最終的には、それが良いOutputを短期間で生み出すことにつながる。 *** ベンダ側としての、在るべき姿勢 [#xc702203] まず、カウンターパートが情シスだろうと、彼らは素人だという意識を常に持ち続けること。 これは馬鹿にしろという意味ではなく、下手な伝え方をすると、正しく伝わらなかったり、誤った内容が顧客内で広がってしまったり、都合良く解釈したりされるということ。 また、彼らはサインオフという文化になれていないため「ここで仕様凍結して、今後は実装するのみ」という進め方の意義が分からず、最終的な品質への影響も鑑みず常に捻じ込んでこようとする。 また、「仕様凍結とか言われるのが嫌だから、サインオフしない」という馬鹿げたユーザすらいた。 そういった不愉快なユーザや役に立たないマネージャ、足を引っ張ってくる同僚や外注、将来性の全くない新人など、疫病の様に避けたい人間は多く存在する。 が、他のサービス業を見てみよう。 コンビニなんて程度の低い輩に命令口調で使われてしまうし、居酒屋、とくに赤提灯系なんてもっと最悪だろう。相手は酔っ払いなんだから。 何が言いたいかというと''世のサービス業は、もっともっと困った人を相手にしていて、もっともっと忙殺され、摩耗している''ということ。 影で悪口を言ったり、敬意を表しないのはいい。しかし客に対しては態度に出さないこと。 どんな劣悪な人間であっても、自分たちの報酬の源泉はその会社から頂いているのだから。 こういった不満は営業の持ってきた仕事をしているだけの技術者にありがちだが、文句があるなら、自分で仕事を取ってこよう。 そういった憤懣やるかたない思い、忸怩たる思いを噛み締めながらもプロジェクトを成功させることは、大きな成長に必ず結びつく。 プロジェクト経験者なら、そのプロジェクトを始める前と後で自分の力量に大きな差が生まれること、周囲にもそれがわかってもらえることを同意してもらえるかと思う。 *** 双方に共通する、在るべき姿勢 [#w42b2b81] プロジェクトの、というところに話を戻そう。 プロジェクトとは、先述の通り「目標を達成」が目標である。 これは、目標達成のための作業をずーーーーーっとやっていくことを意味しているのだが、プロジェクトには''やったら終わり''という作業は存在しない。 もう少し言えば、「全ての作業は、後の作業を進めるための作業である」ということ。 例えば[[概要設計書>成果物/概要設計書]]を書くのは、大枠の内容を合意した上で[[詳細設計書>成果物/詳細設計書]]に落とすためであるし、[[詳細設計書>成果物/詳細設計書]]はコーディングするために作成するわけだ。 然るに、''常に後々の作業をイメージして作業すること''が肝要であると言える。 中には「仕様書作って」と言ったら「○○仕様書というファイルを作ること」が目的かのように解釈してしまう人間も少なくないのだが、あくまで''作成物を元に後続作業ができるように、捗るように''という意識で臨まなければならない。 この例でいえば、詳細設計やコーディングができないような仕様書には全く意味がない。 顧客との関係上作成しなければならないドキュメントという例外が存在するのは確かだし、また有限の期間で限られているという人もいるかとは思うが、とにかく「後続作業の品質は、前段の作業次第」ということを忘れず実務にあたってほしい。 * 工程別 [#j5858972] 通常''フェーズ''と呼ばれる区切りについて、代表的な成果物を軸に。 ** 提案フェーズ [#k398cef2] -[[プロジェクト提案書>成果物/プロジェクト提案書]] ** 構想フェーズ/予備調査フェーズ [#cee5de7d] -[[Fit＆Gap一覧>成果物/Fit＆Gap一覧]] -[[機能一覧>成果物/機能一覧]] -[[移行対象一覧>成果物/移行対象一覧]]（第一版） -[[マスタ一覧>成果物/マスタ一覧]]（第一版） -[[追加開発一覧>成果物/追加開発一覧]]（第一版） ** 設計フェーズ [#p4d38ca7] -[[業務設計ドキュメント>成果物/業務設計ドキュメント]]参照のこと。 -[[プロトタイプ>プロジェクト/プロトタイプ]] --プロトタイプ方針 --データ定義 ** 開発フェーズ/実現化フェーズ [#m4f0f27e] -[[追加開発ドキュメント>成果物/追加開発ドキュメント]]参照のこと。 -統合テストシナリオ、エビデンス -[[ジョブ一覧>成果物/ジョブ一覧]] --[[ジョブ定義書>成果物/ジョブ定義書]] -[[権限仕様書>成果物/権限仕様書]] ** 移行/教育フェーズ [#l9953848] -移行 --[[移行>プロジェクト/移行]] -教育 --[[エンドユーザトレーニング>プロジェクト/エンドユーザトレーニング]] --[[キーユーザトレーニング>プロジェクト/キーユーザトレーニング]] --[[オペレーションマニュアル>成果物/オペレーションマニュアル]] ** 本番稼動・稼働後サポート [#u5d92a4a] -本番移行 残高移行、伝票残移行、在庫移行 -ゴーライブチェック パフォーマンスやシステム構成が要件に適しているかなど潜在的な問題のチェックという意味が一つ、課題解決や[[アドオン]]実装スケジュールの消化状況などの観点でのチェックという意味が一つ。 ** 保守・運用 [#z06f277f] -引き継ぎについて * 推進の考え方 [#y218f161] 下記の要素が挙げられ、詳細は個別に。 ** 進捗管理 [#tbe7f330] 作業内容・担当者・納期を明確にした作業予定を[[WBS>成果物/WBS]]化し、最終的な納期を遵守するため、状況を（出来れば日々）チェックする。 何をすべきで、実際の進捗はこれこれ、リカバリプランの提示、そしてそれらのステータスを総員が共有することが肝要であり、形式的ばった冗長な報告は時間の無駄というもの。 よく何パー終わった的な表現の仕方をするが、パーセンテージの基準を作ると尚よい。 特に多くの人間が実施するテスト系のイベントなどは素人同然の人間が入ってくることもあるため、定量的な物差しを用意することで各人の認識のバラツキを抑制する。 なお、たまに''虚偽申告をしてくる人間''がいるが、こういう人間は客前だろうとプライムの前だろうと周囲が引く程の公開処刑を実施しなければならない。場合によっては即日で引き揚げさせる。 黙認してこれが横行した時に、プロジェクトが失うものが大きすぎるからだ。 ** 品質管理 [#rc3cc8f5] 作成物に関する品質基準を設定しレビューポイントを設けることで、品質面で発生する手戻り作業を軽減することを目的とし、基本的には全成果物に対し実施すべき。 -レビューポイントについて 対象のテーマや工程により、またレビュー者によって指摘の観点は異なり、ある程度は仕方ないとして、底上げや不整合を防ぐため、管理基準を作成し、網羅的にチェックすべき。 また、要件変更など承認済みの作成物を変更する必要が生じた場合は、全体の品質を向上するため、後述の変更管理と同期して基準を追加/更新することでフィードバックする。 また、育成中の人間に対して、「どこが、どういう理由で、評価基準になるのか」を明示することにより手戻りの防止とコツをピンポイントで伝えることができる。 -レビュー後フォロー とにかく「ベンダー側が作成し、ユーザ側のレビューを経て、正式に承認とする」というプロセスを遵守する。 忙しさを理由に省略しても、手戻りするだけであるからだ。 レビューについては、指摘しっ放し・対応しても報告しない・報告を受けても確認しないetcの「やらない病」を仕組みで軽減したいもの。 やらない病の患者ほど評論家目線で無責任な放言をするため、このせいで下がってしまう周囲のモチベーションも勘案すべきかと思う。 ** 課題管理 [#e3ae11f7] 長くなったので、[[こちら>プロジェクト/課題管理]]を参照のこと。 ** リスク管理 [#aeeb8d59] 全体のスケジュール遅延や予算超過となる恐れがあるトピックについて重点的にケアし、インパクトを極小化する。 進捗会議で健在化したリスクは勿論のこと、リスク予備群をいち早く察知し、対応策を検討・実施することが肝要となる。 雑な人間や、今までこれでやってきましたから！的な残念な人には見えづらいところなので、これはPMやリードが他の要素以上に目を光らせなければならない。 しかし、心配性の人間はそれはそれで「なんとなく不安、という気持ちに支配されがちなだけ」だったりしてあまり役に立たなかったりするため、これはこれで難しい。 ** 変更管理 [#o331769f] 問題管理の対応として、システムの変更を必要とする場合の手順について基準を設定し、迅速かつスムーズな対応を推進することを目的とする。 -目的 導入先組織・導入コンポーネントなどのプロジェクトスコープを変更する際には、重要性・現実性・作業スケジュールへの影響などを充分に考慮した上で、その採否を決定しなければならない。 これを軽視してしまうと、プロジェクト目標の達成を阻害したり、納期や予算の超過を招くためだ。 従い、変更依頼は個別に厳格な審査を行った上で採否を決定し、少なくともプロジェクトのキーパーソン全てが結果を共有する必要がある。 -変更管理の対象 システムへの実装やドキュメントは勿論のこと、プロジェクトスコープ・作業期間、ベンダとユーザの作業分担など、「変更するもの」は須らく対象とする。 -影響分析 己が所属するチームタスクへのインパクト、他チームタスクへのインパクト、スケジュールへのインパクトなどを明確にする。 これを軽んじると、安請け合いになってしまうなど感情的なトラブルになりやすい。 -判定プロセス これについてもプロセスが非常に重要であり、個別随時なり週次なりでジャッジするべきと考える。 インパクト小・リスケ可能・要員追加・他のテーマとトレードオフ。 これらの何れかが是ならばやるし、すべてNoなら実施しない（できない）というロジックが明確化と思う。 また、やるにしろやらないにしろ、必ずログは残す。 * 地雷 [#rde85e35] プロジェクトは地雷原であり、迂闊に進めると足がモゲる。 筆者が考える地雷を下記に。 ** ユーザを入れない [#i6c8fae4] 何故か昨今は情報システム部「だけ」がカウンターとなる事例が多いように思う。 情シスという組織は然程ヒマではないはずはないし、情シスが窓口になることに異を唱えるつもりはないが、とにかく''ユーザに参加させない''というプロジェクトは少なくない。 何でもかんでも言うことを聞くという話では当然ないが、ベンダや情シスに分からないこと・そこまで重大だと認識していないことがクリティカルだったりと、実際の利用者抜きに語るということ自体が有り得ない話である。 もしそういう進め方をしてしまうと、ユーザの感度が見えるのはトレーニングや運用テストの段階になってしまい、既に工程の三分の二は消化しているであろうプロジェクトのスケジュールで、残り三分の一程度で想定済みのミッションと想定外のタスクを必死こいてこなす羽目になる。 もちろん慌てて「終わらせること」を第一優先にした仕事など充分な要求・品質を満たせるわけもなく、度重なる変更と試験が繰り返される地獄絵図となる。 但し、ユーザの意見を取り入れる = [[アドオン]]祭り・・・という訳ではなく、もちろん[[BPR>プロジェクト/BPR]]が大前提であることは補足しておく。 ** スケジュールが非現実的 [#pac99052] Budgetの問題もあるし無理無理いってても仕事なんて取れないんだよ！という声もあり、痛いほど理解できるのだが、無理なもんは無理としか言えないケースが少なくないのは事実である。 一般的に、予算や期間を削った時に真っ先に犠牲となるのは品質である。 案件が取れないことも死活問題だが、低品質なものを納品したりそもそも納品まで行けなかったりすれば、そのユーザからは二度と仕事がもらえなくなってしまう。 他社事例を気にするユーザは少なくなく、それをきっかけに会社同士の交流ができるケースすらあるわけだが、一度立った悪評はそういった場の話題にもなり中々消えないわけで、最悪の場合は顧客の同業や関係会社にまで広がり得る。 ** インタフェースが多い [#p534b07a] 何でもかんでもSAPに詰め込むことが正しいとは考えていないし、住み分けるところは住み分けた方が設計も実装も運用もシンプルになり、維持コストも安上がりになることもある。 が、何でもかんでも繋げばいいってもんでもない。[[インタフェース>アドオン/インタフェース]]という本来なくて良い[[アドオン]]が増え、SAP内部では考慮する必要のないシステム間の互換性もケアする必要があり、運用コストも高くつくことになる。 また、余程メジャーなものでなければ「SAPとその顧客の対象システム」の専門家など業界内に多いはずもなく、属人化の温床となりやすいことも懸念事項として挙げられる。 ** 上層部が残念な人 [#u8214970] これは避けようがない。 ユーザが残念な人である場合でも我慢できることは多いが、自軍に足を引っ張られてしまうと、自らを含め[[プロジェクト]]の士気がブチ壊しになる。 自分なりに動いてみて、それでもダメなら抜けるという「損切り」のようなアクションしか取ることはできないが、含み損が極大化する前に尻尾巻いて逃げるが吉。 ** 一部モジュールだけ入れようとする [#x6992859] もちろんこれは稼働後に「じゃあ[[AA>財務会計/固定資産管理]]も入れましょう」なんて話ではなく、新規導入の話である。 *** 導入に旨味がない [#a75d6eb1] そもそも[[ERP>SAPの共通用語/ERP]]は定食みたいなもんなので、頼んでおいて小鉢やお新子を残すならまだしも、米やメインディッシュを食わないなら単品で頼んだ方が余程いい。 つまみ食いの体を取る以上はプロジェクト目標に大したものを掲げられないのだから、少なくともユーザが評価する「コストに見合う成果」などは出るはずもない。 *** 他のモジュールを考えずにデザインされがち [#u9dc65b8] 一部導入の最たるものは[[財務会計]]のみの導入であるが、システムのデザイン、即ち[[主要マスタ>SAPのマスタ]]や[[組織定義>SAPの組織構造]]などは鳥瞰的に見渡してトータルで決めなければならないが、例えば[[FI>財務会計]]だけの導入であればFIコンサルだけがアサインされるはずで、ロジの世界を勘案しつつなんてできるはずもないでしょという話になる。 *** ロールアウト時に、プライムに継続発注する意義が少ない [#mc3f7f06] 上記とも少し関連するが、例えば[[FI>財務会計]]だけの導入であれば、次に[[SD>販売管理]]や[[MM>在庫・購買管理]]も入れましょうという運びになったとしても一次導入ベンダを再選択するメリットがあまり無いことになる。 具体的には、一通りのモジュールを導入したのならば一次導入ベンダは「ある程度、御社のことは総合的な勉強させて頂いたという自負があります」くらいのことは言えるはずだし、ユーザとの関係が悪くないのであれば、向こうにとっても「他に頼んで、また一からキャッチアップしてもらうよりかは・・・」という損得勘定もはたらく。 しかし[[FI>財務会計]]だけに限れば、誤解を恐れずに言えば''どこだって、やってることは大して変わらない''わけで、見積もり価格やスコープの話し方ひとつで継続発注は選択肢のひとつ以下になってしまうだろう。 逆にいえば、自社が導入ベンダでない場合、そういった導入事例を持つユーザから追加案件があれば、プライムを尻目に横から攫っていくことができる・・・と言うこともできる。 * 関連ページ [#ydcb9a52] -[[多言語対応>プロジェクト/多言語対応]] -[[ドキュメンテーション>プロジェクト/ドキュメンテーション]] -[[V-Model>http://ja.wikipedia.org/wiki/V%E3%83%A2%E3%83%87%E3%83%AB]] #ls(プロジェクト/) ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_book_sap_system_implement) ~ ~ ---- #pcomment(reply)