Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Android案件見積りに現れる要素、あるいは丁寧に埋設された地雷たち

24,525 views

Published on

DroidKaigi 2018
Day2 / 14:50- / Room3

Published in: Business
  • Be the first to comment

Android案件見積りに現れる要素、あるいは丁寧に埋設された地雷たち

  1. 1. Android案件見積りに現れる要素、 あるいは丁寧に埋設された地雷たち 株式会社トップゲート 山下武志@eaglesakura
  2. 2. 山下武志 Twitter@eaglesakura  Github@eaglesakura
  3. 3. エンジニアにとって、 見積もりとは何か?
  4. 4. 想定すること
  5. 5. 前提を提示すること
  6. 6. エンジニアからみた見積もり要素 ● 難易度(作業量)の想定 ● 期限の想定 ● アサインされる人数の想定 ● 技術的習熟度の想定 ● 機材価格の想定 ● サービス利用料の想定
  7. 7. 日常的に起こりうる、 想定と、想定外
  8. 8. こんな事を言われたら
  9. 9. 今回の開発ではすでにiOS版があり ます。 画面の素材も提供されます。 SNS投稿も行います。
  10. 10. 想定
  11. 11. ● デザインはiOSのものが提供される ○ 必要なリソースはiOS版からもらってくるのでコスト減 ○ ビジネスロジックはiOS版コードを閲覧でできる ● 画面遷移等の仕様がはっきりしているので、仕様策定にか かる時間を削減できる ● SNSは指定ハッシュタグで投稿するだけ すでにiOS版が存在する
  12. 12. 想定外
  13. 13. デザインはiOSのものをそのまま使える
  14. 14. デザインはiOSのものをそのまま使える
  15. 15. リソースはiOS版流用でコスト減
  16. 16. リソースはiOS版流用でコスト減
  17. 17. ● 「アプリ内で全部完結させたい」と後から言われた ● 他のアプリへの遷移しちゃダメ ○ Intent連携使えない ○ ログイン処理が必要になる ○ ログインUIが必要になる ○ 開発者アカウント必要になる SNSは指定ハッシュタグで投稿するだけ
  18. 18. 見積もりに失敗、 とは?
  19. 19. 想定から外れること
  20. 20. 正確な想定による 効能とは?
  21. 21. 定時で帰れる
  22. 22. マネージメント層が プロジェクトを制御しやす くなる
  23. 23. こんな事を言われたら
  24. 24. エンジニアリング編
  25. 25. ユーザーの位置情報を活用する。 ユーザー同士が近づいたら、特定 の処理を行う。
  26. 26. 想定
  27. 27. Androidの位置情報を利用する ● Runtime Permissionで権限を取得する ● 位置情報はGoogle Play Serviceの機能を使用する ○ 実装経験がある ○ サンプルコードもいっぱいある ● 「近づく」とは、10メートル圏内に入ることを指す ○ サーバーで位置情報の近さを判定する
  28. 28. 想定外
  29. 29. 10メートル圏内に入る ● 10メートルぴったりで処理が行われない、とバグ報告 ● 相手が目の前にいても反応しない、とバグ報告 ○ 機種が違えば、現在座標が10メートル以上ズレるのも珍しくない ○ 「センチメートル単位」の精度が取れると思われている場合がある ○ ビル街等は屋外であってもズレが大きくなる ○ GPSは瞬間的に数メートル~数十メートル「飛ぶ」ことがある ○ 加重平均で数値を平滑化すると、追従性が下がるので導入が100%正解で はない
  30. 30. 動作確認コストが増大する ● GPSの動作確認には数十メートル~数百メートルの移動が 最低限必要 ○ オフィスから屋外が遠い場合、移動コストも馬鹿になららない ○ 一度の往復で5~10分かかる等 ● 歩きスマホは大変危険 ○ 不審者に間違われたときのために、身分証明書を持ち歩く ○ 夏場は熱中症も注意 ● これらのコストは必ず見積もりに反映させる
  31. 31. テクノロジーを 過信しない
  32. 32. こんな事を言われたら
  33. 33. Androidアプリ起動時に、 特定の初期化処理を呼び出す。
  34. 34. 想定
  35. 35. アプリ起動時に必ずやる処理 ● スプラッシュ画面で前提条件を満たさせる ○ 必須Permissionを取得する、リソースダウンロード等も行える ○ Firebaseのログインとかさせる ● その他の仕様に干渉しない ○ 時間のかかる処理でも問題ない
  36. 36. 想定外
  37. 37. こんなパターンはどうなるだろうか? 戻るボタン連打 Activity起動 ● Processは生きている ● staticな値はそのまま残り続ける ● 初期化処理する?しない?
  38. 38. こんなパターンはどうなるだろうか? Homeボタンを押す アプリに戻る ● メモリが少なければProcess再起動 ● Activityスタックが復元されるのでスプラッ シュは経由しない ● 初期化処理する?しない?
  39. 39. こんなパターンはどうなるだろうか? ● AndroidはRecentから削除しても、 Process Killが保証されない iOSのTask Kill AndroidのRecent
  40. 40. Androidアプリにおいて「起動」とは? ● Androidアプリにおける「起動」とはなんだろうか? ○ Processが立ち上がったとき? ○ Activityが立ち上がったとき? ○ Processが生きたままActivityが再起動したら? ○ 複数Processを使うような構成のアプリは? ● 仕様策定者は、「起動」の定義が多くの場合曖昧 ○ 「起動時」がどのようなパターンがある? ● 「起動時」を軽々しく考えると、沼にハマる
  41. 41. 何気ない言葉の定義が 僕らの想定を傷つけた
  42. 42. こんな事を言われたら
  43. 43. 今回のプロジェクトは1年くらい。CI も構築する。
  44. 44. 想定
  45. 45. ● ソースコード管理はgithubで行う ● 基本的にはCircleCIを利用 ● CI環境の構築は前例があるから1週間あれば十分 CIを構築する
  46. 46. 想定外
  47. 47. CIの「構築」は見積もった ● CIは構築するだけではない ○ CIは運用するものである ● 継続した運用には、コストがかかる ○ build.gradleのProduct Flavorが増えたら? ○ Gradleの破壊的アップデートがあったら? ○ 依存しているPluginが使えなくなったら? ● 運用コストを無視すれば、それ以上の打撃を与える ○ CIが壊れたまま? ○ 誰も直す余裕がない? ○ リリースしないと行けないから手動操作? ■ いっけね、操作まちがった! ■ 指差し確認!
  48. 48. CIが激重になった ● 当初想定していない処理もCIでやらせる場合もある ○ リソース圧縮をCI側で行う等 ● 開発後半でビルド速度が落ちて開発に支障が出る ○ 1ビルド40分かかるのは、リリース直前だとかなり大きな痛手 ○ それを放置すると自分たちが痛い目を見る ● 見積もりづらいが、ゼロにはできない ○ CIサービスの利用料金が実費でかかる ○ 月初に1人が丸1日メンテする、等
  49. 49. 開発中にも、 運用は発生する
  50. 50. こんな事を言われたら
  51. 51. にんげん編
  52. 52. 今回のプロジェクトは1年くらい。CI も構築する。
  53. 53. 想定
  54. 54. ● ソースコード管理はgithubで行う ● 基本的にはCircleCIを利用 ● CI環境の構築は前例があるから1週間あれば十分 ● メンテのために毎月1人日を想定 CIを構築する
  55. 55. 想定外
  56. 56. それ、 本当に信頼できる?
  57. 57. 「それ、信頼できるの?」 ● 必要以上にセキュリティを気にする ○ 自社サーバーで構築したサービス以外認めない ○ IPのホワイトリスト作成が必須 ● クラウドサービスはハッキングリスクが高い ● 「オープン」なライブラリは認められない ○ 誰が実装しているかわからないものはリスクであるという意見 ○ セキュリティ問題が発生したら攻撃者が攻撃しやすくなる ■ OpenSSLのHeartbleed問題等
  58. 58. どうなった? ● 特定IPからしか接続できないリポジトリを構築 ● 社内LANからしかつながらないJenkinsを構築 ● OSSライブラリ全部はずして1からコーディング ● フォーマッタも信用出来ないからフォーマット禁止 ● 全部想定外で、開発期間を圧迫した
  59. 59. 「常識」を整理しよう
  60. 60. こんな事を言われたら
  61. 61. 新規Androidアプリ開発案件。 リリースは1年後。 アプリの開発言語は……?
  62. 62. 想定
  63. 63. 使う技術の選定 商用未経験だけど Xamarinがいい 商用未経験だけど Kotlinがいい 商用未経験だけど React Nativeがいい Javaはみんな 商用経験あるよ
  64. 64. アサイン予定のメンバーからヒアリング ● みんなJavaは使ったことある ○ Kotlinを使いたいという意見が出た ○ React Nativeを使いたいという意見が出た ○ Xamarinを使いたいという意見が出た ● 複数種類の見積もりを作成した ○ Java以外は商用での導入経験がないため、期間を長めに設定 ○ Javaの場合はすぐさま開発開始可能 ● 最終的にJavaに決定した ○ 目新しくは無いが、手堅い ○ プロジェクトの方針は「手堅い技術でやる」
  65. 65. 想定外
  66. 66. メンバーのモチベーション低下 ● プロジェクト方針として枯れた技術しか使えない ● 新しい技術を導入したいが、できない ● メンバーのモチベーションが低下し、コード品質が低下して いった ● アサイン変更によって引き継ぎコストが発生した
  67. 67. 開発者は、にんげんです。 モチベーションは、品質です。
  68. 68. こんな事を言われたら
  69. 69. 新規開発案件。 とてもデキるエンジニアがいるけ ど、一人では足りないので 追加人員を見積もった。 これで期間内に間に合うはず。
  70. 70. 想定
  71. 71. メイン開発者とサブ開発者 メインで開発します 画面単位で開発します
  72. 72. メイン開発者とサブ開発者 ● 「デキるエンジニア」に開発リードを行わせる ● メイン開発者はビジネスロジックの重要な部分を担当 ● サブ開発者は個々のActivity単位で担当 ○ 場合によっては細かい調べごとも行ってもらう ● メイン開発者がPull Requestをレビューすることでコード品 質を担保
  73. 73. 想定外
  74. 74. メイン開発者とサブ開発者 ここのコードがダメだか ら修正して 作業したんですけど ……
  75. 75. メイン開発者とサブ開発者 ● 開発リードがPull Requestに対して必要以上に品質を要求 した ● そもそも開発リードが怖くてPull Requestしづらい ● いつまでもマージできず、進捗が思わしくない ● 期間延長してメイン開発者が殆どの作業を終わらせた ・・・・・・
  76. 76. 「個人」としてのスキルと 「集団」としてのスキルは 別物である
  77. 77. 「状況に合わせて妥協する」 こともスキルの一つである
  78. 78. まとめる
  79. 79. 今日の想定外 は 明日の想定内
  80. 80. Android案件を見積もる場合に 考えておくことリスト https://goo.gl/PUCmVQ

×