CaFeterria

システム導入支援において、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.】

私が参画しているプロジェクトでは、基幹システムはアジャイル型とウォーターフォール型を組み合わせたハイブリッド型、周辺システムはウォーターフォール型で開発している。

このように開発手法の異なるシステム間のインターフェース開発を行う場合、基幹システムと周辺システム間の積極的なコミュニケーションによってマイルストーンを同期したうえでスケジュールの調整を図り、自システムの開発を遅延させないよう対応することが重要になると考える。

私が担当する人事システムとの連携では、基幹システム側の要件検討が遅延しており、開発遅延リスクを抱えていた。
そこで、基幹システム側には、人事システムとして要件確定が必要な時期を提示し、その期限内に要件が確定できないか調整しつつ、人事システム側とは、基幹システム側からの要件に依存しない機能を先行して開発する方向で対応した。

両システムの間に立つ調整役として、今後も双方の進め方や作業内容を理解し、密にコミュニケーションを取りながら進めていく所存である。

【投稿担当：G.F.】

最近、十数年ぶりに要件定義フェーズの重要性を再認識する状況に遭遇しました。

（詳細は割愛しますが、クロージングフェーズで要件の認識相違が発覚）

要件定義フェーズは、操作マニュアルやイメージ図等を使った所謂「紙芝居」で議論が進むケースが多く、認識相違が発生しやすいフェーズと考えています。

紙芝居を見ながら実際に動作しているシステムをイメージできるようにコミュニケーション頻度・密度を上げつつ、様々なモノを活用しながら進めたつもりでしたが、少しだけ足りていなかったなと反省しています。

「準備8割・実行2割」という言葉がありますが、PJの”準備”にあたる要件定義フェーズが非常に重要であることを改めて肝に銘じていきたいと思います。

【投稿担当：C.I.】

皆さんはユーザが安心して利用できるシステムを構築するには、何が重要だと思いますか。

導入実績、要件定義、セキュリティ・・・色々な観点が挙げられると思いますが、システム開発の最後の砦として、テスト工程が非常に重要であると考えます。

特に10～20年以上利用されている、いわゆるレガシーシステムとの連携が必要となる場合は、仕様がブラックボックス化していることが多く、改修した機能が他の機能に思わぬ影響を及ぼすことや、未知の仕様によって想定外の挙動になることもあります。

そのため、本番同様の検証環境を用意し、開発者の思い込みを排除した網羅的なテストを行うことが最低限必要です。

具体的には、第三者によるテスト仕様書レビューやツールを用いたテスト自動化、また、過去の失敗事例などナレッジの共有を図ることで、テストおよびプロジェクト全体の品質向上に寄与すると考えます。

【投稿担当：T.N.】