サービス開発における工程

24
ササササササササササササ

description

about development method for service.

Transcript of サービス開発における工程

Page 1: サービス開発における工程

サービス開発における工程

Page 2: サービス開発における工程

自己紹介 名前: 森 英寿

職業: フリーランスプログラマ

住所: 宮城県仙台市

開発言語: Java/Ruby/PHP/VB/VC++/Objective-C

Twitter:   @h_mori

Facebook:   facebook.com/hidetoshi.mori

サービス開発実績: TweetMe SOICHA ATND 暦

Page 3: サービス開発における工程

自己紹介職歴:

株 )JIEC (2000-2004)基幹業務開発プログラマ

株 ) フライトシステムコンサルティング (2004-2011)基幹業務開発プログラマ、プロジェクトマネージャ基幹業務コンサルタントサービス開発プログラマ、コンサルタント

Page 4: サービス開発における工程

ソフトウェアの開発工程とは実装したいことをまとめる

どこまでの機能を作るか決める

どのような仕様で作るか・どのように実装するか決める

ソースコードを書く

決めた仕様に即して動くかテストする

※ 大雑把にウォーターフォール型か反復型に分類される

Page 5: サービス開発における工程

ウォーターフォールモデルウォーターフォールモデル

要件定義基本設計詳細設計コーディングユニットテスト ( UT )インテグレーションテスト (IT)システムテスト ( ST )運用テスト ( OT )

Page 6: サービス開発における工程

ウォーターフォールモデルの特徴

前工程に間違いがない前提

工程を確実にスケジューリング

コーディング比率 (約1割)

有効なケース運用サイクルが長い (約10年)開発期間 (約半年〜3年)

Page 7: サービス開発における工程

ウォーターフォールのメリット

作業見積の誤りが少ない

各工程で FIX するため手戻りが少ない

大規模でも進捗を把握しやすい

一定の製造品質を担保できる

運用保守を見越しているため運用コストが低い

Page 8: サービス開発における工程

ウォーターフォールのデメリット

初期投資コストが高くなりやすいコーディング率が低いため

後工程での仕様変更に多大のコストが発生しやすい

Page 9: サービス開発における工程

アジャイル開発スパイラルモデル (反復型)

プロトタイプ開発

方法論エクストリームプログラミング ( XP )テスト駆動開発 (TDD)ペアプログラミング(ペアプロ)ソースコードの共有化BTS におけるタスク管理

Page 10: サービス開発における工程

エクストリームプログラミング

共同化 イテレーション、フィードバック 用語統一

開発 テスト駆動開発、リファクタリング、結合試験サイクルの短縮 ペアプログラミング、コードの共同所有 YAGNI

管理 責任の切り分け、タスク分離( BTS 等の活用)

コンシューマ コンセプト設計、計画、短期リリース

Page 11: サービス開発における工程

テスト駆動開発( TDD )品質向上の目的ではなく開発者がコードに確信を裏付ける目的

開発サイクル(Red) テストコードと失敗する本体コードを書く(Green) テストがパスするように最低限のコードを書く(Refactor) テスト成功を保持したまま、シンプル化し完成させ

TODO リストの利用

向かないケース並列処理GUI を扱うもの

Page 12: サービス開発における工程

ペアプログラミング2人(ドライバ・ナビゲータ)が1台の PC に向かって作業

ドライバがテストコードを書く間に本コードの実装を考える

メリット コード所有およびコードレビューを兼ねている教育に向く サボれない

デメリット スケジューリングのズレによりトータルコストが上がる場合があ

Page 13: サービス開発における工程

アジャイル開発の特徴予測困難な要件・仕様に適応しやすい

熟練した開発者を要する

有効ケース少人数開発の場合 (10人以下)ミッションクリティカルでないシステム開発開発者が遠隔でない開発期間が短い

Page 14: サービス開発における工程

アジャイル開発のメリット初期投資コストが安くなる場合が多い

課題点が早期に発見されやすい

仕様変更に適応しやすい

Page 15: サービス開発における工程

アジャイル開発のデメリット作業見積が取りにくい

一括受託の場合、際限ない仕様変更になりがち

保守コストが膨れ上がることがある

大規模人数の場合、プロジェクト管理が難しい

Page 16: サービス開発における工程

アジャイル開発のポイントプロジェクトの性質的に適合するか検討する

あくまで方法論(ツール)であり目的ではないコミニュケーションの取り方作業者の精神的負荷を減らす目的

カウボーイコーディングにならないように

Page 17: サービス開発における工程

サービス開発の背景初期投資であり収益化は半年後〜1年後

低予算スモールスタート

低人数1人で開発することもあり得る

短い開発サイクル1日〜3ヶ月

時流に合わせた仕様変更世の中は激しく変化している

Page 18: サービス開発における工程

サービス開発のサイクルコンセプト設計、ターゲット分析

メイン機能に注力したプロトタイプ開発

β リリース

ユーザー動向をウォッチ (売上確認)

続投の判断 (売上見込調査)

拡張開発・仕様変更 

3ヶ月

Page 19: サービス開発における工程

初期計画収益構造 (ビジネスモデル)

サービスの目的、コンセプト設計

ターゲット層の分析

競合分析

収益予測 (利用ユーザー見込・単価)

経費コスト算出 開発費、デザイン費 コンテンツ使用料 販促費 (広告費)

スケジュール策定

Page 20: サービス開発における工程

インタラクションデザインの重要性

ユーザーエクスペリエンス・ユーザビリティの向上

製品を効果的に利用できるようにデザインを目指す 機能の単純化視覚効果の利用

ユーザーシーンを考慮 5W1H を考える

ユーザーターゲットを明確に性別、年齢層、文化背景 等

※ 例) iPhone

Page 21: サービス開発における工程

リリース計画リリースタイミング

サービス機能性(品質)と早期ローンチのバランス時流の動向に即したタイミング

プロモーション方法 プレスリリース メディアへの露出 動画・サイト作成 ゲリラマーケティング

ユーザー囲い込み導線の作り方 ユーザーに対するインパクト

Page 22: サービス開発における工程

中期計画収益予測の見直し

サービス方針の見直し

ターゲット層の拡大

効果的なプロモーション方法の再検討

運用方法、運用コストの見直し

Page 23: サービス開発における工程

私見アジャイル的な開発手法が向く

企画者も開発者も知恵を絞ることが重要サービスを作る上で正解はない企画と技術とニーズがマッチした場合のみヒットする

何よりもプロモーションが重要

サービスの価値は品質よりコンセプトが評価される

Page 24: サービス開発における工程

ご清聴ありがとうございましたm(_ _)m