マイルストーンとは？意味・役割・設定方法と、実務で機能させる運用ポイントを解説

会議で「マイルストーン」という言葉を聞くものの、意味を自分の言葉で説明できないと感じたことはありませんか。

本記事では、マイルストーンの基本的な意味から、プロジェクト管理における役割、設定方法、そして実務で機能させるための運用設計までを整理します。単なる「節目」としてではなく、進捗・工数・課題を踏まえた判断基準として活用する方法を解説しますので、ぜひ参考にしてください。

マイルストーンの意味とプロジェクト管理での役割

本章では、マイルストーンの基本的な定義と、プロジェクト管理においてどのような役割を担うのかを整理します。マイルストーンは単なる「節目」ではなく、次の意思決定を行うための確認ポイントです。

マイルストーンの定義

マイルストーンとは、プロジェクトにおける重要な到達点を示す管理指標です。進捗率のような割合ではなく、成果物の完了や承認といった客観的事実に紐づく点として設定されます。

例えば、以下のような状態が典型例です。

• 要件定義書が承認された
• 基本設計レビューを通過した
• 結合テストが完了し、品質基準を満たした
• 本番リリースが完了した

重要なのは、「作業が進んだ」ではなく「次工程へ進んで良い状態か」を確認できることです。マイルストーンを設定していない場合、次のような問題が起きやすくなります。

• 進捗率80％だが、承認未了で次工程に進めない
• 成果物は完成しているが、レビュー未実施で品質リスクが残る
• 問題を抱えたまま工程を進めて、後半で手戻りが発生する

マイルストーンは、こうした曖昧さを排除し、プロジェクトの状態を「完了／未完了」で明確化する役割を担います。

ガントチャートとの関係

ガントチャートは、タスクを時間軸で可視化する計画図です。その中でマイルストーンは、「確認・承認・区切り」を示す基準点として機能します。

ガントチャートが「流れ」を示すのに対し、マイルストーンは「止まって確認する点」です。

例えば、

• 設計完了マイルストーンが遅れた場合 → 開発開始も自動的に遅れる
• テスト完了マイルストーンが未達 → リリース延期判断が必要

このように、マイルストーンの配置は、遅延の連鎖を早期に可視化する装置として機能します。不適切な配置（例：単なる中間報告日に設定）では、実質的な管理効果は生まれません。「判断が必要なタイミング」に設定することが重要です。

プロジェクト管理で活用される理由

マイルストーンがプロジェクト管理で活用されるのは、進捗を、曖昧な割合ではなく、成果物の到達可否という明確な基準で判断できるためです。設計承認やテスト完了などの到達点を設定することで、遅延や品質上の問題を早い段階で把握できます。

また、到達していない状態で次工程に進むことを防ぐ判断材料となるため、後半での大きな手戻りや混乱を抑制できるのです。さらに、節目ごとに状況を確認することで、リスクや課題を顕在化させ、関係者間の認識を揃えながら、計画全体を安定的に推進する役割も担います。

マイルストーンと混同しやすい言葉との違い

プロジェクト管理では、スケジュールやタスク、フェーズなど、似た役割を持つ用語が数多くあります。これらを正しく区別できていないと、計画と判断基準が曖昧になり、認識のズレや手戻りを招きかねません。

本章では、マイルストーンと混同しやすい主要な用語との違いを整理し、それぞれの役割を明確にします。言葉の定義を揃えることが、安定したプロジェクト運営の前提です。

スケジュール

スケジュールは、タスクの開始日・終了日・期間・依存関係を含めた時間軸上の計画全体を指します。プロジェクトの流れを示す設計図であり、作業順序や所要期間を可視化する役割を担います。一方、マイルストーンはそのスケジュール内に設定される確認ポイントです。スケジュールが「全体の流れ」を示すのに対し、マイルストーンは「到達確認の点」です。両者を混同すると、計画と判断基準が曖昧になります。

タスク

タスクは、担当者・期限・工数が割り当てられた具体的な作業単位です。設計書作成やテスト実施など、実行可能なアクションが該当します。一方、マイルストーンは個々の作業ではなく、複数タスクの完了によって到達する節目です。タスクは「行動」、マイルストーンは「到達点」という関係にあります。タスクの進捗とマイルストーンの達成を混同すると、成果物未承認のまま次工程へ進むリスクが生じます。

下記記事では、タスク管理の定義からメリット、具体的な進め方までをわかりやすく解説していますので、併せてご覧ください。

合わせて読みたい

タスク管理とは？重要性や進め方・おすすめのツール3選も紹介

タスク管理とは、仕事やプロジェクトが計画どおりに進行するようタスクを管理することです。仕事を進行させるうえで解決しなければならない課題を整理し、優先順位・期限を.....

ベンチマーク

ベンチマークは、業界標準や過去実績などを基準にした比較指標です。品質水準や作業効率を評価するための外部または過去データが該当します。一方、マイルストーンはプロジェクト内部で設定する到達目標です。ベンチマークが「比較の基準」であるのに対し、マイルストーンは「進捗の確認点」です。対象が外部か内部かで区別できます。両者を混同すると、達成評価と目標設定の軸が「ぶれ」ます。

フェーズ

フェーズは、要件定義・設計・開発・テストといった論理的な工程区分を指します。プロジェクトを管理しやすくするための期間的なまとまりです。一方、マイルストーンはフェーズ内または終了時に設定される到達点です。フェーズが「期間のまとまり」であるのに対し、マイルストーンは「その成否を確認する点」となります。フェーズ自体をマイルストーンと誤認すると、完了基準が曖昧になります。

ガントチャート

ガントチャートは、タスクと期間を横棒で示したスケジュールの可視化ツールです。依存関係や進捗状況を一目で把握できます。一方、マイルストーンはガントチャート上にひし形などで表示される確認ポイントです。ガントチャートが「全体構造の図」であるのに対し、マイルストーンは「図中の重要な到達点」です。図と点を混同すると、計画設計と判断基準の役割が不明確になります。

下記記事では、ガントチャートの基本からビジネスでの具体的な活用方法、効果的な作り方までをわかりやすく解説しています。併せてご覧ください。

合わせて読みたい

【無料テンプレート付き】初心者でもわかるWBSの作り方と活用法を徹底解説

プロジェクトを成功させるWBSテンプレート活用法！無料テンプレートのご紹介からWBSの使い方と作成の5ステップを徹底解説。効果的に活用するための注意点も解説しま.....

ロードマップ

ロードマップは、プロジェクトや製品の中長期的な方向性を示す戦略的計画です。主要な目標や大まかな時期を示し、関係者に全体像を共有する役割を持ちます。一方、マイルストーンはロードマップ上の節目として具体的な到達確認に使われます。ロードマップが「戦略の道筋」であるのに対し、マイルストーンは「進捗確認の基準点」です。抽象度の違いで区別できます。

クリティカルパス

クリティカルパスは、最短完了期間を決定するタスクの連鎖経路です。この経路上の遅延はプロジェクト全体の遅延に直結します。一方、マイルストーンはその経路上や重要地点に配置される到達確認点です。クリティカルパスが「遅延に直結する経路」であるのに対し、マイルストーンは「その経路上の監視点」と言えます。経路と点の違いを理解することが重要です。

下記記事では、クリティカルパスの基本的な概要から、具体的な見つけ方までをわかりやすく解説しています。併せてご覧ください。

合わせて読みたい

クリティカルパスとは？仕組みから特定方法、実務での活用ポイントとおすすめツールまで徹底解説

クリティカルパスはプロジェクトの進行に重要な役割があり、プロジェクト全体の進行においてスケジュールを結ぶ作業経路のことを指します。当記事では、クリティカルパスの.....

メルクマール（merkmal）

メルクマールは「特徴」や「特性」を意味し、成果物やプロジェクトの質を評価する指標として用いられる概念です。品質水準や成果の特性を示す広義の評価軸に近い位置づけになります。一方、マイルストーンは進捗管理上の具体的な到達点です。メルクマールが「評価の観点」であるのに対し、マイルストーンは「進行確認の節目」です。目的が品質評価か進捗確認かで区別できます。

マイルストーンを設定するメリット

マイルストーンを設定すると、プロジェクトの状態を客観的に把握できるようになり、判断の質が向上します。本章では、実務上の効果を3つの観点から整理します。

進捗状況を把握しやすい

マイルストーンは、進捗を割合ではなく到達事実で共有できる点に価値があります。「全体の50％程度」ではなく、「設計レビュー承認済み」「テスト完了基準を満たした」といった明確な状態で示せます。これにより、曖昧な自己評価や感覚的な報告を排除でき、関係者間の認識ズレが起こりにくくなるのです。また、到達可否が明確なため、報告資料や会議での説明も簡潔になります。

進捗の見える化は、透明性の高い運営につながる重要な要素です。

問題や遅延に気づきやすい

マイルストーンは、遅延やリスクを表面化させる検知装置として機能します。期日までに到達できない場合、その時点で計画に無理があると判断できます。

例えば、設計完了マイルストーンが未達であれば、見積精度、レビュー体制、リソース配分のいずれに課題があるのかを分析できるのです。終盤で問題が顕在化する場合と比べ、前工程で軌道修正できるため、手戻りや追加コストの抑制につながります。結果として、納期遵守の確度が高まります。

チームの共通認識を持てる

マイルストーンは、次に何を達成すべきかを明確にします。例えば、「来週までにプロトタイプ完成」「今月末までに承認取得」といった到達点を共有することで、優先順位が自然と揃います。また、目標が具体化すれば、タスクの取捨選択やリソース配分の判断が容易になるでしょう。無駄な作業を減らし、集中すべきポイントが明確になります。

また、節目ごとに到達確認を行うことで成功体験を積み重ねやすくなり、長期プロジェクトでも集中力を維持しやすくなります。

マイルストーンの設定方法と具体例

マイルストーンは「とりあえず節目に設定するもの」ではありません。意思決定・承認・工程移行など、止まって確認すべき地点に設けることが基本です。本章では、実務で使える設定の考え方と具体例を整理します。

どこに設定すべきか

マイルストーンを設定すべき場所は、「達成していなければ次に進めない地点」です。単なる作業完了ではなく、判断や承認を伴うタイミングに設定します。具体的には、次のようなポイントが該当します。

• 重要な意思決定が発生する地点（例：設計方針の確定、仕様変更の最終判断）
• 主要成果物の完成・承認時（例：試作品完成、基本設計書承認）
• 外部関係者の確認が入る地点（例：クライアント承認、監査レビュー）
• 後続工程に大きく影響する完了点（例：基幹システム導入完了、API仕様確定）

設定のポイントは、「到達していないとリスクが拡大する地点かどうか」で判断することです。単なる中間報告日をマイルストーンにすると、管理効果は限定的になります。

開発・制作・業務プロジェクトでの例

プロジェクトの種類ごとに、典型的な配置例を整理します。重要なのは、後続工程や意思決定に影響する地点に設定することです。

マイルストーンは、プロジェクトの特性に合わせて柔軟に設定することが大切です。

マイルストーンが機能しなくなる原因

マイルストーンは設定するだけでは機能しません。達成基準・判断材料・更新体制のいずれかが欠けると、単なる予定日と変わらなくなります。本章では、機能不全に陥る代表的な原因と対策を整理します。

共有されない理由

マイルストーンが機能しなくなる大きな原因は、達成基準が曖昧なことです。「資料作成完了」のような抽象的な設定では、人によって完了の認識が異なります。ドラフト提出を完了と考える人もいれば、承認取得までを含める人もいるでしょう。この認識差があると、到達したはずの節目が実際には未達という状態が生まれます。

成果物名・承認者・完了条件を具体的に定義し、客観的に判断できる状態にしておくことが不可欠です。

判断材料が揃わない理由

マイルストーンを迎えても、進捗実績や工数消化、課題状況が把握できていなければ正しい判断はできません。設計完了としていても、工数が大幅超過していたり、重大な指摘が残っていたりすれば次工程に進むべきではありません。マイルストーンは通過点ではなく、進行可否を判断する地点です。そのため、日々のタスク進捗、工数、課題を可視化し、節目で横断的に確認できる仕組みが必要です。

材料が揃わなければ形骸化します。

更新が追いつかない理由

計画の更新が滞ると、ガントチャートと実態が乖離し、マイルストーンは意味を失います。実際には遅延していても計画上は順調に見える、スコープ変更が反映されていないといった状態では、正確な判断は不可能です。更新を担当者任せにすると遅れが常態化します。週次更新のルール化や完了時即時反映など、計画を常に最新状態に保つ運用が不可欠です。

最新情報と紐づいてこそマイルストーンは機能します。

機能するマイルストーンにするための運用設計

マイルストーンは、設定して終わりではありません。日々のタスク管理・工数管理・課題管理と連動して初めて、意思決定の基準として活用できます。本章では、実務で定着させるための運用設計を整理します。

WBSとの連動

WBSは、成果物を基準にプロジェクトを分解した構造です。マイルストーンを有効に機能させるには、「どのWBSタスクが完了すれば到達とみなすのか」を明確に定義しておく必要があります。例えば「基本設計完了」というマイルストーンであれば、設計書の作成だけでなく、レビュー対応や最終版の確定までを含めるのかを事前に決めておかなければなりません。

この対応関係が曖昧だと、到達判定にばらつきが生まれます。WBSと連動させておけば、未達時にどのタスクが停滞しているのかをすぐに特定でき、対応も迅速になります。マイルストーンは日付ではなく、成果物の完了状態として設計することが前提です。

下記記事では、WBSの基本要素をわかりやすく解説しています。併せてご覧ください。

合わせて読みたい

ガントチャートとは？簡単な作り方や基本要素、WBSとの違いを徹底解説

ガントチャートの基本から応用まで、この記事で完全マスター！WBSや工程表との違い、メリット・デメリット、ツールの選び方まで、プロジェクト管理の悩みを解決します。

節目で確認すべき進捗・工数・課題

マイルストーン到達時は、単なる通過確認ではなく、プロジェクトの健全性を点検する機会と捉えます。進捗だけを見るのではなく、工数や品質、リスクの状況まで横断的に確認することが重要です。

例えば、形式上は設計完了となっていても、実績工数が大幅に超過している場合や、重大な指摘が残っている場合は、次工程への移行を再検討すべきです。マイルストーンは「完了確認」ではなく、「進行可否の判断点」と位置づけることで意味を持ちます。

Excelや手動管理では形骸化しやすい理由

小規模なプロジェクトであれば、Excelでもマイルストーン管理は可能です。しかし、関係者が増え、工程が増え、変更が頻発するようになると、手動管理は急速に限界を迎えます。問題は操作性ではなく、整合性と即時性が保てない点にあります。

整合性が崩れる理由

Excel管理では、進捗変更や日程修正が発生するたびに、WBS、ガントチャート、進捗表、報告資料を個別に更新する必要があります。この更新が完全に同期されない限り、どこかに古い情報が残ります。

例えば、設計工程が1週間遅延した場合、本来は後続工程の開始日も自動的にズレるべきですが、手動管理では依存関係をすべて修正しなければなりません。その結果、ガントチャートは修正されたが進捗サマリーは未更新、といった状態が発生します。

さらに、ファイルがメール添付やローカル保存で共有されると、最新版がどれかわからなくなります。担当者ごとにコピーが存在する状況では、マイルストーン日付が人によって異なるといった事態も起こり得るでしょう。この状態では計画そのものの信頼性が低下し、マイルストーンは判断基準として機能しなくなります。

複数案件で管理が難しい理由

複数案件を並行して管理する場合、Excel管理はさらに脆弱になります。各案件が独立したファイルで管理されていると、全体の優先順位やリソース負荷を横断的に把握できません。例えば、A案件でトラブルが発生し、エンジニアを追加投入したとします。その影響でB案件の設計工程が遅れる可能性がありますが、案件ごとのExcelでは、この波及が可視化されません。結果として、B案件のマイルストーン遅延に気づくのは直前になります。

また、案件数が増えるほど会議や報告資料も増え、情報の集約に時間がかかるでしょう。更新確認や整合性チェックに工数が割かれ、本来の判断に集中できなくなります。意思決定のスピードが低下し、結果として、遅延が後続工程へ波及し、連鎖的なスケジュール崩壊を招きます。

本質的な課題

Excelや手動管理の問題は、「更新できないこと」ではなく、「変更が自動連動しないこと」にあります。依存関係、工数、進捗、課題が分断された状態では、マイルストーンは単なる日付になってしまうでしょう。プロジェクトが複雑化するほど、管理は静的な表計算ではなく、動的に連動する仕組みへ移行する必要があります。そうでなければ、マイルストーンは形だけ残り、判断基準としての役割を失います。

下記記事では、Excelによるプロジェクト管理の限界と実務で押さえるべき運用ポイントを解説していますので、併せてご覧ください。

合わせて読みたい

プロジェクト管理はExcelでどこまでできる？┃限界・運用ポイント・代替策まで徹底解説

開発プロジェクトでExcelを使って進捗管理をしたい方は必見です。進捗管理の必要性から具体的な手順まで、開発プロジェクトでの進捗管理について網羅的に解説していま.....

マイルストーンは、ツールを活用すると安定して機能する

手動管理では、更新漏れや整合性の崩れによってマイルストーンが形骸化しやすくなります。これを防ぐには、計画・進捗・工数・課題が分断されない環境を整える必要があります。その役割を担うのがプロジェクト管理ツールです。ツールを活用すると、情報が一元化され、変更が自動的に反映されるため、マイルストーンが「最新の計画」に常に紐づいた状態を維持できます。

ガントチャートとWBSの連動

プロジェクト管理ツールでは、WBSで分解したタスク構造とガントチャートが連動しています。これにより、タスクの期間や依存関係を変更すると、後続工程やマイルストーンの日付が自動で再計算されるのです。例えば、設計工程が3日延びた場合、開発開始日やテスト開始日、さらにはリリースのマイルストーンまで自動で調整されます。手動管理のように複数ファイルを修正する必要はありません。

この自動連動により、計画変更時の修正漏れが防止され、常に整合性の取れた状態を維持できます。マイルストーンは固定された予定日ではなく、依存関係に基づいて動的に管理される節目として機能します。

進捗・工数・課題の一元管理

マイルストーンを判断点として活用するには、進捗だけでなく、工数や課題の状況も同時に把握できる状態が求められます。プロジェクト管理ツールであれば、タスクの進捗率、実績工数、未解決課題を同一画面で確認できます。例えば、設計完了のマイルストーンに到達していても、実績工数が見積を大きく超過していたり、重大な課題が未解決のまま残っていたりする場合には、次工程への移行を再検討すべきです。

必要な情報が自動的に集約されるため、報告資料作成のための転記作業は不要になります。その結果、ガントチャートだけが更新され、進捗サマリーには古い数値が残るといった不整合を防ぐことができます。

ツール活用の本質

プロジェクト管理ツールの価値は、作業を便利にすることではなく、「判断に必要な情報を分断させないこと」にあります。依存関係、進捗、工数、課題が連動していれば、マイルストーンは単なる予定日ではなく、確かな判断基準として安定して機能します。

Lychee Redmineでマイルストーンを実務に定着させる

引用：Lychee Redmine

Lychee Redmineは、WBS・ガントチャート・工数管理を一体で扱えるプロジェクト管理ツールです。マイルストーンを単なる予定日ではなく、判断点として機能させるための仕組みが備わっています。手動管理では分断されがちな「計画・進捗・工数・課題」を同じ基盤で管理できるため、節目で必要な情報が揃った状態を維持できます。

進捗状況を把握できる

Lychee Redmineでは、WBSとガントチャートが連動しています。タスクの期間を変更すれば、依存関係にある後続タスクやマイルストーンの日付が自動で再計算されます。例えば設計工程が3日延びた場合でも、開発開始やテスト開始、リリースのマイルストーンまで自動で再計算されるため、修正漏れを心配する必要がありません。

一画面で担当者、期限、依存関係を編集できるため、遅延タスクを即座に特定できます。進捗が滞っている箇所を可視化し、対処の優先順位を明確にできる点が実務上の強みです。

担当者の負荷を把握できる

工数管理機能により、各タスクに対する実績工数を記録し、担当者ごとの稼働状況を可視化できます。例えば、マイルストーン到達時に「設計は完了しているが、特定メンバーの工数が見積の150％に達している」といった状況を確認できます。進捗だけでは見えない負荷偏在を早期に発見できるのです。

さらに、ドラッグ＆ドロップで担当変更や再割り当てが可能なため、負荷が集中しているメンバーから他メンバーへ迅速にリソースを再配分できます。計画修正とリソース調整が同じ画面で完結します。

リスクを把握できる

チケット単位で進捗・工数・課題を紐づけて管理できるため、マイルストーン到達時に状況を横断的に確認できます。例えば、「進捗率は80％だが工数超過が進行している」「重大課題が未解決のまま残っている」といった状態を早期に把握できるのです。予実差分や傾向を可視化することで、後工程での手戻りを未然に防げます。マイルストーンは完了確認ではなく、進行可否の判断点として機能します。

複数のプロジェクトの状況を確認できる

Lychee Redmineでは、複数案件のガントチャートや進捗状況を横断的に確認できます。各プロジェクトを個別に開かなくても、遅延やボトルネックを一覧で把握できます。例えば、A案件で設計遅延が発生しリソースを追加投入した場合、その影響がB案件やC案件に波及していないかを同時に確認できるのです。案件横断での負荷調整が可能になるため、遅延の連鎖を防ぎやすくなります。

実務で定着する理由

Lychee Redmineの本質は、情報を一元化することにあります。進捗・工数・課題が分断されていなければ、マイルストーンは常に最新の状態と紐づきます。その結果、マイルストーンは単なる予定日ではなく、根拠に基づいた判断基準として安定して機能するのです。

マイルストーンに関するよくある質問（FAQ）

本章では、マイルストーン運用で実際によく出る疑問に対し、実務視点で整理します。

いくつくらい設定するのが適切か

適切な数はプロジェクト規模によって異なりますが、目安は「2週間〜1か月に1回、到達確認が発生する程度」です。あまりに間隔が長いと問題発見が遅れ、短すぎると節目の意味が薄れます。重要なのは数ではなく、「次工程へ進む判断が必要な地点」を漏れなく押さえることです。成果物承認や外部レビューなど、進行可否を左右する節目に絞って設定します。

途中で変更しても良いか

変更は可能です。むしろ、状況変化に合わせて見直さなければ形骸化します。ただし、日付だけを修正するのではなく、「なぜ変更するのか」「後続工程へどう影響するのか」を明確にし、チームで共有することが前提です。依存関係や工数見積もりも同時に見直さなければ、表面上の修正に終わります。変更履歴を残し、判断の根拠を記録することが重要です。

進捗確認に時間がかかるのはなぜ

多くの場合、達成基準が曖昧なことが原因です。「設計完了」と設定していても、ドラフト提出なのか承認取得なのかが定義されていないと議論が発生します。完了条件は具体的かつ測定可能に定義する必要があるのです。SMARTの原則を用い、成果物名・承認者・完了条件を明文化すると、確認作業は短時間で済みます。曖昧さがある限り、毎回の確認が議論になります。

何を確認すれば良いかわからない場合はどうする

基本は「進捗・工数・品質・課題／リスク」の4観点です。進捗は予定との差異、工数は見積比と負荷偏在、品質はレビュー指摘や不具合残数、課題は重大リスクの有無を確認しましょう。これらを定例会議の固定アジェンダに組み込むと、確認漏れを防げます。慣れてきたら、顧客満足度やROIなど、プロジェクト特性に応じた指標を追加します。

複数プロジェクトはどう整理すれば良いか

複数案件を個別ファイルで管理すると、優先順位やリソース競合が見えません。ツール上で主要マイルストーンを時系列に並べ、横断的に可視化することが重要です。例えば、A案件の設計遅延がB案件のリリースと重なる場合、リソース再配分を早期に判断できます。案件横断で負荷と遅延を確認できる仕組みが、連鎖的な遅延を防ぎます。

更新するタイミングはいつか

原則は週次または隔週の定例進捗会議で確認・更新します。ただし、仕様変更や重大課題が発生した場合は、定例を待たずに即時見直します。重要なのは「節目到達時点で最新状態になっていること」です。進捗・工数・課題の更新を事前に完了させ、判断材料を揃えた上でレビューを実施します。更新が遅れると、マイルストーンは形だけになります。

マイルストーンを「節目」から「判断基準」へ

マイルストーンを単なる通過点ではなく、進捗・工数・課題を確認する判断基準として活用することで、次工程へ進むべきかどうかを的確に判断できます。例えば、設計完了に到達していても、工数が大幅に超過していたり、重大な課題が残っていたりすれば、計画の見直しが必要です。

この判断を安定して行うには、進捗・工数・課題を一元管理できる環境が欠かせません。Lychee Redmineのようなプロジェクト管理ツールを活用すれば、節目で必要な情報を即座に確認でき、整合性の取れた状態で意思決定を行えます。

マイルストーンを実務で機能させたい方は、無料トライアルでその違いを体験してみてください。