この機能が特に効果を発揮するのは、複数のプロジェクトが並行して進行し、リソースを横断的にやりくりする必要がある組織です。たとえば、特定のスキルを持つコンサルタントやエンジニアが複数プロジェクトに部分的にアサインされている場合、どこに余力があり、どこが過密なのかを把握することは簡単ではありませんでした。Get organization-wide view of assignmentsを使うことで、個別プロジェクトの枠を超えてアサイン状況を一覧できるようになり、リソースの偏りやボトルネックを早い段階で把握しやすくなります。結果として、アサイン調整や追加要員の判断を、経験や勘ではなく全体像を見た上で行えるようになります。

2025wave2までのProjectOperationsでも、リソース管理そのものは可能でしたが、視点はあくまでプロジェクト中心でした。プロジェクトマネージャーは自分の担当プロジェクト内でのリソース状況を把握できますが、別プロジェクトで同じリソースがどの程度使われているかを把握するには、個別に確認する必要がありました。そのため、組織全体としての最適配置よりも、プロジェクト単位での最適化が優先されがちで、結果として一部のリソースに負荷が集中したり、逆に余力が見えにくくなる、といった課題が残っていました。

2026wave1では、こうした前提が変わり、組織全体を横断したリソースアサイン状況を俯瞰できるようになります。プロジェクトをまたいだ割り当てを一覧で把握できることで、個別最適ではなく全体最適の視点でリソース計画を考えやすくなります。これは単に「見える化」するだけでなく、今後の要員計画や案件受注の判断においても重要な材料になります。どのスキル領域が慢性的に不足しているのか、どのタイミングで余力が生まれそうかといった判断を、より現実的なデータに基づいて行えるようになる点が、この機能の価値だと言えるでしょう。

一方で、留意点もあります。組織全体のアサイン状況が見えるようになると、データの正確性がこれまで以上に重要になります。アサイン情報が最新でなかったり、実態と乖離していたりすると、全体ビュー自体が誤解を生む可能性があります。また、誰がどのレベルでこの全体ビューを見るのか、どの情報までを共有するのかといったガバナンスの整理も必要です。この機能はリソース管理を自動化するものではなく、意思決定の材料を提供するものです。だからこそ、日々のアサイン更新を前提とした運用と組み合わせることで、初めて組織全体のリソース活用を一段引き上げる力を発揮すると言えそうです。

この機能が特に効果を発揮するのは、プロジェクト立ち上げ時の初期アサインや、同じ役割・スキルを持つメンバーを複数名まとめて投入するケースです。従来は、同じ期間・同じ要件であっても、予約操作を一人ずつ行う必要があり、入力ミスや期間設定のズレが発生しやすい状況でした。複数のリソースをまとめて予約できるようになることで、同一条件でのアサインを一つのまとまりとして扱いやすくなり、計画作業のスピードが上がるだけでなく、手作業に起因するミスも抑えやすくなります。

2025wave2までのProjectOperationsでは、リソース管理や予約の仕組み自体は整っていましたが、操作の単位は基本的に「一人ずつ」でした。そのため、チーム規模が大きくなるほど予約作業の負担が増え、リソース計画がボトルネックになるケースも少なくありませんでした。予約方法や割り当てロジックはあっても、実務の中では「まとめてやりたいができない」という操作上の制約が残っていたと言えます。

2026wave1では、この制約が解消され、同じ要件に対して複数のリソースを選択し、予約内容を確認したうえで一括で予約できるようになります。これにより、リソースマネージャーやプロジェクトマネージャーは、チーム単位でのアサインをより直感的に行えるようになり、大規模または並列チームの人員配置をスムーズに進められるようになります。操作の効率化という観点だけでなく、計画全体の見通しを保ったままアサインを進めやすくなる点が、この機能の価値だと言えるでしょう。

一方で、留意点もあります。複数のリソースを一度に予約できるようになることで、アサイン確定のスピードは上がりますが、その分、要件定義や期間設定が曖昧なまま確定してしまうリスクもあります。また、誰がどの段階で予約を確定するのか、提案と確定の境界をどう運用するのかといったルールが整理されていないと、過剰予約や後戻りが増える可能性もあります。この機能は予約を速くするためのものですが、リソース管理の判断そのものを自動化するものではありません。日々のアサイン更新と運用ルールを前提に使うことで、初めて効果を発揮する機能だと言えそうです。

この機能が効果を発揮するのは、リソースマネージャー、プロジェクトマネージャー、現場担当者など、複数の役割がリソース予約に関わる組織です。たとえば、ある担当者は柔軟に空き時間へ割り当て、別の担当者は期間全体を固定で押さえる、といった運用が混在すると、結果として過剰予約や認識違いが生じやすくなります。Configurable booking methodを用いることで、予約時に採用する方法を事前に定義し、そのルールに従って予約が行われるため、属人的な判断を減らし、計画と実績のズレを抑えやすくなります。

2025wave2までのProjectOperationsでは、リソース予約の機能自体は十分に備わっていましたが、予約方法の選択や使い分けは運用側に委ねられていました。そのため、同じ組織内でもプロジェクトごと、担当者ごとに予約の考え方が異なり、後から全体を見たときに「なぜこの予約になっているのか」を説明しづらい場面がありました。仕組みとしては柔軟である一方、その柔軟さが一貫性の欠如につながる可能性をはらんでいたと言えます。

2026wave1では、予約方法を構成可能な設定として定義し、それを前提に予約プロセスを進められるようになります。これにより、組織として「どの予約方法を標準とするのか」を明確にしたうえで運用できるようになり、予約操作の迷いが減ります。結果として、リソース予約がより予測可能なものになり、後続の計画調整や実績管理との整合性も取りやすくなります。この機能は派手なUI変更ではありませんが、日々の運用の質を底上げする実務的な改善だと言えるでしょう。

一方で、留意点もあります。予約方法を標準化するということは、一定の運用ルールを組織として決める必要があるということでもあります。すべてのプロジェクトに同じ予約方法が適しているとは限らないため、どのケースでどの方法を使うのかを整理しないまま導入すると、逆に現場の柔軟性を損なう可能性もあります。この機能は予約判断を自動化するものではなく、判断の前提を揃えるための仕組みです。プロジェクトの特性やリソース管理の成熟度に応じて設定を見直しながら使うことで、初めて一貫性と効率の両立が実現できるはずです。

ProjectOperationsの予約(bookings)において、現実のプロジェクト遂行に近い形で「まとめて動く単位」を扱えるようにする機能です。ここでいうpoolは互換性のある予約可能リソースのグループで、必要に応じてその中から1名または複数名を選んで予約できる概念です。一方crewは固定のメンバー構成(人や機器を含む)を前提として、必ず一緒にスケジュールされるべきリソースのセットです。個人単位の予約だけでは表現しづらかった“チームで動く”“枠で押さえる”という実務を、標準の予約プロセスに取り込むことが狙いです。

この機能が効いてくるのは、複数人・複数職種が同じ期間にまとまって必要になる作業や、日をまたいで同じ体制を維持したい作業です。たとえば現場立ち上げで、リードとサブメンバー、必要な機器を含めた固定チームを数日連続で確保したい場合、個別に予約していくと「一人だけ確保できたが別の人が取れない」「機器が別枠で衝突する」といった競合が起きやすく、調整コストが増えます。crewとしてまとめて予約できれば、必要なリソースをタスク期間全体で確保しやすくなり、スケジュール競合を未然に防ぎやすくなります。逆にpoolは、同等スキルのリソースが複数いて“誰でもいいが人数は必要”というケースで強く、特定個人の確定を後回しにしつつ、必要なキャパシティを先に押さえる運用に向きます。結果として、アイドル時間を抑えながら計画精度を上げ、複雑で多分野なプロジェクトでも人員配置をスケールさせやすくなります。

2025wave2までの前提では、予約は基本的に個人(単体リソース)を中心に組み立てる運用になりやすく、チーム単位の計画は「複数人をそれぞれ予約して結果としてチームになる」形でしか表現できませんでした。そのため、予約作業は手動の調整が増えやすく、同じ期間に必要なメンバーを揃えるために何度も試行錯誤する場面が発生しがちでした。特に複数日にわたる作業や、固定チームで動く前提の案件では、個別予約の積み上げがそのままスケジュール競合や抜け漏れの温床になりやすかったと言えます。

2026wave1では、機能コントロールで有効化することで、poolとcrewを作成・管理し、それらにリソースを追加・管理し、スケジュールボード上でpoolとcrewを検索・表示し、poolとcrewとして予約を作成・管理できるようになります。これにより、交換可能なリソースグループを“pool”として、固定チームを“crew”として、予約の単位そのものを実務に合わせて選べるようになります。個別最適の寄せ集めではなく、最初から「現実の動き方」に近い形で予約を設計できる点が、この機能の価値です。

一方で留意点もあります。poolとcrewを導入すると予約の表現力は上がりますが、その分、組織として「poolを使うべき要件」「crewを使うべき要件」を定義しておかないと、現場ごとに使い方がばらつき、かえって混乱を生む可能性があります。また、crewは固定セットで動く前提なので、メンバー入れ替えが多い組織では維持管理のコストが出ますし、poolは互換性が前提なので、スキル・ロール・稼働条件の揃え方が曖昧だと“誰でもいいはずが誰でもよくない”状態になり、後工程で調整が増えるリスクがあります。予約を強化する機能である以上、データ整備(リソース属性)と運用設計(どの単位で押さえるか、いつ確定するか)をセットで整えることで、初めてスケジュール競合の低減と計画精度向上という効果が安定して出るはずです。

この機能が効いてくるのは、計画と実行の間にズレが生じやすい現実的なプロジェクト運営の場面です。たとえば、予約時点では想定していた期間や稼働率が、実際の進行に合わせて変わっていくことは珍しくありません。部分的にキャンセルされた予約、別プロジェクトへの一時UGBIAN入、想定外の延長などが積み重なると、予約情報と実態の乖離が増えていきます。Perform bulk reconciliation of bookings from UIを使えば、こうした不整合を一覧で把握し、まとめて調整することで、計画データを現実に近づけやすくなります。結果として、リソース状況の見通しが改善され、次の判断に使えるデータの鮮度が保たれます。

2025wave2までのProjectOperationsでは、予約と実態のズレを認識する手段はあっても、修正は基本的に個別対応が中心でした。どの予約が過剰なのか、どこが未消化なのかを見つけること自体は可能でも、それを一括で是正する仕組みはなく、担当者の手作業に依存する場面が多く残っていました。そのため、調整が後回しになったり、「いずれ直そう」と思ったまま放置されたりすることで、計画データの信頼性が徐々に下がっていくケースも少なくありませんでした。

2026wave1では、この前提が変わり、UI上から複数の予約をまとめて確認・調整できるようになります。個別の修正を積み上げるのではなく、一定のまとまりとして予約と実態の差分を捉え、一括で整合させることで、調整作業の効率が大きく向上します。これは単なる作業時間の短縮にとどまらず、「ズレを前提に、定期的に整える」という運用を現実的なものにします。結果として、リソース計画を“一度作って終わり”ではなく、“更新され続ける前提の管理情報”として扱いやすくなります。

一方で、留意点もあります。一括で調整できるようになるということは、修正の影響範囲も広がるということです。どのタイミングで誰が一括調整を行うのか、どこまでを許容範囲のズレとし、どこからを修正対象とするのかといった運用ルールを決めておかないと、逆に調整が頻発し、計画が安定しなくなる可能性もあります。この機能は、ズレをゼロにするためのものではなく、ズレを把握し、管理可能な状態に戻すための道具です。定期的なレビューや責任分界と組み合わせることで、初めてリソース計画と実行の関係を健全に保つ力を発揮すると言えるでしょう。

この機能が活きるのは、リソースの掛け持ちや将来アサインが多い環境です。たとえば、あるコンサルタントが今月はAプロジェクト、来月からはBプロジェクトに部分アサインされ、その合間に別案件の短期対応が入る、といったケースでは、現在と将来の負荷をまとめて把握するのが難しくなりがちでした。タイムラインビューを使えば、現在進行中のアサインと今後予定されているアサインを同じ時間軸上で確認できるため、「いつ余力が生まれるのか」「どの時点で負荷が重なりそうか」といった判断がしやすくなります。これはリソースマネージャーだけでなく、チームメンバー自身が自分の予定を把握するうえでも有効です。

2025wave2までのProjectOperationsでも、リソースの割り当てや予約状況を確認する手段は用意されていましたが、視点はプロジェクト中心になりやすく、個人単位での時系列的な把握には工夫が必要でした。現在のアサインと将来の計画を結び付けて見るには、複数のビューや外部レポートを使うケースもあり、「分かる人には分かるが、直感的ではない」状態が残っていました。そのため、負荷の偏りや将来の過密状態に気付くのが遅れることもありました。

2026wave1では、チームメンバー単位で、現在および今後のスタッフィング状況をタイムライン形式で可視化できるようになります。これにより、アサインの連続性や重なりを時間軸で自然に捉えられるようになり、調整や事前の相談がしやすくなります。個別の予約や割り当て情報を細かく確認しなくても、全体の流れとして稼働状況を把握できる点は、日常的なリソース管理の負担を確実に下げてくれるはずです。計画と実態を“点”ではなく“線”で見るための改善だと言えます。

一方で、留意点もあります。タイムラインビューの価値は、元となる予約やアサイン情報が正確に更新されていることが前提になります。実態とズレたままの予約が放置されていると、見た目は分かりやすくても判断を誤る原因になります。また、誰がこのビューを主に使うのか、本人向けなのか、マネージャー向けなのかによって、求められる粒度や更新頻度も変わります。この機能は稼働状況を自動で最適化するものではなく、状況を共有し、調整のきっかけを作るための可視化手段です。定期的な見直しやコミュニケーションと組み合わせることで、初めてリソース管理の質を一段引き上げる役割を果たすと言えるでしょう。

この機能が特に効果を発揮するのは、タスク単位で作業が細かく分かれているプロジェクトや、複数プロジェクトを並行して進めるチームです。たとえば、タスク一覧やプロジェクト詳細を確認しながら作業している最中に、「この作業分の時間を入れておこう」と思った場合、従来は時間入力画面へ移動し、対象プロジェクトやタスクを選び直す必要がありました。プロジェクトやタスクの画面から直接タイムエントリを開始できれば、対象を選び直す手間や入力ミスを減らし、作業の流れを止めずに実績登録を行えます。結果として、入力漏れやまとめ入力に頼る運用を減らしやすくなります。

2025wave2までのProjectOperationsでは、時間入力の機能自体は成熟していましたが、起点はあくまで「時間を入力する」という行為そのものでした。作業の文脈と時間入力が分離しているため、入力のタイミングが後回しになりやすく、結果として週末や月末にまとめて入力する、といった運用が残りがちでした。その場合、タスクとの対応関係が曖昧になったり、実績の精度が下がったりするリスクもありました。時間入力が“別作業”として扱われていた点が、実務上の課題だったと言えます。

2026wave1では、プロジェクトビューやタスクビューから直接タイムエントリの作成を開始できるようになり、時間入力が作業の延長として扱いやすくなります。作業内容を確認している画面からそのまま実績登録につながることで、「覚えているうちに入力する」「区切りのよいタイミングで入力する」といった行動を取りやすくなります。これは単なる操作性の改善ではなく、実績データの鮮度と正確性を底上げする効果が期待できる変更です。チームメンバーの入力体験を改善することで、結果的にプロジェクト管理や請求、収益管理の基礎データの質も向上します。

一方で、留意点もあります。入力がしやすくなる分、どのタスクにどの時間を紐づけるのかという判断を、チームメンバーに委ねる割合が増えます。そのため、タスク設計が粗いままだと、入力は楽になってもデータの粒度が揃わない可能性があります。また、作業途中でこまめに入力できるようになることで、組織として期待する入力タイミングや締めのルールを再整理する必要が出てくるかもしれません。この機能は時間管理を自動化するものではなく、入力行動を業務フローに近づけるための仕組みです。タスク設計や運用ルールと組み合わせることで、初めて実績管理全体の質を引き上げる効果を発揮すると言えるでしょう。

この機能が特に役立つのは、会議が多く、細切れの作業時間の中で業務を進めているチームメンバーです。たとえば、一日の中で複数の内部会議や顧客ミーティングが入り、その合間にプロジェクト作業を行っている場合、「どこからどこまでが作業時間だったか」を正確に思い出すのは簡単ではありません。タイムエントリカレンダー上にOutlook会議が表示されていれば、「この会議の前後でこのタスクをやっていた」「この時間帯は会議で埋まっていた」といった判断がしやすくなり、実績入力の精度が上がります。結果として、入力漏れや過剰入力を防ぎやすくなります。

2025wave2までのProjectOperationsでは、時間入力とOutlookの予定は完全に別物として扱われていました。チームメンバーはOutlookを見て一日の予定を確認し、その記憶を頼りにProjectOperationsで時間を入力する、という流れが一般的でした。このため、会議が多い日ほど入力の手間や心理的な負担が増え、まとめ入力や後回し入力につながりやすい傾向がありました。時間入力の仕組み自体は整っていても、日常の働き方との接続が弱かった点が課題だったと言えます。

2026wave1では、タイムエントリカレンダーにOutlook会議が表示されることで、時間入力の体験が大きく変わります。会議予定を時間軸の一部として確認しながら、その前後に作業時間を割り当てることができるため、実際の一日の流れに即した形で実績を入力できます。これは入力を楽にするだけでなく、「会議にどれだけ時間を使っているか」「実作業に使える時間がどこにあるか」を本人が意識しやすくなる点でも意味があります。結果として、時間データの信頼性が上がり、プロジェクト管理や請求、収益管理の基礎情報としての価値も高まります。

一方で、留意点もあります。Outlook会議が見えるようになることで、時間入力がしやすくなる反面、「会議時間をそのまま作業時間に含めるのか」「会議は非稼働として扱うのか」といったルールが曖昧だと、入力内容にばらつきが出る可能性があります。また、すべての会議がプロジェクトに紐づくとは限らないため、どの会議をどう扱うかについて、組織としての考え方を揃えておくことも重要です。この機能はOutlookとProjectOperationsを自動的に整合させるものではなく、時間入力時の判断材料を増やすための可視化です。時間入力のルールや期待値と組み合わせることで、初めて実務にフィットした使い方ができるようになるでしょう。

この機能が活きるのは、コストを即時に費用化せず、一旦資産として計上したうえで、条件が整った段階でプロジェクト原価へ振り替えたいケースです。たとえば、外注費や一部の間接費を一時的に前払費用や仮勘定としてバランスシートに計上し、検収や進捗確認が完了した後にプロジェクトへ配賦したい場合、従来はプロジェクト管理と会計処理の間にギャップが生じやすく、調整が属人的になりがちでした。本機能により、バランスシートからプロジェクト原価への手動振替を前提とした運用が可能になり、会計上の整理とプロジェクト実態の反映を両立しやすくなります。

2025wave2までのProjectOperationsでは、統合プロジェクトにおけるコスト処理は、自動連携を軸とした設計が中心でした。そのため、原価をいつ・どのタイミングでプロジェクトに載せるかを細かく制御したい場合、標準機能だけでは対応が難しく、追加の仕訳や個別対応に頼る場面もありました。結果として、Finance側での調整とProjectOperations側の実績管理が乖離しやすく、説明や突合に手間がかかることがありました。

2026wave1では、バランスシート勘定に計上されたコストを、手動でプロジェクト原価として転記できるようになることで、この制約が緩和されます。自動連携を前提としつつも、「あえて後から載せる」という選択肢が標準で用意されることで、会計的な判断や内部統制の要件を満たしながら、プロジェクト原価を適切なタイミングで反映できるようになります。これは、Finance主導のコントロールとProjectOperationsの実績管理を、より現実的な形で接続する改善だと言えるでしょう。

一方で、留意点も明確です。この機能は原価転記を自動化するものではなく、あくまで手動での振替を可能にする仕組みです。そのため、どのコストを対象にするのか、いつ振り替えるのか、誰が判断するのかといった運用ルールを定めておかないと、原価計上のタイミングがばらつき、プロジェクト損益の見え方が不安定になる可能性があります。また、手動操作が増える分、内部統制や証跡管理の観点も重要になります。この機能は柔軟性を高めるためのものですが、自由度が上がるからこそ、Financeとプロジェクト側の役割分担と判断基準を明確にしたうえで使うことで、初めて安定した原価管理につながると言えるでしょう。

この機能が特に有効なのは、計画段階で複数の選択肢を比較検討したい場面です。たとえば、リソースを追加投入した場合と現行体制を維持した場合で完了時期がどう変わるのか、特定タスクの順序を入れ替えた場合に全体スケジュールへどのような影響が出るのか、といった検討はプロジェクトマネージャーにとって日常的な課題です。従来は、こうした検討を行うために計画を複製したり、Excelなどの外部ツールでシミュレーションしたりする必要があり、最新状態との乖離や管理の手間が問題になりがちでした。what-ifシナリオを使えば、同じプロジェクト計画をベースに複数の案を並べて検討できるため、比較がしやすくなります。

2025wave2までのProjectOperationsでは、プロジェクト計画の編集や調整は可能でしたが、「検討用の案」と「確定した計画」を明確に分けて扱う仕組みは限定的でした。そのため、シナリオ検討を行う際は、計画を一時的に書き換えるか、別管理にする必要があり、どれが正式な計画なのか分かりにくくなるリスクもありました。結果として、計画変更に慎重になりすぎたり、逆に勢いで変更して後戻りが発生したりといった運用上の課題が残っていました。

2026wave1では、複数のwhat-ifシナリオを用いてプロジェクト計画を分析できるようになり、現行計画を維持したまま、代替案を安全に検討できるようになります。これにより、「検討」と「確定」を切り分けた計画運用がしやすくなり、関係者との合意形成や説明も行いやすくなります。最終的にどのシナリオを採用するかを判断する際にも、感覚や経験だけでなく、具体的な比較結果をもとに話を進められる点が、この機能の大きな価値です。

一方で、留意点もあります。what-ifシナリオはあくまで仮説であり、入力される前提条件やデータの精度に大きく左右されます。リソースの稼働率やタスク依存関係が現実と乖離していれば、シナリオ結果も当然ながら参考値に留まります。また、シナリオを作りすぎると、どれを基準に判断するのかが曖昧になり、意思決定が遅れる可能性もあります。この機能は「答えを出す」ためのものではなく、「考える材料を増やす」ためのものです。どのタイミングで、どの観点のシナリオを作るのかを整理したうえで使うことで、計画検討の質を一段引き上げるツールとして活きてくるでしょう。

この機能が特に有効なのは、プロジェクトの途中で前提条件が変わりやすい環境です。たとえば、スコープ変更やリソース制約、顧客都合によるスケジュール調整などにより、当初計画から修正計画へ移行する場面では、「どこが、なぜ変わったのか」を説明できることが重要になります。複数のベースラインを持てば、初期計画、修正後計画、再調整後計画といった形で履歴を残せるため、単なる最新状態だけでなく、計画変更の流れそのものを確認できます。これはプロジェクトマネージャーだけでなく、ステークホルダーとの合意形成や振り返りの場面でも役立ちます。

2025wave2までのProjectOperationsでは、ベースラインは基本的に単一で、計画変更を行うと過去の基準点は上書きされる形になりがちでした。そのため、計画を更新するたびに「以前の前提とどう違うのか」を別資料で管理したり、記憶に頼った説明が必要になることもありました。結果として、計画変更に慎重になりすぎたり、逆に変更理由が曖昧なまま進んでしまったりと、運用上の難しさが残っていました。

2026wave1では、プロジェクトに対して複数のベースラインを設定・保持できるようになり、この制約が緩和されます。これにより、計画変更のたびに新しいベースラインを作成し、どの時点の計画を基準にしているのかを明確にできます。現在の実績がどのベースラインに対してどの程度ズレているのかを把握しやすくなり、進捗管理や説明の精度も向上します。ベースラインが「一度決めた過去の記録」ではなく、「判断の節目ごとの基準」として使えるようになる点が、この機能の大きな価値です。

一方で、留意点もあります。複数のベースラインを持てるようになると、どのベースラインを公式な基準とするのかを明確にしないと、かえって混乱を招く可能性があります。また、ベースラインを頻繁に作りすぎると、比較や説明の軸がぼやける恐れもあります。この機能は計画変更を正当化するためのものではなく、変更を記録し、理解しやすくするためのものです。どのタイミングでベースラインを切るのか、誰が判断するのかといった運用ルールを定めたうえで使うことで、プロジェクト管理の透明性と説明力を一段引き上げることができるでしょう。

この機能が特に意味を持つのは、初期導入プロジェクトの後に、月額・年額でのサポートやアドバイザリー契約が続くようなケースです。従来は、初期プロジェクトはProjectOperationsで管理し、その後の定額サービスは別システムやFinance側の契約管理で処理するといった分断が起きがちでした。その結果、プロジェクト実績と継続収益の関係が見えにくくなり、顧客単位・契約単位での収益性を一貫して把握するのが難しくなることもありました。サブスクリプション請求をProjectOperationsの枠内で扱えるようになることで、プロジェクトと継続サービスを一続きの顧客関係として管理しやすくなります。

2025wave2までのProjectOperationsでは、請求の中心はプロジェクトの進捗や実績に基づくもので、期間ベースで自動的に繰り返される請求モデルは標準的な想定ではありませんでした。そのため、定額サービスを提供している場合でも、実態としてはプロジェクトを擬似的に使ったり、Finance側で別管理したりといった工夫が必要でした。このような運用では、請求処理は回せても、プロジェクト管理やリソース実績との結び付きが弱くなりやすいという課題が残っていました。

2026wave1では、プロフェッショナルサービス向けにサブスクリプション請求をサポートすることで、この分断が緩和されます。一定期間ごとに発生する請求を前提とした契約形態を、ProjectOperationsの中で自然に扱えるようになり、プロジェクト型の作業と定額サービスを同じ顧客・同じ契約文脈で管理できます。これにより、請求の仕組みだけでなく、リソースの稼働状況や提供価値と収益を結び付けて捉えやすくなり、サービスビジネスとしての全体像が見えやすくなります。

一方で、留意点もあります。サブスクリプション請求を導入すると、「どこまでが定額で、どこからが追加作業なのか」という線引きがこれまで以上に重要になります。プロジェクト的な作業が増えすぎると、定額収益の中で原価が膨らみ、収益性が見えにくくなるリスクもあります。また、サブスクリプションは期間をまたいで継続するため、契約更新や条件変更の管理も前提になります。この機能は単に請求方法を増やすものではなく、プロフェッショナルサービスを「単発案件」から「継続的な価値提供モデル」へ広げるための土台です。プロジェクト管理、リソース管理、収益管理をどう結び付けるかという視点で使うことで、初めて本来の価値が見えてくるでしょう。

この改善が特に効果を発揮するのは、外注や協力会社を含むプロジェクトや、固定上限付きの契約が多いケースです。たとえば、外注先に対して「この金額を超えない」という前提で業務を委託している場合、実績入力や請求処理のどこかでチェックが抜けると、後から超過が発覚し、調整や交渉が必要になります。NTEの検証範囲が広がり、信頼性が高まることで、実績登録や請求の段階で超過リスクを早期に把握でき、問題が大きくなる前に対処しやすくなります。結果として、契約条件に基づいたコストコントロールが現実的になります。

2025wave2までのProjectOperationsでも、NTEの概念自体は存在していましたが、検証のタイミングや対象は限定的でした。特定の入力経路や処理ではNTEが考慮される一方、別の経路では十分に検証されない、といったケースが残っており、「設定しているはずなのに完全には守られていない」という不安が生じやすい状態でした。そのため、最終的には人のチェックや後工程での調整に頼る運用が必要になることもあり、NTEが持つ本来の統制力を十分に活かしきれていなかったと言えます。

2026wave1では、NTEに対する検証の信頼性とカバレッジが改善され、より多くの処理やシナリオでNTEが一貫して適用されるようになります。これにより、「どの画面・どの操作で入力してもNTEは守られる」という前提に近づき、上限管理をシステムに任せやすくなります。NTE超過を後から検知するのではなく、入力や処理の段階で抑止できるようになる点が、この改善の本質です。コスト管理をルールベースで安定させるための土台が強化されたと言えるでしょう。

一方で、留意点もあります。NTEの信頼性が高まるほど、設定そのものの正確さが重要になります。NTE金額の設定ミスや、どの範囲に適用するのかという定義が曖昧なままだと、システムが正しく動いても実務では混乱が生じます。また、NTEを厳格に適用することで、例外対応が必要なケースでは手続きが増える可能性もあります。この機能はコスト管理を自動化するものではなく、ルールを確実に守るための仕組みです。契約条件や例外対応の整理と合わせて使うことで、NTEを実効性のある統制手段として活かせるようになるでしょう。

この改善が効いてくるのは、請求タイミングがプロジェクトの進捗や実績入力から少し遅れる、あるいは契約条件に基づいて特定の日付で請求が行われるケースです。たとえば、月末締め翌月請求や、マイルストーン到達後にまとめて請求する契約では、実績は先に積み上がっているのに、請求日は後になることがあります。この場合、財務上の数値と顧客向けの請求情報を並べて見ると、期間ごとの数字にズレが生じ、「なぜこの月は売上がこう見えるのか」という説明が必要になります。請求日と財務認識の関係が整理されることで、こうした説明コストを下げ、数字を直感的に理解しやすくなります。

2025wave2までのProjectOperationsでは、実績や収益認識はプロジェクト進捗や会計ルールを中心に処理され、顧客請求日との関係は必ずしも強く意識されていませんでした。そのため、Finance側で見る数値と、請求管理や顧客とのやり取りで使う情報との間に時間差が生まれやすく、月次や四半期の締めの場面で突合作業が必要になることもありました。仕組みとしては正しくても、「見え方」が揃っていないことで、現場や経営層にとって分かりづらい状態が残っていたと言えます。

2026wave1では、顧客請求日を意識した形で財務的な正確性を整えることで、このギャップが緩和されます。請求日と連動した形で数値を捉えられるようになることで、プロジェクト管理、請求管理、財務管理の間で同じ時間軸を共有しやすくなります。これは単に計算ロジックを変えるというより、「どの日付を基準に数字を見るのか」という視点を揃える改善であり、月次・四半期のレビューや顧客説明の場面で効果を発揮します。数字の正しさだけでなく、数字の納得感を高めるための変更だと言えるでしょう。

一方で、留意点もあります。顧客請求日を軸に財務を整合させる場合、すべてのプロジェクトや契約に同じ考え方が適用できるとは限りません。進行基準や内部管理目的では、請求日とは異なるタイミングで実態を把握したいケースもあります。また、請求日が遅れること自体がビジネス上のリスクになる場合もあり、数字が「見えにくくならない」ことと「実態を正しく管理する」ことのバランスが重要です。この機能は財務管理を単純化するためのものではなく、請求と財務をより自然につなぐための選択肢です。どの指標を重視するのかを整理したうえで使うことで、ProjectOperationsとFinanceの関係をより分かりやすく保つ助けになるでしょう。

この機能が活きるのは、顧客からの前受金や仮受金をプロジェクトに関連付けて扱うケースです。たとえば、プロジェクト開始前に一部金額を受領し、後続の作業実績や請求に応じて相殺していくような契約では、「これは売上なのか」「まだ原価や収益として認識すべきではないのか」という判断が常に伴います。on-accountカテゴリをDataverseで明確に扱えるようになることで、プロジェクト実績や請求データを見た際に、その金額が本来どの性質のものなのかを誤解しにくくなり、Finance側との突合や説明もスムーズになります。

2025wave2までのProjectOperationsでは、on-accountに相当する取引は存在していても、それがDataverse上で明確なカテゴリとして区別されているとは言いづらい状態でした。そのため、プロジェクト管理の画面だけを見ると、前受金なのか、実際の売上や原価なのかが分かりにくく、最終的にはFinance側の仕訳や帳簿を見て判断する必要がありました。結果として、プロジェクト管理と会計管理の間に「分かっている人だけが理解できる」暗黙の前提が生まれやすくなっていました。

2026wave1では、on-accountカテゴリがDataverseでサポートされることで、この前提が整理されます。前受金や一時的な金額を、実績や請求とは異なる性質のものとして明確に区別できるようになり、プロジェクト管理のデータを見ただけでも、その金額がどのフェーズ・どの性質の取引なのかを把握しやすくなります。これは数値の計算ロジックを変えるというより、データの意味付けを正しく揃える改善であり、ProjectOperationsとFinanceの間で共通言語を持ちやすくする効果があります。

一方で、留意点もあります。on-accountを明示的に扱えるようになることで、「どの取引をon-accountとして扱うのか」「いつ通常の請求や売上に振り替えるのか」といった運用ルールを、これまで以上に明確にする必要があります。カテゴリが増えることで、入力や判断が複雑になる可能性もあるため、現場にとって分かりやすいルール設計が欠かせません。この機能はon-accountを自動的に整理してくれるものではなく、正しく区別するための土台を提供するものです。Financeとプロジェクト側での役割分担や判断基準を揃えたうえで使うことで、前受金を含むプロジェクト管理をより健全で説明しやすいものにしてくれるでしょう。

この機能が特に効果を発揮するのは、契約変更が頻発するプロジェクトや、顧客との合意内容を明確に残す必要がある案件です。たとえば、当初スコープに含まれていなかった追加作業を顧客から依頼された場合、従来はプロジェクト計画や実績に直接反映してしまい、後から「これは追加分だったのか」「請求対象だったのか」を整理する必要がありました。Change Orderとして変更を管理できれば、元の契約との差分を明確にし、その変更がスケジュール、コスト、請求にどう影響するのかを可視化したうえで進められます。結果として、現場判断に頼らない、説明可能なプロジェクト運営がしやすくなります。

2025wave2までのProjectOperationsでは、変更管理の考え方自体は存在していても、プロジェクト計画や財務・請求プロセスと強く結び付いた標準的なChange Order管理は限定的でした。そのため、変更内容を別資料や外部ドキュメントで管理したり、プロジェクトを擬似的に分割して対応したりといった運用が必要になるケースもありました。これらの方法は回避策としては機能しますが、プロジェクト全体の見通しや収益性を把握しづらくなるという課題が残っていました。

2026wave1では、Change Orderをプロジェクトの正式な構成要素として扱えるようになり、計画・実績・請求の流れの中に自然に組み込めるようになります。変更が発生した場合に、新たなChange Orderとして切り出し、その影響をプロジェクト全体の中で管理できるため、元の契約と追加・変更分を分けて把握することが可能になります。これにより、「当初計画はどうだったのか」「どこからが変更分なのか」を明確にしたままプロジェクトを進められ、財務的な影響や顧客への説明も行いやすくなります。プロジェクト管理と契約管理の間を埋める、重要な一歩だと言えるでしょう。

一方で、留意点もあります。Change Orderを正式に管理できるようになるということは、変更を記録し、承認し、反映するプロセスを組織として定義する必要があるということでもあります。すべての小さな変更をChange Orderにするのか、一定以上の影響があるものだけを対象にするのかといった判断基準を決めておかないと、運用が煩雑になりかねません。また、Change Orderを作らずに進めてしまう運用が残っていると、せっかくの仕組みが形骸化するリスクもあります。この機能は変更を自動的に管理してくれるものではなく、「変更を正しく扱うための器」を提供するものです。現場の判断とガバナンスをどう組み合わせるかを整理したうえで使うことで、プロジェクトの透明性と収益管理の精度を大きく高めることができるでしょう。

この改善が特に効いてくるのは、複数の国や地域にまたがるチームでプロジェクトを進めているケースです。たとえば、日本のプロジェクトマネージャーが設定した開始日や期限が、海外拠点のメンバーの画面では前日や翌日に見えてしまい、「まだ始まっていないはず」「もう期限を過ぎているのでは」といった認識のズレが生じることがあります。タイムゾーンに依存しない日付として扱えるようになれば、「このタスクは◯月◯日開始」という計画上の事実が、誰の画面でも同じ意味として表示され、計画の読み違いを防ぎやすくなります。

2025wave2までのProjectOperationsでは、日付フィールドはユーザーや環境のタイムゾーンの影響を受ける形で扱われることが多く、グローバルプロジェクトでは注意深い運用が必要でした。プロジェクト計画そのものは正しくても、表示の差異によって「なぜこの日付になっているのか」を説明する必要が生じたり、レポートやエクスポート後に日付を補正したりする場面もありました。日付が“時刻を含んだデータ”として扱われていることが、実務上の分かりにくさにつながっていたと言えます。

2026wave1では、プロジェクトおよびプロジェクトタスクに、タイムゾーンに依存しない日付フィールドが追加されることで、この前提が整理されます。計画上の開始日・終了日・期限といった情報を、「世界共通のカレンダー上の日付」として扱えるようになり、ユーザーの所在地や表示環境によって意味が変わることがなくなります。これは派手な機能追加ではありませんが、グローバル環境での計画共有やレビュー、合意形成を静かに支える、基盤的な改善だと言えるでしょう。

一方で、留意点もあります。タイムゾーンに依存しない日付と、実際の作業開始時刻や締切時刻が重要なケースは、必ずしも同じではありません。たとえば「◯月◯日中に完了」という表現と、「◯月◯日の◯時までに完了」という表現は、意味合いが異なります。この機能は、計画レベルの日付を安定させるものであり、時刻レベルの管理を不要にするものではありません。どの情報を日付ベースで管理し、どの情報を時刻やタイムゾーン込みで管理するのかを整理したうえで使うことで、初めて効果が最大化されます。

この改善は、グローバルプロジェクトでよく起きる“地味だが厄介なズレ”を解消するためのものです。数値やロジックを変えるのではなく、「計画をどう解釈するか」という前提を揃えることで、ProjectOperationsを国境を越えて使いやすいものに近づける一歩だと言えるでしょう。

この機能が特に効果を発揮するのは、プロジェクトの中で明確な物品調達が発生するケースです。たとえば、システム導入や設備構築のプロジェクトにおいて、特定の機器やライセンス、部材を所定のタイミングで調達する必要がある場合、従来はプロジェクト計画と購買発注が別々に管理されがちでした。Enable purchase orders with item requirementsを利用することで、プロジェクト側で定義した品目要件を起点に購買発注を行えるようになり、「どのプロジェクトの、どの要件のための調達なのか」を明確にしたまま進められます。結果として、調達漏れや過剰調達を防ぎやすくなり、プロジェクト進行と購買の足並みを揃えやすくなります。

2025wave2までのProjectOperationsでは、購買発注は可能であっても、プロジェクトの品目要件と直接結び付けて扱うシナリオは限定的でした。そのため、プロジェクト計画上では必要とされている品目が、購買側では別の文脈で処理され、後から「これはどのプロジェクト向けだったのか」を確認する必要が生じることもありました。プロジェクト管理と購買管理が機能的に分断されているわけではないものの、実務上は人の理解や運用で補っている部分が残っていたと言えます。

2026wave1では、プロジェクトの品目要件を前提に購買発注を扱えるようになることで、この分断が緩和されます。プロジェクト計画の中で定義されたitem requirementsが、購買プロセスの出発点として機能し、調達の進捗や状況をプロジェクト文脈で把握しやすくなります。これにより、「計画はあるが調達が進んでいない」「調達は済んでいるがプロジェクト側で認識されていない」といったズレを減らし、プロジェクトと購買を同じ時間軸・同じ前提で管理できるようになります。プロジェクト型業務における物品調達を、例外ではなく標準プロセスとして扱える点が、この機能の価値です。

一方で、留意点もあります。品目要件を起点とした購買が可能になることで、プロジェクト側での要件定義の精度がこれまで以上に重要になります。数量や仕様、必要時期が曖昧なままだと、購買プロセスにそのまま影響し、調達トラブルにつながる可能性があります。また、すべての調達が品目要件に基づくとは限らず、突発的な購買や例外対応が必要なケースもあります。この機能は購買を自動化するものではなく、プロジェクト計画と調達を結び付けるための基盤です。プロジェクト側と購買側の役割分担や要件定義のルールを整理したうえで使うことで、初めて調達を含めたプロジェクト管理全体の一貫性が高まるでしょう。

この機能が特に意味を持つのは、社内システム刷新、製品開発基盤の構築、長期的な研究開発、設備投資に近いITプロジェクトなどをProjectOperationsで管理したいケースです。これらのプロジェクトでは、日々の作業実績やコストは発生するものの、それをすぐに売上や顧客請求と結び付けることはありません。従来のプロジェクト管理モデルでは、こうした投資型プロジェクトをサービス案件と同じ前提で扱うことで、「請求しないプロジェクト」「収益が出ないプロジェクト」として見え方が歪んでしまうことがありました。Investment projectとして扱えるようになることで、目的や性質に合った見方でプロジェクトを管理しやすくなります。

2025wave2までのProjectOperationsでは、投資プロジェクトと業務プロジェクトを明確に区別する標準的な仕組みは限定的でした。そのため、投資目的の活動であっても、通常のプロジェクトとして登録し、請求や収益認識を行わない、あるいは例外的な設定で対応するといった運用が必要になることがありました。このような扱いでは、プロジェクト一覧やレポート上で、投資活動と顧客向けプロジェクトが混在し、経営層や管理部門にとって分かりにくい状態が生まれやすかったと言えます。

2026wave1では、Investment projectという位置づけが明確にサポートされることで、プロジェクトの目的に応じた管理が可能になります。投資型プロジェクトとして設定することで、請求や収益認識を前提としない管理が自然になり、発生したコストを将来価値への投資として捉えやすくなります。これにより、サービス提供型プロジェクトと投資プロジェクトを同じツール上で管理しつつも、評価軸や見え方を切り分けることができます。ProjectOperationsを「顧客向け案件管理ツール」に留めず、企業活動全体のプロジェクト管理基盤として使うための重要な拡張だと言えるでしょう。

一方で、留意点もあります。Investment projectとして扱えるようになることで、「どこまでを投資とみなすのか」という判断基準を組織として定める必要が出てきます。すべてを投資プロジェクトにしてしまうと、コスト管理や優先順位付けが曖昧になる可能性がありますし、逆に厳しすぎる基準を設けると実態に合わなくなることもあります。また、投資プロジェクトであっても、進捗管理や実績把握が不要になるわけではありません。この機能は投資判断を自動化するものではなく、プロジェクトの性質を正しく表現するための枠組みです。Finance側の会計方針や経営管理の考え方と整合させたうえで使うことで、投資活動を含めたプロジェクト管理の透明性と説明力を高めることができるでしょう。

この機能が特に効いてくるのは、プロジェクト、リソース、顧客、品目など、複数の軸でディメンションを管理している組織です。たとえば、あるプロジェクトではプロジェクト自体のディメンションを優先したいが、別のケースではリソースや購買側のディメンションを基準にしたい、といった要件は珍しくありません。従来は、どこか一つの基準に寄せるか、入力後に手修正することで対応していましたが、柔軟性が高い分、運用が属人化しやすい側面もありました。ディメンションの初期値決定を柔軟にできることで、入力時点で意図した構造に近いデータを作りやすくなります。

2025wave2までのProjectOperationsでは、財務ディメンションの初期値はあらかじめ定められたロジックに基づいて設定されることが多く、実務上は「このケースでは合っているが、別のケースでは微妙に合わない」という状況が発生しがちでした。その結果、入力後に修正仕訳や調整が必要になったり、レポート作成時に補正を行ったりといった対応が必要になることもありました。仕組みとしては一貫性があるものの、現場の多様な運用を完全には吸収しきれていなかったと言えます。

2026wave1では、財務ディメンションの初期値を決定する際の柔軟性が高まり、どの情報を優先するのかを運用に合わせて調整できるようになります。これにより、プロジェクト起点、リソース起点、購買起点など、業務シナリオに応じたディメンション設定がしやすくなり、後からの修正や例外処理を減らせます。ディメンションを「後で整えるもの」ではなく、「最初から整った状態で持たせるもの」として扱いやすくなる点が、この機能の実務的な価値です。

一方で、留意点もあります。ディメンションの初期値決定を柔軟にできるということは、裏を返せば、どの基準を優先するのかを明確に決める必要があるということです。ルールが曖昧なまま設定を広げると、プロジェクトごとに異なるディメンション構造が生まれ、集計や分析が難しくなる可能性があります。また、Finance側の会計ポリシーやレポート設計との整合も欠かせません。この機能はディメンション管理を自由にするものではなく、実務に合った形で“正しく揃える”ための選択肢を増やすものです。会計方針と業務運用をすり合わせたうえで活用することで、入力効率と分析精度の両立が実現できるでしょう。

この改善が特に効いてくるのは、複数の国や地域にまたがるチームでリソースを共有しているケースです。たとえば、日本のリソースマネージャーが「4月1日から参画」と計画した内容が、海外拠点の画面では3月31日や4月2日に見えてしまうと、「本当にこの日からなのか」という確認や調整が必要になります。リソース計画は調整の連続であるため、こうした認識のズレは積み重なるほど負担になります。タイムゾーンに依存しない日付として計画を扱えるようになることで、「4月1日開始」という計画上の事実が、誰にとっても同じ意味で共有されるようになります。

2025wave2までのProjectOperationsでは、リソース計画に使われる日付情報も、ユーザーや環境のタイムゾーンの影響を受ける形で扱われることが多く、グローバル運用では注意深い取り扱いが必要でした。計画そのものは正しくても、表示上の差異によって「なぜこの日付なのか」を説明する必要が生じたり、会議や資料では日付を言い換えて説明したりする場面もありました。リソース計画という“日付が命”の領域で、日付の意味が揺らぐこと自体が、実務上のストレスになっていたと言えます。

2026wave1では、リソース計画においてもタイムゾーンに依存しない日付フィールドが使われることで、この前提が整理されます。計画上の開始日・終了日・割り当て期間を「世界共通のカレンダー上の日付」として扱えるようになり、リソース計画の読み違いや解釈違いを防ぎやすくなります。これはUIの派手な変更ではありませんが、グローバルなリソースマネジメントを安定させるための重要な土台です。計画を共有するだけでなく、計画について議論し、合意するプロセスを滑らかにします。

一方で、留意点もあります。リソース計画を日付ベースで安定させることと、実際の稼働開始時刻や勤務時間帯を無視してよい、ということは同義ではありません。特に、短時間の割り当てや、日をまたぐ作業、シフト制の運用などでは、時刻やタイムゾーンの概念が引き続き重要になります。この機能は、リソース計画の“骨格”となる期間管理を安定させるものであり、詳細な時間管理を不要にするものではありません。どこまでを日付ベースで扱い、どこからを時刻ベースで扱うのかを整理したうえで使うことで、リソース計画の分かりやすさと実態把握の両立が可能になります。

この改善は、グローバル環境でリソース計画を行う際に起きがちな「説明しづらいズレ」を静かに解消するものです。数値やロジックを変えるのではなく、計画の前提となる日付の意味を揃えることで、ProjectOperationsのリソース管理をより信頼できるものに引き上げる一歩だと言えるでしょう。

この改善が効いてくるのは、複数の契約形態や条件が混在するプロジェクトです。たとえば、固定価格と時間材料の混在、マイルストーン請求、サブスクリプション、Change Orderによる条件変更などが重なると、「今、このプロジェクトはどの契約条件で動いているのか」を把握するだけでも手間がかかります。契約管理の使い勝手が向上することで、契約条件、期間、請求方法、変更履歴といった情報を、プロジェクトの文脈の中で確認しやすくなり、現場の判断や顧客との会話に使える情報として活かしやすくなります。

2025wave2までのProjectOperationsでは、契約管理機能は備わっているものの、UIや導線の観点では改善余地が残っていました。契約情報は正しく登録されていても、確認や更新の操作が分かりにくく、結果として「普段は見ない」「必要なときだけFinanceや管理部門に確認する」といった使われ方になりがちでした。そのため、プロジェクト管理と契約管理が心理的に分断され、契約が“背景情報”として扱われてしまうケースも少なくありませんでした。

2026wave1では、契約管理の操作性が改善されることで、この分断が緩和されます。契約情報をより分かりやすく表示し、必要な情報に辿り着きやすくすることで、プロジェクト管理の流れの中で契約条件を自然に参照できるようになります。これは機能追加というより、「使われ方」を意識した改善であり、契約を単なる登録データではなく、日常的に参照・判断される情報へと位置付け直すものです。結果として、契約条件に基づいた計画や請求、変更管理が行いやすくなります。

一方で、留意点もあります。契約管理の使い勝手が向上すると、現場で契約情報に触れる機会が増える分、「どこまでを編集してよいのか」「誰が最終的な責任を持つのか」といったガバナンスの整理が重要になります。また、契約情報が見やすくなったからといって、内容そのものが自動的に正しくなるわけではありません。この改善は、契約管理を楽にするものではなく、契約を正しく理解し、正しく使うための土台を整えるものです。Change Order管理や請求管理と組み合わせて活用することで、ProjectOperations全体として「契約に強いプロジェクト管理」を実現する一助になるでしょう。

この改善は派手ではありませんが、プロジェクト管理の信頼性と説明力を静かに底上げする重要な一歩です。契約を起点にプロジェクトを考える文化を支えるための、実務寄りの改善だと言えます。

この機能が特に効果を発揮するのは、複数のプロジェクトが並行して進み、共通の資材やサービスを調達する必要がある環境です。たとえば、同じ外注先や同じ品目を複数プロジェクトで利用している場合、個別に発注していると条件や単価が揃わなかったり、全体としてどれだけ発注しているのかが見えにくくなったりします。中央集約型の購買発注を行えるようになることで、「どのプロジェクト向けの調達か」を明確に保ちつつ、発注をまとめて管理でき、交渉力や調達効率の向上にもつながります。

2025wave2までのProjectOperationsでは、プロジェクトに関連する購買発注は可能であるものの、実務上はプロジェクト単位・担当者単位での運用になりやすく、全体最適という視点を持ちにくい側面がありました。結果として、購買状況を横断的に把握するには追加のレポートや管理作業が必要になり、調達がプロジェクト管理から一歩外れた活動として扱われてしまうケースもありました。仕組みはあっても、運用上は分散管理に寄りやすかったと言えます。

2026wave1では、プロジェクト調達における購買発注を中央集約的に扱えるようになることで、この前提が変わります。プロジェクトごとの要件や関連性を保持したまま、購買発注をまとめて管理できるようになり、調達状況を全体視点で把握しやすくなります。これにより、発注漏れや重複を防ぎやすくなるだけでなく、購買プロセスとプロジェクト進行の足並みを揃えやすくなります。調達が「後追いの事務作業」ではなく、「プロジェクト計画の一部」として扱われる点が、この機能の大きな価値です。

一方で、留意点もあります。購買発注を中央集約化するということは、誰が発注を行い、誰が承認し、どのタイミングでプロジェクト側と連携するのかといった役割分担を明確にする必要があるということでもあります。現場の柔軟な判断を残しつつ、統制を効かせるためには、運用ルールの設計が欠かせません。また、すべての調達を中央に寄せるべきとは限らず、緊急対応や少額調達など、例外をどう扱うかも整理しておく必要があります。この機能は購買を自動化するものではなく、調達をプロジェクト管理の中に正しく位置付け直すための基盤です。プロジェクト管理、購買管理、Financeの役割を揃えたうえで使うことで、プロジェクト調達全体の透明性と効率を高めることができるでしょう。

この機能が特に重要になるのは、すでに進行しているプロジェクトを途中からProjectOperationsで管理し始めるケースや、旧システムから移行してくるプロジェクトです。たとえば、移行時点ですでに原価が発生している、請求済み金額がある、あるいは前受金や未収金が存在している場合、従来は「移行前は別管理」「移行後からが本番」と割り切るか、擬似的な取引で帳尻を合わせる必要がありました。期首残高を正式に持てるようになることで、プロジェクトの履歴を断ち切ることなく、継続した形で管理できるようになります。

2025wave2までのProjectOperationsでは、プロジェクトは原則としてゼロベースで開始される前提が強く、途中からの引き継ぎや、過去実績を含んだ状態での管理は運用や個別対応に頼る部分がありました。その結果、プロジェクト管理上の数値と、財務や過去資料上の数値の間に「スタート地点の違い」が生じ、説明や突合が必要になることも少なくありませんでした。仕組みとしては回避策があっても、自然な形で扱えるとは言いづらい状態でした。

2026wave1では、beginning balancesを正式に扱えるようになることで、この前提が大きく変わります。プロジェクト開始時点に、原価、売上、請求、前受金などの残高を持たせたうえで、その先の実績を積み上げられるようになり、プロジェクトの全体像を一続きで捉えられます。これにより、「どこからが新しい実績なのか」「移行時点でどの状態だったのか」を明確にしたまま管理でき、プロジェクト管理と財務管理の整合性が取りやすくなります。特にシステム移行や長期プロジェクトの引き継ぎでは、非常に実務的な価値を持つ改善です。

一方で、留意点もあります。期首残高を設定できるようになるということは、その数値の正確性がプロジェクト全体の信頼性を左右するということでもあります。beginning balancesの設定を誤ると、その後のすべての実績や分析が歪んでしまいます。また、どの項目を期首残高として持ち、どこからを通常の実績として扱うのかという整理も重要です。この機能は過去を自動的に正しくしてくれるものではなく、過去を正しく引き継ぐための器です。移行方針や会計ルールと整合させたうえで使うことで、ProjectOperationsを「途中からでも安心して使える基幹プロジェクト管理基盤」へと引き上げる役割を果たすでしょう。

この機能は目立ちにくいものの、現実のプロジェクト運営に強く寄り添った改善です。プロジェクト管理を“新規案件専用”から、“継続的な業務の受け皿”へと広げるための、重要な一歩だと言えます。

この改善が特に効いてくるのは、長期間にわたる契約や、明細行数の多い見積を扱うケースです。たとえば、数十人月規模のサービスを複数フェーズに分けて提供する契約や、月次・四半期単位で売上や原価を配分する必要がある場合、time phasingの計算は避けて通れません。従来は、見積や契約を保存・更新するたびに処理が重く感じられたり、計画変更のたびに待ち時間が発生したりすることもあり、現場では「細かく分けるのをやめよう」「後で調整しよう」といった運用に流れがちでした。パフォーマンスが改善されることで、時間配分を前提とした正確な計画を、ためらわずに扱えるようになります。

2025wave2までのProjectOperationsでは、time phasingの機能自体は備わっているものの、規模が大きくなるにつれて実務上の負荷が顕在化しやすい状況でした。見積や契約の明細数が増えるほど処理時間が伸び、計画変更を繰り返すと操作性に影響が出ることもありました。その結果、理論上はできるはずの期間配分を、運用上は簡略化せざるを得ない場面もあり、見積精度や将来予測の質に影響を与えることがありました。

2026wave1では、見積および契約明細の時間配分処理におけるパフォーマンスが改善され、より多くの明細や長い期間を扱っても、実務上のストレスを感じにくくなります。これにより、見積段階から「いつ・どれくらい発生するのか」を現実的な粒度で表現しやすくなり、契約後の計画や収益管理へも自然につなげられます。time phasingが「後工程のための補助情報」ではなく、「意思決定に使える前提情報」として扱えるようになる点が、この改善の本質です。

一方で、留意点もあります。パフォーマンスが向上したからといって、時間配分の前提やロジックが自動的に正しくなるわけではありません。どの期間に配分するのか、どの粒度で管理するのかは、引き続き業務設計に依存します。また、過度に細かい配分を行えば、管理やレビューの負荷が増える可能性もあります。この改善はtime phasingを“使いやすくする”ものであり、“考えなくてよくする”ものではありません。見積や契約の段階で、どこまでの精度が必要なのかを整理したうえで使うことで、計画精度と運用負荷のバランスを取りやすくなるでしょう。

この改善は派手な新機能ではありませんが、見積・契約・計画を時間軸で正しくつなぐための基盤を強化するものです。ProjectOperationsを小規模案件だけでなく、長期・大規模案件でも安心して使うための、実務に直結した底上げだと言えます。

この改善が特に効いてくるのは、複数の見積案を短期間で作成・調整する必要がある場面です。たとえば、顧客とのやり取りの中でスコープや体制が変わり、見積を何度も更新するケースでは、操作の分かりにくさや画面遷移の多さがそのまま作業負荷になります。見積の使い勝手が向上することで、構成や金額、条件の検討に集中しやすくなり、営業担当やプリセールスが「ツールの使い方」ではなく「提案の中身」に時間を使えるようになります。

2025wave2までのProjectOperationsでも、見積機能は十分な情報を扱える一方で、UIや導線の観点では改善余地が残っていました。見積行や条件、期間配分などを確認・編集する際に、どこを見ればよいのか分かりにくかったり、全体像を把握するのに手間がかかったりする場面もありました。その結果、見積作成が「慣れている人でないと扱いづらい」作業になり、属人化しやすい側面がありました。

2026wave1では、Project Quote体験における使いやすさが改善され、見積作成や編集の流れがより分かりやすくなります。情報の見せ方や操作の一貫性が見直されることで、見積全体の構成や前提条件を把握しやすくなり、変更時の影響も追いやすくなります。これは新しい機能を増やすというより、既存の機能を「実務で使いやすい形」に整える改善であり、日々の見積作業にじわじわと効いてくる変更です。見積がプロジェクト実行の出発点として、より信頼できるものになります。

一方で、留意点もあります。見積の操作性が向上しても、前提条件や見積ロジックそのものを自動的に正しくしてくれるわけではありません。見積の質は、引き続き、前提の整理や関係者間の合意に依存します。また、使いやすくなることで、見積案を気軽に増やしすぎると、どれが正式な案なのか分かりにくくなる可能性もあります。この改善は見積作成を楽にするためのものではなく、考えるべきポイントに集中できる環境を整えるためのものです。見積管理のルールや承認プロセスと組み合わせることで、営業からプロジェクトへの引き継ぎを、よりスムーズで確実なものにしてくれるでしょう。

この改善は派手さはありませんが、ProjectOperationsを日常的に使う人ほど恩恵を感じやすい領域です。見積体験の質を底上げすることで、プロジェクト型ビジネス全体のスピードと一貫性を静かに支える、実務寄りのアップデートだと言えます。

この改善が特に重要になるのは、ProjectOperationsや他の業務画面の一部として、Project for the webを参照・活用している組織です。たとえば、プロジェクト全体の進捗を確認する目的でiFrame表示している画面において、閲覧だけを想定しているユーザーが、意図せず計画を編集できてしまうと、計画の整合性が崩れるリスクがあります。アクセス制限が適切に実装されることで、「参照専用」「限定的な編集」「フル編集」といった役割ごとの使い分けがしやすくなり、プロジェクト計画の信頼性を保ちやすくなります。

2025wave2までの前提では、Project for the web自体の権限管理は存在するものの、iFrameとして組み込んだ際の振る舞いについては、利用者から見ると分かりにくい部分が残っていました。画面上は単なる埋め込み表示に見えても、背後では通常のProject for the webと同じ操作が可能になっている場合があり、「この画面では何をしてよいのか」「どこまで責任を持つべきか」が曖昧になりやすい状態でした。その結果、計画変更が意図しない経路で行われたり、誰が変更したのかを追う必要が生じたりと、運用上の不安が残っていました。

2026wave1では、Project for the webをiFrameで利用する際のアクセス制御が強化され、こうした不安が軽減されます。埋め込み先の文脈に応じて、表示や操作を制限できるようになることで、iFrameは「便利だが危うい統合」ではなく、「役割が明確な一部機能」として扱いやすくなります。これにより、ProjectOperationsなどの業務画面にProject計画を自然に組み込みつつ、計画の編集権限や責任範囲を明確に保つことができます。プロジェクト計画を共有しながらも、統制を失わないための重要な改善だと言えるでしょう。

一方で、留意点もあります。アクセス制限を強化するということは、「誰がどの画面で何をするのか」を事前に設計する必要があるということでもあります。単に制限をかければ安全になるわけではなく、業務フローと役割定義が曖昧なままだと、逆に「見たい情報が見られない」「必要な操作ができない」といった不満が生じる可能性もあります。また、iFrame上での操作制限と、元のProject for the web画面での操作権限との関係を理解しておかないと、想定外の挙動に見えることもあります。この機能はアクセス管理を自動的に整理してくれるものではなく、既存の権限設計を前提に、それを安全に埋め込むための補強です。

この改善は、Project for the webを単体ツールとして使う段階から、他の業務アプリケーションの中に組み込んで使う段階へ進んだ組織にとって、非常に実務的な意味を持ちます。計画の可視性と統制のバランスを取りながら、プロジェクト情報を必要な場所に届けるための基盤として、iFrame利用の信頼性を一段引き上げる機能だと言えるでしょう。

この機能が特に効果を発揮するのは、タスク数が多く、進捗更新の頻度が高いプロジェクトです。たとえば、短いタスクが連なる設計・開発・導入フェーズでは、タスクを一つひとつ開いて進捗を更新する作業自体が負担になりがちでした。Tasks grid上で進捗を直接更新できれば、タスク一覧を確認しながら「ここは完了」「ここは50%」「ここはまだ未着手」といった判断を、その場で反映できます。結果として、進捗更新がリアルタイムに近づき、プロジェクト全体の状況把握もしやすくなります。

2025wave2までのProjectOperationsでは、タスク進捗の更新は主に個別タスク画面を起点とする運用が中心でした。そのため、進捗をまとめて確認する画面と、進捗を更新する画面が分かれており、「確認はしたが更新は後で」という状態が生まれやすい構造でした。特に、進捗確認を会議やレビューの中で行った場合、その場で反映せず、後から更新することで漏れや遅れが発生することもありました。進捗管理の重要性と、操作の手間の間にギャップがあったと言えます。

2026wave1では、Tasks gridから直接タスク進捗を記録できるようになることで、このギャップが縮まります。タスク一覧という“全体を俯瞰する視点”と、進捗更新という“実績反映の行為”が同じ画面で完結するため、進捗管理のテンポが大きく改善されます。これは単なる操作性の向上ではなく、「見たら直す」「分かったら反映する」という自然な行動をシステムが後押しする改善です。結果として、計画と実態のズレを小さいうちに把握・修正しやすくなります。

一方で、留意点もあります。進捗を簡単に更新できるようになる分、進捗の定義や基準が曖昧なままだと、更新内容にばらつきが出る可能性があります。たとえば、50%完了の意味が人によって異なると、一覧上では分かりやすく見えても、判断材料としての信頼性が下がってしまいます。また、進捗更新の権限を誰に与えるのか、チームメンバー自身が更新するのか、プロジェクトマネージャーがまとめて更新するのかといった運用設計も重要です。この機能は進捗管理を自動化するものではなく、進捗更新を“やりやすくする”ためのものです。タスク設計や進捗定義と組み合わせることで、初めてプロジェクト管理の精度を底上げする効果を発揮します。

この改善は、派手な新機能ではありませんが、プロジェクト管理の「更新されない計画」という根本的な問題に正面から向き合った実務的なアップデートです。Tasks gridを“見るだけの一覧”から“進捗管理の主戦場”へと変えることで、ProjectOperationsをより現場に近いツールへ進化させる一歩だと言えるでしょう。

この改善が効いてくるのは、テンプレート的にプロジェクトを量産する運用です。たとえば、同種の導入プロジェクトや、地域展開ごとに構成が似通った案件では、過去プロジェクトをコピーして新規案件を作成することが一般的です。しかし、従来はコピー後にプロジェクト開始日や期間、担当者、ステータス、契約関連項目などを手動で修正する必要があり、「どこを直すべきか」を理解していないと、意図しない情報を引きずったまま進めてしまうリスクがありました。主要フィールドが適切に更新されることで、コピー直後から安心して計画作業に入れるようになります。

2025wave2までのProjectOperationsでは、Copy projectは構造やタスク、計画を引き継ぐための機能として有効でしたが、プロジェクトのライフサイクル上重要な項目については、コピー元の値がそのまま残るケースもありました。その結果、開始日や状態、契約との関係などがコピー元のままになり、後から修正漏れが発覚することもありました。仕組みとしては問題なくても、実務では「コピー後の初期整備」が前提作業として必要だったと言えます。

2026wave1では、Copy projectを使った際に、主要なプロジェクト項目が新規プロジェクトとして適切な値に更新されるようになります。これにより、コピー元の履歴や文脈を引きずらず、新しいプロジェクトとして自然なスタート地点を持てるようになります。コピーはあくまで「型を再利用する」ための手段であり、「過去をそのまま複製する」ことが目的ではありません。この改善は、その本来の意図にCopy projectの挙動を近づけるものです。

一方で、留意点もあります。どの項目をコピーし、どの項目を更新・初期化すべきかは、組織や運用によって異なります。すべてを自動的にリセットすればよいわけではなく、あえて引き継ぎたい情報も存在します。この機能はコピー後の判断を不要にするものではなく、「最低限、危険な引きずりを防ぐ」ための改善です。プロジェクトテンプレートの設計や、Copy projectを使う際の社内ルールと組み合わせることで、初めて効果が最大化されます。Copy projectを「時短のための機能」から、「品質を保った再利用の仕組み」へと引き上げることで、ProjectOperationsを日常的に安心して使えるプロジェクト基盤に近づける改善だと言えるでしょう。

この機能が特に効果を発揮するのは、複数の役割が同じタスクを異なる視点で扱うプロジェクトです。たとえば、プロジェクトマネージャーは進捗率や依存関係、期限に関心がありますが、チームメンバーは作業内容や優先度、関連ドキュメントを素早く確認したいことが多く、Financeや管理部門は原価や請求との関係を意識します。従来は、すべての情報が同じタスク詳細画面に詰め込まれがちで、「必要な情報に辿り着くまでにスクロールが多い」「自分には関係のない項目が多い」といった使いづらさがありました。タスク詳細ペインをカスタマイズできることで、役割ごとに“見るべき情報”を前面に出しやすくなります。

2025wave2までのProjectOperationsでは、タスク詳細ペインの構成は基本的に固定的で、表示される情報は共通でした。そのため、機能的には十分でも、実務では「見る人によってはノイズが多い」「重要な項目が埋もれる」といった課題が残っていました。特に、タスク数が多いプロジェクトや、タスクを頻繁に確認・更新する運用では、画面の使い勝手がそのまま生産性に影響する場面もありました。

2026wave1では、タスク詳細ペインを用途に合わせて調整できるようになることで、この前提が変わります。必要な項目を中心に配置し、不要な情報を抑えることで、タスクを開いた瞬間に「今、判断すべきこと」が目に入るようになります。これは単なる見た目の変更ではなく、タスクを確認するたびに行っていた“頭の中での取捨選択”を、システム側で肩代わりする改善です。結果として、タスク更新や確認のスピードが上がり、タスク管理がより日常業務に溶け込みやすくなります。

一方で、留意点もあります。タスク詳細を自由にカスタマイズできるということは、どの情報を重視するかをあらかじめ整理する必要があるということでもあります。カスタマイズの方向性が定まっていないと、画面構成が人やチームごとにばらつき、逆に共通認識が持ちづらくなる可能性もあります。また、すべてを簡素化しすぎると、後から必要な情報に気付きにくくなるリスクもあります。この機能はタスク管理を簡略化するためのものではなく、役割ごとの視点を明確にするためのものです。どの項目が意思決定に直結するのかを整理したうえで使うことで、初めて効果を発揮します。

この改善は、ProjectOperationsを「機能が多いツール」から「使う人に寄り添うツール」へ近づける一歩です。タスク詳細ペインを自分たちの業務に合わせて整えられることで、タスク管理が負担ではなく、自然な確認・更新の場として機能しやすくなります。現場の使い勝手を重視する組織ほど、じわじわと価値を感じられる実務寄りのアップデートだと言えるでしょう。

この機能が特に効果を発揮するのは、類似構造のプロジェクトを繰り返し実行する組織です。たとえば、拠点展開プロジェクト、製品導入プロジェクト、定型的なフェーズ構成を持つ案件では、毎回ほぼ同じタスク構成を作る必要があります。従来は、プロジェクト全体をコピーするか、手作業でタスクを作り直すしかなく、「必要な部分だけ再利用したい」という要望にはうまく対応できませんでした。他プロジェクトからタスクを直接取り込めるようになることで、計画作成のスピードが上がり、タスク設計の品質も安定しやすくなります。

2025wave2までのProjectOperationsでは、Copy projectによるプロジェクト単位の再利用は可能でしたが、タスクだけを選択的に取り込むことは前提とされていませんでした。そのため、過去プロジェクトの一部構成を使いたい場合でも、不要な要素を含めてコピーしたり、コピー後に削除・調整を行ったりする必要がありました。この運用は回避策としては成立しますが、手間がかかるうえ、意図しない情報を引きずるリスクもあり、計画作成の心理的なハードルになっていました。

2026wave1では、他プロジェクトからタスクをインポートできるようになることで、この前提が変わります。プロジェクト全体ではなく、「このフェーズのタスクだけ」「この作業セットだけ」といった形で、必要なタスク構成を取り込めるようになり、計画作成がより部品化されたアプローチに近づきます。これにより、プロジェクト計画は一品物ではなく、「組み立て可能な構造」として扱いやすくなります。タスクを再利用できることは、単なる時短ではなく、組織としての知見を計画に埋め込む手段でもあります。

一方で、留意点もあります。タスクを他プロジェクトから取り込めるようになると、「そのタスクがどの前提で作られたものか」を理解せずに使ってしまうリスクも出てきます。期間、依存関係、リソース前提、成果物定義などが、元のプロジェクトの文脈に強く依存している場合、取り込んだだけでは実態に合わないこともあります。また、タスクをテンプレート的に使い回す場合、更新や改善をどこで反映するのかという管理も課題になります。この機能はタスク設計を考えなくてよくするものではなく、「考えるための材料を再利用しやすくする」ための仕組みです。

Add support to import tasks from other projectsは、ProjectOperationsの計画作成を、コピー中心の再利用から、より柔軟な部品再利用へと進化させる改善です。計画を個人の経験に閉じたものではなく、組織の資産として積み重ねていくための基盤として、じわじわと効いてくる機能だと言えるでしょう。

この機能が特に価値を発揮するのは、提案段階で不確定要素が多い案件です。たとえば、体制を厚くした場合と抑えた場合で原価や期間がどう変わるのか、外注比率を上げた場合の収益性はどうなるのか、開始時期をずらした場合に全体の負荷はどう影響するのか、といった検討は日常的に発生します。従来は、こうした比較を行うために見積をコピーしたり、Excelで別管理したりする必要があり、「どれが正式な見積なのか」「最新の前提はどれか」が分かりにくくなるリスクがありました。what‑if analysisを使えば、同じ見積をベースに複数の案を並べて検討でき、比較の軸を保ったまま判断できます。

2025wave2までのProjectOperationsでは、見積の編集や再計算は可能でしたが、「検討用」と「提出用」を明確に分けて扱う仕組みは限定的でした。そのため、シナリオ検討を行う際は、見積そのものを書き換えるか、別の見積として作り直す必要があり、途中でどの案がベースなのか分からなくなることもありました。結果として、見積変更に慎重になりすぎたり、逆に勢いで変更して後戻りが発生したりと、意思決定の質に影響を与える場面もありました。

2026wave1では、見積に対してwhat‑if分析を行えるようになることで、この前提が変わります。元の見積を保持したまま、複数の仮説シナリオを作成・比較できるため、「今検討しているのはあくまで仮の案」であることを明確にしたまま議論を進められます。これにより、営業、プリセールス、プロジェクトマネージャー、Financeといった関係者が、同じ前提・同じ構造の見積を見ながら、「どの案を選ぶべきか」を議論しやすくなります。感覚や経験だけでなく、比較結果をもとに判断できる点が、この機能の本質です。

一方で、留意点もあります。what‑if分析はあくまで仮説検討であり、入力する前提条件の精度に大きく依存します。リソース単価や稼働率、期間設定が現実とかけ離れていれば、比較結果も参考値に留まります。また、シナリオを作りすぎると、どれを正式案とするのかの判断が遅れ、意思決定そのものが停滞するリスクもあります。この機能は「答えを自動で出す」ものではなく、「考えるための材料を整理する」ための仕組みです。どの観点でシナリオを作るのか、どの段階で収束させるのかを整理したうえで使うことが重要です。

Use what‑if analysis on estimatesは、見積を単なる提出物から、意思決定のためのシミュレーション基盤へと引き上げる機能です。見積段階での検討の質を高めることで、その後のプロジェクト計画や収益管理のブレを小さくし、結果としてプロジェクト全体の成功確率を高める土台になります。提案の精度とスピードの両立を目指す組織にとって、実務的な価値が大きい改善だと言えるでしょう。

この機能が特に価値を発揮するのは、期間が長く、フェーズやマイルストーンに分かれて価値を提供するプロジェクトです。たとえば、初期設計、構築、テスト、展開といった段階ごとに原価や売上が発生する場合、総額だけではプロジェクトの実態を正しく捉えることはできません。見積や契約明細を時間配分できれば、「この四半期にどれだけの原価と売上を想定しているのか」「どの期間に負荷が集中するのか」を見積段階から明確にできます。結果として、営業判断だけでなく、リソース計画や収益予測との整合も取りやすくなります。

2025wave2までのProjectOperationsでは、見積や契約に金額情報を持たせることはできても、それを標準的に期間配分して扱うには制約がありました。そのため、時間軸での配分はExcelや外部資料で管理したり、プロジェクト計画に落とし込んでから初めて見えるようにしたりと、段階的な分断が生じがちでした。見積・契約・計画が同じ構造を持っていないことで、「提案時の想定」と「実行時の計画」がズレるリスクもありました。

2026wave1では、見積および契約明細に対してtime phasingを行えるようになることで、この分断が緩和されます。見積段階で想定した期間配分を、そのまま契約・計画の前提として活かせるようになり、「いつ・どれくらい」という視点を一貫して持ち続けられます。これは単に表示が増えるという話ではなく、見積を“将来の姿を描いた計画の入口”として位置付け直す改善です。結果として、プロジェクト開始後の計画調整や説明の負荷も下がります。

一方で、留意点もあります。time phasingを有効にするということは、見積や契約の段階で、ある程度の期間設計を行う必要があるということでもあります。初期段階で前提が固まっていない案件では、過度に細かい配分を行うことで、後からの修正負荷が増える可能性もあります。また、配分ロジックが曖昧なままだと、見た目は整っていても、意思決定に使いづらいデータになることもあります。この機能は見積や契約を正しく分解するための道具であり、考えなくてよくするものではありません。

Enable time phasing of quote and contract linesは、見積・契約を「金額の塊」から「時間を持った計画情報」へと引き上げる機能です。提案段階の想定を、そのまま実行と収益管理につなげたい組織にとって、非常に重要な基盤強化だと言えるでしょう。見積、契約、プロジェクト計画を同じ時間軸で語れるようになることで、ProjectOperations全体の一貫性と説明力が大きく高まります。

この機能が特に効いてくるのは、標準フィールドだけでは表現しきれない金額情報をプロジェクト管理に持ち込みたいケースです。たとえば、契約上の参考金額、内部管理用の見積原価、特定条件下でのみ使われる追加コストなどを、カスタム列で管理している組織は少なくありません。従来は、それらを単なる数値として持たせるしかなく、通貨の前提を別途説明したり、見る人の解釈に委ねたりする必要がありました。通貨型として扱えるようになることで、「これは金額であり、この通貨である」という意味を、データそのものに持たせられるようになります。

2025wave2までのProjectOperationsでは、カスタム列は非常に柔軟である一方、財務的な意味付けについては限定的でした。金額を表す数値であっても、システム上は単なる数値として扱われるため、標準の金額フィールドとは異なり、通貨の整合性や表示の一貫性を保つのが難しい状況でした。その結果、カスタム列は「補足情報」や「一時的な管理用」に留まり、正式な意思決定や分析には使いにくい、という扱いになりがちでした。

2026wave1では、カスタム列で通貨型をサポートすることで、この前提が変わります。金額を金額として扱えるようになり、通貨単位を意識した表示や管理が可能になります。これにより、標準フィールドとカスタムフィールドの間で意味の断絶が起きにくくなり、「なぜこの列は信用できて、あの列は参考値なのか」といった違和感も減っていきます。カスタマイズによって追加した情報であっても、財務的に意味のあるデータとして扱えるようになる点が、この機能の本質です。

一方で、留意点もあります。カスタム列に通貨型を持たせられるようになることで、金額情報をより自由に追加できる反面、「どの金額が公式なのか」「どの金額を基準に判断すべきなのか」を整理しておかないと、情報が増えすぎて混乱を招く可能性があります。また、通貨換算や会計処理とどこまで連動させるのかについても、過度な期待を持つとズレが生じます。この機能は会計ロジックを拡張するものではなく、あくまでデータ表現の精度を高めるためのものです。

Add support for Currency on custom columnsは、ProjectOperationsのカスタマイズを「便利な拡張」から「意味のある拡張」へと引き上げる改善です。標準機能とカスタム要素の間にあった温度差を埋めることで、組織固有の管理項目であっても、安心してプロジェクト判断に使えるデータとして扱えるようになります。細かな改善ではありますが、カスタマイズを前提にProjectOperationsを使い込んでいる組織ほど、その価値を実感しやすいアップデートだと言えるでしょう。

この機能が特に効いてくるのは、同時期に多くのプロジェクト請求を確定する必要がある環境です。たとえば、月末締めで数十、数百のプロジェクト請求提案を一気に転記する場合、従来は処理完了まで待ち続ける必要があり、その間にエラーが発生すると全体が止まってしまうリスクもありました。マルチスレッドのバッチ処理を使うことで、請求提案を並列に処理できるようになり、全体の処理時間が短縮されるだけでなく、一部の処理が遅れても全体が巻き添えで止まる可能性を下げられます。結果として、請求処理を“神経を使う作業”から“定型的な締め処理”に近づけることができます。

2025wave2までのProjectOperationsでは、請求提案の転記や確定は基本的に順番に処理される前提が強く、件数が増えるほど処理時間と不安定さが問題になりがちでした。特に締め直前のタイミングでは、「処理が終わるまで他の作業が進められない」「エラーが出たらやり直しになる」といった心理的・実務的な負荷があり、請求処理自体がスケジュールリスクになることもありました。機能的には可能でも、運用上は余裕を見た対応が必要だったと言えます。

2026wave1では、請求提案の転記をマルチスレッドのバッチタスクとして実行できるようになることで、この前提が大きく変わります。複数の請求提案を同時に処理できるため、全体のスループットが向上し、大規模な請求処理でも現実的な時間内に完了させやすくなります。これは単なる高速化ではなく、「請求件数が増えても運用を変えなくてよい」状態に近づける改善です。プロジェクト規模や件数が拡大しても、請求プロセスが足かせになりにくくなります。

一方で、留意点もあります。マルチスレッドで処理できるようになることで、エラーや例外が発生した場合の把握や切り分けの考え方も変わります。すべてが一括で成功・失敗するのではなく、「一部は成功し、一部は失敗する」状態が起こり得るため、どの単位で再処理するのか、どこまでを自動で進め、どこで人が確認するのかといった運用整理が重要になります。また、請求処理のスピードが上がる分、事前のレビューや承認プロセスをどこで行うのかも改めて考える必要があります。この機能は請求判断を自動化するものではなく、処理を耐えられるものにするための基盤強化です。

Post project invoice proposals using multithreaded batch tasksは、ProjectOperationsを小規模案件向けのツールから、エンタープライズ規模の請求処理にも耐えうる基盤へと引き上げる改善です。請求件数が増えても、締めのたびに身構える必要がなくなることで、プロジェクト管理と財務締めのリズムをより安定させます。規模が大きくなるほど効いてくる、実務に直結したアップデートだと言えるでしょう。

この機能が特に効いてくるのは、プロジェクトやタスクに、組織固有の管理軸や参照情報を持たせたいケースです。たとえば、社内の担当部署、承認フローの責任者、関連する社内システム、特定の契約種別や管理コードなどを、単なるテキストではなく、マスターデータと結び付けて管理したい場面は少なくありません。lookup型を使えるようになることで、「入力された値が何を指しているのか」を明確に保ったまま管理でき、表記揺れや入力ミスによる解釈違いを防ぎやすくなります。結果として、プロジェクトデータの信頼性と再利用性が高まります。

2025wave2までのProjectOperationsでは、カスタム列は自由度が高い反面、他のエンティティとの関係性を持たせることが難しく、実務では「この値は○○を意味する」という暗黙の前提に頼る場面がありました。そのため、データを横断的に分析したり、後工程で自動処理に使ったりする際に、追加の変換や確認が必要になることもありました。カスタム列が便利ではあるものの、「正式な業務データ」として扱いきれない場面が残っていたと言えます。

2026wave1では、カスタム列でlookupをサポートすることで、この前提が変わります。カスタムで追加した項目であっても、他のエンティティやマスターデータと明示的につながるようになり、データ同士の関係性をシステム上で表現できるようになります。これにより、カスタム列は単なる補助情報ではなく、業務プロセスや判断を支える正式なデータ要素として使いやすくなります。標準機能とカスタマイズの間にあった「意味の壁」を下げる改善だと言えるでしょう。

一方で、留意点もあります。lookupを使えるようになることで、カスタム列の設計はこれまで以上に重要になります。どのエンティティを参照させるのか、参照先のマスターデータを誰がどのように管理するのかが曖昧なままだと、逆にデータ構造が複雑化する可能性があります。また、lookupは関係性を強く持たせる分、後から変更しにくい設計になることもあります。この機能はカスタマイズを無制限に広げるためのものではなく、「意味のある拡張」を可能にするためのものです。事前に管理方針や責任分界を整理したうえで使うことが重要です。

Add support for Lookups on custom columnsは、ProjectOperationsのカスタマイズを、見た目や入力補助のレベルから、業務データモデルの拡張へと一段引き上げる改善です。組織固有の管理軸を、標準機能と同じ文脈で扱えるようになることで、プロジェクトデータの一貫性と活用余地が大きく広がります。カスタマイズ前提でProjectOperationsを使い込んでいる組織ほど、その価値を実感しやすい、基盤的で実務寄りのアップデートだと言えるでしょう。

この機能が特に効いてくるのは、サービス提供と物品提供がセットになったプロジェクトです。たとえば、IT導入プロジェクトでの機器納入、設備構築プロジェクトでの部材供給、あるいはリソース作業と同時に消費される在庫品がある場合、従来は「サービスはProjectOperations、在庫品は別管理」という分断が起きやすい状況でした。在庫品をリソースベース展開の中で扱えるようになることで、「どのプロジェクトで、いつ、どの在庫品が使われたのか」を一貫した文脈で把握でき、原価管理や進捗管理の精度が高まります。

2025wave2までのProjectOperationsでは、リソースベース展開は主に人や外注サービスを中心としたモデルで設計されており、在庫品の扱いは限定的、もしくは別プロセスで補う必要がありました。そのため、プロジェクト計画上は存在しているはずの物品が、在庫管理や購買管理の世界では別の文脈で処理され、後から突合や説明が必要になることもありました。プロジェクト管理としては成立していても、物の動きとの整合を取るには運用での工夫が欠かせなかったと言えます。

2026wave1では、リソースベース展開においても在庫品を正式に扱えるようになることで、この前提が変わります。プロジェクトの中で、サービス提供と在庫品消費を同じ流れで捉えられるようになり、「作業の進捗」と「物の動き」が切り離されにくくなります。これにより、原価の見え方がより実態に近づき、プロジェクト損益や在庫影響を含めた判断がしやすくなります。プロジェクト型業務を、よりERP的な視点で扱えるようにするための重要な拡張だと言えるでしょう。

一方で、留意点もあります。在庫品をリソースベース展開に組み込むことで、プロジェクト管理と在庫管理の境界が近づく分、データの正確性やタイミングの重要性が増します。在庫引当、出庫タイミング、原価計上のルールが曖昧なままだと、プロジェクト側では見えているが在庫側では整合しない、といった新たなズレが生じる可能性もあります。また、すべてのプロジェクトが在庫品を扱うわけではないため、どのシナリオでこの機能を使うのかを整理しておくことも重要です。この機能は在庫管理を簡単にするものではなく、プロジェクト管理と在庫管理を同じ土俵で扱えるようにするための基盤です。

Use stocked products in resource‑based deploymentsは、ProjectOperationsを「人中心のプロジェクト管理」から、「人と物の両方を含むプロジェクト管理」へと進化させる機能です。サービスと物品が一体となったプロジェクトを多く扱う組織にとって、実態に即した原価管理と進捗把握を可能にする、実務的で影響範囲の大きいアップデートだと言えるでしょう。

この機能が特に効果を発揮するのは、初期導入プロジェクトの後に、月額・年額の定額費用が継続的に発生するような契約形態です。たとえば、導入プロジェクトが完了した後、運用保守費用や継続支援費用をサブスクリプションとして請求するケースでは、「プロジェクトとして管理したい情報」と「定期請求として扱いたい金額」が同時に存在します。project fee journalsがサブスクリプション請求を前提に扱えるようになることで、定額料金をプロジェクト文脈の中で正しく計上・管理しやすくなり、請求処理とプロジェクト管理の分断を減らせます。

2025wave2までのProjectOperationsでは、プロジェクト費用の仕訳は主にプロジェクト単位・イベント単位での請求を想定しており、サブスクリプションのように「同じ内容を一定周期で繰り返す」モデルとの親和性は高いとは言えませんでした。そのため、定額請求部分はFinance側で別管理したり、擬似的にプロジェクトを分けて対応したりといった工夫が必要になることもありました。この運用では、プロジェクト実績と継続収益の関係を一貫して把握しにくいという課題が残っていました。

2026wave1では、project fee journalsがサブスクリプション請求をサポートすることで、このギャップが緩和されます。定期的に発生するプロジェクト費用を、サブスクリプション契約の前提で仕訳・管理できるようになり、プロジェクト型の活動と継続課金モデルを同じ枠組みで扱いやすくなります。これにより、「プロジェクトとして何を提供しているのか」と「そこからどのように継続収益が生まれているのか」を、ひと続きの流れとして捉えられるようになります。プロジェクトとサブスクリプションの境界を滑らかにつなぐ改善だと言えるでしょう。

一方で、留意点もあります。project fee journalsがサブスクリプションに対応することで、費用や収益の扱いが柔軟になる分、「どこまでをプロジェクト費用として扱い、どこからを純粋なサブスクリプション収益とみなすのか」という整理が重要になります。また、定期請求である以上、契約期間、更新、解約といったライフサイクル管理との整合も欠かせません。この機能はサブスクリプション管理を自動化するものではなく、プロジェクト管理と定期請求を同じ言語で扱えるようにするための基盤です。

Enable project fee journals to support subscription billingは、ProjectOperationsを「単発プロジェクト管理のツール」から、「継続的なサービスビジネスを支える基盤」へと進化させる重要な一歩です。プロジェクト型とサブスクリプション型が融合したビジネスモデルを採用する組織にとって、管理・請求・説明を一貫させるための、実務的で影響範囲の大きいアップデートだと言えるでしょう。

この機能が特に効果を発揮するのは、計画策定と実行管理のツールが分かれている環境です。たとえば、初期計画や顧客向け合意はMicrosoft Projectで作成し、その後の実行管理や実績管理をProjectOperationsで行っている場合、計画変更や詳細化のたびに「どちらが正なのか」という問題が生じがちでした。既存プロジェクトにMPPファイルをインポートできるようになることで、外部で作られた計画をそのまま取り込み、ProjectOperations上のプロジェクト構造に反映できます。これにより、計画と実行の分断を減らし、計画資産を無駄にしない運用が可能になります。

2025wave2までのProjectOperationsでは、MPPファイルの取り込みは主に「新規プロジェクト作成」の文脈で使われることが多く、すでに存在するプロジェクトに対して計画を統合するには制約がありました。そのため、既存プロジェクトを作り直したり、計画部分だけを手作業で転記したりといった回避策が必要になることもありました。この運用では、プロジェクトIDや契約、実績との紐づきが切れてしまい、管理の一貫性を保つのが難しくなるケースもありました。

2026wave1では、MPPファイルを既存プロジェクトにインポートできるようになることで、この前提が大きく変わります。すでに存在するプロジェクトの枠組みや契約、実績を維持したまま、計画部分だけを更新・統合できるため、「計画はProject、管理はProjectOperations」といった役割分担を現実的に成立させやすくなります。これは単なるインポート機能の拡張ではなく、プロジェクト計画を“外部で作られた参考情報”ではなく、“正式な計画ソース”として扱えるようにする改善です。

一方で、留意点もあります。MPPファイルを既存プロジェクトに取り込む場合、どの情報を上書きし、どの情報を維持するのかを明確にしておかないと、意図しない計画変更が発生するリスクがあります。タスク構造、期間、依存関係、進捗率などが既存データとどう統合されるのかを理解したうえで使うことが重要です。また、MPP側とProjectOperations側で計画の更新が並行して行われると、どちらが正なのか分からなくなる可能性もあります。この機能は計画管理を自動的に統合してくれるものではなく、「計画を取り込むための正式な入口」を提供するものです。

Import projects in MPP files into existing projectsは、ProjectOperationsを“計画も含めた統合基盤”として使うための重要な機能です。既存の計画資産を活かしながら、実行・実績・請求までを一貫して管理したい組織にとって、計画移行のハードルを大きく下げる、実務的で影響範囲の広いアップデートだと言えるでしょう。

この機能が特に効果を発揮するのは、計画品質が高く、再利用価値の高いスケジュールを多く持つ組織です。たとえば、地域展開プロジェクトや製品導入プロジェクトのように、タスク構造や依存関係、期間設計がほぼ共通している案件では、外部スケジューラで作られた計画そのものが大きな資産になります。Copy externally scheduled projectsを使えば、その資産を活かしたまま新しいプロジェクトを立ち上げることができ、計画の再現性と立ち上げスピードを両立できます。結果として、「前回うまくいった計画」をそのまま次に活かすことが容易になります。

2025wave2までのProjectOperationsでは、外部スケジュールを使ったプロジェクトは存在していても、その再利用は必ずしもスムーズではありませんでした。外部ツール側でコピーしたり、MPPファイルとしてエクスポート・インポートしたり、あるいは内部プロジェクトとして再構築したりと、いくつかの回避策はありましたが、いずれも手順が多く、プロジェクト文脈や関連情報を引きずらないよう注意が必要でした。そのため、外部スケジュールを「再利用前提」で扱うことに心理的なハードルがあったと言えます。

2026wave1では、外部スケジュールを持つプロジェクト自体を、ProjectOperations上で自然にコピーできるようになることで、この前提が変わります。外部スケジューラで定義されたタスク構造やスケジュールの考え方を保ったまま、新しいプロジェクトとして再利用できるため、計画作成をやり直す必要が減ります。これは単なる時短ではなく、「計画は一度作ったら資産になる」という考え方を、システムとして後押しする改善です。外部スケジュールとProjectOperationsの役割分担を維持したまま、プロジェクトの量産や横展開がしやすくなります。

一方で、留意点もあります。外部スケジュールをコピーできるようになることで、過去の前提や制約を十分に見直さずに新しいプロジェクトを立ち上げてしまうリスクもあります。期間設定、リソース前提、依存関係は、当時の状況に最適化されている可能性があり、コピー後に必ず再確認が必要です。また、外部スケジュール側とProjectOperations側のどちらを“正”とするのか、更新責任をどこに置くのかを整理しておかないと、計画管理が二重化する恐れもあります。この機能は計画を考えなくてよくするものではなく、考えるための出発点を再利用しやすくするためのものです。

Copy externally scheduled projectsは、ProjectOperationsを「実行管理の場」から「計画資産を循環させる基盤」へと進化させる機能です。外部スケジューラで磨かれた計画を、一度限りで終わらせず、組織の知見として蓄積・再利用していきたい組織にとって、非常に実務的で効果の大きいアップデートだと言えるでしょう。

この改善が特に効いてくるのは、予算と実績の関係を頻繁に確認しながらプロジェクトを運営しているケースです。たとえば、プロジェクトマネージャーが進捗会議やレビューの中で、「当初予算に対して今どこまで消化しているのか」「この先の見通しはどうか」を確認したい場合、画面を行き来する必要があると、確認自体が後回しになりがちでした。左ナビゲーションから予算情報に直接アクセスできるようになることで、プロジェクト全体の流れを見ながら、必要なタイミングで予算状況を確認しやすくなります。結果として、予算確認が“特別な作業”ではなく、日常的な判断の一部になります。

2025wave2までのProjectOperationsでは、予算情報は管理できるものの、UI上ではやや奥まった位置にあり、メインフォームとの行き来が必要な場面もありました。そのため、予算は「設定時や問題が起きたときに見るもの」という扱いになりやすく、日々の意思決定の中で自然に参照される情報とは言いづらい側面がありました。情報自体は正しく存在していても、使われ方の面で改善余地が残っていたと言えます。

2026wave1では、予算情報を左ナビゲーションから直接参照できるようにすると同時に、メインフォームの表示や構成が改善され、予算に関する情報をより分かりやすく扱えるようになります。これにより、予算設定、確認、調整といった作業がプロジェクト管理の流れの中で途切れにくくなり、「計画」「実績」「予算」を同じ文脈で捉えやすくなります。単に表示場所を変えるだけでなく、予算を“見に行く情報”から“常に意識される情報”へ引き上げる改善だと言えるでしょう。

一方で、留意点もあります。予算情報にアクセスしやすくなることで、数値の変動に過度に反応してしまうリスクもあります。短期的なブレと本質的な問題をどう見分けるのか、どのタイミングで予算調整を検討するのかといった判断基準は、引き続き運用側で整理する必要があります。また、誰が予算を閲覧し、誰が変更できるのかという権限設計も重要になります。この機能は予算管理を自動化するものではなく、予算を“正しく使う”ための視認性を高めるものです。

View budget information in left nav with improved main formは、予算管理をプロジェクト管理の中心に引き戻す改善です。数字そのものを変えるのではなく、数字との向き合い方を変えることで、プロジェクト判断の質を底上げします。日常的にProjectOperationsを使うプロジェクトマネージャーほど、その効果を実感しやすい、実務寄りで本質的なアップデートだと言えるでしょう。

この機能が特に効果を発揮するのは、長期間にわたる予約や、部分的な変更が頻発するリソース計画です。たとえば、当初は1か月フルアサインの予定だったリソースが、途中から別案件に一部時間を割くことになった場合、従来は予約を一度キャンセルして再登録するか、期間を分割して管理し直す必要がありました。スケジュールボード上で部分キャンセルができるようになることで、「この期間だけ不要」「この一部だけ解放したい」といった調整を、直感的に反映できます。結果として、計画変更に対する心理的・実務的なハードルが下がります。

2025wave2までのProjectOperationsでは、予約のキャンセルは基本的に全体単位で行う前提が強く、部分的な調整は運用で補う必要がありました。期間を細かく分けて予約を作成しておく、変更が出たら一度削除して作り直す、といった方法は成立しますが、調整回数が増えるほど管理が煩雑になります。また、キャンセルと再作成を繰り返すことで、「なぜこの予約構成になっているのか」を後から追いにくくなる問題もありました。計画の柔軟性と可読性の間に、どうしてもトレードオフがあったと言えます。

2026wave1では、スケジュールボードから予約の一部をキャンセルできるようになることで、この前提が変わります。予約全体を壊すことなく、不要になった期間や稼働分だけを解放できるため、計画の履歴や意図を保ったまま調整が可能になります。これは単なる操作性の向上ではなく、「予約は固定されたものではなく、現実に合わせて調整され続けるもの」という考え方を、システムとして自然に支える改善です。リソース計画が、より現場の動きに追従しやすくなります。

一方で、留意点もあります。部分キャンセルができるようになることで、予約構成がより柔軟になる反面、計画の読み取りには一定の理解が必要になります。どの期間が有効で、どの期間がキャンセルされたのかを、チーム内で正しく共有しないと、誤解が生じる可能性もあります。また、頻繁な部分調整が前提になると、計画自体が短期的な最適化に引っ張られやすくなるリスクもあります。この機能は計画を流動的にするためのものではなく、現実に合わせて丁寧に調整する余地を与えるものです。どのレベルの変更を許容するのか、どのタイミングで見直すのかといった運用ルールと組み合わせることが重要です。

View partial cancellation of bookings from schedule boardは、リソース計画を「一度決めたら固定するもの」から、「前提を保ちながら調整できるもの」へと進化させる機能です。計画を壊さずに直せる、という安心感は、リソース管理の実務において非常に大きな意味を持ちます。調整のたびに作り直す必要がなくなることで、計画の質と現実対応力の両立を支える、実務に即したアップデートだと言えるでしょう。

この機能が特に効果を発揮するのは、同じ条件で複数のリソースを扱うケースや、計画変更が一括で発生する場面です。たとえば、特定期間のプロジェクトが延期になり、複数人の予約をまとめて後ろ倒ししたい場合、従来は一件ずつ選択して修正する必要がありました。bulk operationsを使えば、スケジュールボード上で複数の予約を選択し、同じ操作を一括で適用できるため、調整作業の時間とミスのリスクを大きく減らせます。結果として、「変更すること」そのものが負担になりにくくなります。

2025wave2までのProjectOperationsでは、スケジュールボードは視覚的に分かりやすい一方、操作の単位は基本的に個別予約が前提でした。そのため、予約数が増えるほど、調整作業は繰り返しになり、作業時間が伸びやすい構造でした。また、同じ変更を複数の予約に適用する場合でも、人が同じ操作を何度も行う必要があり、入力漏れや不整合が生じる可能性もありました。計画を柔軟に保つほど、運用負荷が増えるというジレンマがあったと言えます。

2026wave1では、スケジュールボード上で複数の予約をまとめて操作できるようになることで、この前提が変わります。予約の移動、更新、キャンセルなどを一括で行えるため、リソース計画の変更が“特別な作業”ではなくなります。これは単なる操作効率の向上ではなく、「計画はまとめて見直すもの」という実務感覚をシステム側が受け止めた改善です。結果として、リソース計画をより頻繁に、より正確に更新しやすくなります。

一方で、留意点もあります。bulk操作は便利である分、影響範囲も大きくなります。どの予約が対象になっているのかを十分に確認せずに操作すると、意図しない変更を一度に反映してしまうリスクがあります。また、誰がbulk操作を行えるのか、どのレベルの変更を許可するのかといった権限設計や運用ルールを整理しておかないと、計画が不安定になる可能性もあります。この機能は計画変更を軽くするものではなく、「まとめて正しく直せる」ようにするためのものです。

Perform bulk operations for bookings on schedule boardは、リソース計画を“個別管理の積み重ね”から“全体調整を前提とした管理”へと進化させる機能です。計画変更が多い現実を否定せず、その前提で扱いやすくすることで、スケジュールボードを「見るための画面」から「調整の主戦場」へと引き上げます。リソース管理を日常業務として回している組織ほど、その効果を実感しやすい、実務直結のアップデートだと言えるでしょう。

「Project Operationsは、これから何者になろうとしているのか？」

今回のwave 1には、分かりやすいAIの前面展開や、派手なUI刷新はほとんど見当たりません。その代わりに並んでいるのは、修正仕訳、見越、収益認識、契約変更、外注請求、予算、リソース計画──どれも現場で“必ず揉める”“必ず歪みが出る”領域ばかりです。しかもそれらは、単体機能として強化されているのではなく、Finance・調達・リソース・請求と一気通貫で成立する前提で再設計されているように見えます。

ここから読み取れるのは、Project Operationsが「プロジェクト管理を便利にするアプリ」であることを、意図的に卒業しようとしている姿です。代わりに向かっているのは、プロジェクト型ビジネスを“会社として回す”ための業務基盤という立ち位置でしょう。

これまでのProject Operationsは、良くも悪くも「プロジェクトマネージャーのためのツール」でした。計画、実績、請求─それぞれは揃っていても、Financeや経営管理の視点から見ると、「最後はExcelで説明が必要」「会計側での再解釈が前提」という場面も少なくなかったはずです。

しかし2026 wave 1で強く感じるのは、「プロジェクトは例外ではない」「プロジェクトも会計・調達・契約の文脈で正しく扱う」という、かなり覚悟の決まった方向転換です。

見越や修正を“例外処理”として片付けるのではなく、Change Orderを“現場判断”ではなく正式な業務プロセスとして扱い、リソースや在庫、外注を“後追い”ではなく計画の一部として組み込む。

それはつまり、「プロジェクトは複雑だから仕方ない」という言い訳を、システム側が許さなくなってきている、ということでもあります。

もちろん、これらの機能を有効にしただけで、プロジェクト運営が自動的にうまくいくわけではありません。むしろ、運用ルールや役割分担、データ整備が曖昧な組織ほど、Project Operationsの“正しさ”が重く感じられる可能性すらあります。

ですがそれでも、今回のwave 1は明確です。Project Operationsは、「使う人が頑張って辻褄を合わせるツール」から、「辻褄が合わない運用を許さない基盤」へと、静かに舵を切っています。

派手さはありません。けれど、プロジェクト型ビジネスを本気でスケールさせたい企業にとっては、これ以上なく“正しい進化”だと、室長は感じています。

D365 Project Operationsよ。君は今、ようやく“基幹業務アプリ”になろうとしているんだね。

Commerceと聞くと、「店舗」「EC」「POS」といった文脈を思い浮かべる方が多いかもしれません。しかし、ここ数リリースの流れを見ていると、Commerceもまた単なる販売チャネル管理ではなく、“顧客との接点をどう設計するか”という業務基盤へと進化を続けています。

特に近年は、

• CopilotやAIが介在する接客・オペレーションの変化
• オンライン／オフラインの境界が溶けていく体験設計
• 価格、在庫、注文、顧客データを“分断させない”設計思想

といったテーマが、静かに、しかし確実に積み重ねられてきました。

Project Operationsが「プロジェクト型ビジネスの基盤」へ進化しつつある今、Commerceは「顧客接点ビジネスの基盤」として、どこまで踏み込もうとしているのか。

次回も、いつものように室長の勝手な解釈で、Dynamics 365 Commerce 2026 wave 1を読み解いていきたいと思います。

引き続き、お付き合いいただけましたら幸いです。