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

1,948 views
1,857 views

Published on

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,948
On SlideShare
0
From Embeds
0
Number of Embeds
261
Actions
Shares
0
Downloads
14
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

[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 iOSiOS 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, FastDesign LanguageCelebrate Typography“Metro”Alive in MotionContent, Not ChromeAuthentically 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 MuseAdobe 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

×