IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

スマホアプリの開発フローをまじめに考えてみた

ウォーターフォールアジャイルモックアップ、デザインスプリント

色んな開発手法があるが、どうにもしっくり来ないのでまじめに考えてみた

 

各フェーズの構成要素はこのように考えた

 

仕様  →何をどうしたいのか

データ構造  →抽象度の高い大きな要素 ex:ユーザー、商品、記事、アルバムと、その関係)

UX  →いつどこで何をどういう風に見せるか。UIの上位概念のようなもの

UI・デザイン  →画面の構成、見た目の部分

 

webでも何でも、構成要素としては大差ないだろう。

ただ特にアプリは、これらの要素一つ一つが適当で片付けられない程度であり、しかもちゃんとやるにはナレッジが溜まっていない

 

どの要素がどの要素に影響されて決まるかは、下の図のようになると思う

f:id:otihateten3510:20150624223524p:plain

 

アプリは特に、プロダクトベースで作るべきという論調が多いことでも分かると思うが「作ってみないとわからない」ということが多い

そしてwebと同等に短納期だ

 

なので、良い物をつくろうとすると絶対に手戻る

この時点でウォーターフォールは無理だ

 

だからアジャイルで作ればいいとか、デザインスプリントで作ればいいという意見があるがそれもちょっと違う

web界隈で流行っているアジャイルの方法論は、各担当が同時並行で仕様にコミットしていくやり方だが、図でも分かる通り、各担当は同時に走りづらい

なのでどこかで破綻するか、誰かが待ちになるような効率の悪い状態となる

(ちなみに、スクラム駆動開発をアプリに適用したことがあり、しっくり来なくて気づいた)

 

そこで必ず最低1度は手戻るように順序立てたのが上図となる

 

要は想定外のものが顕在化するまで無理やり話を前に進めることで、不確実性を徐々に取り除いていくという作戦だ

「作ってみないとわからない」なら一度間違ってもいいので作ってみる、というのはもちろん合っているが、それだと途中のフェーズで間違っているのに気づいたまま進む事になるので、各フェーズで一回手戻る

 

図にもあるが、具体的に言えばこの手順だ

 

必ず手戻る前提になったアプリ開発フロー

1.要求定義

  何をしたいか、企画の話を聞く

2.フィジビリティスタディ

  簡単なデータ構造を作る(外部設計者、内部設計者)

  技術的にその構成で実現可能か調べる(PM,外部設計者、エンジニア)

3.要件定義、提案

  ここで仕様に手戻り、企画が破綻しないか、実現可能かまた相談し、仕様に落としこむ

4.デザインスプリント

  基礎となるデータ構造を満たした形でアイディアを出し、UX(ストーリー、手順)に落としこむ

  ここでデータ構造に出戻り、データ構造をアップデートする

  また、仕様にも手戻り、仕様をアップデートする

5.外部設計(仕様+データ構造→UX→WF→デザイン)を行う

  なお、最後はUXに手戻り、データ構造に手戻る

6.外部設計(仕様+データ構造→IF)を行う

  なお、最後はデータ構造に手戻る

7.外部設計(UXに合わせたIFの調整)を行う

  なお、最後はデータ構造に手戻る

8.仕様に手戻り、5,6,7で出てきた問題をフィードバックし仕様をアップデートする

9.外部設計をもう一度、不確実性の無いようにキチンと行う

10.内部設計、実装する

 

 

実際のところ、そこそこの規模の開発をしている人は「まあそうなるよね。それが当たり前でしょ」と思うかもしれない。

が、基本的にスケジュールは手戻りのない形で組まれたり、アジャイルと称してざっくりとしたミーティングをすることが多いのではないだろうか。

それはウォーターフォールのようなフローチャートを頭に描けないからだと思う(私もそうだった)

このように必ず1回は手戻るという前提に立てば、フローチャートは描けるのではないだろうか。

 

 

 

 

と、ここまで何となく考えたはいいが、正直これを実行するのはかなり骨が折れると思う

何故なら関係各位にこのフローを納得させなければならないからだ

ひょっとしたら、表向きのスケジュールと裏スケジュールで分けたほうがよいかもしれない

 

 

私が主張したいことはむしろ「こうすると上手くいく」ではなく、「どちみちこのフローチャートは避けられない」ということだ。これを避けようとするとどこかで破綻する。

 

であればそれに則ったスケジューリングをした方が見通しが立ちやすいし、要らぬ手間もなくなるのではないかと思う。

破綻しそうになった時、この手戻りフロー分をどうにかするのは「何とかする系エンジニア」なのだ(´・ω・`)

 

そしてもう一つ、主張したいのが外部設計者の重要性

 

ウォーターフォール型にすると、途中で上流の人が別のプロジェクトに移るなどの問題が発生する。そうじゃなくても、予定が崩れ他のプロジェクトと足並みが合わなくなり燃え広がることになるだろう

もっとマズイのが、そもそも外部設計者を用意していないケースだ

(要件定義→実装 のような、中間をイメージ出来ていない状態)

そういう場合、よっぽどスケジュールに余裕が無い限り必ずQCDのどれかが破綻すると思う

 

 

メモ:

※アプリ規模として3人月以上のものを想定している

※外部設計者と言っているのは、大規模SIで言うところのアーキテクチャだ。小規模(〜50人月)の場合、アーキテクチャを立てないケースが多い