CaFeterria

製造業一筋だった私が、初めてコンサルタントになった。

現在は、製造業のお客様のシステム導入プロジェクトに、

工場側のPMとして参画している。

以前の職場では、私も長年SAPを使っていた。

とはいえ、使いこなしていたかと問われれば怪しい。

誤った処理の修正となるとお手上げで、

決まって「社内のSAP駆け込み寺」のお世話になっていた。

システムは立派でも、私の業務を救ってくれたのは人だった。

今のプロジェクトでも、工場の現場から多くの質問が寄せられる。

画面の操作は分かっても、

それが日々の業務のどこにつながり、

仕事がどう変わるのかまでは見えにくい。

かつての自分を思い出し、現場の戸惑いもよく分かる。

一方、今は支援する側である。

現場の疑問を担当者につなぎ、

課題が埋もれないよう進め方を見直し、

計画を具体的な作業に落とし込み、

解決まで動かしていく。

かつては駆け込み寺の常連だった私が、

今は迎える側になった。

現場で悩み、助けられてきた経験は、

私なりの「お経」になっている。

目指すは、誰もが駆け込めて、

一人ひとりの悩みに寄り添い、解決へ導く説法のできる住職。

そんな唯一無二の住職になれると、確信している。

【投稿担当：I.T.】

ある小売企業様のポイント制度刷新支援では、

店舗とECで共通のサービスレベルを提供するにあたり、

顧客データ基盤とEC側のリアルタイム連携が論点となりました。

営業側が店舗と同じ即時ポイント付与など体験の一元化を求める一方、

カスタマーサポートや店舗からは

「連携遅延による手作業補填は避けたい」

という現場目線の要望があり、

開発側からは

「既存ECとの連携改修に多大な費用と納期がかかる」

と難色を示されるなど、

それぞれの立場から要望や懸念が寄せられました。

こうした状況でPMOに求められるのは単なる意見調整ではなく、

サービスを分解・構造化してクライアントの適切な判断を導くことです。

ポイント計算ロジックは共通化しつつも、

即時性が求められる店舗はリアルタイム連携、

EC側は夜間バッチ連携で時間差を許容するなど仕様を切り分けることで、

顧客体験・コスト・現場負荷のバランスが取れた意思決定を支援できました。

【投稿担当：T.H.】

立場や役割が異なる人々が集まるプロジェクトでは、

同じ言葉を使っていても捉えている側面が違う。

例えばテスト進捗の報告一つとっても、

予定通りの完了という「納期」を管理する立場と、

バグの出し切りという「品質」を重んじる立場では、

注視するポイントが異なる。

このズレを放置すれば、議論は平行線をたどり、

意思決定の遅れや終盤での致命的な手戻りを招きかねない。

こうした事態を防ぐため、

私はまず自分なりの「たたき台」を提示することを実践している。

最初から完璧な正解を出すのは難しくとも、

議論の出発点を作ることはできるはずである。

誰かに判断を委ねるのではなく、

不完全でも案を作り「これで進められそうか」と具体的に問いかける。

目に見える材料があって初めて主体的に動く足がかりが得られ、

クライアントも「何が判断の壁か」を具体的に示せるようになる。

たたき台を介して互いの観点を共有し合うことで、

隠れていた齟齬が解消され、合意形成へと向かい始める。

バラバラな認識を揃え、そこにある観点を丁寧に繋いでいくこと。

その積み重ねこそが、プロジェクトを前へ動かす確かな一歩になると信じている。

【投稿担当：S.S.】

システム開発プロジェクトにおいて、「情報・意見・相談」を早期に吸い上げ、

解決につなげる仕組みづくりは、プロジェクト運営の重要な要素です。

開発現場では、関係者が多く、専門性も異なるため、

必要な情報が必要な人に届かないことで、

認識のズレや手戻り、進行遅延が発生しやすくなります。

こうした状況を防ぐため、現場では「どの情報を、誰に、いつ伝えるべきか」

を意識した情報共有を心掛けています。

定例の会議や資料共有に加え、

進捗の変化や小さな懸念点についても早めに共有することで、

認識のズレが大きくなる前に調整することが可能になります。

また、メールやチャットといった文字情報だけに頼らず、

必要に応じて対話の機会を設けることで、背景や意図を含めた理解が進みます。

こうした意識を積み重ねることが、

円滑なプロジェクト推進と成果につながると考え、日々業務に臨んでいます。

【投稿担当：Y.S.】

システム導入支援において、PMOの主軸はシステム仕様やベンダー調整、

スケジュール順守といった“第1領域（重要かつ緊急）”の業務です。

今回従事している総合小売事業会社のPOS導入プロジェクト（PJ）でも、

それは当社として全力で果たすべき中心使命です。

そのうえで私が意識しているのは

“第2領域（重要だが緊急ではない）”の課題を見逃さないことです。

現PJの例では従業員の期待コントロール、他PJとの歩調合わせ、

顧客・関係会社告知、展開日と開店時間確定、

導入メリット／デメリットの明確化などが該当します。

従業員・関係会社・顧客などは導入効果の評価者であり

局面によってはPJの継続をも左右しうる最もケアすべき存在ではないかと思います。

またメリデメは状況が複雑化したときなどに経営判断がブレないための大義となります。

どれも差し迫ったときに後付けでは間に合わない、経営者にとっての重要事項です。

抽象的になりやすい第2領域は、まず課題を具体化し、

続いて解決に着手する承認を得て経営報告への道筋を作って取り組みを進めやすくして、

優先順位が下がりそうなときは自分が推進力となることが重要だと考えています。

【投稿担当：T.N.】

コンサルタントとして勤務し始めて、半年が経ちました。

前職ではSIerとしてシステム開発や導入サポート等を担当しました。

現在は業務支援の立場でシステム更改のプロジェクトに参画しています。

コンサルタントとしてまず意識を変えねばならないと思ったのは、「タスク管理」の方法です。

例えば、Sler時代のシステム運用のサポート業務においては、

発生する課題・問題が明確、かつ優先順位付けや工数算出が容易なケースが多く、

矢次に処理していくことが多かったと思います。

しかし現在の業務は、課題自体を提起し、

タスクを細分化したうえで優先順位を設定していくことが多く求められています。

定量的な根拠に基づき工数を出すことはもちろんのこと、

全体のスケジュールや後続タスクへの影響などの必要な情報を集め、

より全体の動きを見て設定していく必要が有ると感じています。

まだまだ慣れない点も有りますが、

コンサルタントとして求められる視点や思考をいち早く会得できるよう、日々精進しています。

【投稿担当：R.K.】

“現在のPJにアサインされてから対面での打合せの重要性を感じております。

コロナ禍に急速に普及した在宅勤務ですが、コロナ終息後も一般的な働き方になり、

今では就活生が重要視する企業選びのポイントに、在宅勤務の可否があげられるほどです。

つい先日まで学生だった私も、「在宅勤務」など当たり前という価値観とともに入社いたしました。

しかし入社してから、クライアントと顔を合わせる重要性を幾度となく感じています。

オンラインミーティングでは相手の表情や態度といった言外の情報が漏れてしまうことが多く、

また発言の心理的なハードルも対面より高くなってしまいます。

他方で、対面であれば相手の反応を見て随時補足を行ったり、

また雑談ベースで会議で聞き漏らした情報を補うこともできます。

実際に現在のPJでは、新システム導入後に実現したい要件について、

「業務上必要不可欠」なのか「あればベター」なのかといったレベル感や、

それに対する各担当者の本音を聞き出せるのは、対面で打ち合わせいただいた時が多いです。

こうした認識のすり合わせの積み重ねが、最終的なPJの満足度を左右するのだろうと日々実感しております。

【投稿担当：K.I.】

最近、プロジェクトで「言った言わない」や誰の責任なのかという課題解決に直接関係ない話に時間を使われてしまう場面に遭遇しました。

従来のウォーターフォール型のシステム開発プロジェクトでは、

前工程までの意思決定が重視されるため、過去の経緯を振り返るプロセスが挟まり、

問題解決の意思決定までに時間が掛かっていました。

しかし、昨今のプロジェクトでは物事を迅速に前へ進めるスピード感が求められていると感じています。

特に海外のメンバが主導するグローバルプロジェクトでは、その傾向が強いと感じており、

私が経験したSAPロールインプロジェクトでは、

問題が発生すると海外メンバが即座に関係者と打ち合わせを設け、

取るべき対応を重点的に議論していたことが印象的でした。

基幹システムなど大規模なシステムであれば、

開発手法としてのウォーターフォール型は有効なアプローチではありますが、

長期間のプロジェクトの途中で、状況を一変する出来事が起こることは珍しくないため、

プロジェクトメンバには、そのような事態に柔軟に対応できるアジャイル的思考が必要だと感じています。

【投稿担当：K.Y.】

私はグループ各社に対し、共通会計システムの導入と業務プロセスの標準化を行うPJで、ユーザ側の各種検討を支援しています。

この“標準化”とは言うは易く行うは難しであり、実現に向けては大小様々な課題や衝突があります。

それらの解決に際し、私が心がけているのは、頭ごなしに方針を押し付けるのではなく、関係者にしっかりと納得してもらうことです。

業務プロセスを標準化することで、とある会社の業務が複雑化してしまうようなケースでは、（当たり前ではありますが） 現場担当者から反発がありました。
その際、“PJ方針だから“と推し進めることもできましたが、今後もPJを円滑に進めるためには、ここでしこりを残さない方が良いと考え、親・子会社双方の役員も交えた検討の場を設けました。
その結果、関係者間でPJ方針を再確認した上で、個社の事情を踏まえた現実的な落としどころ（ToBe業務）を見つけられ、今に至るまで大きな問題無くPJを推進できています。
今後も各社の事情にも配慮しつつ、グループ全体として最適な結論へ導けるよう、支援していきたいと思います。

【投稿担当：H.Y.】

多くのプロジェクトは複数チームで体制が構築されており、チーム横断の適切なコミュニケーションが重要となります。

チーム横断で検討が必要な事柄について、チーム間のコミュニケーションが不十分な場合、

後々他チームから「その話は認識できていなかった。その検討結果は許容できない。」と

自チームで一度検討が完了したことを再検討しなくてはいけないことがあります。

このような手戻りを防ぐためにも、検討時には「チーム内で検討を留めてよいか」

または「他チームとの認識合わせが必要なのか？またそのチームはどこか？」を都度考える必要があります。

また、チーム横断の課題は管理主体チームが曖昧なことが多いため、対応を漏らさないためにも、

管理主体チームを明確にしたうえで、横断課題としての管理が必要となります。

私はしばしば自身の視野の狭さを痛感することがあります。

そのため、チームを横断した適切なコミュニケーションを常に意識しなければならないと、

強く思っている今日この頃です。

【投稿担当：Y.N.】