Log in

要件は定義できるという幻想【opinions】

OPtitle oishi 

ソフトウェア開発とは要件定義→設計→実装→テストと順番に進めるものと勘違いされている方が未だにおられます。半年の工期のうち最初の1カ月は要件定義、次に設計、そして実装は2カ月程かけて最後の1カ月間はテストにしましょうといったガントチャートが典型的な例でしょう。

どなたにも心当たりのありそうなことですが、一度問いかけてみていただきたいのは、定義した要件に従って設計して実装してもらって一発で使いやすいものができた…ということがこれまで一度でもあっただろうかということです。おそらく答えはNOでしょう。

IMG 0008

古い時代の発想を捨てる

手作業をコンピュータの力で自動化するといういわゆるOffice Automationの文脈でソフトウェアを開発していた時代はすでに終焉を迎えました。コンピュータ石器時代の発想は一度頭から捨て去る必要があります。

特に昨今のモバイルアプリは旧来のソフトウェアに比べて驚くほど高度になっており、要件を100%洗い出すことはもはや不可能です。また、業務用のモバイルアプリにいたっては、つくり手はおろか顧客の情報システム部門さえ開発したものを使うことがないという、つくり手と利用者の環境乖離という問題があり、現場からの要件に対する理解はますます難しくなっています。(モバイル業務改革を支えるサービスその1「GPS Punch!」前編後編を参照)

これからの時代、要件とは「定義する」ものではなく「つくりながらあぶり出す」「使いながら顕在化させる」ものであるという前提で、私達はモバイルアプリと付き合っていく必要があるのではないでしょうか。

プログラミングせずにつくる

とはいえ、いきなりプログラミングを始めるのは愚の骨頂。つくるという行為は何もプログラミングだけを指しているわけではありません。プログラミングをまったくせずに動くものをつくる「プロトタイピング」という手法を積極的に使うべきです。大げさに構える必要はありません。昨今のモバイルアプリ市場の盛り上がりを受けて手軽なツールも充実してきていますので、これから何回かに分けて御紹介したいと思います。

まずはペンと紙を使うアナログなプロトタイピングから。

実はコピー用紙とペンがあれば十分です。画面の絵を描いてみて、ココを押したら次はこの画面…というように画面遷移を思い浮かべながら次々と画面の絵を描いていく手法です。動くものをつくるといっても動くのは自分の頭の中。それだけで十分です。実際にユーザが使っていることを想像しながら、どこをどうしたらどうなるかをなるべく漏れなく描き出していくのがポイントです。

IMG 0007 

この作業を行うだけで、お客様が想像できていなかった使用パターンがあぶり出せたり、実装上の課題や問題点や新たな検討事項を見い出せたりすることが多々あります。これがつまり要件のあぶり出しです。単に画面の絵を描く作業と侮る無かれ。例えば、ボタンやタブの位置の検討をきっかけに「結局このアプリでユーザーは何をするべきなのか?」という根源的問いに立ち返り、本来行うべきこと(真の要件)をより明確に導き出せるといったこともあります。 

絵が描けたらお客様にも確認してもらって、場合によってはああでもないこうでもないと議論して一緒に仕上げていく、この過程がすべてプロトタイピングです。 

使う紙はコピー用紙の裏紙がもっとも手軽ですが、UX/UIの分野でも有名な THE GUILDの深津氏が制作したプロトタイピング用ノートはお勧めできる小道具のひとつです。

1ノート実物。iPhoneが最初から描かれている。画面内は方眼で手書きしやすい。iPad版もある

モバイルアプリは画面サイズが限られています。このノートにはiPhoneやiPadを模した絵があらかじめ描かれていて、画面の狭さをあらかじめ制約として課しながらプロトタイピングできるというメリットがあります。実際の使用イメージがより想像しやすくなるようにできています。

まれに、描いたものをコピペしやすいからという理由で、いきなりドロー系ツールやPhotoShopを使ってデジタルにプロトタイピングを始めてしまう方もおられますが、残念ながら潜在的な要件をあぶり出せる確率は低い傾向にあります。おそらく変に微細な部分を描き込むことを始めてしまえるからかもしれません。まず手書きからつくってみる。これが鉄則です。

弊社がお世話になっているデザインパートナーさんは、ペンとコピックを使ってプロトタイピングされていました。やはり手で描くほうが要件のあぶり出し率は高くなる傾向があるように思います。手書きの早さが考察の時間を増やしてくれるのでしょう。前述の深津氏も紙とペン、コピックによる手書きを推奨されています。(同氏のブログfladdict「ペーパープロトタイピング入門」も参照)

3A4サイズに畳んで持ち運べるホワイトボード。画面案の議論がどこでもできる

また、もし現場に出てお客様やユーザー様と直接議論するような場合には、持ち運び型のホワイトボードも重宝するに違いありません(写真はButterflyBoard。個人的には、前述のプロトタイピング用ノートのホワイトボード版のようなものもあれば非常に便利ではないかと考えています)。

潜在要件を如何に顕在化させるか 

ご紹介したとおり、いろいろな道具を駆使してアナログにプロトタイピングを行うことができます。何度も何度もつくって壊してを繰り返すことが一番のメリットです。その過程で明示されていない要件を明らかにしていけるからです。どんな案件でも思ったより考慮漏れがあることに毎回驚きますが、この感覚は実際にプロトタイピングをやってみないとわからない感覚です。ぜひ、実践してみてください。

前回エントリ『独自の業務用アプリを外注する矛盾でも書きましたが、ソフトウェア開発は現場利用者の理想形に徐々に近づけていく漸近的なプロジェクトでなければななりません。開発とは、潜在的な要件を顕在化させる作業でもあると言えます。その意味で、本当に要件を定義しきれるのは開発物が完成したときです。その定義行為を最初に持ってきている時点で、ウォーターフォール型の開発はモデルからして破綻しているのです。

要件は定義できるという幻想を捨て、つくりながら要件をあぶり出していくようにしていきたいものです。次回はアナログとデジタルを融合し、本当にiPhoneやiPad上で動くプロトタイピングができるツールをご紹介します。

執筆者

大石裕一氏/1975年大阪生まれ。大阪府立大学工学部卒業後、ソフト開発会社にエンジニアとして入社。6回の転職でWindows/Mac/Linux/組み込み系、ネットワーク系の開発やマネージャ経験を経て、2006年株式会社フィードテイラーを設立。エンタープライズiOS分野を得意とし、安易な新規業務アプリ開発を否とする考えを持つ。自社で開発したクラウド型ファイル共有サービス「SYNCNEL」を海外含む約200社に提供中。