スマホアプリの開発工程、技法について

Question

スマホアプリの開発(とくにSwiftによるiOSアプリ)の以下についてご教授ください。
・スマホアプリの開発工程、開発技法と、各工程で決定すべき事項
・各工程ごとの具体的な成果物の残し方(設計書やテスト仕様書、テスト結果等)

このような質問をした背景ですが、私はCOBOLやJavaなどによる業務アプリケーションの開発を事業の中心とする会社に勤めております。私自身もCOBOL一辺倒の仕事をしておりましたが、この度、社内で初めてスマホアプリの開発を行う部署を立ち上げ、そこに異動することとなりました。

SwiftによるiOSアプリの開発は独学で趣味でポチポチ作る程度はできますが、仕事としてのアプリケーション開発についてはズブの素人のため、開発工程や技法についてのノウハウが無い状態です。

これまで、完全なウォーターフォールによる開発しか経験しておりませんが、スマホアプリの開発においては必ずしもウォーターフォールが当てはまるとは思っておらず、模索している最中です。

そこで、上記のような質問をすることとなりました。
大変大雑把かつ概念的な質問であることは重々承知しておりますが、社内でのノウハウ作りをゼロから始めるこのような機会はなかなか無いので、なんとかモノにしたいも考えております。

Swiftの解説や簡単なアプリの製造部分については一般的な書籍が多数販売されておりますが、そこに至るまでの設計段階やテスト工程についてはあまり書籍がない印象です。

具体的なサンプルアプリを元に、設計からテストまでの一連の考え方や成果物の残し方を学べる解説書がありましたらご教授ください。

なお、現状はSwiftによるiOSアプリの開発を進めるので、それに直接当てはまるアドバイスいただけたら大変ありがたいです。また、当てはまらない場合も「Androidはこうしている」や「Webアプリはこうしている」など応用できることがありましたら、ぜひ宜しくお願いします。

Answer 1

なんとなく開発経験の長い方と想像しますが、開発手法って結局
1.開発過程のステイクホルダー(受注先、上司、株主等)との良い関係
2.プロダクトにとって良い方法
3.自分たちにとって良い方法
のバランスで成立するものだと思います。が、話が大きくなるので一旦2についてだけ簡単に。
私がひとつだけ絶対にやった方が良いと思ってる開発フェイズは「プロトタイプ」。
アプリ開発の基本は「さわり倒す」だと思ってます。
たとえばゲームなんかだと
プロトタイプ+設計->開発->社内β->クローズドβ->リリース->アップデート
とにかく設計からリリース後まで
さわってみる・さわってもらう+反応や意見を聞いて直す
の繰り返しです。アプリは手触り悪いと救いようがありません。
ここさえ担保できれば開発モデルはとりあえず「自分たちにとって良い方法」を選べば良い。

Comments

[wai21]

回答ありがとうござます。

> 2.プロダクトにとって良い方法
> 3.自分たちにとって良い方法
まずはこの2点を模索して自分たちのカタチを作っていこうと思っています。

`プロトタイプ` を大変重視されているとのことですが、UI/UXに関する意見をより多く集め、なるべく早い段階で固めようということでしょうか。

仕様の確度が大変高く、業務内容に特化した開発ではプロトタイプという発想がなかったので、大変興味深く感じました。

[kurokoba]

>なるべく早い段階で固めようということでしょうか。
これは一般論というより一意見として聞いていただきたいのですが。
「ソフトウェア工学」という分野って非常に曖昧な分野だとはおもうのですけれども、以下の2つはわりとはっきりした事実だと思います。
・良いものをつくろうとすれば仕様変更は発生する。
・工期の短縮を増員で補おうとすることはできないor乗数的にコストがかかる。
ウォーターフォール以降に出てきた開発モデルってある意味これに対するリスク回避だと思ってます。たとえばアジャイルは
・仕様変更は避けられないので仕様変更に耐性のある開発スタイルにする。
・長期・大人数はリスクがでかいので短期・少人数の計画を積み上げる。
という守りの思想だと思います。別にアジャイルをお勧めはしませんが「早い段階で仕様が固まってないと瓦解する」開発スタイルは良いものを作る上で無視できないリスクではないでしょうか。
たしかにプロトタイプ作成は余計な工数をかける分、仕様を固めるうえで効果があります。が、むしろ以下の効用が大きいと思います。
1.使えないものをつくちゃうリスクの回避
2.技術課題の早期発見
3.ゴールの共有
特に1です。業務システムの画面やWEBサイトでも紙芝居的なデザインレビューってやりますけどアプリは操作感あってのデザインなので。ウォーターフォールで進めるにしても、適切なチェックポイントを設けるとか成長モデルに近い形をとるとか、"使いにくいものに妥協しない"体制が理想です。
※これはアプリ云々というより業務システムか一般向けのソフトかの違いに起因することでもあります。業務システムはユーザ(=オペレータ)は「操作を覚える事も仕事」なのに対し消費者は使いにくいものは切るだけなので。

[wai21]

> 「早い段階で仕様が固まってないと瓦解する」開発スタイルは良いものを作る上で無視できないリスクではないでしょうか。

これまでウォーターフォールで開発する中で、なんとなくモヤモヤと疑問というか、解決したいと思っていたことをズバッとご指摘いただいて、ものすごく納得しました。
いきなりウォーターフォールを捨てるとか、アジャイルに完全に移行するのではなく、まずは自分たちの開発を見直してどこにリスクが潜んでいるのかを一つずつ潰していこうと思います。

プロトタイプの工程については今の自分たちのレベルでどの程度開発に組み込めるかわかりませんが、少しずつ検討したいと思いました。

本当に貴重なアドバイスありがとうございます。

Answer 2

開発手法となるとウォーターフォールかアジャイルかという話になると思うのですが、Wikipediaのアジャイルソフトウェア開発がよくまとまっているので、それを引用します。

アジャイル開発の得意とする状況
クリティカルではないシステム (顧客の業務に重大な支障をきたす可能性がなく、人命に関わらないシステム)
熟練した開発者が参加する場合
開発中に頻繁に要件が変わる場合
開発者が少ない場合
混沌とした状況に対しても意欲的に取り組む組織的文化

計画重視開発の得意とする状況
クリティカルなシステム (顧客の業務に重大な支障をきたす可能性がある、もしくは人命に関わるシステム)
経験の浅い開発者が多い場合
開発中に要件がほとんど変わらない場合
開発者が多い場合
秩序を重視する組織的文化

社内で初めてスマホアプリの開発を行うのであれば、スマホアプリだからと構えず、まずは社内で実績のある手法で一度開発し、次のステップとして開発手法の見直しを検討していった方が無理がないと思います。

私個人の判断としてはシステムの内容にもよるのですが、結局のところプロトタイプとリリースの期間の違いなので、チームにリリースのタイミングを決定できるレベルの技術者がどの程度いるかで、プロジェクトの進め方を決めることが多いです。

Comments

[wai21]

回答ありがとうござます。

> 熟練した開発者が参加する場合
以外はアジャイルの得意とする状況に当てはまると思います。
とはいえ初めてのため、ご指摘の通り、これまでの手法から出発し、徐々に改善を繰り返すのが現実的のようですね。

> 結局のところプロトタイプとリリースの期間の違い
大変申し訳有りませんが、これはどういうことでしょうか。
開発開始当初はリリースの時期を決めず、プロトタイプを作成した段階で、リリースまでの期間を決定するということでしょうか。

[shoko1]

> 開発開始当初はリリースの時期を決めず、プロトタイプを作成した段階で、リリースまでの期間を決定するということでしょうか。
ほぼ逆です。アジャイル開発の場合、短い期間を決めてリリース可能なプロトタイプを開発するサイクルを繰り返すので、このサイクルを管理・最適化できるレベルの技術者が必要になります。でないと、負債が増えて自転車操業になります。

[wai21]

ご指摘ありがとうございます。

確かに、短期間であればあるほどそこを管理する技量が問われますね。
経験を重ねるにつれて、管理面も学ばなければならないと思いますのでら開発者として手を動かしつつも管理面の意識も持つべきですね。

本当に貴重なアドバイスありがとうございます。