開発手法

プロトタイプをサクッと作成する件

更新日:

私の開発のスタイルとしては、仕様書を作るよりまずはプロトタイプを作成し、それを見ながら仕様を詰めていくというやり方が好きです。

その方が絶対早いし、手戻りも少ないです。但し、私は業務系システムには弱いので基本はWEB系のサイト開発のお話ですが。

もちろんドキュメントを否定はしませんし、実際にドキュメントは最初に作るのですが、ドキュメント自体を作ることに工数はかけません。要するに仕様を明確にすることが重要なわけですから、メモ書きみたいなものです。いちおう絵は書きたいのでパワポにはしますが、本当にざっくりしています。

納品物ではなくでクライアントと意識あわせをするための資料なんでこれでよい。

仕様がだいたい決まったら、あとは動くものを見ながら詰めるのが一番だったりするわけです。

仕様なんて変わるに決まっているのに最初からガチガチにするから、あとで大騒ぎになるんです。まあ大規模システムだとウォータフォール開発するしかないので仕方ないですが。

このスタイルは2000年代初めころ、私がガラケー向けサイトを超短期で、バンバン作ってきた経験から生まれたものです。

その当時からアジャイルとかスクラムとかが、いろいろ話題になっていて、結構そうゆうのを取り入れています。

我流を承知で、わたしなりの手法を書いてみます。気に入ったら真似てみて。

1.クリティカルパスから作成する
サービスというものには、かならずサービスのコアになる遷移がいくつか存在します。コンテンツを配信する会員向けサイトなら 入会=>課金=>コンテンツ利用 となるでしょう。

まずはココだけを作ります。それ以外の機能は一旦無視です。まずはサービスの根幹部分を可視化して、クライアントと認識をあわせていきます。

 

2.仕様は変更され続けるものだと理解
クライアントと動くものを見ながら、あーだこーだやっていると、必ず仕様変更が発生します。そうゆうものだと理解しておきましょう。せっかく作ったプログラムを壊すことも多々ありますが、これは慣れですね。

 

3.バグは残してヨシ
上記のように、プログラムは常に書き換わる可能性があるわけですから、バグ取りに余計な工数を割いてはいけません。例えば、ある関数がどうしても期待通りの値を返してくれないなら固定で期待値
RETURN 1000;

とか書いてしまいましょう。今の目的は仕様を固めることです。なのでDB定義とかも粒度が粗くてOKです。

※バグ残していいけど、残したことを忘れないようにw

 

4.これはプロトタイプと伝える
動くものを見せられるとクライアントはもう出来上がっていると勘違いしてしまうケースがあります。気がつけばリリース日を縮められたり値切られたり。。。

これは紙芝居であるということを繰り返し伝えましょう。一番効果的なのはデザインを最後の最後までやらないことです。見た目が粗末であれば、できてない感じを醸し出すことができます。

 

5.パターンのストックをたくさん持つ
早く作るためには、最初からスクラッチ開発をしていてはダメで、部品をたくさんストックしておく必要があります。部品を組み合わせる感じです。

私はPHP使いなので、仕事をしながら個人的に部品を増やしてきたのですが、最近ではRUBY ON RAILSなるものが流行っており、さまざまな部品が簡単に手に入るようになりました。なので、今後はこっちを使うほうがよさそうな感じ。

ただ問題はRUBYのエンジニアが少ないことと単価が高いことです。私個人で完結する開発であればRAILSを使ったほうが良いと思うのですが、ある程度大きなプロジェクトになると外注するケースもあり、まだまだPHPの方が分業はしやすいです。

 

6.クライアントとのコミュニケーションは密に
基本的にクライアントとは話しやすい関係をつくりましょう。まあ、当たり前なのですが、システム開発のトラブルの多くはコミュニケーションロスから起因しています。

特にプロトタイプ作成の時は頻繁に話す必要があるので、電話、スカイプ、スラック大活躍です。

逆に話しずらい客の場合だと、言った言わないとか、めんどくさいことが増えていくのでまずはドキュメントありきのウォーターフォール手法になっていきます。

プロトタイプ開発は設計書ができてから、などという本末転倒なことが起きるのです。

個人的には、昭和な感じかもしれませんがキックオフで飲み会するとか、意外にそうゆうのが大事だったりすると思います。

-開発手法

Copyright© ばしさんの開発ブログ , 2019 All Rights Reserved Powered by STINGER.