【バカでも分かるPM⓪】PMに出てくる用語集をまとめてみました。

ビジネスで出てきた用語をまとめていきます。

”見出し”に用語を入れておきます。

下に簡単に説明を書いていきます。

もしあなたの調べたい用語がありましたら、「command＋F」か下記の目次で調べていただければ光栄です！

[toc]

ビジネス用語一覧

プロジェクト

ステークホルダーマネジメント

スコープマネジメント

成果物記述書

基本的にプロジェクトのゴールを表した文書の事を指す。

最終的に作り出す製品だったり、サービスの特徴だったりと色々な”ゴール”が細かく記されている

制約条件

分かりやすい言葉にすると”前提条件”とも言う。

もともと前提として設定されているものなんかを指す。

プロジェクトを始める前に、プロジェクトに影響を与える前提としてあるリソース(予算とか、人材とか)を表す事が多い。

プロジェクト憲章

”プロジェクトチャーター”とも言う。

プロジェクト憲章には、プロジェクトが「スタート」から「ゴール」まで無事辿り着けるように、プロジェクトの詳細が細かく記されてあるももの。

中には、【プロジェクトの目的】だったり【プロジェクトのリスク】…などなどプロジェクトに関する事柄は全て書かれている

制約条件や成果物記述書もこの”プロジェクト憲章”に含まれている事がある。

スコープ定義

スコープマネジメントにおいて1番最初にするべきもの。

プロジェクトの成果物を細かく構成要素に分解したものを指す。

個々の実績から役割の分担だったりを明確にする事で、プロジェクトを円滑に進めさせる。

WBSにまとめる事が多い

WBS

Work Breakdown Structure(作業分割構造)の略。

プロジェクトにおける作業を分解して、分かりやすいように構造化する方法の1つ。

プロジェクトが「ゴール」に確実に辿り着けるように、プロジェクトの過程において全ての作業を漏れ無く洗い出す事に必要不可欠な方法である。

ワークパッケージ

簡単に言うと、WBSの最下層の作業の事を言います。

大きなプロジェクトの場合、めちゃくちゃ小さな作業過程の事を言うので外注される事があります。

外注された場合、外注先の会社はまたそのワークパッケージがWBSによって分割される事があります。

私はこれが俗に言う”下請け”の事を指しているのではないかと思っているのですが…。

スコープ検証

プロジェクトの1つの作業が終わると、成果物が完成します。

その成果物のレビューをする事で、その作業における要求事項に合っているかを確認します。

1つ1つの作業を検証する事で、確実に「ゴール」まで辿り着くことができるようになります。

※品質管理プロセスと同時に行う

品質管理プロセス

品質管理の考え方。

”プロセスコントロール”とも言います。

結果ではなく過程が非常に大切だと言うこと。

スコープ変更管理

プロジェクトを進めていると、必ず変更するべきものが出てきます。

その変更の発生をしっかりと確認し、WBSを修正することを指します。

変更管理の手順だったり、変更を検討する規定を予め決めて置くことも大事です。

変更した履歴が残るようにするのも忘れてはいけません。(プログラマーの場合はGitなんかが使えますね笑)

超概算見積

プロジェクトの選定なんかに使われ、プロジェクトの本当の初期段階で使われるコスト見積もり方法

フィージビリティスタディーの段階などで利用する。

精度の振れ幅が非常に大きい。

フィージビリティスタディー

プロジェクト案が出された時に、そのプロジェクトは実現可能かを確かめるもの。

予算見積

プロジェクトの予算を計算する際に使うコスト見積もり方法

見積もる際に得られる情報に比例して精度の質が変わるため、精度の振れ幅がやや大きい。

基本設計情報に基づいて行われる。

確定見積

プロジェクトの予算見積もりのなかで1番精度が高い。

詳細な設計情報の元、より細かい単価データ、数量…を計算する。

購買発注時に確実に見積もりを出すために使う。

類推見積もり

過去にある類似したものを参考にしてコストを見るモル手法

適切な判断は経験値がないと難しい。

ボトムアップ見積もり

求めたい資源のコスト見積もりを分解してここの見積もりを積み上げていく手法

時間やコストがかかってしまいやすい

パラメトリック手法

パラメトリックは”parameter(パラメータ)に基づくデータを予測して行う手法の事を言うらしい。

つまり統計学と密接に関係しており、プロジェクトの特性を利用したにコストを見積もっていく。

正直言って初心者にはむずいて

スケジュールバッファ

”緩衝材”とも言われている。

想定外のリスクなどによって、遅れたスケジュールを取り戻すための予備の時間などを指す。

完璧な計画はなく、必ず未知の時間や管理困難なリスクは出てくるためプロジェクトには必要不可欠な存在。

個別計画では設定せずに、全体の計画の中に入れておくべきもの。

ネガティブリスク

想定外のマイナス影響が出た場合のリスク。

プロジェクト内で、軽減策や回避策、転嫁策、受容策などをあらかじめ決めておくと良い。

ポジティブリスク

ネガティブリスクの逆。

想定外のプラスな結果が出てしまうこと。

タイムボックス

作業を達成するための、固定された時間の事を指す。

ITの世界でアジャイル開発なんかでも使われている。

やや分かりづらかったので、参照ページを載せておく。(参照)

ストーリーポイント

プロジェクト内の作業の大きさや大変さを相対的に数字で見積もるもの。

1, 2, 3, 5, 8, 13, 21, 40のフィボナッチ数で指定する。

かかる時間ではなく、あくまで作業の大変さや大きさで判断する

品質マネジメントの7原則

大事だから覚えておけって偉い人が言ってた。

プロセスアプローチ

全てのタスク(作業)の過程がしっかりと進むように、それぞれのプロセスにおける相互関係を把握した上で、1つのプロセスを”システム”として運用すること。

プロセスを明確にし、相互作用させて、運営管理する事で、プロセスがシステムとして適用できるようになる。

参照ページ

リレーションシップマネジメント

略称”RM”。

クライアントとの関係を管理する事を指す。

管理している人の事を指す場合が多い。

機能適合性

品質特性の1つ。

必要な機能がしっかりと揃っているのかを判断するもの。

使用性

品質特性の1つ。

ターゲットされたクライアントたちが、使いやすいと思えるものかを判断するもの。

保守性

品質特性の1つ。

システムや機能上で、修正したい部分や拡張したい部分があった時に、すぐに機能拡張ができるか判断するもの。

移植性

品質特性の1つ。

容易に他の環境にも移すことができるか判断するもの。

性能効率性

品質特性の1つ。

性能(早く動くか、メモリが少なくても動きやすいか)を判断するもの。

分かりやすく言うと、MacBookのM1チップが意識した部分。

互換性

品質特性の1つ。

環境を共有している場合、他システムと同じようにアクセスできるのかというものを判断するもの。

MacBookのM1チップには、やや欠けていた部分。
(Adobeとかが対応していなかった)

信頼性

品質特性の1つ。

信頼度があり、いつでも使えて壊れないのかというものを判断するもの。

多くの人は常に重要だと言う。

セキュリティ

品質特性の1つ。

安全性を判断したもの。

突然爆発したら怖いでしょ？

フォールト

IT用語でよく使われる。

欠陥の事を指す。

テスタビリティ

何かを検証(テスト)する時に、検証しやすいかを表したもの。

プログラミングの時にはデバッグなどが用いられる。

名前がちょっとカッコつけている。

ミッションクリティカルシステム

システムがしっかりと機能していないのに事で、使用者＋社会にも影響が出るレベルのシステムの事を指す。

ミッションインポッシブルに出てきそうな感じがする。

ミッションクリティカルプログラム

ミッションクリティカルシステムによって、利用可能なソフトウェアのこと。

アベイラビリティ

簡単に言うと、”耐久性”のこと。

システムが安定した状態で、使い続けることができるかを示したもの。

稼働時間の向上と、不稼働時間の減少を求める事で質が上がる。

ホウレンソウ(報・連・相)

報告、連絡、相談をしっかりとしようねと言うビジネス用語。

時代の変化によって消えていく気がする。

高コンテキスト文化

日本によくある文化。

コミュニケーションの予測がしやすいため、「察しろよ」と言う文化。

異文化コミュニケーションで度々問題になる。

俺は嫌い。

低コンテキスト文化

高コンテキスト文化の逆。

調達マネジメント

プロジェクトを行う上で、必要なリソースを外部から調達する管理のこと。

外部から調達するしかないものに関しては、この調達マネジメントが必須。

外部インターフェース

外部で仲介している媒体の事。

分かりづらいので、プロジェクトを一緒にやっていて、任せている外部のことと思ったら良いのでは.

コア・コンピタンス

他の企業とかサービスにはない圧倒的な強みのこと。

競合が真似できない、核となる強み。