解決方法が求められている場合: ホワイト ペーパー

このホワイト ペーパーは、「From the trenches」コレクションの一部です。ここでは、プロジェクトのスケジュールを設定するときに発生するいくつかの一般的な問題を取り上げます。プロジェクトのスケジュールを最適化するために、どれだけの数のタスクを設定し、どれだけの時間をかけるかを判断しようとするときの最適なアプローチを提案します。さまざまなスケジュール (ソフトウェア開発、EPM (エンジニアリング、調達、建設工事)、施設の一時操業停止など) が、異なる業界で通常、どのように必要とされているかについて説明します。また、プロジェクトの解決法を選択するときの複数の要因 (プロジェクトの長さ、関与するリソース、リソースの管理または分配、データの収集に必要な速度と労力、データの更新スケジュールなど) も取り上げます。

このホワイト ペーパーの Word 版をダウンロードするには、「解決法が必要だと人は言う (Project Server 2010)」を参照してください。

その他のホワイト ペーパーについては、「From the Trenches」のホワイト ペーパーを参照してください。

解決法が必要だと人は言う

ビートルズをもじったタイトルで申し訳ありませんが、今日のトピックは、プロジェクトの解決法です。

スケジュールを作成する方法について参考にできる資料は数多くありますが、最も重要なレッスンの 1 つは簡単に得られるものではありません。そのレッスンとは、プロジェクトのスケジュールでどれだけのタスクを設定し、それぞれのタスクにどれだけの時間をかけるべきかということです。

日頃から、途方もなく複雑に見えるプロジェクト スケジュールをよく見かけます。また、スケジュールが概要レベルであるために、問題点を特定できずに困っているプロジェクト マネージャーにも、よく出会います。100 年以上にわたるプロジェクト (実際そうです) がありましたが、その期間は完全に適切でしたし、その中には数十年の期間にわたるタスクが含まれていました。また、1 時間以内で終わるプロジェクト スケジュールもありましたが、その期間も完全に適切で、その中にはわずか 1 分で終わるタスクが含まれていました。ほんの一握りのタスクしかないプロジェクトもありましたし、100,000 個以上のタスクを含むプロジェクトもありました。

現在使用しているソフトウェアは、数千個のタスクを処理でき、さまざまな期間に対応できます。

では、正しいアプローチとはどのようなものでしょうか。

プロジェクト スケジュールを最適化するには、タスクにどれだけの時間をかけ、どれだけのタスクを設定すべきでしょうか。これをプロジェクトの解決法と呼びましょう。

十人十色

業界、プロジェクトの種類、状況が異なれば要件も異なるので、どれだけのタスクをスケジュールに含め、タスクにどれだけの時間をかけるべきかを特定する方法を見ていきましょう。

プロジェクトの種類が異なれば、当然ながら必要になるスケジュールの種類も異なります。次の別々の 3 つの例を考えてみましょう。

  1. ソフトウェア開発   。多くのソフトウェア プロジェクトには共通の特性があります。すべてのソフトウェア プロジェクトは独特ですが、一般に、設計フェーズ、プログラミング フェーズ、品質保証フェーズ、ドキュメント フェーズ、展開フェーズがあります。ソフトウェア プロジェクトは通常、数週間または数か月と見積もられ、期間が 1 日から数週間のタスクに適しています。このときのリソース割り当ては、多くの場合、個々のレベルに対して割り当てられます。

    ソフトウェア開発にアジャイル プロセスを採用してきた人々は、1、2 週間の「短距離走」に関心があり、その中に短期間のタスクを含めていますが、全体のプロジェクト期間は、やはり数週間と見積もられています。アジャイル開発については、後で少し説明します。

    アジャイル スプリントのガント チャート ビュー
  2. EPC – 設計、調達、建設   。EPC プロジェクトはクリティカル パス スケジューリング方法が始められたプロジェクトです。この種のプロジェクトでは、非常に大きなものが開発されます。PERT ダイアグラムを生み出したポラリス ミサイル プロジェクトのような大規模な防衛プロジェクトの場合も、海底油田掘削装置、新造船、発電所などの場合もあります。この種のプロジェクトでは、終了したプロジェクトの姿を予想するエンジニアリング フェーズがあります。エンジニアリング フェーズには、通常、これまで設計されていなかった側面を含めます。調達フェーズでは、プロジェクトの要素について供給物の配送や下請け業者を探したり、契約したり、管理したりします。建設フェーズでは、最終製品を構築して、運用します。通常、EPC プロジェクト スケジュールといえば、数か月から数年にわたるもので、そのどの時点でもアクティビティの継続期間が数週間から数か月続くものが思い浮かびます。このようなプロジェクトでは、5,000 ~ 20,000 個のタスクがあることもまったく珍しくありません。このときのリソース スケジュール設定は、ほぼ常に、個人ではなくスキル レベルに割り当てられ、管理しやすくするために、プログラムまたはマスター プロジェクトに多くの下位プロジェクトが存在することもあります。

    複数のプロジェクトとサブプロジェクトのガント チャート ビュー
  3. 施設の一時操業停止   。メンテナンスのために施設を一時操業停止させて修復するプロジェクト スケジュールを設定する場合、最も厳しいスケジュール設定環境の 1 つでの作業になります。メンテナンスを行うための施設の一時操業停止には計画停止と緊急停止の 2 種類があります。緊急停止の種類についてはしばらく置いておきましょう。独自に扱う必要があります。施設の計画的な一時操業停止の期間は、施設の種類に大きく左右されます。たとえば、原子力発電所では「短期」の施設一時操業停止および修復に 12 か月かかることがあります。精油所では 4 ~ 6 週間続きます。ただし、最も興味深い施設プロジェクト スケジュールの種類は、製鋼所や製紙工場などの製造所です。世界中にこのような施設が数千または数万箇所存在し、年に 1 回程の定期的なメンテナンスを受ける必要があります。

    このような状況の一時操業停止のコストは、通常、機会コスト、つまり施設が休止しメンテナンスを受けている間に製造されない製品のコストで見積もられます。このコストは時間で測定され、時間あたり ¥15,000,000 ~ ¥25,000,000 以上になることもあります。このためジョブを完了させなければならないというプレッシャーは、分刻みでのしかかります。このような状況では、一時操業停止は通常 5 ~ 8 日続き、1 日の遅れは数億円単位で計算されます。従来からの、より期間の長いスケジュールにしか慣れていない場合、2 ~ 3 日という短期間に「通常、どれだけのタスクを含められるのか」と思うかもしれませんが、このような一時操業停止では、それぞれ 15 分から 2、3 時間のタスクが 2,000 ~ 4,000 個存在することがまったく珍しくありません。このときのリソース割り当てはスキル別に行われますが、従業員にリソースの平準化が行われることはまれです。1 時間あたりのコストが非常に高いので、プロジェクトに配置する人員を増やすかどうかは重要ではなく、ただ急いで済ませることだけが重要になります。この状況でのリソースの平準化は、多くの場合、非常に制約されたボトルネックのために行われます。たとえば、「電気室に 2 人しか配置できないので、個別に管理する必要がある」という場合です。

    連続作業のガント チャート ビュー

さて、これで 3 種類の例を示しました。これ以外にも多くの例はありますが、ここで説明するには、これらの 3 つで十分です。タイプ 1 (ソフトウェア開発) には、通常、1、2 日から 2 週間かかるタスクが含まれます。タイプ 2 (EPC) には、数週間から数か月かかるタスクが含まれます。タイプ 3 (施設の一時操業停止) では、6 分単位 (1 時間の 1/10)、10 分単位、15 分単位 (1 時間の 1/4) で測定され、最高 2、3 時間かかるタスクが含まれます。ある場合には短時間のタスクが有効であり、他の場合には長時間のタスクが適切であることは明らかです。 同じ論理に従えば、非常に多数のタスクを設定することが有効な場合も、有効でない場合もあるということになります。

プロジェクトの解決法を選択するための要因

このように 3 つに区別すると、2 か月の EPC プロジェクト タスクは、6 日の一時操業停止スケジュールにはばかげており、15 分のタスクが EPC やソフトウェア プロジェクトには不適切であることが簡単にわかります。ただし、この記事を参照して「Vandersluis が、これはソフトウェア プロジェクトであり、タスクには 1 ~ 10 日しかかからないと言っている」という場合は別ですが (どうかこのようにしないでください)、プロジェクトの特性によって、どのレベルの解決法を選択すればよいかがわかります。いくつかの明らかな特性を見ていきましょう。

プロジェクトの期間はどれだけか?

最も明らかなものから始めましょう。一時操業停止の例のようにプロジェクトの期間が 2、3 日と予想される場合、5、6 日かかるタスクを設定することはまったく意味がありません。適用範囲を細分することを考えると、トップダウン アプローチから始めれば、多くの場合で生産的になります。作業分割構造の考え方を使用して、主要コンポーネントから開始します。含める項目は 4 つ以上、20 個以下にすると考えてください。

これはルールでしょうか。もちろん違います。

これは常識です。4 つ未満の場合、作業を分割した理由がわからなくなり、20 個を超えると、一度に覚えることが非常に困難になります。個人的には、WBS 要素あたり 8 項目以下にすることをお勧めします。それは数年前の記事で、単純な図形の中で八角形が即座に頭で認識できる最も複雑なものだと記されていたからです。

この点について少し検討してみましょう。円、三角形、四角形、五角形、六角形 (6 つの辺)、七角形 (7 つの辺を持ち、思い浮かべるには困難な形)、八角形を識別できます。

9 つの辺の形を数えずに識別できるでしょうか。自分にはできません。もちろんこれは「九角形」です。

したがって、個人的には 8 つの項目に抑えようと努めていますが、経験則では 4 ~ 20 個になります。

確認した要素ごとに、どのように作業を分割すべきかを考えます。繰り返しになりますが、4 ~ 20 個のルールを考慮してください。ただし、いつ停止するかは秘密です。経験が浅いプロジェクト マネージャーほど、すべてのステップが管理タスクになるまで分割を繰り返します。タスクの期間について自問するのに適している重大な質問は、次のとおりです。

  • このタスクが遅れた場合、どのアクションを行うか?    この回答が「ない」であれば、対象のタスクが非常に小さくて管理するほどではないことを示しています。もしそうであれば、詳しく調べすぎています。レベルを戻し、一歩退いて、完了しているかどうかを確認してください。

  • このタスクの更新に関するデータの収集にかかる時間は、タスク自体よりも長くなるか?    スケジュールされたタスクの管理にどのような取り組みが必要であるかを常に考えているわけではありませんが、少しの間でも考えてみる価値はあります。タスクの完了よりもタスクの管理により多くの労力が必要になる場合、タスクが詳しすぎるレベルで定義されていることを示しています。

  • このタスクにはどれだけの時間がかかるか?    作業を細分していると、作業が非常に微細になっているかがわからなくなることがあります。最も高いレベルの大きなフェーズはおそらく数週間の期間でしたが、細分のレベルを 2 つ、3 つ下げると、わずか 2、3 分のタスクを管理対象として定義しているという罠に陥りがちです。非常に小さいタスクになった場合は、そのようなタスクを管理してどのような利点があるのかを考える必要があります。

今話した内容の真偽を確認しましょう。2 年間の EPC プロジェクトで、1 週間のタスクが 1 日遅れた場合、まず間違いなく措置を講じる価値はありません。6 か月のソフトウェア プロジェクトで、1 週間のタスクが 1 日遅れても、おそらく措置を講じる価値はありません。6 日の一時操業停止プロジェクトで、1 週間のタスクが 1 日遅れた場合、緊急度は非常に高くなります。つまり、1 週間のタスクは、EPC プロジェクトでは詳細のレベルが細かすぎる可能性があり、ソフトウェア プロジェクトでは、おそらく適切なレベルであり、一時操業停止プロジェクトではまず間違いなく、さらに細分する必要があります。

関与するリソースはどれだけか?

適用範囲で作業していることがわかっていますが、どの種の解決法が必要かを調べるときに、どれだけの人員がタスクに取り組むことになるかを考えると役立ちます。たとえば大規模な EPC プロジェクトでは、1 つのスキルの作業員が数十人、作業のあるフェーズに関わっていることがあります。ただし、最終的には同一のタスクで多くの異なるスキルが必要になり、そのタスクの管理は、不可能でなくても非常に困難になります。したがって、この場合、多くの異なるスキルを必要とするタスクは、おそらく分割する必要があります。

ソフトウェア プロジェクトでは、ほとんどすべての個人を、独特の機能を持った非常に技術性の高いリソースと見なす傾向があります。さらに、ソフトウェア プロジェクトでは通常、部門内で再割り当てできる多くのタスクが存在しますが、1 人の人員には 1 つのタスクだけが割り当てられます。したがって、人員が 1 人の特定のリソース グループまたは部門に割り当てられるタスク (たとえばインターフェイス プログラミング) がある場合、これ以上の詳細は必要ないといえます。

リソースをどのように管理または細分するか?

リソースの管理方法は、タスクを細分する方法を決める大きな要素になります。たとえば、大規模な EPC プロジェクトでは、多くの場合、大規模な下請け業者に分配されるサブプロジェクトに分割されます。この状況では、次のいくつかの作業を行う必要があります。

  • プロジェクト マネージャーが、進捗状況が大きな要因であると確信して下請け業者を監視できるように、作業を定義する。

  • 下請け業者のプロジェクト管理およびエンジニアリング スタッフが、曖昧さを残さずその意味を理解できるように、タスクを定義する。

  • 標準として採用した解決法のレベルを、下請け業者が理解し、同意していることを確認する。

ソフトウェア、生物学的調査、エンジニアリングなどのホワイトカラー プロジェクトを調べてみると、マトリックス管理構造に出会う可能性が高く、この構造では、プロジェクト マネージャーはリソースを所有せず、多くのさまざまなプロジェクトにわたってこれらのリソースを割り当てる部門マネージャーを通じて作業する必要があります。この場合、主要な質問は次のようになります。

  • 1 日に、1 人のリソースはどれだけのプロジェクトを処理すると思われますか?

  • 従業員がプロジェクトを切り替えるのにどれだけの時間がかかりますか?

  • 従業員とリソース部門マネージャーの両方が正しいスキルの割り当て方法を理解できるように、作業が定義されていますか?

一時操業停止または建設プロジェクトでは、特別な目的に向けて構築されたグループで作業する傾向があります。このような場合、リソース チームのリーダーが、電気関係チーム (そのチームに大工作業員や配管工員が含まれる場合も含む)、給排水チーム、ボイラー装置修繕チームを管理していることがあります。グループが勤務時間の間、暇ができないように、また既にその領域の何かに携わっている別のグループに加えないように作業を編成する必要があります。一時操業停止プロジェクトを完了させるという強力なプレッシャーを考えると、作業は多くの場合、最初に作業別に編成され、スケジュール設定され、続いてリソース チームのリーダーによって再グループ化および細分されるので、各チーム リーダーは 1 つのドキュメントに自身のタスクだけを、別のドキュメントに文脈を考慮したプロジェクト全体を持ち歩くことができます。したがって、タスクは、従業員とリソース チームのリーダーが理解できるように定義されている必要があります。ここでのタスクはおそらく時間単位にまで定義されるか、時間の 1/10 または 1/4 にまで細かく定義されます。

どれだけすばやくデータを収集し、どれだけの労力を費やすことができるか?

週末には、レビューできるようにすべてきちんと並べられたプロジェクト データを見慣れているときには、これはばかげた質問のように聞こえますが、プロジェクトの解決法のレベルを判断しようとするときには、これは重要な質問になり得ます。たとえば、多数の下請け業者を通じて作業している場合、毎週または毎月、何らかの更新を行う可能性があります。実際、プロジェクト管理の更新条項を契約に組み込むことは欠かせません。この状況では、これらのさまざまな企業からのデータを独自のデータと統合して、進捗状況データが納得のいくことを検証し、独自の分析およびレポート作成を行う必要があります。EPC モードでは、これはおそらく毎月実施します。

一時操業停止プロジェクトでは、勤務時間ごとにプロジェクトを迅速に更新して、次の勤務時間の最中にリソース チームのリーダーに伝える必要があります。この状況では、プロジェクト要員は、勤務時間中ずっと施設全体を飛び回り、できるだけリアルタイムでデータを収集します。リソース チームのリーダーおよび現場主任には、「書き付け」シートを使用して、職務の進捗状況を「書き付け」させます。ソフトウェア プロジェクトやリサーチ プロジェクトでは、おそらく毎週またはそれに準じたスケジュールで個々の作業の進捗状況をレポートさせ、一両日中に承認します。

データの収集にはコストがかかるため、これは、どれだけのタスクがプロジェクトに必要かを調べるときに考慮すべき重要なポイントです。

したがって、どれだけ迅速にデータを周期的に収集、承認、統合、分析、レポートできるかについて考えることが、データの収集のコストおよびそのデータの収集の投資収益率の考慮と同様に重要になります。

どれだけの頻度で更新するのか?

どれだけのデータを収集でき、含められるかを判断するには、次の 2 つが重要です。

  • データを収集する方法について考える。

  • どのような頻度でプロジェクトを適度に更新できるか、また、プロジェクトとリソースを正しい方向に導くために必要な意思決定ツールを使用した管理を提供できるかについて考える。

これまで、「リアルタイム」のプロジェクト管理およびプロジェクト収集に移行することを主張するプロジェクト マネージャー達もいました、これは理論上可能かもしれませんが、実際に実現することは非常に困難です。

プロジェクト管理データを検討する場合、何らかの想定を行っていますが、ここでは次のような想定を行っています。

  • データはすべて揃っている   。見ているタスクの一部は更新済みで、その他のタスクは更新されていないという状況は想定していません。

  • データはすべて同時期に更新された   。タスクの半分が数分前に更新されたが、残りの半分は 2 週間更新されていないという状況は想定していません。

  • データはすべて何らかのレベルの承認を受けた   。プロジェクト マネージャーが、表示されているデータを支持し、「これはプロジェクトを公正で正確に表している」と言えることを想定しています。

  • データは互いに   。コストやリソースでリスクが曖昧になるようにレポートと分析を特別に設計しているのでない限り、そのようになることを想定していません。

リアルタイムのプロジェクト管理の概念に熱心な経営者に、これまでに挙げたポイントを克服できれば何を行うかをよく尋ねます。「1 週間毎日管理上の意思決定を行う用意はできていますか」という質問です。その回答は、解決法のレベルに応じて異なります。一時操業停止プロジェクトでは、回答は「はい」であるほうがいいでしょう。ソフトウェア プロジェクトでは、回答はおそらく「いいえ、それは週に 1 度行います」になるでしょうし、EPC プロジェクトでは回答は「月に 1 度」になるでしょう。

収益逓減の法則により、ある時点で「プロジェクト レポートの配信速度を上げても、効率性が高まらない」ようになります。

作業のレビュー

ここまで、考察の材料が得て、作業配分方法を使用してデータを細分し、データの定義が細か過ぎるときの兆候をいくつかみてきました。次に、スケジュールを壁に立てかけ、いろいろな視点からプロジェクトを眺めてみましょう。驚くべきことに、多くのプロジェクト マネージャーはこの作業を行っていません。最後の細部の定義に関わり過ぎ、タスクを何度も細分することに非常に忙しいので、立ち上げ期限直前まで取り組んで、作り上げてきたものが管理しにくくなるかどうかをまったく調べないのです。

MBA トレーニングだけから「詳細なほどよい」と確信している経営者もおり、6 か月のプロジェクトで 5 分か 15 分のタスクを推進しているのです。

開始する前のプロジェクト変更は、常に、開始後のどの時点よりも簡単なので、必要に応じて、スケジュールを修正する時間をスケジュール構築アクティビティに組み入れてください。

多すぎるか?

プロジェクト マネージャーは、作成してきたものの適用範囲を見て、詳細のレベルが細かすぎることに気がつくことがあります。その場合、明らかに修正する必要があります。大量の作業になる可能性はありますが、レベルを繰り上げることでスケジュールがよりシンプルになり、後から、その修正を行った甲斐があったと思えるでしょう。

事態はそれほど簡単ではないこともあります。場合によっては、スケジュール全体が組み立てられるまでどれだけ複雑かをプロジェクト マネージャーが確認できないこともあります。複雑なプロジェクトは、その性質のためによりリスクが高く、今日の経済におけるリスクがプロジェクトの重要な選択要因になります。このような複雑なプロジェクトが始まる前に、検討したほうがよい複数の質問を次に示します。

  • 細かくして実行できるのか?    リスクの高いプロジェクトの中には、容易に処理できる小さなサイズに細分できるものもあり、プロジェクトが小さくなればリスクも低下します。ただし、この方針を採用する場合、それぞれの個別のプロジェクトは、完了したときに独自の価値を持っている必要があります。

  • 適用範囲を再考する必要があるのか?    場合によっては、最初に作業の設計者までさかのぼって、スケジュールの明白な複雑さについて説明し、作業を書き換えられるかどうかを確認するという方法が最も単純な処置になります。この方法は、再考が行われなければ生じる機会もなかった革新的な思考に導くことがあります。

そもそもそれを行う必要があるのか?

プロジェクトの中にはそうなるはずではなかったものもあり、最も費用をかけずに取り消すタイミングは、これらを開始する前の日です。プロジェクトのリスクが今になって明らかになった場合、後からではなく、今、認識したほうが適切です。スケジュールの実施結果をプロジェクト ポートフォリオ管理 (PPM) プロセスにフィードバックするときに、より複雑なプロジェクトのリスクによって、投資収益率のスケールで作業のスコアが非常に悪くなっていることがわかることもあります。

アジャイル プロジェクトについて

アジャイル プロジェクト管理に少し触れると約束しましたが、もしアジャイルの支持者でこの文書を長々と読んでくださったのであれば、その忍耐力には頭が下がります。アジャイル手法を通じたソフトウェア プロジェクト管理は哲学のようなものですが、大規模なソフトウェア開発プロジェクトの失敗でやけどを負った人々の間で評価が高くなっている哲学です。

アジャイル ソフトウェア開発の世界では、プロジェクトを簡単に処理できる 1 ~ 3 週間の「短距離走」に分割しようと試みます。それぞれのミニ プロジェクトの目標は、最終的に使用可能なコードをもたらすことです。この場合、いくつかのかなりよく知られた制約内で作業することになるので、解決法のレベルは非常に限られたものになります。

1 ~ 3 週間の期間があり、リソースは利用な状況で、作業を各リソースに割り当てるとします。この構造で定義できる可能なタスクの数は限られており、このことは適切なレベルの解決法の維持に役立ちます。つまり、非常に短時間のタスクを定義すると、アジャイルで問題が生じることがあります。「フィールド 1 の定義: 10 分、フィールド 2 の定義: 10 分、フィールド 3 の定義: 10 分」などは一般的ではありません。

アジャイルは、社内使用のソフトウェアを作成する企業開発環境向けに設計されたもので、使用範囲が商用ソフトウェア開発に及ぶことも多くなっています (HMS では自社の TimeControl の開発に、この方法を使用しています)。アジャイル手法では、開発部門の機動性と迅速性が高まりますが、すべての業界やすべてのソフトウェア企業に適用できるわけではありません。ソフトウェア環境でプロジェクト管理を行っている場合、アジャイルについて研究し、そこから学習し、続いて最も効果を高める要素 (すべて、一部、またはなし) を採用することをお勧めします。

まとめ

プロジェクト管理のほとんどの側面と同様に、最初は非常に明らかであるように見える質問に対して決まった回答はありません。プロジェクト内のタスクの数とそれぞれのタスクに必要になる時間は、自身で決定するために調べる必要のある要素です。

解決法のプロジェクト レベルの選択は、プロジェクト管理の責務の 1 つであり、プロジェクト スケジュールの管理において重要な成功要因になり得ます。

著者について

Chris Vandersluis 氏は、カナダのモントリオールに拠点を置き、Microsoft 認定パートナーである HMS Software 社の社長であり創業者です。マギル大学で経済学の学士を取得し、プロジェクト制御システムの自動化に 30 年以上携わってきました。PMI (プロジェクト マネジメント協会) の古くからの会員であり、MPUG (Microsoft Project Users Group) のモントリオール、トロント、ケベックの支部の設立を支援しました。Vandersluis 氏が寄稿した出版物には、Fortune、Heavy Construction News、Computing Canada magazine、および PMI の PMNetwork などがあり、Project Times のレギュラー コラムニストです。マギル大学で上級プロジェクト管理を教えており、北米および世界中のプロジェクト管理団体の会合で頻繁に講演しています。HMS Software 社は TimeControl プロジェクト指向型の時間管理システムの発行元であり、1995 年から Microsoft Project ソリューション パートナー企業です。

Chris Vandersluis 氏のメールの連絡先は chris.vandersluis@hms.ca です。

Chris Vandersluis 氏の EPM 関連のその他の記事については、HMS 社の EPM ガイダンスのサイト (http://www.epmguidance.com/?page_id=39) を参照してください。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×