About Us
JPSはプロジェクトマネジメントのプロフェッショナル集団です。
JPSは日本中のあらゆる業種・業界の企業に向けたプロジェクトマネジメントサービスを提供しています。技術の進歩やビジネスモデルの変化に伴い、単にプロジェクトマネジメントができればよいということではなく、クライアントの文化や価値観、習慣などを深く理解すること、またマインドセットやコミュニケーション能力が必要不可欠です。JPSのプロジェクトマネージャーが、価値あるプロジェクトマネジメントのご支援をいたします。
Our Services
Backlog Solution
JPS Style
適応型マネジメント
適応型マネジメント
三現主義に基づき、実際に『現場』へ行き『現物』を確認し『現実』を認識した上で、机上の空論ではない問題解決を実行します。
学習と改善を織り込んだ高速回転するPDCAプロセスループを実現します。
アジリティ（俊敏性）マネジメント
現場で発生する事態をあらかじめ想定し備え、プロアクティブな活動を行い、組織の生み出すバリューを高め、リスクの軽減を図ります。
作業の｢ムリ｣｢ムラ｣をなくし平準化を実現し、プロジェクトのあらゆる局面に、迅速に対応します
アジリティ（俊敏性）マネジメント
自律的組織マネジメント
自律的組織マネジメント
役割に限定しないフレキシブルな協力関係を醸成し自ら学習改善するチームを組成します。
チームの知識と経験を集合知として、プロジェクトマネジメントの標準化と見える化を行い、現場の状況に応じ、自発的に最適な活動を行います。
News
- PMIイズム#7「変更要求に対し常に分析し、真摯に対応している。」
PMIイズム#7
「変更要求に対し常に分析し、真摯に対応している。」
変更要求は常にプロジェクトのメンバーをとことん苦しめ、時に混乱に陥れるものです。……いきなりネガティブな出だしになってしまいましたが、「変更要求をいかに上手く確実に処理していくか」がプロジェクト成功の鍵になることは間違いありません。
変更要求が発生した場合、まず変更による影響を分析し、影響が発生する各種ベースライン、成果物を漏れなく修正する必要があります。
ここがプロジェクトの勝敗を左右すると言っても過言ではありません。
例えば、変更要求によりソースコードは修正しても設計書の修正が漏れてしまった場合、両者の整合性が崩れます。そして、後々になって発見された場合、「他にも絶対ある」と見なされ全面的な見直しを求められてしまいます。こうなるとデスマーチに向かって一直線です。
変更管理の最も難しい点としては「対応フローを複雑にすると多くの時間が奪われる」ところにあります。私が過去に参画していたプロジェクトでも影響分析→成果物の修正→メンバー間クロスチェック→リーダーレビュー→管理者レビュー→顧客レビューと、1つの変更を処理するためにとてつもなく長いステップを踏むようにルール化した（実際は親会社が強引に決めた）結果、実に多くの時間を浪費してしまいました。スケジュールはどんどん遅延し、最後に待っていたのは部長による容赦ない怒号の嵐でした。
何に時間がかかっていたかと言うと資料の印刷・準備、レビュー記録票の作成、レビューアのスケジュール確保等、コアではない部分ばかりとなります。コアとなる作業である成果物の修正にかかる時間は正直なところ全体の1割にも満たない、という感じでした。
さらに、どこかのレビューポイントでNGになると振り出しに戻ります。
当時は紙文化が常識であり、Googleカレンダーのようなツールも浸透していない時代でしたのである程度は致し方無いのですが、これでは最初から自分たちで自分たちの首を絞めるだけでした。当然のことながらプロジェクトは大赤字の大失敗に終わりました。
「変更要求に真摯に対応する」とは、必要最小限の工数で全ての変更要求を迅速かつ的確に処理できるような仕組みを作り、運用に乗せることがゴールであると考えます。方法としてはチケットツールの導入、ペーパレス化の推進、レビューをできるだけ複数件まとめて実施する等が考えられますが、無駄な時間をいかに省けるか?を考える必要があります。ここは手動でやっていることを自動化する、つまり解としては「自動化を実現できるツールを導入する」所に着地します。
例えば、Confluenceを導入してドキュメントのマスタをこちらに統合しますとドキュメントの作成・レビュー・指摘取込を全て同じ場所で実施できますし、レビュー時のコメントがそのままレビュー記録票になります。さらに変更履歴も個別に書く必要もありません。
また、変更要求をjiraやBacklogのチケットで管理すれば発生から完了までの経緯を自動的に蓄積できます。このように、手作業で実施すると面倒かつ作業漏れが発生しやすい部分に対し、いかにツールを適用して自動化するか、ここを提案し、運用していくことがPMOに求められていると考えます。
私自身、変更要求を捌くことに対するベストプラクティスには辿り着けていない状態ですので、引き続きいろいろと経験を積みながら、そしてトライ&エラーを繰り返しながら最適解を探していきたいと思います！ - 2023年 ゴールデンウィーク期間休業のお知らせ
平素は格別のご高配を賜り、厚く御礼申し上げます。
日本プロジェクトソリューションズでは、ゴールデンウィーク期間中は下記のとおり休業とさせていただきます。
休業期間中、お問合せは受け付けておりますが、お問い合わせに対するご返信は営業日に順次対応させていただきます。
皆様にはご迷惑をおかけいたしますが、何卒よろしくお願い申し上げます。2022年4月29日（土） 休業日
2022年4月30日（日） 休業日
2022年5月1日（月） 営業日
2022年5月2日（火） 営業日
2022年5月3日（水） 休業日
2022年5月4日（木） 休業日
2022年5月5日（金） 休業日
2022年5月6日（土） 営業日
2022年5月7日（日） 休業日
2022年5月8日（月） 営業日 - PMOに求められるセキュリティ施策#1
どこのプロジェクトにおいてもセキュリティインシデントは起こりうるものであり、未然に予防するための教育も定期的に実施されています。
そして、実際にセキュリティインシデントが発生した場合、PM/PMOに対して再発防止策を検討するような依頼が発生することもあります。
一方で、PMBOKにおいてセキュリティに関するネタはさほど出てこないのが実情でもあります。
そこで今回は「セキュリティ施策」に着目する形でコラムの連載を開始させていただくことにしました。
支援に入っているプロジェクトにおいて「○○について検討いただけないか?」という依頼を受けているはずです。
そして、JPSにはこの際「依頼されたことだけでなく、他にも何かプラスアルファの価値を出す形で応えよう」とする素晴らしい思考を持つメンバーも多くいるはずです。
私は、こちらの「プラスアルファ」について、セキュリティに着目し、セキュリティを強化するための施策を提案したいと考えます。
例として、「コミュニケーションツール」で考えてみることにします。
以前は「経緯・証跡を残せる唯一のコミュニケーション手段」はメールでした。しかし現在では、SlackやTeams等のメンション機能を有するツールが主流となり、メールを使う頻度は減ってきています。そして、「社内に限定したコミュニケーションはSlack（Teams）を使い、社外に連絡が必要な場合のみメールを使う」ことをルール化しているプロジェクトも多く見られるようになっています。
この際、「メールには誤送信、標的型攻撃、サイバー攻撃等のセキュリティインシデントが発生するリスクがついて回るが、用途を制限し使用頻度を減らすことでリスクを軽減できるだろう」と言われることがあります。
しかし、ここで大切なのは「リスクは軽減されるのではなく余計増える」と考えることです。
何故かと言いますと、メールを「たまにしか使わないようになってしまう」ことでルールを忘れ、基本的なルールである送信時の宛先確認や添付ファイルの暗号化等が漏れてしまう可能性が高くなってしまうためです。
さらに対社外となると、セキュリティインシデント発生時の影響が社内のみの場合と比べはるかに大きいことは明らかです。
対策としては、社外へのメールを送信できる人や送信先のドメインに制限をかけること、セキュリティ教育の定期的な開催によりメンバーへの注意喚起をより一層徹底すること等が考えられます。
このように、何かを依頼された際、セキュリティに着目することでプラスアルファの効果をもたらすポイントが見えることがあるはずです。
既存のルールを改善したり、新たなルールを策定する際にはそのルールをより良いもの・価値のあるものにしていくための施策に加え、「改善や策定により新たに発生する可能性があるセキュリティインシデントに目を向け、もし何か見つかればこちらを未然に防ぐための施策を考え、提案する」ということも必要だと考えます。