無計画に作られたアプリケーションは仕様変更に弱い

本連載では、Google Android（以下、Android）を使った携帯アプリ作成を例に、マインドマップやUMLによる設計について学んでいきます。前回「第1回：UMLとマインドマップ」ではマインドマップ、UML、Androidの概要に加え、筆者が開発しているMame Talkの紹介をしました。今回はMame Talkの事例をもとにマインドマップの活用方法を紹介します。

筆者は携帯電話でインスタントメッセンジャーが使えると面白そうだと思いMame Talkの開発をはじめました。

はじめは特に何も考えず連絡先一覧画面とチャット画面があれば十分と思い、頭の中になんとなくあるイメージを頼りに開発を始めました。それから2週間後にグループチャット機能を残しほとんどの実装が終わりました。

その数日後、Android SDKのバージョンがM3からM5に上がったので最新バージョンのAndroid SDKをインストールしてみたところ、プログラムと設定ファイルに多くのコンパイルエラーが見かったので、あわててSDKのリリースノートを確認すると、パッケージ移動、クラス名の変更、メソッドの廃止、新規クラスの追加、新機能の追加など非常に多くの変更や改善が発覚しました。

リリースノートをもとに修正をしようと試みましたが計画的にプログラムをしていなかったため問題の特定に時間がかかり修正が難航しました。結局、影響範囲の特定ができずプログラムの大半を作り直す羽目になりました。このときはじめて無計画に開発をはじめたことを後悔したのでした。

この教訓を生かし変更に強いアプリケーションを作るため、筆者はアプリケーションの仕様をマインドマップにまとめて整理することにしました（図1）。

マインドマップの利点

アプリケーションの仕様をまとめるのに文章や表を使わずマインドマップを使うとどのような利点があるのでしょうか。

まずマインドマップはテーマにそってキーワードをつなげていくだけなので、いちいち文章を考えなくてもどんどん描いていくことができます。文章を考えているうちに大事なことを忘れてしまったということが起こりません。またテーマを中心に置き、そこから放射状にキーワードが広がっていくので全体を把握しやすいということも大きな利点です。目次と本文が一体になっているかのように内容が素早く理解できます。

このような利点から、開発の初期段階で仕様があいまいな時にマインドマップを使えば自分が今からどんなものを作ろうとしているのかが明確になり開発効率がアップします。

次のページでマインドマップをどのように使ったのか見てみましょう。 次のページ