| 標準を基準として逸脱している部分に注目を集める事ができる（管理者の立場）し、作業者はやるべき事とやる内容が示されているのであれこれ考えなくても済む（効率的かつ品質の標準レベルは達成できる）反面、作業者は深く考えなくなり、提示されている事を形式的にこなすようになる。それが原因で問題が発生する事もある。プロセス標準はベストな品質ではなく、最低限の品質を保証するためのものであることを理解して実装しないとただ理想的な実現できないものになってしまう |
匿名希望 |
| 早期プロジェクト着手のため、またプロジェクト毎の品質等レベルの均一化のため必要と考えます。メリットも同上です。デメリットは標準プロセスの枠に縛られる人がいるのではと思います。 |
中島 亮様 |
| メリット：俗人性を少なく出来る。初心者・初級者でもある程度のレベルまでを行うことが出来る。組織としての教訓が活かせる。デメリット：テンプレート等のメンテナンスが大変である。 |
ふじ様 |
| 臨機応変（対ユーザ）に関しては威力を発揮しない。メリットは、初心者でもある程度作業を進めることができる。 |
Gosa様 |
| 属人性を排除し、管理品質を一定以上のものとするために必要。 |
yoshiki様 |
| ISO9001:2000の運用を行っております。今までのところ、ISO9001＝品質向上という意味で運用しておりまいしたが、現場への浸透を促すにはなかなか難しい面があります。ですので、ISO9001＝プロジェクトマネジメントという意味で運用を行えば、現場への浸透も本当の面での品質向上につながる運動になるのではないかという意味で、プロジェクトマネジメントのさらなる向上を勉強しております。標準プロセスを決める必要性は、マニュアル化ができる（マネジメントシステムが構築できる）OR しなければならないという必要性があるからです。メリットはマニュアル化することにより、誰もが同じプロセスでプロマネを行うことにより、品質の保たれた製品を顧客に供給できるという面があるかと思います。デメリットは、標準プロセスに対しての例外処理が発生した場合に個別対応となることです。ただし、これも同じような事例が発生すれば、標準プロセスに取り込み、標準プロセスを改善していく活動につながるとかんがえます。ただし、これもＰＭＯ的な支援組織が必要になり、組織的な対応が必要不可欠かと思われます。 |
いしばし様 |
| 標準化を実施すると、第三者が見えやすくなり、凡ミスや違う方向性を矯正するのには役にたつが、その第三者がいい加減な人やプロジェクトを理解しない人になった場合は、一瞬にしてプロジェクトの不良債権を抱え込む事になるので、標準化を貫く場合は、ステークホルダーがどれだけプロジェクトを理解しているかに依存します。結論として、標準プロセスは必要なものではあるが、問題はステークホルダーが理解できる人間かどうかにかかってくると思います。 |
まんてん様 |
| プロセスの単位が細部に渡ると作業することが負荷となり、おおまかにすると作業が曖昧となりアウトプットが統一されないため、プロジェクトごとに一番効率的なプロセスを計画時に取り決め、定期的に見直し改善していく。又、大型プロジェクトでは、各プロセスのアウトラインを共通化して、個々の具体的作業プロセスは、タスクやグループ毎に自由に取り決め、共通プロセスを強要しないことが必要。 |
岡本 直樹様 |
| 業務の品質を一定レベル以上に保つ（これがメリットだと思う）ためには標準プロセスの存在が必要だと思うが、実際には属人的なノウハウによって運営されており、時間が経つにつれて馴れ合いが生じているため、業務マニュアルが形骸化（デメリット）している。 |
よし様 |
| 弊社ではマネジメントのプロセスが無く、マネジメント担当者のマネジメント力の底上げのためにも必要であると考える。ただ、実際にプロセスを作る（実装する）となると、どういうアプローチを取るかの判断が難しくうまく進まないことに気づく。プロセスを作るメリットとしては、共通の見方・やり方を共有できるところにあると思う。コミュニケーションを考えると重要だと思う。しかし、「共通の見方・やり方」にデメリットもあるとは思う。広がりが無くなると感じる。プロセスに頼らずさらに改善を回せる人は良いが、プロセスに固執しがちな人にとっては良くないと思う。プロセスに固執するというのは個人の資質や性格などにも問題はあるとは思うが、組織でプロセスを取り入れた場合にどこまでプロセスを受け入れるか難しいと感じる。 |
高田様 |
| 私が従事している業務は、業務コンサルティングです。情報システムの構想立案は対象にしますが、実際の構築は含みません。この業務においても、標準プロセスは必要であると考えます。理由としては(1)顧客、上級マネジメントに対する品質保証の基礎、(2)チームメンバーとのコラボレーション・コミュニケーションの基盤、(3)プロジェクト進捗管理上のベースライン、そして忘れてならないのが(4)プロジェクト終了後のふりかえりの基盤となるからです。一方、標準プロセスを設定するリスク（デメリットというより）としては、コンサルティングというプロジェクトの特性上、途中で「解決すべき課題」自体が変わる、つまり原因と考えていたものが現象に過ぎず、「真の課題」はより深いところにある、ということがしばしば起こります。その場合、プロジェクトの進め方を見直すことがより大きな顧客満足につながります。対策としては、課題を与えられたものとするのではなく、「課題設定」自体もコンサルティングの中に含み、時間をかけることですが、顧客がこれを理解していただけない場合もあります。その場合にも、コンサルタント側が「あるべきプロセス」を頭に入れながら進め、顧客が「真の課題は別にある」に気付かれたところで、切り替える、というやり方がベターではないかと考えています。ただし、コンサルタントという職業柄か、「標準」に縛られるのが好まれないところもあります。その結果、各メンバーが個々人の方法で業務を進めているということが多いのが実情です。 |
林 宏典様 |
| 必要性・メリットは多いと思うので、デメリットについて。標準プロセスを導入した際に最も大きいのは「使う側の抵抗」である（導入して3年以上経つが未だにある）。導入メリットを十分理解したメンバーからは抵抗は無いが、「組織からの押しつけ」と思っているメンバーは当然ながら抵抗勢力となる。組織は嫌がるが、やはり導入段階で工数をかけ、メンバーの理解度を十分に上げることが、高い費用対効果を生み出すことになると思う。それに失敗した自組織から、これから実施しようとしているみなさんへの切なる忠告です。 |
山ちゃん様 |
| メリット：プロジェクトを評価するうえで、同じレベルにあわせ絶対的に判断できる。標準化することで、経験（時間）をつめば生産性・保守性が狙える。デメリット：標準化プロセスに関する評価、見直しをしないと上記メリットを生かせない。そのため、その時間を割かずに逆に標準化でプロジェクトの質を悪くする。必要性：開発言語やインフラ構成により標準化は著しく変化する。同じような条件にヒットしない限りはメリットがなかなか出てこないのが現状。したがって、標準化プロセスはプロジェクト単位に選択もしくは改修しながら体系にフィットさせる必要がある。 |
ごんた様 |
| ない |
いしやん様 |
| 標準プロセスによる一定のプロセスは、比較的経験の浅いプロマネには大きな助けとなりますが、熟練したプロマネにとっては標準プロセスを基に、夫々の場合に沿って自由に取捨選択の選択できるプロセスが望ましいです。 |
ochi-san様 |
| 大規模なプロジェクトがあるわけではないのでなくても不自由はない。が、会議等への報告の際に書式・用語等の統一が図られていることは必要だと思う |
亀山 裕己様 |
| メリットとしては、誰がマネジメントしても同じ手順を踏んでいくので、チーム内のメンバーも困惑せずに、作業が進められる。デメリットとしては、プロジェクトのタイプによって、プロセスを変える必要がある場合、そのタイプ毎に標準を設けなければならない。 |
橋本憲様 |
| 複数のプロジェクトを統一的視点で捕らえるためには、標準プロセスは不可欠な存在である。 但し、標準プロセスはどうしても抽象的・総花的になりすぎる嫌いがあるので、個別プロジェクトへの適用に際しては、手法・ツール・手順等をプロジェクト特性に応じて取捨選択／テーラリングすべきである。 |
吉野様 |
ビジネスは適所適材であるが，適材のいない方が多い。またリソースが足りない場合も多く，プロマネはチーム員の能力以上のレベルでオペレーションせざるを得ないのが現実である。そこで，少し力が落ちても，標準プロセスやフレームワークにすることで，実力以上のアウトプットを出すことが可能になる。
ただし，こういうオペレーションを長く続けると標準オペレーションの意味を理解できない人が現れてくるというデメリットがある。このデメリットは，繰り返し，繰り返し教育を行い，経験から体験にまで高めることによって克服してきた。標準プロセスによるプロジェクト運営を実際に行い，収益を二桁にした。効率よく標準プロセスでオペレーションするにはフレームワーク化も大切です。 |
堀内 政信様 |
| 社内に標準プロセスがあっても、それをどうやって社内に浸透させていくかが問題である。標準プロセスによる成功事例等を紹介する等により、社内にそれを有効活用する文化を形成していく必要がある。 |
モリモリ様 |
| プロジェクトマネジメント実行上、ステークホルダーに共通のルールに沿って遂行する必要がある。メリット：ステークホルダーの共通理解・認識が得られ易い。デメリット：一度決めると融通性に欠ける。個人差が出やすい。 |
ハッピ-まさ様 |
標準プロセスを、本当に「標準」として適用するためには、使用するフレームワークやツールなどの固定はもとより、ユーザインタフェースのある程度の統一化が必要だと感じる。しかし、ユーザインタフェースについては、ユーザの希望によってシステムごとに異なるのが普通だと思うので、標準プロセスを「標準」として取り扱うことは難しいと考える。
なので、標準プロセスはプロセス設計のチェックリストレベルとして使用するものなのではないかと思う。あるプロジェクトに直面したときに、プロジェクトにあったプロセスを設計する。その設計したプロセスに抜けや誤りがないかをチェックするために標準プロセスが存在するのではないかと思う。標準プロセスを決めることによるメリットは、「名前付け」にあると思う。開発者やプロジェクトの内外の関係者が、プロセスについて同じ言葉で会話できることが重要だと思う。対してデメリットは、標準プロセスの「設計者」と「利用者」に分かれた際に、「利用者」側へそのプロセスの意図を完全に伝えるのが難しいということではないかと思う。 |
平田様 |
| 標準は、当然必要であるが、「標準」であるので特例や定型外について臨機応変な対応が重要である。組織での標準プロセスに準拠した活動を行ったこともあるが、地方やプロジェクトの特色で融通の利かないものは、「悪」であると考える。 |
料理人様 |
| 2次ベンダーとしてのSILerの立場が多く、開発プロセスが上位に従う事が多い。これからのアプリケーション開発がコンポーネントアーキテクチャー及びMDAが主流になると思われる事と海外オフショアー開発を視野に入れ、人海戦術中心ではなく、コックピット型のPMを模索・確立する事が重要と考えている。 |
眞鍋@企画様 |
１．必要性(1)事前計画（予測）性の確保：スケジュール、タスク分担、見積などの精度向上による(2)ＰＤＣＡベースでのノウハウ蓄積：事後的な評価・検証を行うための前提（その繋がりとして、継続的に標準プロセスも見直し）(3)メンバ内でのベクトル共有：特に異業種に跨るプロジェクトチーム体制の場合
２．メリット(1)経験不足の解消（他人資本≒経験の活用）(2)見積精度の向上(3)（特に、異業種に跨るプロジェクトチーム体制時）分担調整時のイメージ共有
３．デメリット(1)根本思想（理由など）の理解不足による無益・有害な状況が発生するリスク(2)メンバが硬直的思考に陥るリスク |
Ryoh様 |
| プロジェクト対象となる業務については、属人化させずに引継ぎ可能となるのがメリット。プロジェクトには人間的な部分（慣習や社内事情など）が影響するため、そういった要素は加味されないし考慮されないのがデメリット。プロセスのスコープ外だというのは分かりますけどね。 |
溝口勇一郎様 |
| 標準プロセスを決めることに世あって、プロジェクトマネジメント初心者でも、すぐにやるべきことがつかむようになり、試行錯誤する時間が省略できると思います。母体組織にとっても、時間やコストの節約になると思います。但し、フレキシビリティや現実性がなく、融通が利かないというデメリットもあると思います。 |
よしの馬様 |
| プラント建設の場合、計画〜設計〜工事〜試験と一応流れが決まっている場合、それぞれのフェーズにおいておさえるべき内容が決まっていれば有効と考える。 |
植田様 |
| 高品質で低コストの開発を実現させる為に、標準プロセスを決める必要があると思う。ただ、実際には、プロジェクトの前提条件は千差万別であり、総てのプロジェクトに適合する標準プロセスを策定するのは至難の業であろう。最大公約数的な標準プロセスであれば、実開発の局面でたちどころに行き詰まるであろうし、あらゆる状況を想定した標準プロセスの策定は事実上不可能であるう。このバランスをいかにとるかが、腕の見せ所というべきか。 |
坂本様 |
| 変更管理あたりが難しい |
アッこのおじさん様 |
| 標準プロセスを定めることで、属人化の排除、プロマネ初心者の取り組み(育成）が容易になる。また、組織として均一のマネジメントが提供できるようになること、スキル蓄積、レベルアップすることで、組織としての競争力アップにつながると思っています。ただ、どんな標準、ガイドラインにも当てはまることですが、標準に従っていれば成功する、というわけではないので、応用力は必要です。機械的な作業、マネジメント項目には有効だが、肝心の判断力、コミュニケーション力は、やはりＰＭの資質によるところが大です。成功の確率を上げるということより、初歩的なミスの防止（考慮もれ）に効果がある。 |
目指せPMO様 |
| 標準プロセスを決めることによるメリットは ・迷いがなくなる（少なくなる） ・進め方に対する安心感と自信が出てくる。 ・チームメンバ含めて具体的な方向性が見い出せる。 ・ステークフォルダーを意識したプロジェクトを可能にする。 ・プロジェクトに対する第３者のレビューを受けやすい。 ・ＰＭとしてスキームも形式知としてとらえられる。 ・計画性が向上し、変更管理もし易くなる。があげられる、一方でデメリットは ・プロセスに忠実になりすぎることで「考え」やPMのスタイルが生まれなくなる。 ・プロセスを守っていることで安心してしまい、本質的なところを見逃してしまいがちになる。 ・自分のスタイルを確立しづらくなる。といったところが考えられる。 |
発展途上人様 |
| 必要性やメリットについて、頭では分かっているが、現実問題としてどのくらいのメリットがあるのか自身が持てない。同じプロジェクトをプロセスの有り無しで比較できないため。トム・デマルコのデッドラインのような比較実験ができればベストだろうけど。そのため、メンバーに浸透させるのが難しい。そのため、中途半端に適用すると「労多くして益少なし」になりかねない、ことがデメリットか。 |
ツンさん様 |
| 失敗プロジェクトの回避が組織からの命題であり、そのためには可視化が必要となる。標準プロセスは可視化の第一歩。半面、優秀なプロジェクトマネージャの制約になっているのは事実。 |
やいはらん様 |
| 標準プロセスを決める必要としては、１００％の保証にはならないが、ある程度のプロジェクトマネジメントの品質を保てることとを第一に挙げたい。それに関連するが、メリットとしては、一定品質以上のプロジェクト遂行を時間を節約して行えることであろう。ただし、デメリットとしては、本当にそのプロジェクトが標準プロセスに合っているのかという吟味が欠けて、合わないものを無理やり標準プロセスに合わせて遂行し、その結果、無駄、無理、ムラを招き、プロジェクト遂行が芳しくなくなってしまうという危険をはらんでいる気がする。当たり前のこととなってしまうかもしれないが、標準プロセスを「軸」として捉え、各プロジェクトがそれぞれその軸に対して、どのような特徴、押さえどころを持っているかの慎重な吟味を行うなど、自分自身のい頭を大いに働かせてプロジェクトを遂行することが、重要だと考えている。 |
テッド様 |
| １長１短である。 |
yasumi様 |
| 基準を設けることで未経験、経験の少ない状況でも最低限の拠り所となることで大きな問題へと発展する可能性を低くすることができる。レベル別に利用価値があるとその後も基準として有効にはなるだろうが、初心者向けといわれるものにも使えそうなものと見たことがない。 |
ピノキオ様 |
| メリット：初心者でも基本的業務の推進ができ、教育ツールとして利用ができる。また、初歩的ミスの防止ができる。デメリット：標準プロセスのメンテナンスをしないと陳腐化し信頼性が低下してしまう。メンテナンス工数が負担。 |
アリスの国様 |
| ツールを含め定型化される事で見える化が可能であるが、その反面必要以上の報告（入力）がされない。曖昧な部分が多くPMの個人の判断に委ねられるなどのデメリットもある。もし、標準プロセスを決めるのであれば、徹底的な標準化とノウハウを蓄積するシステムが不可欠である。 |
匿名希望 |
| ・初めての人の教育とＰＪ成功への確立向上・応用性が欠けてくる・新技術・手法への追随を行なう必要が有り、改善コストがかかる |
三田ノ富士様 |
| メリット：コミュニティ内での基本方針の確立、Pj独自プロセス作成時のベースデメリット：上記メリットの理由から標準プロセスの決定は必要であると思うため、デメリットは特に感じられない |
井上美佐子様 |
| 長い時間をかけて標準プロセスを決めても長年経験と勘だけで仕事をしてきた社員にとってはうまくはまらず、常にブラッシュアップを続けて対応させていかなければならないが、そのような時間を確保し続けるのが難しい |
諸永様 |
| 決まりきった内容のプロジェクトには有効だが、ちょっと内容が変ると対応できないため、階層的には上位でのみ汎用的にプロセスを定義せざるを得ず、あいまいな点が多くなり、有効性が不明瞭化してしまうデメリットがある。 |
BoA様 |
| メリット：やるべきことが明快デメリット：オーバヘッド |
匿名希望 |
| 標準に縛られすぎるし、逸脱（いい意味で、標準の改善）が難しくなる。 |
小林様 |
| 標準化によって出来ているかどうかのチェックが容易になることと、出来ていない人へのなぜだめかが可視化できる。本当に出来る人は、標準化を離れて、プロジェクトごとに最適のプロセスを組み立てられるが、そんな人はまれ。標準プロセスがないと、名人が自由にやっているからといって、初心者も適当にやりがちになる。武道の稽古のように、型がちゃんと出来る人だけ乱取りさせるようにしないと。 |
田崎雅彦様 |
| 必要性：組織内にプロジェクト管理の知識が蓄積されるためにも必要。メリット：成果物が明確。フォーマットが用意されているのでドキュメント作成が容易になった。デメリット：標準プロセスに当てはまらないプロジェクトの場合の規程が全くないためノウハウを経験者から聞かなければならない。（組織として蓄積されないものがある。）無駄な審査と承認が多く非常に時間がかかる。エビデンスを残すための作業に負荷がかかる。 |
匿名希望 |
| メリットは、誰でもある程度は成果を残せる。デメリットは、試行錯誤することが減り、プロセスありきになってしまうこと。 |
take様 |
| ノウハウを共有できることがメリット。デメリットはやり方を一方的に押し付けられること。 |
だい様 |
| 【メリット】・どうしてよいのか判断に迷うときに参照できる・現状との乖離状況を分析することで、プロジェクト状態を共通語で報告することができる【デメリット】・テーラリングの経緯に対してＰＭＯから介入されることがあり、仕事の妨げになることがある。 |
raika様 |
| 必要性・メリット：プロジェクトの性格上メンバーが固定でないため、新たに結成したプロジェクトチームで毎回PMによってプロセスが異なるとメンバーがキャッチアップするまでに時間をとってしまう。社内である程度統一されどのチームにいってもPMもメンバーも共通の理解でプロセスに取り組めればプロジェクトの立ち上げがスムーズになります。立ち上げがスムーズにいくことはプロジェクトにとって大きなメリットであると思います。また、基本はプロセスが習慣化されていることでミス・コミュニケーションなどによる問題発生を未然に防げるという効果をもたらすと考えられますが、プロジェクトが危機的状況に近い時ほど、プロセスに習熟し、信頼しているからこそ、プロセスに立ち返って状況を立て直すことが可能になるのではないでしょうか。つまり、標準プロセス（というよりも習熟・浸透したプロセス）は、プロジェクトチームにとって未知の取り組み、問題発生時にプロジェクトを進めるよりどころであると考えます。デメリット：プロセスを標準化しても社内への浸透が進みにくいという課題はあると思います。理由は、体系が広くすべてを理解して実践で適用するためには相当量の知識習得の時間と実際のプロジェクト経験が必要であること、実際のプロジェクトではプロセスよりもコンテンツ（課題解決）に意識が向かってしまうことなどが考えられます。私の場合、社内標準のプロセスの中で、自分で理解し、納得でき、実行上効果があると考えたプロセスやツールを自分なりにより集めてマネジメントに取り入れています。 |
RH様 |
| 必要性：属人的プロジェクトマネジメントでは、失敗／成功の原因があいまいになってしまうため、類似プロジェクトのために標準化されたノウハウ収集が必要。メリット：抜けが少なくなり、プロジェクト全体の品質が向上する。特にステークホルダーと調整すべきことについて抜けが少なくなれば、最終的に成功（合意）する確率が向上する。デメリット：経験の少ないプロジェクトマネージャにおいては、臨機応変に考え、行動するマネジメント能力が下がる懸念がある。 |
日向野 靖様 |
| 現状個人のスキルによる部分が多い。企業規模が小さく、教育に割ける時間が少なくスキルアップへの取り組みが少ない。外国籍のメンバーとのやり取りでも、コミュニケーションで悩むことが多い。 |
匿名希望 |
| 私はプロジェクト手法の標準化を担当していますが、顧客により担当の手法が変わるので、汎用的な手法の確立の難しさを感じています。しかしながら、標準化することで、各自が行っていた手法では気づかないことを集約できており、今後はより高いレベルでPMを行えるものと思われます。 |
ぐっちい様 |
| ソフトウェア開発というプロジェクトにおいて、定量化しにくいプロセスが多くあります。 |
黒田克己様 |
| クライアントとの交渉の際に大変役立つ。クライアントあるいは中間業者では、プロセスが不明確でどんぶりマネジメントだけで仕事をしているところが多く、リスクは制作側がかぶるようなことはさけたい。 |
さいとうくん様 |
| 標準作業による工数計算、スキルアップ教育計画などが可能。 |
菅田武史様 |
| 開発に関して多くの外注の方が常駐形態で携わっていただいているが、それぞれの会社の言葉があり同じタームを違う意味で使ったりしてコミュニケーションの部分から必要性とメリットを強く感じている。デメリットは監視/監査の工数が積まれてコストがかさむ。PSPが上がればこの部分の工数は削減されるのだろうか？ |
大志の父様 |
| いかに浸透させるかがポイントとなる |
匿名希望 |
北海道の某建設コンサルタント会社に勤める者です。当社はまだ建設コンサルタントとしての歴史が浅く、近年やっとプロジェクトマネジメント等に対する標準手順を定めようとの動きが出てきたという状況です。ですので、標準プロセスに乗っ取ってプロジェクトを遂行してきたという経験が会社として無い状況です。また、私は大学卒業後に初めて就職した会社が当社です。（従って、標準プロセスに乗っ取った仕事のやり方というものを誰からも教わっておりません。）私は、まだプロジェクトマネージャーとしてプロジェクトマネジメントを行える立場ではございませんが、日頃から思っているプロセスの標準化について意見を述べさせて頂きます。（前置きが長くなりまして申し訳ございません。）
【標準プロセスを決める必要性】 標準プロセスに従って仕事を行うのが最も重要な事項ではなく、現在ある標準プロセスをより良く見直していく過程（ＰＤＣＡサイクル）を発生させることが最も重要で必要だと思います。 （既存の標準プロセスを継続的に是正していく過程は、並大抵の努力ではできないと思うし、それには、多くの発想力、行動力、指導力が必要となる。 それに伴い、自ずと個人レベル、企業レベルともに向上していくという好循環を生む結果となる。）
【メリット】
１．個人及び企業レベルの向上。２．新入社員や中途採用者が実戦力となるまでの時間を大きく短縮できる。（仕事に対しての理解を大きく助けるものだと思う）３．アウトプットの品質を均一化できる。４．工期の短縮化が図れる。５．作業プロセスの効率化６．３及び４によりコスト削減が図れる。
【デメリット】
１．仕事に対しての深い知識や理解の探求を妨げる恐れがある。（とりあえず仕事は進むという状況になれば、各人の個性にもよるが、自己満足感などにより成長がストップしてしまう可能性がある。）２．良くも悪くも品質の平均化が進むこととなり、突出した悪い成果は発生しない代わりに、良い成果も無くなる。 また、会社としての個性も無くなる恐れがある。３．できの悪い標準化プロセスに縛られるあまり、アウトプットの品質が落ちる。 |
匿名希望 |
| IT系企業のシステム部門を統括している。旧体然とした属人的なマネジメントが大半を占めているのが実情であり、企業として非常に大きなリスクを抱えている。現在、システム開発標準と併せてプロセス・スタンダードを構築中であるが、経営層の認識が甘く経営資源を投入できず苦慮している。 |
NOBUTA様 |
| 共通認識や共通言語が広まり、コミュニケーションは円滑になる。また初心者への道しるべとしてのメリットはある。反面、一部の人達には、自分で悩んで考えてプロセスを作り出す能力が欠如してしまっていると感じる。 |
PMPビギナ様 |
| 基準に縛られるあまり、個性のあるマネジメントが出来ないケースがある |
さぁらぁ様 |
| 標準があることによって、指標とすることができる。 |
晋二様 |
| 組織内のマネジメントクオリティの平均化を図るために、標準プロセスは必要だと思います。組織としてマネジメントを提供するのであれば、組織内のマネージャーによって、プロジェクト遂行に対する良し悪しがでては、クライアントの組織へのイメージが均一化できないと思います。 |
コヤマ様 |
| プロセスを守ってマネジメントを行うのは重要だが、業務の仕様を抑えていない管理者は、有益な判断をするのに時間がかかり、周りの人間もスムーズに進めることができない。 |
おの様 |
| 必要性はあると感じているが、プロジェクトのニーズにあった万人（すぺてのプロジェクト）に合うプロセスはないと思っています。そのため独自にプロセスを作る必要プロジェクト標準プロセスが必要である。また期間の短縮等を考えると標準とはそもそもなにかを標準としているかを考える必要があると思っている。 お金と期間さえあれば、標準プロセスは最高です。現実的にはデメリットだらけです。 |
匿名希望 |
| プロジェクトメンバーの経験にばらつきがある場合は、ガイドラインとして有効。プロジェクトが大きく、サブプロジェクト単位に分割されるような場合も、全体を管理するために必要。但し、SPJの特性もあり、標準だけにたよるとマネジメントの粒度が実態と乖離してしまうと思います。 |
匿名希望 |
| ・単純なほど素人に理解されやすい、実行されやすい（メリット）。・事業が多様で、毎回調整追加する必要がある（デメリット） |
Good Samurai様 |
| 必要性：標準プロセスを決めることにより、標準期間の見積もりが可能となる。標準プロセス・期間があれば、現状の問題点が浮き彫りになり、改善につなげることができる。メリット：経営層にとって複数プロジェクトの進捗状況を把握・比較しやすい。 プロセスのムリ・ムラ・モレ・ダブリを解消できる。デメリット：標準にないプロセスが発生するとき、混乱する恐れがある。 標準を遵守するあまり融通がきかなくなり、かえってスピードが落ちる恐れがある。 |
匿名希望のWM（ワ-キングマザ-）様 |
| 自分自身や他人との考え方の統一ができる。 |
高橋様 |
| メリット：社内で共有された価値観となり，コミュニケーションの円滑化の手段となる。 また開発の効率化の手段，尺度として有効である。デメリット：適用の仕方によっては生産性を阻害する要因でもある。 |
田中 敏昭様 |
| 社内に標準プロセスを適用させようと試みてはいるが、現場からは習得に至るまでの作業負荷とに対する忌避感が強い。開発規模や状況に応じて必用な作業をテーラリングする事を面倒がる。すべてやるか（実際は面倒がってやらない）、各人の経験で行なうかどちらかしか行なわれていない。実際の所、無手勝流に進めているプロジェクトは大半が破綻しているので理解してもらえるとは思うのだが。 |
鈴木様 |
| メリット：予測の精度向上、進捗の見える化と対策すべきところの明確化、人に帰属するリスクの低減、管理ノウハウの共有．．．デメリット：？（標準プロセスが定期的に要否について見直しされているならＯＫ。逆に見直しされない標準プロセスはすぐに足かせにしかならない。標準プロセスも生き物だと考えて進化していくものという認識がメンバーにあれば問題ない）アンケートについて問１でないの場合問８となっているが送信に進むと問４記入を催促してくる。アンケートソフトに不備有り！。問２〜問７は意味のない記入となっています。 |
匿名希望 |
| 多くのメンバーが作業を分担して進めるプロジェクトでは、同じベクトルで効率よく目標を達成するためにプロセスの標準化が有効なのは自明であるが、それにも増して、プロセスごとのベストプラクティス（具体的な作業手順、教訓、テンプレート等も含む。）の収集、再利用の枠組みとして重要だと思う。ただし、行き過ぎた標準化は、チームメンバーの自律性、創造性を殺す危険もあるので注意を要する。 |
高橋 正憲様 |
| カスタム生産が多いので、標準プロセス自体の意味よりは、標準プロセスのカスタマイゼーションスキルが要求されている。 |
匿名 |
| 標準プロセスは定めても、初心者の域を脱すれば、特にこだわる必要性は薄れると思います。 |
魚猫狩人様 |
| べき論を振りかざした、ある意味よく出来た標準プロセスをいきなり現場に押し付けても、現場は付いていけずに結局無駄なものになってしまうと思っています。 |
白井様 |
| メリットは，繰り返しの頻度が多いものは問題が少ないが，繰り返す頻度が少ないものは，忘れてしまう．明文化は必須．デメリットは詳細化させすぎ，煩雑となる．逆に，決まっていないため，曖昧となる． |
ミッキ-様 |
| 必要性：それが本来のあるべき姿だからメリット：標準プロセスを理解し、実行できるメンバーがそろった時は相当の強みを持てるはず。デメリット：標準プロセスを理解できずにいるメンバーがいた場合、その組織（チーム）は崩壊する。 |
北田孝明様 |
| 標準プロセスは、PMの違いによる属人性を排除し、一定レベルのプロジェクトマネジメントを提供できることがメリットである。ただし、例外なく全プロジェクトに適用しないとその効果も薄れてしまう為、PMに対する啓蒙、教育、フォロー、監査が必須であり、標準プロセスを推進する為のPMO等の組織が必要となる。デメリットとしては、標準プロセスを守らせる為には、PMOの組織が必要になる等、コストが必要な事であろうか。 |
じんごろう様 |
| メリットとしては、初心者や新たにプロジェクトに加わったメンバーが今のポジションを容易に理解出来る。デメリットとしては、標準化により創造性や改善をしないで仕事を進めてしまうこと。 |
taka様 |
<メリット> ・何か問題があった時に原則(ベース)に戻り話し合いができる。 ・標準プロセスに基づいた監査(きちんと運用されていることの確認)ができる。 ・全員の意識統一ができる。
<デメリット> ・維持が大変。 ・文書(紙)が多くなる。 |
荏原様 |
| 決めた方が管理の工数・手間・それにかかる精神的な労力は減ると思う。ただなくなるように思う。 |
町田様 |
| 半導体デバイスの開発に携わっています。この分野の場合は標準プロセスというよりは、標準開発シーケンスと言う様なものになると思いますが、ある程度、の道筋は決めた方が分かりやすいものの、マイルストーン管理的になってしまい必ずしもうまくいってないのが実情だと思います。しかし研究開発においても各開発プロジェクトに対するマネジメントをいたずらに放置すれば何も新しい物は生み出されないでしょうしたがって何らかの標準は必要であるとおもいます |
匿名希望 |
標準プロセスは、ある程度の規模がある開発では有効だと思いますが、小規模・短納期案件では、標準プロセスに従っている時間が、開発期間にまで影響する可能性があり、却って効率を下げるのではないかと思います。私の会社でも、基本的なプロセスは、そのようなプロジェクトでも行うべきという考えがありますが、少し違うのではないかと思っています。小規模案件だと、プロジェクトに関わる人数も少ないので、標準プロセスに従わなくても、コミュニケーションのやり方で、プロジェクトを完成させることは可能だと考えています。
このあたりは、みなさん、どのように思われているのでしょうか？優秀なプロジェクトマネージャの方のご意見を、ぜひ、お聞きたいです。 |
みのきち様 |
| 組織が若いこともあり、まだどのような手法を取るべきなのか悩んでいます。 |
徳力基彦様 |
| 小規模プロジェクトへの適用が中心と言う観点で（きめられたものを部分的に適用）メリット 沿ってやったもの蓄積と次へプロジェクトの参考ディメリット：小規模なりの有り様が大巾改善要(取組中） |
安部様 |
必要性：ステークホルダーとの要件確認プロセス、最低限の品質確保に必要。
メリット：役職や権限による恣意的な仕様変更の歯止めになる。基本的な開発作業の流れを作ることができる。デメリット：たとえば設計レビューの内容が形式主義的になり、内容が不十分なまま次工程に進んでしまう場合がある。 |
kimesan様 |
| メリット:それをガイドラインすることにより、例外が発生した場合でもその外れた理由を明確にすることができる。デメリット：１）標準から外れた行為ばかりが横行するとなんのための標準なのかが不透明になる。２）標準に固執するとよりよい改善されたプロセスを生む出す環境が阻害される恐れがある。 |
ふぃるP様 |
| 企業・組織全体レベルの底上げとトップからの状況把握のために有効。ただ、自社ではまだまだ実績の蓄積が少なく有効に活かせていない |
東中 博司様 |
| 少ない人数が乗った船は舵を切れば、船はすぐ方向変えれるが、多くの人数が乗った船はなかなか曲がれないのと同様で、小さなプロジェクトでは、ある程度の決まりがあり、必要に応じて途中で変えてもよいが、大きなプロジェクトを行う場合は事前に、しっかりとした標準がなければ、余計な工数がかかり、コスト、スケジュール、品質を守ることができなくなる。 |
USAMON様 |
| 大規模開発の場合にはプロセスを明確にすることにより各担当者への周知が徹底できるがプロセスに対する解釈の相違によりシステムの品質レベルを保つことが困難となる場合がある。（プロセスに固執するため現状の本質を見抜くことができない） |
相島 広伸様 |
| 次フェーズに移行する時の判定の目安となる |
匿名希望 |
| 標準プロセスを決めるとそれに固定されてしまう。常にそれを見直すことができる仕組みが必要だと思います。 |
牛山一也様 |
必要性暗黙のうちにあるもの程度だと、知っている人は知っているが、知らない人は何も知らないものになってしまい、しかも様々な人々の思惑も絡み、全く統一性が計れない。そもそも、私の会社では、そのようなものがあることすら知らず、知っているものは、その手のものを何を思ったか、魔法か何かのように思っている節があり、言葉は威勢がいいが、全く形にならず、同じ失敗を懲りずに繰り返している標準プロセスを導入することにより、そのものの存在を知り、考え方を知り、やり方を知るためにも必要だと考える無知程恐ろしいものはない
メリット必要性のところでも述べた通り、「そのものの存在を知り、考え方を知り、やり方を知る」ことによって、プロジェクトマネジメントの真似事がプロジェクトマネジメントに近付いていくそして、学ぶ雰囲気がもたらされるのではないか、とも思う
デメリット学ぶことにより、同じ轍を踏む可能性が減りはするが、標準プロセスによって、劇的にプロジェクトマネジメントが成功するわけではないこと(即効性ない)標準プロセスを学ぶための時間が必要である、ということ |
亜井譲様 |
標準プロセスに従うことで、ＰＪのやらねばならぬことが抜けなく行えることは、メリットであるが、あまり詳細に決めてしまうことにより、ＰＪの自由度がなくなり、管理のための業務・稼動が増えるというデメリットが発生する恐
れがある。 |
渡辺 順子様 |
| 必要性としては十分にある。メリットは管理が楽になりノウハウをためやすくなる。また標準化されていることで次のステップとしての工夫を考えることができるようになる。デメリットとしては行き過ぎると逆に効率が悪くなる。 |
匿名希望 |
| メリットはぬけがなくなる。デメリットは柔軟な対応ができなくなる。 |
もと様 |
| 情報ビジネスでは、個人能力依存の仕事が多く、標準化しなければスケジュールの遅れが可視化しにくい。もっとも有効な手続きで標準プロセスを作る事で、初心者を利用して生産性を挙げる事が可能である。しかし、プロジェクトが肥大化することで数々の標準が密接に絡み、手続きどおりで仕事をすすめられる反面、大企業病と呼ばれるマニュアル主義に陥り、改善に対するコストが膨れる、又は変更できなくなる傾向にある。インプット・アウトプットを明確に定義し引き継ぐことも大事であるが、現実プロジェクトでは不要な手続きを廃棄して減らす、又は統合化するといった事も必要であると思います。 |
匿名 |
中国オフショア開発における標準プロセスについて。・メリット 進捗管理・コスト管理・リスク管理のためには、標準プロセスを決めるしか方法がない。・デメリット 中国オフショア開発における標準プロセスは、生産性向上ではなく
進捗管理を目的として決めるべき。
「あうんの呼吸」が全く通用しない中国企業を相手にするときは、標準プロセスでは対処しきれない状況が頻発する。そんなとき、日本側の都合だけで中国に管理業務を押し付けると、かえって悪影響を及ぼしかねない。中国のために良かれと思って決めた標準プロセスが、中国企業の首を絞める結果になりかねない。 |
幸地司様 |
| マニュアル化してしまう可能性がある。特にルーチン作業を得意とするメンバーが、プロジェクトに参画している場合には注意が必要だと思う。 |
kumaboo様 |
| メンバーの進捗を客観的に判断するため、プロジェクトマネジメントの負荷を減らすためにも、標準プロセスが必要であり、メリットであると思います。標準プロセスを決めるデメリットはプロセスの意味を考えなくなってしまい、形骸化する恐れがあることではないでしょうか。 |
高奥浩明様 |
| メリットは、全社のプロジェクトが同じ基準で状況を把握できること。デメリットは、ある程度の規模の会社になると普及させるためにコストと期間がかかること。 |
大塚様 |
| 基本的に、「できる」PMには標準化は必要ないと思う。しかし、「普通」のPM、「成長途中」のPMには、非常に効果的であると思う。まずは標準化し、結果をフィードバックすることにより更に効率的な標準プロセスを検討すること、成果を平均化することが出来る。それによって育ったPMは、自分のスタイルを構築し、それが更なる標準化につながっていけばなおさら良いと思う。 |
天野 結子様 |
| 上記は社内（金融機関）向けシステム開発について記載した。このケースのような比較的変化の少ないプロジェクト（例：ユーザーが固定、または同質）においては標準プロセスは有効だと思われる。しかし、現時点において、「優れた」標準プロセスはなく、手探りであったり、過去事例を（優劣考えずに）適用するケースが多い。また、変化が少ないとはいえ、プロジェクトである以上は必ず何らかの特殊性があり、それに応じてプロセスを調整しながら適用するのはＰＭのセンスに依存する部分が大きいと考える。総じていえば、プロセスは必要であるが、それだけでは不足であり、状況（プロジェクトの内容・サイズ・メンバー・環境等）を継続的に観察して調整しながら適用するＰＭの能力（センス）が必要だと思われる。 |
匿名希望 |
| 標準プロセスを決めることにより、プロジェクト立ち上げまでの期間の短縮を図ることが出来る。また、グループで共通の見積方法を用いることにより、会社全体での見積精度向上に貢献することも可能になると思われる。 |
匿名希望 |
| 業務が定型ではないので標準的なプロセスを構築しずらいが、ノウハウ等の蓄積のためには必要であると思う。また担当が変わっても品質が落ちないように、決める必要性はあると思う。 |
本橋洋様 |
| 客観性、透明性、構造化 |
杉様 |
| 冗長的にならず、俗人的にならず、やはり標準化は必要だと感じるが、「標準」となるまでの試行錯誤と適用範囲におけるGAPが発生しがちである。 |
もたい様 |
標準プロセスのメリット、デメリットについてまとめてみた。メリット・プロマネがこのプロセスに則ったマネジメントを行うので抜け漏れが無い。・プロジェクトに対する判断、評価がしやすい。・なあなあにやっている部分が無くなる。・プロジェクトの目的やゴールが明確になる。
デメリット・標準に縛られ感がある。・評価する者が間違った解釈をしていると混乱が生じる。・PMOが機能しないと標準化した意味がなくなる。
以上かと思います。もっと時間をかければ、メリットデメリットについて考えられると思いますが、今回はこの程度で勘弁して下さい。以上、よろしくお願いします。 |
てら様 |
必要性：組織の規模が大きくなればなるほど、規律が必要メリット：生産物の
標準化、組織異動時の再教育コストの低減デメリット：標準にとらわれて自由な創造力が欠落してしまう |
市村様 |
| 標準プロセスを決めなければ、企業としてナレッジが蓄積できない事と、結果のばらつきというリスクが発生する。しかしながら、デメリットとして標準プロセスの見直しが必要なので、逆に業務が大変になってしまい、メンテナンスコストが掛かる |
Kaz様 |
| テンプレートとして、標準化のメリットはあると思います。また、業界別のテンプレートも意味があると考えます。ただし、トラブル時のノウハウや経験で得られる知識などもあると思うので、テンプレートからずれた場合は、軌道修正できるような仕組みが必要かと思います。 |
匿名希望 |
| メリット：社員全員で手順や範囲等の意思統一をすることができる。デメリット：複雑すぎることがあり、主に短納期のプロジェクトの場合、プロセス手順を守ることのほうが難しいことがある。 |
ひでぽん様 |
| 個人的にはプロセスは大事だと思うし、体系的に学びたい。が、所属企業は小規模でその方面に対しては組織として力を入れていない。口頭で何とかしろ、と言うばかり。元請SIerでは見よう見まねで自分なりのツールを駆使している状態です。 |
小畑様 |
"組織" が "決められた標準プロセスを持っている" ということと "人" が "プロセスを実行し/進化させるスキルを持っている" ということは別物である。しかし、前者ばかりがクローズアップされる傾向があり(少なくとも私の組織においては)、標準を"決める"ことに一生懸命になってしまい、決められてはいても実行できないし、一旦決めた後は進化しなくなってしまっている。
そういった中で、メリット/デメリットですが、メリットは、スキル不足の人に対して、やるべきこと を端的に示せること。デメリットは、標準を決める＝固定化 になってしまい(もちろん本来はそんなことは無いが)、ISO9000で多くの日本の組織がそうであったように、いつしか "使えない" プロセスになってしまうこと。半分冗談ですが、思うに「標準プロセスは決められていますか？」のような問い掛けは宜しくない。「ありません」→「それでは、決めなくては」という思考に誘導される。「あなたの組織は、プロセスを進化させ続ける組織ですか？」といった具合に、"決める" ことにではなくて "プロセスを作る/変化させる" ことに意識を持って行くように問い掛けるのが良いのではないかとちょっと思ったりします。 |
庄司和彦様 |
| メリット：マネジメントプロセスの標準化、全体的な質の向上が図れる。デメリット：規模の小さいプロジェクトに負荷が過剰となる時がある。 |
八正庵様 |
| 変更管理のプロセスを標準化する事は困難である。大規模と小規模のプロセスで２つのプロセスになっている。 |
大野 芳敬様 |
| プロジェクトマネージメントは個々の人のスキルによるところが多いが、標準プロセスを決めることにより１）初心者や困ったとき、迷ったときの「辞書」になる。２）サービスレベルのぶれが少なくなる。（標準プロセスを個々のマネージャが採用すればであるが）のメリットがあると考えます。逆にデメリットは、決められた標準プロセスを「理解せずにただこなすだけ」と言う状態となり、本質である個々の人的スキルの向上が遅れる。ということが考えられます。 |
だいちゃん様 |
＜必要性＞ＰＭも世代交代が必要であり、標準的なものがあれば、それを踏襲、発展していくことで新たなＰＭが育つはず
＜メリット＞新たなＰＭがＰＭとして行う作業の質がある程度期待できる
＜デメリット＞革新的なＰＭが育ちにくい |
あき様 |
| 必要性は痛感してるが、会社としての認識が無いため期限のみ考えたスケジュールと導入の失敗、フォローの繰り返し。上層部でPMの重要性と運用の大切さを認識してもらうのが第一。 |
ヨ-ダ様 |
| ステークホルダーに共通の言語として認識できる。 |
まさ様 |
| 見落としが減り、要員間のスキルにディペンドする部分が平準化出来る。他方、形式にだけ従うきらいがあり、なぜそんな仕組みになっているかを考えなくても仕事が進むので、ある意味バカチョン化してしまう。 |
大木 幹雄様 |
| 仕様確定の明確な承認段階・機能が無いため、断続的な回収が発生してしまう、工程管理を含めて標準化を行いたい |
中澤様 |
| 初心者だった時に先輩から「いろいろ考えはあると思うが、スケジュール管理や定例報告などはこのフォームを使うように」と言われてそれをどう使いこなすか苦労しながら考えた。その中でプロジェクトの進捗管理をしていく方法を（正しいかはわからないが）勉強していったと今振り返ると思います。標準プロセスを決めると、複数の会社の寄り集まりの時など進め方が良くなると思います。以前は社風の違いで色々な考え方・進め方を持った人を同じ方向に向けるのに苦労しましたが、ツールを統一することによって、進捗会議などが同じレベルで情報を共有できる場になっていったと思います。 |
まこちゃん様 |
| プロジェクト推進において人材が重要であるが、育成には期間を要するし、会社にスーパーマンが何人もいるわけではない。マネージメントの標準プロセスを設定することで、そのノウハウの底上げと醸成により品質や生産性向上を図れる。但しあくまでも標準化は最低限の知識にならざるを得ない。同一のプロジェクトはないので、やはり重要なのは最低限の知識を基本言語としたノウハウの継承と考える。 |
壁様 |
| 標準プロセスを組織に定着させることができれば，問題点の早期把握と対策実施が可能になり有効であると考えています。ただ目的が理解されなかったり，運用が定着しない場合は報告のための時間がかかるだけで効果が出ない。 |
光広 章文様 |
| 知識不足のため、プロジェクトマネジメントプロセスというものが、具体的な作業として想像できません。「二次請け同士の会社間で、作業および成果物に対する認識違いや契約における不公平がなくなる」のであれば、標準プロセス導入は非常にメリットがあると思います。なお前提として、私の所属する会社は基本的に二次請けです。 |
匿名希望 |
| 標準プロセスを決めることにより、どのプロセスのどこに問題がある/あったのかを振り返り、次のプロジェクトに活かすことができる。デメリットは、標準プロセスの強制力をどこまで持たせるかにより、かえってマネージメントなどに工数を要する場合がでてくる。 |
高橋様 |
共通の会話を行うためのベースとしてのメリットがある反面、従う事のみを念頭に置き、本来の目的（プロジェクトを進める）を忘れがちではないか？というデメリットがある。
何事にもいえる事だが、「この標準を守ったから大丈夫」ということはなく、あくまでも、ベースの部分であったり、大枠をはずさないための意味合いであり、本当にプロジェクトをドリブンしていくのは、適用していく人である。 |
Fukum様 |
| プロセスについてある程度の範囲で決めることは必要だと思うが、「必ずしもそれに従わなければならない」と言うものではない。臨機応変に対応していくことも重要だと思う。 |
おいどん様 |
| 皆さん同じようなことをお考えだと思いますが、「標準化すること」が手段なのか目的なのかが分からなくなってしまうということがまずありますよね。いわゆるベストプラクティスは確かによくできていると思う部分もあるのですが、結局のところ「お題目」のような部分もあり、「まぁ参考程度に」ということになることも往々にしてあります。ただ、当然ながら存在しないよりも存在することの方が素晴らしく、ありがたいというのが正直なところです。改善するにも、スタート地点がなければ改善のしようがありませんので。 |
匿名希望 |
| 役員がやる気がない為、結局進まない |
アキト様 |
必要性 プロセスが煩雑になり、報告先・作業者に対して混乱を招く事を回避できる。
メリット 標準プロセスを基盤として、そこにPM個々のエッセンスを加えることによって、最低基準を維持した上での自由度が高まると考える。
デメリット 人によっては、標準プロセスにとらわれ、自由な発想が生まれがたくなる。
|
ダイスケ様 |
| 必要性：効率的な業務改善を行うためにはプロセスの可視化と標準化は不可欠である。メリット：ステークホルダーに対して、マネジメントの納得性と品質に対する信頼性を高めることができる。未知のプロジェクトを立ち上げるときの勇気の源となる。デメリット：継続的かつ戦略的に改善していかないと陳腐化してしまう。 |
今野 浩一様 |
| 品質管理ツールは独自開発したものを使用しているが、まだ問題点が多く、有効に機能していないと思われる。 |
Yupa様 |
標準プロセスがあると、プロジェクトマネジメントスキルを完全にしていなくてもある程度対応できるメリットがあります。プロマネスキルは広すぎて、完全にモノにするまでは非常に時間がかかるが、標準プロセスがあって、それに沿っていけば、難しいプロジェクトでなければ、熟練者でなくても遂行することができます。また、プロセスに従った資料を残せば事例の蓄積になり、組織のノウハウに生かしていくことができるでしょう。
ただ、盲目的にプロセスに従う癖をつけてしまうと、プロジェクトマネジメントの本質を理解する努力をせず、型通りの対応しかできないマネージャを作りかねないので、プロセスに従いながらも、継続的に改善を繰り返す姿勢と意識共有が必要と考えます。 |
bookridge様 |
| 標準プロセスでリスクチェックが出来て、急所どころをうまく捉えられ、問題を予見でき、課題を恐れず進められる |
堀チャン様 |
| 標準プロセスが無いと、プロジェクトの進め方がマネジャーの質に依存するばかりか、個々のメンバー間で、業務の捕らえ方がことなり、収拾がつかなくなる。 |
匿名希望 |
| プロジェクトに参画しているメンバー全員及びステークホルダーのプロジェクトマネージメントに対する考えが揃やすいというメリットがある。逆に、正しい知識を持たずニュアンスや思い込みでマネージメントを曲解している人も少なくなく、余計な混乱をまねくデメリットもある。 |
atts様 |
| 標準プロセスを決めることにより、アウトプットの品質が一定の範囲内に収まる確率が高まるというメリットがあると思います。ただし、標準プロセスが決められた背景を理解し、プロジェクトに応じてどのように修正すべきかを考えた上で標準プロセスを応用しなければ、問題発生時の対応が遅れる恐れがあるように思います。 |
泉 通博様 |
| 現時点では、標準化及び明文化したプロセスは作成しておらず、プロジェクト憲章とマスタスケジュールのみを明文化しています。それを基にマネージャ及びマネージメント担当者が進捗状況を見ながら適宜WBSやトレードオフを作成しつつ作業を実施するようにしています。その際には、PMBOOK等を参考にしながら、適宜現時点で最良と思われるフォーマットにして展開しております。なお、進捗状況の把握は毎週ミーティングを開催することにより実施しています。さらに、状況(問題発生時)に対応するための考え方は、貴メールマガジンを大いに参考にさせていただいております。このようにした経緯としては、・当方、マネージメント業務は初めてであり、PMBOOKが膨大すぎてどこから手をつければいいのか、よく解らなかった・完璧にPMBOOKに則ってやることはその準備だけでリソース不足となることは明らかだったこと・定型作業に陥ってしまいマネージメントのための業務が増えることを危惧した。それよりも、メンバーにはプロジェクト憲章を常に意識させることを優先したかった。現在プロジェクトの中盤に差し掛かっておりますが、スケジュール・モチベーションの面ではほぼ問題なく進行していると思っています。反省点としては、コスト見積の精度が低かったことによる問題が発生しております。プロジェクト開始時における見積にもっとリソースをかけることができるように調整・努力すればよかったと反省しております。現在の思いとしては、PMBOOKにあげられている各スコープは、問題が発生しやすい部分とその対処法の一例を明確に示してあると考えています。PMBOOKの形式に囚われる事はないが、なぜPMBOOKに書いてあるのかを意識して作業を進めていく事が涵養かと思います。特に計画段階でより強く意識すれば良かったと反省しております。 |
渡辺清幸様 |
プロジェクト独自的な裁量による部分が多いので正確なコスト、スケジュール
の見積りがあいまいになる。 |
mogeo様 |
| ソフトウェア開発において一定以上の品質を確保するためには、属人化した管理方法ではなく、社内あるいは部門内で標準のプロセスを持つことが重要であると考える。こうすればマネジメントの初心者でも、ある程度の品質を確保することができる。デメリットとしては、プロセスが硬直化したり、標準プロセス自体の管理・改善がうまくいかなくなる、などが考えられる。 |
橋場 光幸様 |
| 標準プロセスを組織や母体として作成し保持することは、重要であるがその標準を自分のプロジェクトで、活用しそのまま使用するのか、カスタマイズして使用するのか、新たにプロセスを作成するのかの権限をプロジェクトマネジャは与えられていると思うので、プロジェクトマネジャが取捨選択し、自プロジェクトの標準プロセスを確定すればよいと思う。プロジェクトが完了した時点で、作成した標準プロセスを教訓として他プロジェクトへ報告する場を提供すればメリットも共有できると考える。 |
匿名希望 |
| プロセスが標準化していると進めやすくメリットと考えられるが、不確定要素が多いと不必要なことがらが増えデメリットとなるように思える。 |
匿名希望 |
| メリットとしては、ある程度のマネージメントのスキルアップが見込める。デメリットは、本来の目的が標準化することによって隠れてしまう、教育面での対策が別途必要。 |
木下様 |
| 何も無いところから始めるよりは標準プロセスがあることが有効なのは誰もが考えるところだと思います。ただ、私の周りでは過渡期（それもとりかかったばかり）で、今のＰＪをひとつのたたき台にしようとしている感じです。したがって、マニュアルチックになって実効性が薄いものを無理やり推奨しようとする動きもあって、かえって浸透しにくいのではないかと感じます。 |
いけちゃん様 |
| 標準なるものがない以上、一応テンプレート的には存在した方が良いと思う。ただ、これに縛られて、臨機応変にという点がうまくいくかどうか疑問な点があるが、経験がカバーしてくれると思います。 |
samson佐様 |
| 一定基準を設けることにより、開発側・顧客側双方のコンセンサスがとれ、問題や障害に対する姿勢や取り組みが積極的になる。 |
レントン.サ-ストン様 |
| 属人的なプロジェクトマネジメントを排除するためにも標準プロセスを整備する必要がある。 |
匿名希望 |
| 標準プロセスを核に、プロジェクト特性の応じた変更を加えて実施すべきだと考えている。核がないと、その都度プロセスを決めねばならず、非効率、もれが生じる、教訓が得られにくい等の問題がある。ただ、経験のない技術(新技術など）を使う場合などは、標準プロセスに引きずられすぎると、かえって誤る原因になることもある。 |
武康様 |
| プロセスに標準のガイドラインを設定するのは必然と考える。それによって、基本的な見落としを防ぎプロジェクト全体を早い時期にイメージすることが可能となる。ただし、プロジェクト特性による標準の適応度や、特別に考慮が必要な点等についてこ考察することが必要となり、単に標準を適応すればよいというスタンスでは、逆にリスクが増大する可能性がある。 |
藤重 茂様 |
| 優秀なプロジェクト運営ができる人材が一人いるよりも標準的なプロジェクト運営ができる人材が百人いたほうが失敗プロジェクトが減ると思う。 |
由田 裕明様 |
| 経験値の少ない者には有効だが、常に中身を洗い直していかなくては効果が少ない。 |
Chopper様 |
| メリット：行程がはっきりするためミスが少なくなる。デメリット：受注した仕事を、このプロセスで行う場合に、クライアントに受け入れられなかったら、仕事の進捗が悪くなる。 |
ちょま様 |
| 弊社では形だけのプロセス管理にとらわれているケースが多く見られる。よって残念ながら、弊社のプロジェクト成功／失敗はそのリーダにエンジンが載っているか？によって左右されています。ただし、そのリーダには明確なプロセスを持って実践しているのも事実です。 |
西川 元一様 |
多くの参加スタッフがプロジェクトへの関わり方について事前に共通の認識及び明確な帰属意識を持つもつことが出来るようにる。ただし、イレギュラーなイベントが起きたときの対処方法についても同じように対処プロセスを作っておかないと、協調性が乱れてケジュール管理も困難になるので要注意である。特に私はコンサルタントとして他社の指導を行っているため、管理の徹底にはコミュニケーション力が成果に直結するので非常に重要視しているところ
である。 |
齊木紀慶様 |
