|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| このページの最終更新日: 2012/05/30
提案日: 2008/10/24 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
スモールステップ開発
概要 複雑な機能や大きな機能をうまく実装するために、スモールステップ開発といった開発方法を提案します。 スモールステップ開発は、はじめに最も機能を落とした最小限のソフトを作り、最小限のソフトが完成したら、落とした機能を1つずつ追加して、次第に拡大させながら最終的なソフトを完成させる、といったソフトの作り方のアイディアです。 スモールステップ開発では、実現したい機能を小さな機能に分けて、それらの機能を1つずつ段階的に実装します(スモールステップ化)。そのため、難しい機能が小さな機能に分割されて、より簡単な機能の組み合わせになり、容易に実装できるようになります。 背景 複雑な機能や大きな機能を実装するとき ソフトを作り始める場面を考えます。何か実現したい機能があって、それを実現するためのソフトを作ろうと思います。何かソフトを作るとき、実現したい機能が簡単で規模が小さければ、その機能を思うままに実装しても、何も問題はありません。 しかし、実現したい機能が複雑になると、機能を思うままに実装できなくなってきます。どこからどのようにソフトを作ればよいのか分からなくなり、手が止まってしまうことがあります。複雑な機能は、頭の中だけで考えてパッと実装できるものではありません。複雑な機能をうまく実装できる方法が必要です。 一方、実現したい機能が大きくなると、一度にすべての機能を実装できなくなってきます。大きな機能を少しずつ部分的に実装していっても、なかなか全体が完成しません。完成しないままだと、目に見える成果が一向に上がらず、他人に進捗状況を説明するときに困ってしまいます。大きな機能でも、その都度成果が見えるように実装する方法が必要です。 そこで、複雑な機能や大きな機能をうまく実装するために、スモールステップ開発といった開発方法を提案するに至りました。 勉強方法 数学や物理など学校で学ぶ科目を勉強する方法の1つに、取り組む演習問題のレベルを自分が理解できる程度まで低くしてハードルを下げ、そこから少しずつレベルを上げて演習を繰り返すことで、スムーズに勉強を進める方法があります。レベルを少しずつ上げながら、小さなステップを繰り返し登ることで、はじめの頃は考えられなかったような問題が解けるようになります。 これと同じように、ソフト開発も、実装する機能を小さくしてハードルを下げ、実装の作業を簡単にしようと考えました。この小さなステップを繰り返す方法は、ソフト開発でも同様にうまく働くことが分かりました。これをベースに、実際どのような方法でソフト開発を進めればよいかを具体的に決めることで、スモールステップ開発が出来上がりました。
どんなもの? 小さなステップずつ繰り返し追加実装する 方法文章 何かソフトを作るときに、はじめから高機能なソフトを目指さずに、はじめに最も機能を落とした最小限のソフトをなるべく早く完成させることを目指して、最小限のソフトが完成したら、落とした機能を1つずつ追加して、次第に拡大させながら最終的なソフトを完成させる、といったソフトの作り方のアイディアです。 この作り方をスモールステップ開発と呼ぶことにします。最小限のソフトに小さな機能を繰り返し追加することで、次第にソフトを完成させることから、小さなステップを何度も踏むイメージをスモールステップと表しています。 具体的な開発方法は? スモールステップ開発は、簡単に表せば、次のようなステップを踏んで開発を進めます。
以降では、これらのステップにしたがって具体的にソフトを作る様子を見ながら、スモールステップ開発とは、具体的にどのようにしてソフトを作る方法なのかを説明します。ここでは作成するソフトの例として、卓上型の計算機アプリケーションを作る場合を考えます。 どんなアプリを作るか考える
まず、どんな計算機アプリを作りたいかを考えます。例えば、右の図にあるようなかなり高機能な計算機アプリを考えたとします。 このような高機能なソフトの作成を目指す場合でも、スモールステップ開発ではステップ1にあるとおり、はじめに最小限のソフトを作ります。はじめから実現したい機能すべてを実装するのではなく、一番基になる機能1つだけを実装します。 ステップ1の最小限のソフトを作ろうとすると、まずはじめに、先に思い描いた高機能なソフトから色々な機能を削ぎ落として、一番基になる最小の機能は何なのかを探す必要があります。 機能を分離して小さな機能に分ける
そこで、図の計算機アプリに含まれる色々な機能を分離して小さな機能に分けます。すると、例えば、図の[A]～[I]のように分けられます。[A]～[I]の機能は次のような内容になります。
一番基になる最小の機能を決める
機能が分離できたので、この中から一番基になる最小の機能を探します。何を最小の機能とすれば、ステップ1が実装しやすくなるか、といった観点から最小の機能を決めます。 ここでは、[C]+[G]を最小の機能と決めます。[C]+[G]を実装した完成イメージは、右の図のようになります。0～9の数字を入力してその値をただ表示するだけの機能です。この程度の大きさの機能であれば、ステップ1で簡単に実装できると考えました。最小の機能はアプリとして意味がなくても全く構いません。 しかし、最小の機能を何とするかは、その人の捉え方によってさまざまに異なります。例えば、最小の機能を[C]だけにすることも出来ます。この場合は、ゼロを表示するだけの非常に単純な機能になり、さらに簡単に実装できるようになります。一方で、最小の機能を[C]+[G]+[H]+[I]にすることも出来ます。この場合は、整数／小数の入力から四則演算までの大きな機能になり、一気に多くを実装する必要があります。
もし、以前、計算機アプリに似たような機能を作った経験があるなら、最小の機能を[C]+[G]+[H]+[I]と決めても、ステップ1でスムーズに実装できると思います。反対に、計算機アプリをどう作るか見当も付かない場合は、最小の機能を[C]だけにして、ステップ1で[C]の実装に集中すればよいと思います。このようにして、ステップ1で簡単に実装できるか、といった観点から最小の機能を決めます。 実装の計画を立てる 最小の機能が決まれば、スモールステップ開発のステップ1へ進めますが、その前に全体の計画を立てておきます。計画では、先に分離した機能をどのような順番で実装するかを決めます。前述で決めた最小の機能を基にして、次にどの機能をどのような順で実装すれば、各ステップが実装しやすくなるか、といった観点から機能にある順番関係を見抜きます。 計算機アプリの例では、ステップ1で実装する最小の機能を[C]+[G]と決めました。これを基に、ステップ2で[A]～[I]のどの機能を追加実装すればよいかを考えます。[C]+[G]が整数を入力する機能なので、ステップ2では[H]の小数を入力する機能を追加すると決めます。数値の入力が完成したので、ステップ3で[I]の四則演算機能を追加すると決めます。
[A]～[I]まですべての機能の実装順を決めると、例えば、次のような順番になります。
このようにして機能にある順番関係を見抜き、機能の実装順を決めていきます。順番を決めると、実装の計画表を書くことが出来ます。計画表では、どのステップでどの機能を実装するかを次のような表で表します。
この計画表を開発の中で使うことで、どのように開発が進んでいくか(工程)、全体としてどれぐらいステップがあるか(規模)、現在どこまで開発が完了しているか(進捗)、といった項目がいつも見えるようになります。 [状態]の項目は、まだ実装していないステップには[未完]、実装中のステップには[WIP]、実装が完了したステップには[完了]、といった状態を表す名前を書きます。 ステップ1を実装する これまで、どんなアプリを作るか考えて、機能を小さく分離し、機能の実装順を決めて、実装の計画を立てました。ここまでは全て、ステップ1の実装を開始するための準備になります。ここまではまだ何もコードを実装せず、どのステップでどの機能を実装するか、といった実装の計画をずっと考えてきました。スモールステップ開発を行う場合は、コードを書く前にこれだけの項目を考える必要があります。 実装の計画が立てられれば、次にその計画に従ってステップ1を実装します。計画の際にステップ1で実装すると決めた最小の機能をここで実装して、最も機能を落とした最小限のソフトを作ります。
計算機アプリの例では、ステップ1で[C]+[G]の整数を入力して値を表示する機能を実装します。右の図のようなソフトの完成を目指します。 [C]と[G]の実装は、例えば、まず[C]の表示部と[G]の数字ボタンのUIを作ります。数字ボタンが押されたら、その数字を内部の変数に入れて、表示部に数字を表示するコードを作ります。数字ボタンを1、2、3と押すと、表示部には1、12、123と表示させたいので、数字ボタンを押したら、10*0+1=1、10*1+2=12、10*12+3=123のように、10*[内部変数]+[入力数字]と計算するアルゴリズムを作ります。 ステップ1を実装し終わったら、そのソフトをテストするコードを作ります。必ずテストコードを作って動作を確認するところまで、ステップ1で行います。計算機アプリの例では、数字ボタンを押したら表示部に数字が正しく表示されるかをテストすればよいので、例えば、数字ボタンのクリックイベントに登録されたハンドラ関数を0から9まで順に呼び出して、表示部の値が0123456789となるかをチェックするテストコードを作ります。 このようにテストコードを作れば、何らかの実行可能なソフトが出来ます。実装したコードは必ず実行できるようにして、実行結果が確認できるようなソフトを作ります。この実行可能なソフトと実行結果がステップ1の成果になります。これによって、ステップ1が完成したことを他人に説明できます。実行可能なソフトの挙動を見ることで、ステップ1とは何なのかを他人に説明できます。 ステップ1で機能を素早く実装できない場合は、機能が大きすぎです。計画の際にステップ1で実装すると決めた最小の機能が、まだ大きすぎたことが分かります。なので、この最小の機能をさらに小さく分離して、ステップ1では分離した機能のうちの1つだけを実装するように計画を変更します。 このようにステップ1で実装する機能は、その大きさや複雑さを十分落としたものにし、素早く実装できるようにします。ステップ1で機能をスムーズに実装できるかどうかは、計画の際にそのアプリの機能をどれだけ分離して、最小の機能をどれだけ簡素化するか、にかかっています。 計画の見直し どんなによく計画してソフトを作っても、作っていくうちに、必ず始めの頃には思い付かなかったような機能が見つかることがあります。 計算機アプリの例では、はじめにアプリのGUIを思い浮かべながら計画を立てたので、例えば、キーボードから数字を入力する機能や、コピー&ペーストで数字を入力／出力する機能は、計画の時点では思い付きません。しかし、ステップ1を実装して、アプリを実際に使ってみると、キーボードから数字を入力したくなって、キーボード入力の機能に初めて気付くかもしれません。 一方で、ソフトを作っていくうちに、この機能は本当はこんな形で分離した方が良い、これらの機能は本当はこんな順番で実装した方が良い、と分かることがあります。ステップ1を実装して、具体的にコードの形にしてみて初めて機能の本質的な形が見え、上手な分離や効率的な実装順に気付くかもしれません。 そのため、ステップ1を実装した後に計画を見直し、必要であれば計画を修正します。ステップ1を実装してみて思い付いた機能があれば、計画表の中の適切な行に1行追加して機能を書き込みます。不必要と感じた機能があれば、別枠に実装を中止する機能の表を作ってそちらに項目を移します。 計画表では、不必要な機能であっても、消さずに内容を残しておきます。ずっと後になってから、やっぱり必要であったことが分かる場合があります。そのため、基本的に計画表の中から文字を消すことはせず、別表を作って項目を移すことで対応します。 ステップ1を実装してみて新しい機能の分離に気付けば、計画表の中の行を複数に分けて分離した機能に書き換えます。新しい実装の順番に気付けば、計画表の中の行を入れ替えて機能の実装順を変更します。 ステップ2を実装する 見直した計画に従ってステップ2を実装します。ステップ1で作ったソフトに、ステップ2で追加する機能を実装して、ソフトの機能を拡大させます。
計算機アプリの例では、ステップ2で[H]の小数を入力する機能を実装します。右の図のようなソフトの完成を目指します。 [H]の実装は、例えば、ステップ1で作ったソフトに[H]の小数点ボタンのUIを追加します。小数点ボタンが押されたら、整数入力から小数入力へ切り替えるコードを作ります。小数入力に切り替わってから数字ボタンを1、2、3と押すと、表示部には0.1、0.12、0.123と表示させたいので、数字ボタンを押したら、0+0.1*1=0.1、0.1+0.01*2=0.12、0.12+0.001*3=0.123のように、[内部変数]+0.1^[入力回数]*[入力数字]と計算するアルゴリズムを作ります。 ステップ2の実装でも、ステップ1と同じ次の3点に注意して実装します。
計画の見直し ステップ2を実装したら、計画を見直します。実装の毎に、計画を見直します。繰り返し計画を見直すことで、より良い計画へと近づけます。ステップ2でもステップ1と同じように、次に挙げる操作を行って計画表を見直します。
ステップの実装と計画の見直しの繰り返し ステップ3もステップ2と同じように、前のステップで作ったソフトに機能を追加実装して、計画を見直し、以降、ステップ3を追加実装→計画見直し→ステップ4を追加実装→計画見直し...のようにサイクルを繰り返します。 このようにして、各ステップを追加実装していくことで、次第に機能を拡大させながら最終的なソフトを完成させていきます。 開発方法のまとめ 計算機アプリの例に沿って、スモールステップの開発方法について説明してきました。最後に、細かい点を含めてもう一度、スモールステップ開発を次の表に整理します。スモールステップ開発は、次のようなステップを踏んで開発を進めます。
大切な6つのポイント スモールステップ開発を行う上で大切になるポイントを次の表にまとめます。スモールステップ開発の持つ利点を効果的に得るためには、これらのポイントに注意します。
その他の効果的なポイント 上記の6つのポイント以外に、スモールステップ開発を行う上で、実施すると効果的なポイントを次の表にまとめます。以降で各項目の内容を詳しく説明します。
スモールステップ開発では1回のステップで1つの機能を追加しますが、1つの機能を追加し終わったら、その機能が正常に動作するかを確認するために必ずテストコードを作り、必ずテストを行うようにします。テストがうまくいくまでは、試行錯誤の汚いテストコードで構いません。代わりに、テストがうまくいったら、そこで終わらずに、テストコードをきれいに直して完成させます。 これによって、各ステップにはうまく動作するテストコードがそれぞれ完成し、各ステップは常に動作可能な状態になります。どのステップでも実際に実行して動作を確認でき、実行すれば正常にテストが動作して意味のある結果を見ることが出来ます。 正常に動作すれば、それだけでコードの価値がぐっと高まります。どのステップも正常に動作するので、過去のステップで作ったコードにもしっかり価値が残ります。テストコードがあれば、コードの動かし方や利用方法が分かり、他の用途へ再利用しやすくなります。常に動作可能なので、前までの全てのステップは確実に自分の成果として説明できます。それらが動作する様子や動作結果によって、進捗状況を他人に直ぐに説明できます。 スモールステップ開発では1回のステップで1つの機能を追加し、どのステップでも動作可能な試作ソフトが完成します。この各ステップで作る試作ソフトとそのソースコード一式は、ステップごとにフォルダに分けて管理するようにします。1回のステップで1つのフォルダを作り、ステップを重ねるごとにフォルダの数が増えていきます。各フォルダには、そのステップで作った試作ソフトとソースコードがそれぞれ入っています。 前のステップが完成して新しいステップを作るときは、前のステップのフォルダを丸ごとコピーして、これを次の新しいステップのフォルダとします。フォルダの名前は、先頭に1から順に番号を振って、その後にそのステップで追加した機能を表す名前を付けます。例えば、「1 ○○機能を作成」、「2 ○○機能を追加」のようになります。もし適切なバージョン管理ソフトがあるなら、そちらの仕組みを使っても構いません。 これによって、開発の過程が履歴として記録され、開発の生い立ちが残ります。もし今のステップで機能追加に失敗した場合でも、保存されている1つ前のステップへ直ぐに立ち返ることが出来ます。バグがどうしても解決できない場合も、同様に立ち返り可能です。そのため、開発者は失敗を恐れず安心して機能追加に集中できます。 このように、各ステップでソースコードが丸ごと残るので、WinMerge等のテキスト比較ソフトを使えば、2ステップ間でコードがどのように変化したかが簡単に分かります。その変化の差分を見れば、そのステップで追加した機能に直結するコードが分かり、時間が経っても開発過程を理解できます。また、その差分を切り取ることで、その機能を実現するコードのみを簡単に抽出できます。 リファクタリングをするときは、新しくリファクタリング用に1ステップを作って行います。1ステップの中で機能追加とリファクタリングを同時に行わずに、機能追加で1ステップ、リファクタリングで1ステップ、の2ステップに分けます。 そうしないと、リファクタリングに失敗したときに、機能追加が完成していた時点へ戻れなくなってしまいます。一度、機能追加が完成していたのに、その時点へ戻れなければ、損失になってしまいます。また、リファクタリングによってプログラムが動かなくなった場合に、その直前のコードがないと、以前の正常なコードと比較できず、原因の究明が難しくなります。 ソフトを作っているときに、いろいろ便利な機能を思い付くかもしれません。アイディア豊富な開発者は、きっと、あんな機能があったら便利になる、こんな機能があったら面白い、とアイディアが尽きないかもしれません。しかし、それらは思い付くや否や直ぐに実装してはいけません。 思い付いた便利な機能は、実装しない代わりにメモに残しておきます。このメモはとても貴重なものになります。ふとしたときに思い付くアイディアほど、いいアイディアが多いものです。後で見返した時に分かるように、要点をまとめてリスト化しておきます。しっかりメモに残すことで、実装したくなる気持ちをぐっとこらえ、実装はしません。 代わりに、ソフトの動作に不可欠な機能をまず実装して、ソフトの完成を第一に目指します。そうしないと、ソフトがいつまで経っても、未完成で中途半端なものに終わってしまいます。思い付いた便利な機能を、その都度実装していたら、なかなかソフトの開発が進まず、精神的に挫折してしまう危険が高くなります。 大抵の場合、思い付いた機能は、あれば便利だけど、あってもなくてもどちらでもよく、動作に必須ではありません。そのため、思い付いた機能は直ぐに実装せずに、必要不可欠な機能をまず第一に実装して、ソフトがとりあえず完成した後に、メモに残しておいた便利な機能をもう一度見返して、必要であれば実装します。 このようにすることで、開発がしっかり進んでいる実感が得られるようになります。また、ソフトをいち早く完成させることで、精神的に楽になります。 今後の再利用を考えて、作成中のクラスや関数を汎用化して、もっと色々なデータが渡せるように拡張したり、それらを綺麗に整理してクラスライブラリを作ったりするかもしれません。しかし、ソフトの作り始めから、汎用化やライブラリ化を考えてはいけません。 汎用化やライブラリ化を考えるときは、実際、ずっと後になってからで十分な場合がほとんどです。そのため、まずソフトの完成を第一に目指します。そして、ソフトが完成した後に、汎用化した方が良い場合は汎用化を考えます。 作り始めから汎用化を考え出すと、一向にソフトが完成しなくなってしまいます。汎用化は、今のクラスに便利な機能を追加してライブラリ化することなので、これは上記の「便利な機能を実装」することになり、良くありません。便利だけれど不必要な関数を実装するのに時間を取られて、一向に作業が進まなくなります。もし、途中で汎用化の良い案を思い付いたら、メモに残しておきます。 ソフトを作りながら汎用化を進めると、作業量が大幅に増えてしまいます。ソフトを作る途中で汎用化して綺麗に整理しても、ソフトを作っていたら必ず拡張が必要になり、せっかく整理した汎用化を崩して、その拡張を取り込んでから、また汎用化を綺麗に整理する、といった作業がずっと付きまとうことになり、作業量が大幅に増えます。なので、ソフトを作る作業と汎用化する作業はしっかり分離して考え、まずソフトを作る作業に集中して、ソフトが完成したら汎用化する作業に移ります。 作り始めからライブラリ化を考えても、どんなライブラリ構造がよいかは、そのソフトを何度も使ってみて初めて分かるものです。なので、まず初めにソフトを完成させる必要があります。もし、ソフトを作る途中でライブラリ構造の良い案が浮かんだら、メモに残しておきます。 ソフトを作る作業の途中で、その作業の内容を表す図を頻繁に描くようにします。実行フロー図でもよいし、機能構成の図でも、データ構造の図でもよく、その内容を的確に表せる図を選びます。 図は無理に1つに収めようとせず、内容が多ければ、注目する点を変えて描くことで、複数の図に分けます。また、内容が多岐に渡り、1つの図で表せなければ、同じことを複数の異なる図法で描くことで、より自由に内容を表現します。 図に描き出さずに、頭の中のイメージだけを頼りにしていると、頭の中は自然によいところだけしか考えない傾向があります。そのため、図に描き出すことで、頭の中のモヤモヤした全容を明確にして、今どんな状況なのか、その実態をよりよく理解します。 作業しているその瞬間に描く図が、なによりその作業をもっとも的確に表します。そのため、作業が完了して時間が経ってからではなく、作業の最中になるべく合わせて図を描くようにします。これらの図は、後にドキュメントとしてまとめるときに大いに役立ちます。 スモールステップ開発では、どのステップでどの機能を実装するかを表にして計画表を作ります。このとき、実装するステップの数が20を超えるようなステップが多い場合には、項目が多すぎて計画表が見づらくなります。 そこで、いくつかのステップを区切りのよいところでまとめて、マイルストーンを設定します。マイルストーンはステップよりひと回り大きな単位の計画項目です。ステップといった小さな単位から、マイルストーンの大きな単位で計画表を捉えることで、項目が多すぎて見づらかった計画表を把握しやすくします。 スモールステップ開発の計画表には、どのステップでどの機能を実装するかをメインに書きますが、その他にも書いておくとよい項目があります。例えば、次の表にあるように、種類、完了日、コード行数を書き加えます。
種類には、実装する作業がどのようなタイプになるかを書きます。例では、アルゴ(アルゴリズム)とプログ(プログラミング)の2種類を挙げています。アルゴは、例えば、ある方法でソートする機能や、数式に基づいてある計算をする機能など、アルゴリズムを実装するステップに付けます。一方、プログは、グラフを描画するフレームワークを作ったり、リファクタリングするなど、プログラミングに関係する機能を実装するステップに付けます。 計画表では、実装作業の内容を一列に並べるので、性質の異なる作業内容が混ざってしまいます。そのため、種類の項目を計画表に書くことで、作業内容の種類を明確に示し、実装内容を把握しやすくします。種類の項目は、アルゴリズム、プログラミングの他にも、テスト、レビュー、ドキュメント作成などが考えられます。 完了日は、そのステップで実装する作業が完了した日付を書きます。コード行数は、そのステップにある全てのソースコードの行数を書きます。コード行数の他にも、表に残しておくと良さそうなメトリクスがあれば、列に追加します。追加するメトリクスは、クラス数やテストケース数など、ツールを使って直ぐに計測できる数値にします。 完了日やコード行数を計画表に書くことで、開発の進捗状況を把握しやすくなります。また、今後の開発スピードや開発規模を大まかに見積もることが出来ます。 スモールステップ開発では計画表を作ります。ここでさらに、計画表とは別の2つの表、バグ表と見送り表を作って管理すると、より多くの効果を得られます。 バグ表には、次の表に挙げるように、発生したバグの内容とその原因／対策方法を書きます。バグに関する情報を記録に残すものです。 開発の中でバグが発生したら、まずバグの症状をバグ内容に追加します。次に、バグを直すためにコードを調べてバグの原因が分かったら、その原因を原因／対策にメモします。原因が分かれば対策方法も考えられるので、これによってバグが解決したら、最終的な対策方法を原因／対策に書き足します。同時に、完了日に日付を入れて、一連のバグ対策が完了します。
バグ表があれば、現在どんなバグがあるのかが一覧で分かります。多くのバグがあっても、忘れず全てに対応できます。また、原因／対策には、今後の開発で気を付けるべき点が残っていきます。将来、同じバグで悩まないように、気を付けるべき点を太字にして残します。 見送り表には、次の表に挙げるように、実装を計画していた機能の中で、今回は取りやめるものを書きます。実装を見送る機能の内容を記録に残すものです。 実装を計画する中で、いろいろな機能を考え付きます。開発を進める中で、あれば便利と思う機能を思い付くこともあります。しかし、開発期間や開発目的など、色々な事情でこれらの実装を見送る場合が多くあります。そんなとき、これらの実装を見送る機能は、見送り表に書いて記録に残します。
見送り表があれば、折角思い付いた貴重なアイディアをしっかり記録に残すことが出来ます。また、開発が終了して時間が経った後でも、どの機能が未実装なのかが一覧で分かるので、以前の開発状況をよりよく把握できます。 ■[ポイントの内容] + [それによってよくなる点] を記載する形式で スモールステップ開発の利点 スモールステップ開発を使う利点を次の表にまとめます。以降で各項目の内容を詳しく説明します。
スモールステップ開発では、実現したい機能を小さな機能に分けて、それらの機能を1つずつ段階的に実装します(スモールステップ化)。そのため、難しい機能が小さな機能に分割されて、より簡単な機能の組み合わせになり、容易に実装できるようになります。難しい機能を一度に実装せず、小さな機能を1つずつ実装するので、実装の開始が楽になります。 スモールステップ開発では、一番基になる最小の機能を探して、はじめに実装する内容を計画します。そのため、難しい機能のレベルを極限まで落とすことが出来ます。ある部分を固定値にしたり、無視したりして、設定を具体化することで機能のレベルを落とします。本質と無関係な機能をとりあえず削ぎ落とすことで、考える範囲が狭まり、簡単に実装できるようになります。 スモールステップ開発では、ステップごとにフォルダを作り、 各ステップで作るソースコード一式をフォルダに分けて管理します。そのため、2つのステップにあるソースコードをフリーの比較ツール(WinMergeなど)で比較すれば、変更箇所が色つきで表示されるので、簡単に変更内容を把握できます。 比較ツールの1つWinMergeを使うと、フォルダ間を比較したり、ファイル間を比較できます。フォルダ間の比較では、どのファイルに変更があるのかファイル単位で大まかに比較できます。ファイル間の比較では、ソースコードを1行単位で細かく比較できます。異なる箇所に色づけされるので、どの部分をどれぐらい変更したのかが一目で分かります。 ソースコード自体で変更部分を表すので、正確に変更内容を伝えられます。ドキュメントとソースコードが不一致になることもありません。また、スモールステップ開発の計画表を合わせて見れば、そのステップでどんな機能を実装したのかが分かります。 スモールステップ開発では、どのステップでも必ず何らかのソフトが完成します。そのため、前のステップで完成したソフトを基にして、次のステップで機能を追加実装すればよいだけになります。このように、前の完成物から次を作るので、実装が簡単になります。スクラッチから作るより、既にあるものに機能を追加する方が、考える範囲が狭まって実装が簡単になります。 一度に実装するのが難しい機能でも、機能を小さく分けて、前の完成物に1つずつ機能を追加することで、実装が簡単なまま難しい機能が実装できます。複数段のステップを使って簡単な実装を複数回行えば、難しい機能が簡単に実装できます。 スモールステップ開発では、どのステップでも何らかの実行可能なソフトが完成します。実行可能なので、ソフトを実際に使ってみることが出来ます。ソフトを実際に使ってみることで、それまでは気付かなかった改善点が分かることがあります。 実際にソフトの動作を見ることで、今まで頭の中だけで想像していた動作イメージが、はっきり分かるようになります。明確な動作イメージがあれば、次のステップを実装する際に役立ちます。 スモールステップ開発では、実装を開始する前に計画表を作ります。この計画表があるので、大規模な開発になっても、今何を実装しているのか、次は何を実装すればよいのかが常に分かります。実装に夢中になっても、計画表に立ち返ることで、自分の位置を見失うことはありません。また、自分だけではなく、他の人もこの計画表を見ることで、進捗状況を把握できます。 スモールステップ開発は、研究段階のプロトタイプ開発のような、不確定要素の多い新規開発に役立ちます。スモールステップ開発では、1ステップを実装するごとに計画を見直して修正を加えられるので、開発途中のいかなる変更にも柔軟に対応できます。そのため、実装してみないと分からないような不確定要素の多い開発に向いています。 一方で、内容が確定している開発にはスモールステップ開発でなく、ウォータフォール開発が向いています。内容が確定していれば、はじめにすべての開発計画を立てて計画を固定することが出来ます。また、計画を固定できるので、どこを誰が担当するかを大人数に割り振ることが出来ます。 スモールステップ開発は、1人からでも始められます。自分1人だけでも実践して効果を得ることが出来ます。なので、今何か開発をしていて、何らかの開発アプローチがほしいなら、スモールステップ開発を使ってみるのも選択肢の一つです。 [スモールステップで開発する利点] スモールステップ開発の問題点 スモールステップ開発の問題点を次の表にまとめます。以降で各項目の内容を詳しく説明します。
計画のときに機能の分割に気付けないと、スモールステップ開発の効果がなくなります。機能の分割は、計画する人の力に大いに頼っています。機能の分割は人にしか出来ない創造的な作業です。人の力に頼るので、誰でもすぐに計画できる、というわけには行きません。 実装する機能が複雑で難しいと、機能の分割に気付けず、1ステップが難しいままになり、実装できなくなる恐れがあります。実装する機能が大規模すぎると、分割した機能が爆発的に増えてしまい、機能をしっかり階層的に整理しないと、どこから実装すればよいか分からなくなる恐れがあります。 スモールステップ開発は、ウォータフォール開発に比べて並行開発がしにくくなります。スモールステップ開発では、各ステップが逐次的に進む場合が多くあります。例えば、ステップ1で完成したコードをベースにして、ステップ2の機能を追加するような、ステップ1を実装しないとステップ2を実装できない場合です。このように、逐次的に進むステップ1とステップ2は、並行して開発できません。 さらに、スモールステップ開発では、ステップごとに計画を見直して修正します。そのため、今実装しているステップ以降の計画が確定しません。計画が不確定なので、前段と後段のステップを分けて並行開発するのが難しくなります。並行開発しても、前段で計画を変更すると、後段の開発に影響が渡って、変更の対応に多くの時間が取られてしまう恐れがあります。 ソフトの規模が大きくて、実装するステップが多すぎると、一向に完成しません。一向に完成が見えないと、途中で精神的に止めたくなる恐れがあります。いくつかマイルストーンを設けて規模を分割し、完成までを近づける錯覚が必要です。 ソフトの規模が大きくて、完成までに時間が掛かると、全体を覚えていられなくなります。各ステップで追加する機能を忘れてしまう恐れがあります。忘れないように、計画表に機能の内容を書きますが、どれだけ書き残しても完全には伝わりません。昔に追加しようと思い描いていた機能のイメージを忘れてしまう恐れがあります。 [問題点] 「分離」による簡単化のアプローチ スモールステップ開発は「分離」によって作業を簡単化するアプローチを採ります。1回のステップで追加する機能の大きさをなるべく小さくして、各ステップで行う作業のレベルを落とし、難易度のハードルを下げます。 実現したい機能全体をなるべく小さな機能に分離することで、1回のステップで扱う範囲を狭めて、小さな機能1つ1つの追加に集中し、実装の作業を簡単にします。スモールステップ開発は、分離によって範囲が狭まり作業が簡単化する、といった「分離」の利点を活しています。
世の中の似た機能 反復型開発 1970年頃に登場した反復型開発(Iterative and Incremental Development)と呼ばれる開発方法があります。スモールステップ開発のベースとなるものです。スモールステップ開発は基本的に反復型開発と同じ発想、同じ方向性を持ちます。 反復型開発は、差分開発、プロトタイプ型開発、スパイラルモデル(サイクルを回して小さな機能を順次追加し次第に大きくしていく)とも呼ばれます。しかし、反復型開発と言ってもかなり一般的な言葉で、具体的に開発の中で実践しようとしても、実際にどうするのかがはっきり決まっておらず、かなかな直ぐに実践できません。 そのため、スモールステップ開発は、反復型開発をベースにして、どのように開発するかをより具体的に決めて、それによって何がよくなるかを明確に考えたものです。スモールステップ開発は、直ぐに実践できるようにやり方を明確に示します。 UNIXの思想 UNIXの開発思想の1つに、「なるべく早くプロトタイプを作る」という言葉があります。これは、スモールステップ開発のポイントの1つにある、「各ステップで機能を素早く実装して、何らかの実行可能なソフトを作り上げる」といった点に通ずるところがあります。素早く実行可能なソフトを試作すれば、早くプロトタイプを作ることになります。
アジャイル開発 1990年代半ば頃に形成されたアジャイル開発(Agile software development)と呼ばれる開発方法があります。アジャイル開発は、開発を反復させる方法や反復の期間など、より具体的にやり方を定義した、反復型開発の1つと言えます1)。 アジャイル開発と同じように、スモールステップ開発も反復をベースにします。そのため、多くの点でやり方や考え方が似ています。アジャイル開発とスモールステップ開発の間で似ている点を次に挙げます。
一方で、アジャイル開発とやり方や考え方が違う部分があります。アジャイル開発とスモールステップ開発の間で違う点を次に挙げます。
■ 参考
※ご意見、ご感想、改善点、その他の情報などがありましたら、メールにてお知らせ願います。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
