記事一覧

基幹刷新のデータ移行は、後工程の作業ではなく上流の判断です。範囲、切替方式、データ品質、照合の基準まで、要件定義の段階で決めておく論点を整理します。

新しいサービスの立ち上げには、もとになる現行業務がありません。要望を仮説に書き直し、外れたら困るものから確かめて、要件に固めていく進め方を書きます。

客先の評価は、参画して最初の1週間から3か月でほぼ固まります。あとから印象を上げるのは大変です。最初の時期に何で全力を出すかを、時期ごとにまとめました。

検討資料の「前提」欄には、性質の違うものが混ざりがちです。前提・制約・未決事項に分けて書く型と、会議での使い方をまとめました。

客先のPMOに入って最初の1か月は、関係者・会議体・決め方・資料の置き場・課題の流れをつかむ期間です。信頼をつくるまでの動き方を、場面ごとに書きました。

議事録の下書き、論点の洗い出し、質問リスト、資料の要約。要件定義で生成AIに任せてよい作業と、合意や優先順位など人が持つべき判断の線引きを、現場の場面で整理します。

「作る側」から「決める側の隣」へ。SIerのPMがITコンサルに移ったときに戸惑いやすい点と、SIerで積んだ経験がどこで生きるのかを、会議や資料の場面で整理しました。

基幹システム刷新の初期に行う現状調査で、上流の担当者が最初に確かめたい5つの観点を整理します。業務とデータの流れから契約の期限まで、現場の場面とあわせて紹介します。

自動車業界のITプロジェクトは、開発から生産、品質、サプライチェーン、販売、全社基盤まで広がっています。領域ごとに上流の役割が求められるテーマを一般論で整理します。

現場をまとめ、進捗と課題を見て、顧客と調整する。SESのリーダーとして積んだ経験が上流の仕事でどう生きるのかと、足りないものを身につける方法を整理しました。

PoCが本番に進まない原因の多くは、検証を始める前にあります。検証の問いと合格基準を先に決め、本番化の判断者・費用・運用を最初から計画に入れる方法を整理します。

議事録の先頭に、決定事項・未決事項・宿題を置く型を紹介します。会議中の確かめ方、送るタイミング、合意がずれたときの取り直し方まで、上流の会議で使える形で書きました。

業務委託として客先に参画したとき、生成AIについて最初に確かめておきたい観点を整理しました。使ってよいツール、入力できる情報、成果物への記載、ログ、個人アカウントの扱いです。

構想や要件定義のWBSを成果物で切ると、進み具合が見えにくくなります。「決めること」を単位にした計画の立て方と、進み具合の測り方、気をつけたい点を書きました。

準委任契約でプロジェクトに入る前に、契約書と事前の打ち合わせで確かめておきたい点を、業務の範囲、精算幅、指揮命令、商流、守秘、契約期間の順に整理しました。

システム連携の方式は、技術の好みではなく業務の条件で決まります。ファイル、API、メッセージング、DB連携を、頻度・即時性・障害時の扱い・所有者の軸で整理します。

業務委託・準委任で客先に入っていると、どこまで自分で動き、いつ誰に上げるかに迷います。判断の軸と、相手が動きやすくなる伝え方の型を、場面ごとに書きました。

要件定義書のレビューを頼まれたとき、誤字の指摘だけで終わらせないための観点を整理します。目的とのつながり、範囲外、非機能、例外、移行、決めた人と日付を順に見ていきます。

複数のベンダーが並ぶプロジェクトでは、各社の契約の隙間に仕事が落ちます。発注者側のPMOとして、境界、課題管理、日程の結合点、会議体をどう押さえるかを書きました。