About Us
JPSはプロジェクトマネジメントのプロフェッショナル集団です。
JPSは日本中のあらゆる業種・業界の企業に向けたプロジェクトマネジメントサービスを提供しています。技術の進歩やビジネスモデルの変化に伴い、単にプロジェクトマネジメントができればよいということではなく、クライアントの文化や価値観、習慣などを深く理解すること、またマインドセットやコミュニケーション能力が必要不可欠です。JPSのプロジェクトマネージャーが、価値あるプロジェクトマネジメントのご支援をいたします。
Our Services
Backlog Solution
JPS Style
適応型マネジメント
適応型マネジメント
三現主義に基づき、実際に『現場』へ行き『現物』を確認し『現実』を認識した上で、机上の空論ではない問題解決を実行します。
学習と改善を織り込んだ高速回転するPDCAプロセスループを実現します。
アジリティ（俊敏性）マネジメント
現場で発生する事態をあらかじめ想定し備え、プロアクティブな活動を行い、組織の生み出すバリューを高め、リスクの軽減を図ります。
作業の｢ムリ｣｢ムラ｣をなくし平準化を実現し、プロジェクトのあらゆる局面に、迅速に対応します
アジリティ（俊敏性）マネジメント
自律的組織マネジメント
自律的組織マネジメント
役割に限定しないフレキシブルな協力関係を醸成し自ら学習改善するチームを組成します。
チームの知識と経験を集合知として、プロジェクトマネジメントの標準化と見える化を行い、現場の状況に応じ、自発的に最適な活動を行います。
News
- PMIイズム#6 「すべての部署のタスクに責任を負う責任感を有している」
Team Work 「責任感を有している人」とは、プロジェクトにおいて課題が発生した場合において発生元がどこであろうと自分に責任があるとしてメンバーを上手く巻き込みつつ解決に向けて動く人、そして、メンバーから相談された際にベストエフォートでの対応を迅速に行える人である、と考えます。
PM/PMOの責任感が最も問われるのはやはり「問題が発生した時」になります。「問題が発生した時にまず何をするべきか?」PMPのシチュエーション問題にもこの手のものが多く出題されるはずです。
ここで必要になるのが「メンバーを上手く巻き込んで原因を究明し、解決に向けて動くこと」であると考えます。
問題の多くは一人で解決することは到底難しく、また、抱え込んでしまうとかかりっきりになってしまい本来やるべきことが放置されてしまいます。メンバーが全員揃っている場で問題の原因を究明し、メンバーと合意しながら「誰が何をどうするか?」つまり、解決に向けた動きを決めていくことが求められます。
こうすることで自身だけでなくメンバーにも責任感を持たせることができ、問題が再発するリスクについても軽減できるはずです。
さらに、実際に動き始めてからも対応の経緯をメンバーに共有していく必要があります。こういう場合のコミュニケーション手段としてはまずは口頭でメンバー全員に問題の内容を共有し、そこからはメールやSlackやBacklog等、経緯を自動的に蓄積できるツールも組み合わせていくのがよいと考えます。
また、PMOはいろいろな開発メンバーから相談を受ける立場でありますが、技術的にコアな内容であったり、自分が管轄しているチーム外に関する内容であったりと、即答できない場合も多々あります。この際、相談を無視したり他人に丸投げしたり、そのまま黙り込むだけになったりしてしまうと当然メンバーからの信頼を失います。
私自身、現在支援に入っているプロジェクトでは技術的な部分にどうしても深入りできない状況ですし、かと言って技術に精通している訳でもありません。そこで、日々の業務で心がけていることとしては・技術的な相談を受けた際には「橋渡し役として回答できるメンバー と取りつなぐ」よう調整する
・メンバーが技術的な作業に専念できるよう事務的な作業を巻き取る
・とにかく何か1つでも自分にできることを見つけて実行に移す
といった感じになります。
「責任感」からは少々脱線してしまった話となってしまいましたが、メンバーがお互いに支え合う、方向性が1つにまとまっている、そして納期に間に合う「強いチーム」ではPM/PMOのみならずメンバー全員が責任感を有して行動できていると考えます。
そして、私たちJPSメンバーのミッションは支援に入っているプロジェクト/チームにおいてメンバーに責任感を持っていただけるようなファシリテーション、そして後方支援を実施することであると考えます。 - PMIイズム#5 「問題や課題を自分事としてとらえ、エスカレーションは最後の手段」
「相談」と「エスカ」は別物 今回はエスカレーション（エスカ）について考えてみました。
「エスカは最後の手段」と言われますと、上長に相談することはよろしくない行為になってしまうのか?と
ふと思いました。そして、「相談」と「エスカ」は何が違うのか?を調べてみました。
結論としましては、「相談」と「エスカ」は別物になります。相談は相手に責任を持たせませんが、
エスカは相手に責任を持っていただきその後の対応を全面的に委ねることとなります。
つまり「バトンを渡さないか渡すか」の部分に違いがあります。こちらの違いについて把握できますと、
エスカ、つまり上長にバトンを渡して委ねる行為は最終手段とするべき、ということは正しいと考えます。
エスカに踏み切る条件としましては、
・顧客や上位会社からの予定外かつ理不尽な要求の発生
・想定外事象（キーマンの急な離脱、偶発的なシステム障害）の発生
等、どうしても自分たちで対応ができず、上長に主体的に動いていただく必要性が生じた場合に限られます。
また、当然のことながらエスカは気軽に行ってよいものではありません。
エスカを確実に行えるようにするため、また、いざエスカを実施した際のもめごとを最小限に
抑えるため、プロジェクト参画時とエスカの予兆を感じた際において必要な取り組みを考えてみました。
■プロジェクト参画時に必要な取り組み
①エスカ先を決め、合意しておく
エスカ先の相手となるのは自身の作業責任者であることが一般的ですが、困った時には相談、
そして最終手段としてエスカさせていただくことについて予め合意しておくことが必要です。
②エスカ先を間違えない
プロジェクトの体制を把握し、エスカ先を間違えないようにする必要があります。
③エスカ先が機能しない場合の相談先を決めておく
必ずしもエスカ先が機能するとは限りません。こうなった場合、しかるべき人に相談して申し入れてもらう
必要があります。私の場合は大山さん、藤原さんになります（その際にはよろしくお願いいたします！）。
■予兆を感じた際の取り組み
①布石を撒いておく
何らかの課題が発生し、近い将来エスカすることになるかも?と感じた際にはこまめに報・連・相を行い
状況を少しづつ理解してもらうことが必要です。
②経緯を文書化しておく
課題発生からエスカに至るまでの経緯はもれなく文書化しておく必要があります。
何も無い状態で単純にエスカしてしまうと経緯の説明・把握にお互いかなりの時間を割くことに
なってしまいます。そして、エスカ先から厳しいお叱りを受けることになりかねません。
③チーム内でのベクトルを合わせておく
エスカの際、チーム内で認識齟齬があると後々もめることになりかねません。
必ずチーム内の認識を1つにしてからバトンを受け取ってもらう必要があります。
こちらのイズムでは、何より「相談とエスカの違い」について理解できたことが大きかったです。
エスカは最後の切り札ですが、相談は相手に迷惑を掛けない、相手に余計な作業を発生させない範囲内では
躊躇なく実施するべきと考えます。私自身、相談を受けることは嫌ではなく、むしろ嬉しいと感じたりもします。
そして、気軽に相談しあえることがイズムの前半にある「問題や課題を自分事としてとらえる」ことに繋がり
チームは確実に強くなっていくと考えます。 - PMIイズム#4-2
「プロジェクトに対し、積極的であり（受け身ではない）、常に他の施策を持っている。」
PLAN-Bの重要性 今回は「他の施策を持つこと」についてです。
何かの施策を提案する際、裏で他の施策を持つことはこれまで私自身意識できていなかったことになります。冷静に考えてみますと、顧客に施策を提案する際、単一の施策のみではやはり強引な感じがしてしまい印象が悪くなるかもしれません。また、次の施策を出すまでに時間がかかればそれだけ信頼度も低下します。一方、複数の施策を出してベストのものを選んでもらうようにする、最初に出した案がNGを食らってもすぐに裏で準備しておいた別の案をぱっと出すことができれば信頼度は間違いなく高まります。
私は「UNO」やトランプの「大富豪」では切り札を早めに出して短期決着を図るタイプでした。その際、より強いカードを持っていた人にやられてしまうのがいつものパターンでした。提案する際も同じで自分が出した案がボツになり、顧客の出した案にそのまま迎合してしまうとこちらも「負け」を意味することになります。ここでぱっと出せる「2枚目の切り札」があれば負けを消すことができ、提案力の高いPMとして信頼を勝ち取ることができるはずです。
「UNO」「大富豪」でも同じで、切り札を2枚持っておけば負けなかったと思います。
状況によっては出せる案がどうしても単一になることもあります。ただし、顧客としても
単一の案で進めるより複数の案を比較するほうが検討も進めやすく、お互いに仕事も面白くなります。そして、こういう所から顧客との信頼関係も生まれてくると考えます。