計画，分析，設計，構築，テスト，運用の6工程の内容と順番を定義したものを開発ライフサイクルと呼びます．開発手法とは，この開発ライフサイクル全体を通して最適なシステムにする方法を体系づけたものです．そして，現在主流の開発手法は，
(1)方向の違い
ボトムアップかトップダウンか
(2)手順の違い
ウォーターフォールかスパイラルフローか
(3)着目点の違い
プロセス中心かデータ中心か
というように大きく区分されています．この区分は，それぞれ独立したものではなく，たとえば，「データ中心＋トップダウンで行なう」というように手法を組み合わせて使います．
ボトムアップは，定型の帳表を基に遂行している業務の整理，分類に適したアプローチです．
ボトムアップアプローチを採用したときは，既存の組織や業務とシステム化の範囲が衝突することがなく，実際に使う人の賛同を得られやすいという利点があります．反面，システム化による効果が既存組織の構成に左右される点や細かなニーズに囚われて，将来の変化に対応できないシステムに陥る危険があります．
そのため，このアプローチを採用するときには，対象が安定していることが前提になります．
コンピュータの導入を機会に，現状の業務形態を変革しようと考えているときには，トップダウンアプローチを採用するのがよいでしょう．
このアプローチは，業務上の課題や改善ニーズを分析・整理して，「理想的なあるべき姿」を設定し，それと現実のギャップを埋めるためには「何をすべきか」という視点で検討していきます．
これら2つのアプローチには一長一短があるので，どちらか一方のみを採用するというよりも，どちらのアプローチを主として開発するかを考えるとよいでしょう．ですから，トップダウンで開発するときは，現場の意見によりチェックするなどが必要になります．
図1：ウォーターフォールの流れ
|
従来の開発手法の代表的なものとしては，ウォーターフォールモデルがあります．この手法は，川の流れのように，上流工程から下流工程へ作業が澱みなく流れてゆくことが前提になっています（図1）．つまり，上流工程からは誤りのない仕様書などの成果物ができ上がってくるので，その次の工程では，たとえば，その成果物を基にして，詳細化することが中心作業になります．
ウォーターフォールの手順
ウォーターフォールでは，各工程では次の工程に受け渡すための生産物を作り，レビューと呼ぶ確認作業を行ないます．生産物は，コーディング前までは設計書ですし，コーディング以降はソースコードや実行ファイルになります．そして，レビューにより生産物の正当性を確認して，その工程での誤りをすべて修正したあとに，関係者の承認を受けて，手戻りしない約束を取り付けます．
ウォーターフォールの問題点(1)：非可逆性の問題
ウォーターフォールモデルの問題点は，この「その工程での誤りは，工程内で解決され，成果物には含まれない」という点にあります．その思想は，工程だけではなく，設計とプログラムを別会社が担当したりといった，開発体制の分割をも意味します．そのため，設計が悪かったときは，プログラム担当者にすべてのしわ寄せが来る傾向が多いようです．つまり，設計工程での誤りがプログラム工程で発見されても，ただちに設計工程を見直して，誤りのない成果物をつくるという行なわれてしかるべき作業が無視され，誤りを発見した工程内での局所的な対処しか行なわれません．
環境や実装技術がほぼ固定化されていたホスト開発では，数年前にプログラムを担当していた人がそのときの実装技術を基にして設計しても，プログラム工程でなんとか挽回できました．しかし，Windows開発では，設計担当者が最新の実装技術や製品間の相性などを知らないと，プログラム工程ですべてのしわ寄せを解消することが不可能なときがあります．つまり，Windows開発では，設計担当者が最新の知識をもっているかどうかが重要で，その知識は，ハードウェアやプログラム言語などのソフトウェアを実際に使ってみなければ身につかない性質のものが多いということです．そのため，設計者も常にプログラムに親しんでいるか，プログラム担当者の声に耳を傾けて，自分の設計に対するフィードバックを拾い上げるように努力する必要があるのです．
ある日NHKを見ていると，「技術者オリンピック」という番組があり，溶接，旋盤，精密機器組み立てなどの競技風景が紹介されていました．番組では，昔の日本の製造業では，設計書が現場に降りてくると技術者がそれを検討して，おかしな所があったら，それを設計にフィードバックする仕組みがあったと言っていました．しかし，今は部品から作る製造部門が少なく，海外から部品を調達して組み立てるだけになったため，設計通り組み立てられる熟練者はいるけれど，設計の意味まで含めて理解できる熟練技術者が少なくなってしまったそうです．そして，それに伴ない「技術者オリンピック」での金メダル数も激減しているそうです．
この番組の中で，特に心に残ったのは，精密機器を削り出し，組み立てる競技に出場していた人が，競技委員会の作成した設計図から，遊びの部分を長年の経験で導き出し，結果，設計図の不備を発見し，なんと競技委員会に「技術者の誇りをかけて」その誤りを指摘し，それが受け入れられる話でした．Windows上の業務システムをウォーターフォールモデルで開発するならば，上位工程と下位工程で契約や会社が異なっても，このエピソードのように，プログラム工程で発生した不具合を設計工程まで戻って検証するような仕組みや体制が必要だと思います．
ウォーターフォールの問題点(2)：設計のタイムラグの問題
ウォーターフォールモデルのもうひとつの問題点は，システム全体が同時に構築されることが前提となっているために，結果的にひとつひとつの工程が長引く傾向があることです．また，システムの一部分の工程が遅れたときの影響が，システム全体のスケジュールに波及しやすいことも問題かもしれません．
しかし，根本的な問題は，実際の利用者がシステムの動作を確認できるのが，最下位工程（システムテスト）のみである点です．そのため，設計時に利用者が欲している要件を取り入れることができたとしても，それを確認するころには，欲している要件が変化している可能性があるのです．
ウォーターフォールの問題点(3)：実際の利用者が仕様を確認するタイミング
ウォーターフォールモデルの中間工程での設計書やテスト項目などを実際の利用者に確認してもらったとしても，利用者自身が欲しているシステムと一致しているかどうかを判断するのはかなり難しいでしょう．そのため，システムテストの段階になって実際に動く画面や出力される帳表をみて，始めて不具合に気が付くことも多いようです．そのため，納期間近になって大幅な変更を余儀なくされるケースも後を立ちません．
ウォーターフォールモデルで発生する問題は，システム化対象範囲を“すべて”設計してしまうために「長期間」の開発になってしまうことが主な原因です．そこで，“少しずつ”設計して「短期間」の開発を行ない，それを積み重ねて全体をつくる開発ライフサイクルが考え出されました．それが，スパイラルフローモデルです．
図2：スパイラルフローの流れ
|
スパイラルフローの手順
スパイラルフローモデルの特徴は，システムの核となる最小機能を短期間で作成し，それに他の機能を肉付けしてゆくことです（図2）．つまり，”分析→設計→構築→テスト”を1サイクルとして，でき上がった部分から，評価してもらい，その評価結果を基に徐々にシステムを成長させてゆきます．最少単位から作成していけば，実際に使って不満があったときの影響範囲も限られているので，ウォーターフォールモデルを採用したときにありがちな「修正は簡単ですが，修正する本数が多いので対応できません」とか「影響範囲を調査しないと実現可能か判断できませんので，調査分，納期を延長させてください」ということなしに，本当に欲しい機能に近づくことが比較的簡単にできます．そして，評価結果が良好ならば，その部分から運用を始めるのもよいでしょう．
そして，仕様変更なのか次の機能の実装なのかにとらわれずにシステムを使う側からみた問題点に対する優先順位を設定して，最重要課題を次の1サイクルで構築することにより，常に最善のシステムであり続けながら成長させてゆくことができます．
スパイラルフローの問題点(1)：使用上の注意点
スパイラルフローは，短期間で稼動するシステム（の一部）を構築できる点と，設計工程の不備を次のサイクルで補うことができる点がウォーターフォールモデルよりも優れています．しかし，その利点を生かすためには，最初の1サイクルでしっかりした核の部分を短期間で構築しなければなりません．短期間で構築できる規模の核を上手く見つけ出すことができるかどうかがポイントになります．
スパイラルフローの問題点(2)：最初のサイクルとプロトタイピングの違い
スパイラルフローモデルで開発するときによく陥るのが，最初のサイクルをプロトタイプ作成工程と勘違いしてしまうことです．スパイラルフローモデルの1サイクルの成果物は「完成品」です．その「完成品」を使って運用してもらうことで，初めて，意味のあるフィードバックが得られます．プロトタイプはあくまでも設計で要件を確認する手段であって完成品ではありません．もちろん，成長させて「完成品」に仕上げることも可能ですが，プロトタイプ完成時点は，1サイクルの途中であることを念頭においてください．そして，複数サイクルまわしてこそ，スパイラルフローモデルの利点が生きてくることも踏まえて，“開発期間＝1サイクル”ではなく，“開発期間＝nサイクル”としたスケジュールを計画してください．
スパイラルフローの問題点(3)：新人育成の場の欠如
大規模開発にウォーターフォールモデルを採用したときには，新人をプロジェクトに参加させ，経験を積ませることが比較的簡単にできました．しかし，スパイラルフローモデルの開発では，小人数のプロフェッショナルな集団が短期間で業務に促したシステムを構築してゆくことが前提となるため，新人育成の場としての開発プロジェクトという側面は薄くなってしまいました．
| 手順の違い： |
|---|
| RAD(Rapid Application Development) |
|---|
スパイラルフローモデルの問題点に陥らない方法として考えられたのが，RADです．これは，開発スケジュールだけを決めて，その期間内で，構築，テスト，ユーザー評価を繰り返す方法です（図3）．
RADの利点は，決めた期間をオーバーすることないしに，納得できるまでシステムを作り込むことが可能な点にあります．システムの設計が短期間で終了し，全体が期間内で十分開発できる規模の開発プロジェクトなどに有効な方法です．
図3：RADの流れ
|
このときの注意点としては，必ず実現項目ごとに優先順位をつけて，その優先順位の高い順に構築する点です．そして，ユーザー評価時に，その構築したものの修正と他の手付かずの項目との優先順位を再度判定して，そのなかから最優先のもの（たとえ，構築したものの修正ではなくても）を次の1サイクルの構築対象とすることです．また，必ずテスト工程を入れて，ユーザー評価の対象物の品質を確保することです．なぜなら，ユーザー評価が終了したときに，優先度の高い実現項目がなければ，その時点のプログラムが運用に回されるからです．
プログラムで実現したい処理（プロセス）に注目してシステム設計を進める方法を，POA(Process Oriented Approach)と呼びます．元来，業務とは，ある事柄を次々と処理していく作業ですので，システム化する対象業務を理解するときには「どのような組織がどのような処理をしているのか」と考えるとわかりやすいと思います．その考え方をシステム設計時に応用したのがPOAなので，比較的簡単に理解できる考え方だと思います．
図4：POAの流れ
|
POAの手順(1)：現状把握
POAの最初の工程は，現状を把握するために，たとえば，どの伝票をどの係が起票して誰がそれを決済するかといった，物理的な処理プロセスがどのようになっているかを明確にします（図4）．その記述には，DFD（データフローダイアグラム：図5）を使って行なうことが多いようです．
POAの手順：(2)物理モデルの抽象化
現状を表記したDFDの最初の形態は，物理的な処理に注目した物理モデルです．この物理モデルをそのままシステム化するのでは，手作業を機械化するだけになってしまいます．業務改善の余地のないものであれば，それでもよいでしょうが，システム化を機会に業務改善を行ないたいと考えているときには，物理モデルのままでは検討しづらいと思います．そこで，物理モデルを抽象化して論理モデルに変更します．つまり，「どのデータがどの機能で発生し，どの機能で更新されるか」というような記述に変更します．
POAの手順(3)：モデルの改善
論理モデルを眺めながら，プロセスの統廃合を行ないます．このとき，どこまでをシステム化するかにとらわれずに最適なプロセスの流れを検討します．
POAの手順(4)：論理モデルの具体化
POAの最後の工程は，改善した論理モデルを伝票，人，プログラム単位などの物理モデルに再変換する工程になります．ここで初めて，コンピュータと人間との間のデータストア（画面，帳表）などが発生します．
図5：DFD
POAの問題点
POAは，業務環境が定型の時には，その理解のしやすさから，業務アプリケーションの開発に多く用いられてきました．それは，POAが現実を忠実にモデル化するのに適していたからです．しかし，そのことがPOAの弱点でもあるのです．現実の状況が変化しやすくなったとき，POAでモデル化したシステムは，その影響を多大に受けることになります．つまり，新しい顧客サービスなどを次々と提供しなければいけないような事態になったとき，そのたびにモデルの根本であるプロセスを全面的に検討しなければなりません．これでは，変化を求められれば求められるほどシステムに反映するタイミングが遅くなり，ビジネスチャンスを逃すことにもなりかねません．
DOA（Data Oriented Approach）では，POAと異なり，業務プロセスではなく，データ構造に注目して「データとプロセスの分離」を目的にしてシステム設計を行ないます．
業務システムの主眼が“紙ベースからデータベース”へ単に業務システムを移行することではなく，“データベースに蓄積されたデータを有意義な情報として活用する”こと，つまり“情報資産の有効活用”に移ってきたことが，DOAが普及してきた要因でもあります．
情報資産を有効活用しようとしたとき，さまざまな活用に耐えられる整理されたデータ項目が必要です．このようなデータ項目は，それぞれのプロセスの入出力形式ではなく，「システムで管理されるべき理想的な形式＝ひとつのものはひとつのところ」に設計されている必要があります．このようなデータ構造の設計を行なうには，POAではなくDOAが適しています．
図6：DOAの流れ
|
DOAの手順(1)：現状把握
DOAでも，まず，これからシステム化しようとする業務の中でどのような処理が行なわれ，どのような情報が入出力されているかを調査します（図6）．
そして把握した現状を基にして物理モデルを作成して要求分析を行います．要求分析とは，経営戦略や情報化や業務改善の方針に沿って物理モデルを整理することです．たとえば，複数のプロセスが必要としているデータを一つに統合するとか，データの流れ変更すれば帳表が不要になるなどの改善点を検討します．この工程での注意点は，物理モデルなので，手紙や電話などの人間系の処理もコンピュータ化されている処理と同様にモデルの中に組み込んでおくことにあります．
要求分析の記述には，POAで用いた物理モデルDFDを使うこともできますが，トップダウン的な視点にたって分析するときは，組織を意識したBP図（ビジネスプロセスダイアグラム：図7）を使います．
図7：BP図
|
DOAの手順(2)：データモデリング
要求分析がある程度固まってきたら，実際の業務及び用件を踏まえながら「どんな情報を必要としているか」に注目して抽象化を行ない，論理モデルであるデータモデルを作成します．データモデルを作成するときは，使用される情報を概念的に表現して，それらのデータ構造と内容，他の情報との関連を明確にしてゆく点に注目して作業します．このときに用いられるのがER図（エンティティリレーショナルシップダイアグラム）です．ER図上では，業務で必要とされる情報の単位としてエンティティを定義し，その属性としてデータ項目を定義します．また，リレーションシップとしてエンティティ相互間の関係を図式化します（図8）．
プロセスモデルを基にして作成したER図には，冗長データが含まれていることが多いので，正規化という規則性のある手順に従って，エンティティ間の関係を正しく定義してゆきます．つまり，正しく正規化されたER図で表されたのが「システムで管理されるべき理想的なデータ構造」となります．
DOAの手順(3)：プロセスモデリング
データモデルを基にして，「どのように情報を管理するか」に注目して，実際の業務及び要件をシステム構造として整理し，論理モデルであるプロセスモデルを作成します．プロセスモデリングでは，場合によってはデータモデリングと同時に行なうこともあります．プロセスモデルではDFDを使ってデータがどのように利用されているかを明確にしてゆきます．
DOAの手順(4)：モデルの結合
ER図のエンティティとDFDのデータストアを統合して，データライフサイクル（CRUD：Create, Read, Update, Delete）を明確にしています．そして明確にしたデータライフサイクルを基にして，プロセスの正規化を行ないます．正規化された一連のプロセスをエンティティごとに眺めたときは，最初にデータの生成（C）があり，最後にデータの削除（D）があります．このとき，まったく同じ処理をしているプロセスの重複がない状態になっています．
DOAの手順(5)：モデルの実装
DOAの最後の工程は，データモデルとプロセスモデルで「理想的なデータのあるべき姿」として定義された概念をプログラム構造やRDBMSのテーブル構造という現実に変換する工程になります．このときは，業務知識だけではなく，該当するプログラム言語やRDBMSの知識が必要になってきます．
DOAの問題点
ER図を用いて，完全に正規化された概念データモデルをそのまま実装したとき，極端に処理パフォーマンスが悪化することがあります．これは，正規化によりテーブル間のジョインが増加することに起因します．そこで，より現実的なデータベース構造（実現データモデル）に展開してゆくためのシステムデザイン工程が重要です．しかし，正規化のように決まった手順があるわけではなく，一般的に担当者の勘と経験によって職人芸的に作業が行なわれており，開発作業標準として明文化されていません．この正規化と現実への変換のアンバランスにより，適切な現実データモデルに辿りつけないことがあります．
DOAは，データの観点から業務を把握して分析しますが，実際にはデータはそれを使う手続きと一体としてとらえて，初めて意味があります．そこであえてデータとプロセスを分離せず，管理すべき実体に着目するのがOO（Object Oriented）開発技法です．
オブジェクト指向の考え方(1)：オブジェクト
DOAのエンティティにあたるもので，管理する実体を指します．オブジェクトの中には，属性（プロパティ）と呼ばれるデータ項目と，操作（メソッド）と呼ばれる手続きが含まれます（図9）．Active Xコントロールをオブジェクトと考えれば，プロパティとメソッドのイメージがつかみやすいと思います．
図9：オブジェクト
|
オブジェクト指向の考え方(2)：カプセル化
「データにメソッドを一体化する」ことをカプセル化といいます．カプセル化によりデータはメソッドを通して「何をするか」を指示することしかできなくなります．そして，指示は，オブジェクトから他のオブジェクトにメッセージを渡すことで行ないます．たとえば，データベースの中にデータ構造以外のデータを操作する手続きを登録できれば，プログラムからは，その手続きが見えているだけで，その手続きの内容やデータ構造は見えません．そのため，手続きのチェックを充分にしておけば，誤った使われかたをする危険がかなり低減します．Visual BasicでもActive X DLLやActiveX EXEを使って同様にカプセル化を行なうことができます．
オブジェクト指向の考え方(3)：クラス
たとえば，「スタッフ」オブジェクトと「会員」オブジェクトがあったとき，この2つのオブジェクトは，「人」オブジェクトがもっている氏名，誕生日，性別，血液型などの属性を，やはりもっています．この「スタッフ」，「会員」，「人」の集まりを「クラス」と呼びます．そして，上位クラスをスーパークラス，下位クラスをサブクラスと呼び，「人」から見れば，「スタッフ」や「会員」はサブクラスであり，「スタッフ」からみれば「人」はスーパークラスになります．そして，スーパークラスでの属性は，サブクラスももっています（継承といいます）．このような属性の継承をインヘリタンスといいます（図10）．
残念なことにVisual Basicは，クラスの継承を行なうことができないので，この時点でオブジェクト指向の考え方から脱落します．
図10：クラス
|
オブジェクト指向の考え方(4)：多相性
多相性は，同じメッセージを送ったときに相手のクラスが異なれば，そのクラス固有の処理が行なわれることをいいます．たとえば，ドロップダウンリストにマウスクリックのメッセージを送ったときと，コマンドボタンに送ったときでは動作が異なるようなものです．
以上，ざっとオブジェクト指向の考え方を見てきました．厳密には他にも考慮する点はあるのですが，Visual Basicのクラス，メソッド，プロパティとオブジェクト指向を結び付けて考えるための前提知識としては，充分だと思います．きっと，同じものと思えることに色々な呼び名がついてしまっていて分かりづらい印象を受けたと思います．しかし，現実社会に目を向けると，たとえばあなたが既婚者で課長職にあれば，家族からは「お父さん」，奥さんからは「あなた」，会社の部下からは「課長」，同僚からは「○○さん」と呼ばれるのと同じようなことだと気楽に考えてください．要は，立場や見方が変われば，呼び名が変化するということも考え方に取り入れてしまったのがオブジェクト指向と言えるのです．
図11：OO開発手順の流れ
|
OO開発技法の手順(1)：概念化
OOの最初の工程は，現実の問題の概略をとらえて検討して，システムの責任範囲と機能を検討することです．ここでは，問題を正確に記述することよりも単純化した形でとらえることが重要です．たとえば，
FAQシステムを開発する．FAQシステムは，蓄積された質問と回答を分類して，検索効率を向上する．FAQシステムのFAQは，News Groupの内容を選択して登録する．News Groupには，VB部門，MS SQL Server部門，Oracle部門がある．各部門には，それぞれ議長が割り当てられる．議長は，FAQの登録権限をもつ管理者である．各議長が投稿を検討して，その内容をFAQシステムに分類登録する．
というような感じです．
OO開発技法の手順(2)：OOA（OO Analysis：OO分析）
分析工程では，
を定義していきます．そして，これは，一過性のものではなく，定義したもので概念化工程で決めたシステムの責任範囲を満たすかを検証します．そして，新たなクラス，関係や操作などが見つからなかったら，次の工程に進みます．また，次の工程で新しいクラスが見つかったときには，分析工程に立ち戻ることが重要です．
OO開発技法の手順(3)：OOD（OO Design：OO設計）
分析工程では，システムの責任範囲を理解することに重点を置きますが，設計では各種の要求をどのように実装するかが問題となります．そのため，設計工程には，大きく分けて
があります．
システム設計では，GUI，RDBMS，エラー処理，ハードウェア（サブシステムといいます）など検討して，そこにクラスを割り当ててゆきます．同時に既存のクラスで再利用可能なものがないかを検討します．
オブジェクト設計では，システム設計で割り当てたクラスを検討して，実装の候補を決定します．そして，実装を前提として，属性，操作，関連，イベント，状態を検討します．
OO開発技法の手順(4)：OOI（OO Implementation：OO実装）
実装工程とは，設計が完了したクラスを割り当てられたサブシステムにあった形態で作成する工程です．たとえば，GUIサブシステムに割り当てたクラスからはVisual BasicのFormを作成します．また，RDBMSサブシステムに割り当てたクラスからは，DDL文などを作成し，データベース定義を行ないます．この工程は，後述するCASEツールがあって始めて成立するものです．人がその知識をフル活用して，1から実装していくのはあまり効率的なことではありません．
|
Visual Basicでシステム開発する上での注意点
|
|---|
Visual Basicを使ってシステム開発を成功させる要因は，小さく，早く作ることだと思います．まとめとして，その視点にたったときの注意点を列挙しておくことにしましょう．
(1)開発よりもその後の保守が重要
社会状況とともにプログラムの機能も変化する必要があります．世の中の流れに遅れないためには，機能改訂を迅速簡単に行なわなければなりません．そのためには，保守しやすい構造，つまり，DOAにより設計し，データプロセスを分離してシステムの基本部分は，世の中の変化に影響されにくいモデルであるデータモデルにする必要があります．
(2)業務を標準化して例外処理を減らす
業務に促したプログラムを心がけるあまり，例外的な処理が多く含まれてしまうことがあります．もちろん，ここでの例外的な処理とは，エラー処理ではなく，「基本的には，この処理ですが，月末には締日の関係で，○○○という処理をしてください」というような処理のことです．このような処理をプログラムに組み込む前に，なぜ締日の関係で処理が異なるかを整理して，業務を標準化することで例外的な処理を減らすことができるかを検討してください．なぜなら，プログラムにとっては，通常処理か例外的な処理かは，あまり問題ではなく，簡単に言えば，例外的な処理がひとつ増加するごとにソースコードもテスト量も保守の手間も2倍になってしまうことになるからです．業務の標準化を行なわずに，プログラムの巨大化・複雑化を防止することはできません．
(3)要求事項の費用対効果を考える
Visual Basicは，柔軟性の高いプログラム言語です．しかし，実現したい要求事項によっては，それにより削減される費用と，その事項を取り入れるための費用や保守する費用が変わらないものがあります．たとえば「データベースやファイルに対して，削除を実行しても簡単に復元できるように，UNDO機能をつけて欲しい」というような要求がそれにあたると思います．このような要求を実現するのはかなり複雑な処理をしなければなりませんし，実際に使っているときに，このUNDO機能を使うことはほとんどないと思います．もし，誤って削除することを防止したいのであれば，「削除してよいかのメッセージボックスを必ず表示．そのときのフォーカスは，［いいえ］ボタンにあること」という仕様でこと足りると言えます．
(4)開発納期が重要
業務アプリケーションを作っていく上で重要なのは，必要十分な機能をその機能を必要としている時期に用意できるかにあります．どんなに要求事項を満たしたプログラムでも，その要求事項が世の中の流れとずれてしまっては，無用の長物になりかねません．最低限，最初に決めた開発納期に基本機能を間に合わせて，変更や追加は新たに期間を決めて挑むようにしましょう．
