Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 115 Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

A los espectadores también les gustó (20)

Anuncio

Similares a [ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用 (20)

Más de masashi takehara (16)

Anuncio

[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用

  1. 1. 2011.12.7 クラスメソッドセミナールーム 永和システムマネジメント × クラスメソッド 共催セミナー 第4セッション 小さく作って大いに役立つ スマートフォンアプリ for iOS, Android, Windows Phone クラスメソッド株式会社 技術部 マーケティング担当 認定スクラムプロダクトオーナー 嵩原 將志 タケハラ マサシ (Tw:@take3000)
  2. 2. 自己紹介 タケハラ マサシ http://twitter.com/#!/take3000 http://takelog3000.blogspot.com 嵩原 將志 http://slideshare.net/takelog3000 Takehara Masashi http://design.classmethod.jp/ Project Management FxUG/DevLOVE /Agile(Scrum)/RIA /UX Design /要求開発アライアンス 職人(LT,KPT,釣 Marketing/Procurement り)ADK48/ナナナナ会
  3. 3. 本日のアジェンダ 1.スマートフォンアプリの概要 2.モバイルOS、開発ツール 3.クラスメソッドのプロセス 4.まとめ
  4. 4. 今日のテーマ やってみよう (さわってみよう)
  5. 5. いいかえると…、 カタログスペックだけで 大事なことを決めない
  6. 6. アジェンダ 1.スマートフォンアプリの概要 2.モバイルOS、開発ツール 3.クラスメソッドのプロセス 4.まとめ
  7. 7. スマートフォンアプリ の状況をおさらい
  8. 8. 日本国内のスマートフォン利用者数 (2011年3月) Android 4,601,000 iOS(iPhone) 3,906,000 その他 1,257,000 総数 9,764,000
  9. 9. 3プラットフォームのアプリ数 Apple アプリ数20万本 2010年6月 総DL数100億 2011年1月 Android アプリ数20万本 2011年1月 総DL数60億 2011年9月 Windows Phone アプリ数3万本 2011年8月
  10. 10. スマートフォンの業務利用 ・在庫管理 ・営業ツール ・トレーディング ・決済 ・グループウェア
  11. 11. かかえる問題 ・プラットフォームの選択 ・開発ノウハウ ・運用ノウハウ (特にセキュリティ)
  12. 12. アジェンダ 1.スマートフォンアプリの概要 2.モバイルOS、開発ツール 3.クラスメソッドのプロセス 4.まとめ
  13. 13. 現在、主要なモバイルOS
  14. 14. (iPhone, iPad)
  15. 15. Develop for iOS iOS SDK、Xcode、Objective-C http://developer.apple.com/jp/technologies/tools/whats-new.html
  16. 16. Android
  17. 17. Android Android SDK(Java) Android NDK(C++)
  18. 18. Windows Phone
  19. 19. Windows phone Silverlight for WP(XAML) Visual Studio 2010 Expression Blend 4
  20. 20. ─ Principles ─ Clean, Light, Open, Fast Design Language Celebrate Typography “Metro” Alive in Motion Content, Not Chrome Authentically Digital http://www.microsoft.com/windowsphone/en-us/features/default.aspx
  21. 21. その他の実装方法 http://everystockphoto.s3.amazonaws.com/favourite_tools_739247_o.jpg
  22. 22. AIR for Mobile Device OS (iOS、Android、Blackberry)
  23. 23. Adobe Muse Adobe Edge
  24. 24. HTML5 + Javascript
  25. 25. Web or HTML Desktop App
  26. 26. Touch
  27. 27. 多用なプラットフォーム Web か ネイティブアプリ か
  28. 28. スマートフォンアプリに限らず 技術選択の際に考えること
  29. 29. ① 移植容易性 ② 開発生産性(向き不向き) ③ テスト(環境種類別) ④ 技術習得難易度 ⑤ 技術者数 ⑥ 開発期間+稼働期間
  30. 30. ① 移植容易性 ② 開発生産性(向き不向き) ③ テスト(環境種類別) ④ 技術習得難易度 ⑤ 技術者数 ⑥ 開発期間+稼働期間
  31. 31. ストーリー
  32. 32. ストーリー 開発のサイクル
  33. 33. ストーリー 開発のサイクル
  34. 34. ストーリー 開発のサイクル タスク
  35. 35. ストーリー 開発のサイクル タスク
  36. 36. ストーリー 開発のサイクル タスク サブタスク
  37. 37. ストーリー 開発のサイクル タスク サブタスク
  38. 38. 出荷可能な (利用可能)な ストーリー 開発のサイクル プロダクト タスク サブタスク
  39. 39. プロダクト開発のサイクル 出荷可能な (利用可能)な ストーリー 開発のサイクル プロダクト タスク サブタスク
  40. 40. プロダクト開発のサイクル 出荷可能な (利用可能)な ストーリー プロダクト タスク サブタスク 開発のサイクル 向いていない技術を選択した場合
  41. 41. プロダクト開発のサイクル 出荷可能な (利用可能)な ストーリー プロダクト タスク サブタスク 開発のサイクル 向いていない技術を選択した場合
  42. 42. プロダクト開発のサイクル 出荷可能な 更に分割された (利用可能)な ストーリー サブタスク プロダクト タスク サブタスク 開発のサイクル 向いていない技術を選択した場合
  43. 43. プロダクト開発のサイクル 更に分割された 出 サブタスク (利 ストーリー タスク サブタスク 開発のサイクル 向いていない技術を選択した場合
  44. 44. 間延びしたプロダクト開発のサイクル 出荷可能な 更に分割された (利用可能)な ストーリー サブタスク プロダクト タスク 開発のサイクル サブタスク 採用した技術によっては必要以上の タスク分割が発生し、リリースのス ピードを下げてしまう。
  45. 45. 向き不向きも大事 そして 本当に使えるのか? はさらに大事
  46. 46. Suica 改札機の 読み取り角度は 13.5度 傾いている。
  47. 47. 「本当に使える」 かどうかは やってみなければ わからない
  48. 48. ・どのような場所で 使うのか? ・利用者は誰か? ・使い慣れているのか? ・片手で使うのか? 両手で使うのか?
  49. 49.  屋外で使うなら色調 を強くしなければ視 認性を損なう  片手で使うならコン トロールは画面下部 に寄せる  環境によっては情報 の取り方も考える
  50. 50. 今日のテーマ やってみよう (さわってみよう)
  51. 51. 1.スマートフォンアプリの概要 2.モバイルOS、開発ツール 3.クラスメソッドのプロセス 4.まとめ
  52. 52. 実装してほしい 要求がある (例)よくある話
  53. 53. 実装してほしい 要求がある 要求が正しい前 提で作る (例)よくある話
  54. 54. 実装してほしい 要求がある ①要求のリストを渡す 要求が正しい前 提で作る (例)よくある話
  55. 55. 実装してほしい 要求がある ②要件定義書 を作る ①要求のリストを渡す 要求が正しい前 提で作る (例)よくある話
  56. 56. 細かく書いてあるけ ③要件定義書を ど、これが欲しかった レビューする んだっけ…? 実装してほしい 要求がある ②要件定義書 を作る ①要求のリストを渡す 要求が正しい前 提で作る (例)よくある話
  57. 57. 弊社の購買と法務が ③要件定義書を チェックするので レビューする 体裁を直して下さい 実装してほしい 要求がある ②要件定義書 を作る ①要求のリストを渡す ④ツッコミを入れる 要求が正しい前 提で作る (例)よくある話
  58. 58. 弊社の購買と法務が ③要件定義書を チェックするので レビューする 体裁を直して下さい 実装してほしい 要求がある ②要件定義書 を作る ①要求のリストを渡す ⑤承諾 ④ツッコミを入れる はいわかりました。 要求が正しい前 ちゃんと読んだ 提で作る のかなあ…? (例)よくある話
  59. 59. ビジネスの専門家 とITの専門家の コミュニケーショ ンは難しい
  60. 60. 要求仕様書や要件定義書 でコミュニケーションを している、これを作って いる間にアイデアの大事 な部分が逃げてしまう (あるいは冷めてしまう)
  61. 61. 〜私たちが抱えている課題〜 ・細かいところまで詰める 時間はない ・要件定義に半年、一年も かけてられない(その間 にニーズが変化する) ・テクノロジーの進化が早 すぎて、時間をかけすぎ ると陳腐化してしまう
  62. 62. サイクロンロゴ (for Mobile Devices)
  63. 63. サイクロンロゴ (for Mobile Devices) クラスメソッドが創業以来実践し 続けてきたシステム開発における デザインのプロセスを体系化した
  64. 64. 大切なことは 1. 「本当に使える」のか? 2. 現実的な期間とコストの範疇 で実現できるのか?
  65. 65. Scrum Framework
  66. 66. Scrum Framework ここをどうやって決める?
  67. 67. クラスメソッドでよくある パターン ・◯◯までに何かやらないと いけない ・予算は◯◯ぐらいで決まっ ている (開示されるとは限らない) ・実現できて上手く行きそう なアイデアがほしい
  68. 68. Scrum Framework ほとんど決まってない
  69. 69. クラスメソッドの対処法 ・要求を整理する ・要求を元に、画面デザインを 行う。必要なら人の動線も含 めてシナリオを描く ・実装可能か調査をする サンプルプログラムを構築し 選定技術の比較をする ・この活動を繰り返す
  70. 70. クラスメソッドの対処法 ・要求を整理する ・要求を元に、画面デザインを 行う。必要なら人の動線も含 めてシナリオを描く ・実装可能か調査をする サンプルプログラムを構築し 選定技術の比較をする ・この活動を繰り返す
  71. 71. クラスメソッドの対処法 ・要求を整理する ・要求を元に、画面デザインを 行う。必要なら人の動線も含 めてシナリオを描く ・実装可能か調査をする サンプルプログラムを構築し 選定技術の比較をする ・この活動を繰り返す
  72. 72. クラスメソッドの対処法 ・要求を整理する 徹頭徹尾 ・要求を元に、画面デザインを 行う。必要なら人の動線も含 めてシナリオを描く 現物主義 ・実装可能か調査をする サンプルプログラムを構築し 選定技術の比較をする ・この活動を繰り返す
  73. 73. この一連の現物主義なサイクル を体系化し、より効率的なプロ セスをデザインしたものが、 サイクロンロゴ (for Mobile Devices)
  74. 74. (提案)考え直す
  75. 75. 実装してほしい 要求がある 要求が正しい前 提で作る ①いきなりこの二者で話をしない
  76. 76. 「ビジネスの専門家」 に専門外の技術文書を 書かせたり読ませたり している時点で重大な 無駄を発生させている
  77. 77. 課題を もっている ②現実を認める(要求は固まってない)
  78. 78. 昔と違って、あらゆる ことが複雑で多くの選 択肢をもつようになっ た。電子化すれば結果 が必ずでるような単純 な世の中ではない。
  79. 79. 課題を もっている あるべき姿を 描ける ③視覚化をして認識を共有を徹底する
  80. 80. ③視覚化をして認識を共有を徹底する ・ストーリーボード(シナリオ) ・ユーザー調査 ・ペルソナ分析 ・デザインラフ(コンセプト) ・ワイヤーフレーム ・ペーパープロトタイピング ※都度、適したツールを選んで使う
  81. 81. ストーリーボード ペルソナ ユーザー調査 ドキュメントの体裁よりも全員が ゴールを正しく認識できること。
  82. 82. 課題を もっている あるべき姿を あるべき姿を 描ける を作れる ④「あるべき姿」の実現方法を考える
  83. 83. ④「あるべき姿」の実現方法を考える 制約(コスト・期間)の下で、実現 できる方法を考える。場合によって は、ITの専門家としてより良い解 決方法を提案する。
  84. 84. 課題を もっている あるべき姿を あるべき姿を 描ける を作れる ⑤見通しを確認し投資に値するか検討
  85. 85. ⑤見通しを確認し投資に値するか検討 システムにプロダクト(サービスや アプリケーション)を組み込んだ時、 それがユーザーに対してどのような インパクトを与えられるのかを再度 考える。
  86. 86. 課題を もっている あるべき姿を あるべき姿を 描ける を作れる ⑥このサイクルを繰り返す(一定期間)
  87. 87. ⑥このサイクルを繰り返す(一定期間) ・本当に役立つのか?を問い続ける ・本当に役立つ状態を模索し続ける
  88. 88. 「Unityではじめるゲームづくり」 ミシェル・メナード (著), (監修), 湊 和久 (翻訳), 大西 康満 (翻訳), 放課後Unity倶楽部 (翻訳) ソフトバンククリエイティブ (2011/11/2)
  89. 89. ゲームアイデアの最初の一歩を創り出 すのに、焦りは禁物です。無理に出し たアイデアが楽しいものになるわけが ありません。そのゲームに、これから 長い時間(数週間、数ヶ月、大きいプ ロジェクトの場合、ひょっとしたら数 年)関わり続けることを忘れないでく ださい。それが、制作期間を通して興 味を持ち続けられるアイデアだという ことをよく確かめましょう。
  90. 90. ゲームアイデアの最初の一歩を創り出 すのに、焦りは禁物です。無理に出し たアイデアが楽しいものになるわけが ありません。そのゲームに、これから 長い時間(数週間、数ヶ月、大きいプ ロジェクトの場合、ひょっとしたら数 年)関わり続けることを忘れないでく ださい。それが、制作期間を通して興 味を持ち続けられるアイデアだという ことをよく確かめましょう。
  91. 91. 本当に役立つのか?
  92. 92. 課題を もっている ファシリテートする あるべき姿を あるべき姿を 描ける を作れる ⑦サイクルを軌道に乗せる
  93. 93. ⑥サイクルを軌道に乗せる 通常、オーナー(発注者)は忙しく、 デザイナ/技術者と頻繁なコミュニ ケーションをとることが難しい。 ここにファシリテーターを入れるこ とで調整役とオーナーの代弁者を兼 ねることで、サイクルのスピードを 下げないようにする。
  94. 94. 課題を もっている ファシリテートする あるべき姿を あるべき姿を 描ける を作れる 3+1の視点
  95. 95. オーナーの 専門アクティビティ 課題を もっている 共通の アクティビティ ファシリテートする あるべき姿を あるべき姿を 描ける を作れる ビジュアライザーの テクノロジストの 専門アクティビティ 専門アクティビティ
  96. 96. オーナーの 専門アクティビティ 問題の提起 課題を 事業化への組織内調整 もっている 事業領域における法令の確認 共通の アクティビティ ファシリテートする あるべき姿を あるべき姿を 描ける を作れる ビジュアライザーの テクノロジストの 専門アクティビティ 専門アクティビティ
  97. 97. オーナーの 専門アクティビティ 課題を もっている 共通の アクティビティ ファシリテートする デザインコンセプト提案 あるべき姿を あるべき姿を インフォメーションアーキテクチャ 描ける を作れる インタラクションデザイン ビジュアライザーの テクノロジストの 専門アクティビティ 専門アクティビティ
  98. 98. オーナーの 専門アクティビティ 課題を もっている 共通の アクティビティ ファシリテートする 実装方式の提案 あるべき姿を あるべき姿を 描ける フィージビリティスタディ を作れる プロジェクトマネジメント計画 ビジュアライザーの テクノロジストの 専門アクティビティ 専門アクティビティ
  99. 99. ビジネスゴールの設定 オーナーの ゴールの認識を共有する 専門アクティビティ ペルソナ作成 課題を ストーリーマッピング もっている プロダクトバックログの作成 妥当性の検証 共通の アクティビティ ファシリテートする あるべき姿を あるべき姿を 描ける を作れる ビジュアライザーの テクノロジストの 専門アクティビティ 専門アクティビティ
  100. 100. オーナーの 専門アクティビティ 課題を もっている 共通の アクティビティ ファシリテートする あるべき姿を あるべき姿を 2種類のアクティビティ 描ける を作れる ビジュアライザーの テクノロジストの 専門アクティビティ 専門アクティビティ
  101. 101. オーナーの 専門アクティビティ 課題を もっている 共通の アクティビティ ファシリテートする あるべき姿を あるべき姿を 描ける を作れる ビジュアライザーの テクノロジストの 専門アクティビティ 専門アクティビティ
  102. 102. 明確なゴール設定と効率的な開発チーム
  103. 103. サイクロンロゴ TOOLS CYCLONEの導入を しやすくするためのツール群
  104. 104. ペーパープロトタイピング 支援ツール 鋭意製作中!!
  105. 105. ・個々のツールや技法は普通 ・CYCLONEはそれらを 体系化し、誰でもはじめや すいようにしている
  106. 106. このサイクルを効果的 に回すには経験と、こ れを良しとする組織の 文化が必要
  107. 107. 1.スマートフォンアプリの概要 2.モバイルOS、開発ツール 3.クラスメソッドのプロセス 4.まとめ
  108. 108. 今日のテーマ やってみよう (さわってみよう)
  109. 109.  初期の無駄を排除し本質に踏 み込むこと  体裁にとらわれ過ぎな要件定 義のあり方を変えること  CMのような開発会社が、こ れまで以上にお客様のビジネ スの成功に寄与すること  1日でも早く「本当に役立 つ」システムを届けること
  110. 110. オープンな発想と 高い技術力により、 すべての人々の創造 活動に貢献し続ける
  111. 111. サイクロンロゴ (for Mobile Devices)
  112. 112. ご清聴 ありがとうございました お問い合わせはこちらまで info@classmethod.jp

×