| エンタープライズ：特集 | 2003/07/04 17:20:00 更新 |
C MAGAZINE 2002年8月号より転載
プログラムのレシピ――プログラミングの考え方・作り方 (4/13)
|
プログラミングを楽しむための準備（３） プログラミングの手順 |
キーボードを叩いてプログラムを書くこと（コーディング）だけがプログラミングではありません。いきなりコーディングから始めることもありますが、たいていはその前にプログラムの設計をするものです。設計にもいろいろと種類があります。プログラムにどんな機能を盛り込むのかという大まかな検討もあれば、画面レイアウトも必要です。データ構造やクラスのデザインといった、プログラム寄りの具体的な設計もあります。
プログラムを作ったあとのテストやデバッグのことも考えておきましょう。書いたプログラムが思いどおりに動かないこともよくあります。また動きは設計どおりでも速度が遅いときには、プログラムを改良して高速化をしなければなりません。
ひと口にプログラミングといっても、このようにさまざまな作業があるものです。そこで、プログラミングに必要な手順を一度確認しておくことにしましょう。
| 構想を練る |
まず最初にやるべきなのは｢何を作るか｣を決めることです。この段階では、できる限り多くのアイデアを出して、作るものの方向性や特徴、セールスポイントをはっきりさせましょう。個性があって魅力的なソフトウェアを生み出すには、構想をよく練ることが大事です。
たとえば｢グラフィックエディタを作ろう｣と思い立ったとします。いきなりプログラムを書き始めてもいいのですが、｢グラフィックエディタ｣だけでは何を作るのかがまだあいまいです。｢実際の絵の具に近い質感を再現するグラフィックエディタ｣とか｢プラグイン機能を中心にした機能拡張が容易なグラフィックエディタ｣といったように、構想を具体的にしましょう。
｢必要は発明の母｣といいますが、たとえば｢自分はこんなソフトウェアがほしい！｣というところから考えると、よいアイデアが出やすいものです。仲間といっしょに｢こんなソフトウェアがあったらいいね｣と議論するのもお勧めです。
アイデアというものは、出るときは出て、出ないときは出ないものです。そこで｢アイデアノート｣を作ることをお勧めします。ノートでも、メモでも、スケッチブックでもかまいません。アイデアが浮かんだら、イメージを文章や絵に書き留めておきましょう。テキストエディタやワープロでアイデアノートを作ってもかまわないのですが、走り書きしやすいとか、出先や移動中でも使えるという点では、普通のノートなどのほうが案外優れています。肌身離さず持ち歩いて、ネタをためましょう！
| 市場調査 |
プログラミングは時間と労力がかかる作業ですから、どうせなら世の中にまだないようなソフトウェアを作りたいものです。そこで構想と並行して、世の中にある似たようなソフトウェアを調べてみましょう。もしかしたら作ろうとしているものの同等品が世の中にすでにあって、改めて作る必要がないかもしれません。そうであっても悲観する必要はまったくなく、自分は別のジャンルのソフトウェアを作ればいいだけの話です。ただ、時間と労力をかけて作ってしまってから気づくとショックが大きいですから（笑）、構想の段階で気づいておきましょう。
もし、作ろうとしているものと似たようなソフトウェアが世の中にすでにあったら、どこかで差別化を図るべきです。どこを変えるかを見つけるのは簡単なことで、既存のソフトウェアを使ってみて、不満な点を見つければいいのです。たとえば、
- 機能が少ない
- 動作が遅い
- 値段が高い
といった欠点のうちいずれかは、ほとんどのソフトウェアにあるものです。
いちばん多いケースは｢自分に必要な機能がない｣ことです。｢ほしい機能が既存のソフトウェアにないからソフトウェアを自作する｣というのは、プログラムを自作するもっとも強力なモチベーションでしょう。
| 機能の検討 |
こういった構想や市場調査の結果を生かして、プログラムの機能を大まかに設計します。ここでもアイデアノートが役立ちます。ほしい機能を順に書いていくだけでもかまいません。新しい機能や重要な機能、実現が難しそうな機能に関しては詳しく検討してイメージを固めておくと、プログラミングが楽です。
この段階で画面イメージを描くのもよい方法です。GUIアプリケーションならばユーザインタフェイスを使いやすく設計する必要があります。ウィンドウやダイアログのデザインだとか、機能を呼び出すメニューやツールバーの構成といったものも、ある程度決めておきます。
機能を増やすことは重要ですが、機能を絞ることも大事です。重厚長大を志向しがちな市販ソフトウェアとは違って、個人で作るソフトウェアは｢小粒で気がきいている｣あたりを狙ったほうがうまくいくように思います。作業時間も限られていますから、目新しい機能や売りの機能を重点的に作りましょう。そのほかの機能は必要なものだけを先に作って、優先度が低い機能は余裕ができたら作り足せばいいでしょう。
| プログラム構造の設計 |
いよいよコーディングが近づいてきました。簡単な機能ならば、大まかに検討したあとすぐにコーディングを始めてもかまいません。でも少し複雑な機能は、データ構造やクラス構成を詰めておいたほうがうまくいきます。
クラスの設計に関しては、さまざまなオブジェクト指向の分析手法や設計手法が使えます。でも、こういった方法論を使わなければよい設計ができない、というわけではありません。設計の助けにはなりますが、無理に使う必要はまったくありません。
方法論は、プログラミングの合間の気分転換に学んでおくといいでしょう。ある程度プログラミングの経験を積むと、自分なりのスタイルができあがってきます。その段階で世の中の代表的な方法論を学べば、何となく身につけていたノウハウを頭の中で整理できたり、自分のスタイルを改良するヒントになったりします。たとえば｢デザインパターン｣や｢UML｣といった方法論は、初めてオブジェクト指向プログラミングを学ぶ人よりも、ある程度の経験を積んだ人にこそ恩恵をもたらしてくれます。
| 制作 |
コーディングで大事なのは、プログラムをどこから作り、どう進めていくかという手順です。なぜなら、プログラムには依存関係があるからです。｢モジュールAを作らないと、モジュールBが動かない｣という場合には、モジュールAとBをセットで作らなければなりません。
たとえばグラフィックエディタを開発するとして、画像フィルタから作ろうと考えます。でも画像フィルタのテスト/デバッグには画像を表示する部分が必要ですし、画像を読み込む部分も欠かせません。そこで最低限、表示部分と読み込み部分は画像フィルタといっしょに作る必要があります。｢プログラムをどこから作ればよいのか？｣はケースバイケースです。基本的には、以下の方針で進めればいいでしょう。
●作りたいところから作る仕事のプログラミングではこうはいきませんが、ホビープログラミングではこれがいちばん大事なことです。自分がほしい機能やコーディングがおもしろそうな機能から作りましょう。プログラミングを楽しむこと自体も目的なのですから！
●難しいところから作るプログラミングで怖いのは、｢途中で行き詰まる｣とか｢設計の破綻に気づく｣といったことです。これらを避けるには、自分が難しいと思うところから作るのがいいでしょう。プログラムの核心部分を先にやっつけてしまえば、あとの作業は気楽です。
●建て増し式に作るプログラムを綿密に設計するのは難しいことです。実際にコーディングすると見えてくることも多いですから、よい意味で｢建て増し式｣にプログラミングを進めるのがお勧めです。ただし、重要な機能や大まかな全体構造だけは設計しておきましょう。
●基本的にはトップダウンに作るトップダウンとは、プログラムの枝葉の部分ではなく、幹の部分から作ることです。サブルーチンから作るのではなく、プログラム全体の流れ（たとえばmain関数）から作っていきます。この方法を使うと、プログラムの全体構造がよく見えます。また、不必要なサブルーチンを作らずに済みます。
●ときにはボトムアップに作るトップダウンとは逆に、末端のライブラリ的な機能を先に整える方法です。末端の機能に難しい処理が集中しているときには有効です。たとえば画面出力まわりやネットワークまわりの基本機能を作ってからプログラム全体を構成する、といったことはよくあります。
●いつでも動くように作るこれはもしかしたら、いちばん重要なことかもしれません。たとえば一度もプログラムを動かさずに10,000行のコードを書いてからデバッグするのと、100行ごとにこまごまと動かしてデバッグするのとでは、どっちが楽でしょうか？ もし書きためた10,000行のコードに重大なバグがあってまったく動かなかったら、泣きそうになりますよね！ それに比べればテストの回数は増えますが、常にプログラムが動く状態にしておいて、少しずつコードを足していったほうがずっと楽です。
| テストとデバッグ |
プログラミングにはテストとデバッグがつきものです。新しい機能を作ったら、こまごまとテストしましょう。こうすれば、もしバグが発生してもそれは新しく作った部分で起こっていることがほとんどですから、原因の特定が簡単です。 テストの効率化にも注意を払いましょう。たとえばテストに大量のデータが必要なソフトウェアを、いちいち手入力でテストするのはたいへんです。少なくとも、テスト用のデータをファイルで用意するくらいの工夫は必要ですね。また、ときにはテスト専用のルーチンを書かなければならないこともあります。これはプログラムの本筋には関係ない、どちらかといえば億劫（おっくう）な作業ですが、一度テスト体制を整えておけば開発作業全体の効率がよくなります。
デバッグにはプログラマの｢勘｣が大事ですが、手慣れたプログラマでも｢勘違い｣をすることは多々あります。勘違いを避けるには、デバッグ用の道具を活用するのがいちばんです。ほとんどの統合開発環境は高機能なデバッガを備えています。まずはこれを使いましょう。またアサーション（assertion）などのデバッグ向け機能も有用です。
| 改良 |
プログラムはただ｢動けばいい｣というものではありません。残念ながら世の中には｢動けばいい｣といった趣きのプログラムも散見されますが、そういったものは使っていてあまり快適ではありません。できあがったプログラムには、できる限り改良を重ねて完成度を高めるべきです。
プログラム、とくにツール系アプリケーションの主な改造ポイントは｢ユーザに接する部分｣です。つまりユーザインタフェイスの使いやすさ、レスポンスのよさ（高速性）、見た目のよさといったところです。もちろんプログラムの内部構造をキレイにすることも大事ですが、どうせやるなら使ったときに改善の効果がわかる部分から改良するのが得策でしょう。
プログラムの高速化に関してはおもしろい格言!? があります。
｢プログラマに速いマシンを与えるな｣
速いマシンを使っていると、プログラムが遅くても気づかず、ついつい高速化を怠ってしまうからです。とはいえ、わざわざ旧式のマシンを引っ張り出してきて使うには及ばないでしょう。コンパイルやリンクが遅いのは困りますからね。ただプログラムをほかの遅いマシンで動かしてみて、高速化のヒントにすることは重要です。
| 完成と公開 |
プログラムが完成したら、ぜひ世の中に広く公開しましょう！ 自分のWebページで公開してもいいですし、ソフトウェアダウンロードサイトに登録するのもよい方法です。公開の際にはヘルプを用意したり、場合によってはインストーラを作る必要もあります。
作ったプログラムは、フリーソフトウェアとして公開するのが理想です。同じ機能を持ったソフトウェアでも、フリーソフトウェアとシェアウェアでは、受ける印象がまったく違うものです。フリーソフトウェアに対しては｢こんなに機能が豊富なのに無償で提供してくれるなんて！｣という感謝の気持ちを抱きがちですが、シェアウェアでは｢○○○○円も取っているのにこれしか機能がないなんて！｣という不満の気持ちを起こしがちです。
ソフトウェアは商売の道具にもなりますが、それだけでは寂しいものです。自分が作ったソフトウェアを喜んで使ってくれる人がいるのは、ほかではなかなか味わえない楽しみです。またソフトウェアを作ろうという意欲が湧いてきますしね。ときには改良の参考になる意見をもらえたり、貴重な仲間ができたりするかもしれませんよ！
前のページ | 1 2 3 4 5 6 7 8 9 10 11 12 13 | 次のページ
[松浦健一郎（ひぐぺん工房），C MAGAZINE]
Copyright © ITmedia, Inc. All Rights Reserved.
