Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads.
Android案件見積りに現れる要素、
あるいは丁寧に埋設された地雷たち
株式会社トップゲート
山下武志@eaglesakura
山下武志
Twitter@eaglesakura
 Github@eaglesakura
エンジニアにとって、
見積もりとは何か?
想定すること
前提を提示すること
エンジニアからみた見積もり要素
● 難易度(作業量)の想定
● 期限の想定
● アサインされる人数の想定
● 技術的習熟度の想定
● 機材価格の想定
● サービス利用料の想定
日常的に起こりうる、
想定と、想定外
こんな事を言われたら
今回の開発ではすでにiOS版があり
ます。
画面の素材も提供されます。
SNS投稿も行います。
想定
● デザインはiOSのものが提供される
○ 必要なリソースはiOS版からもらってくるのでコスト減
○ ビジネスロジックはiOS版コードを閲覧でできる
● 画面遷移等の仕様がはっきりしているので、仕様策定にか
かる時間を削減できる
● SNSは指...
想定外
デザインはiOSのものをそのまま使える
デザインはiOSのものをそのまま使える
リソースはiOS版流用でコスト減
リソースはiOS版流用でコスト減
● 「アプリ内で全部完結させたい」と後から言われた
● 他のアプリへの遷移しちゃダメ
○ Intent連携使えない
○ ログイン処理が必要になる
○ ログインUIが必要になる
○ 開発者アカウント必要になる
SNSは指定ハッシュタグで投稿するだけ
見積もりに失敗、
とは?
想定から外れること
正確な想定による
効能とは?
定時で帰れる
マネージメント層が
プロジェクトを制御しやす
くなる
こんな事を言われたら
エンジニアリング編
ユーザーの位置情報を活用する。
ユーザー同士が近づいたら、特定
の処理を行う。
想定
Androidの位置情報を利用する
● Runtime Permissionで権限を取得する
● 位置情報はGoogle Play Serviceの機能を使用する
○ 実装経験がある
○ サンプルコードもいっぱいある
● 「近づく」とは、10メ...
想定外
10メートル圏内に入る
● 10メートルぴったりで処理が行われない、とバグ報告
● 相手が目の前にいても反応しない、とバグ報告
○ 機種が違えば、現在座標が10メートル以上ズレるのも珍しくない
○ 「センチメートル単位」の精度が取れると思われて...
動作確認コストが増大する
● GPSの動作確認には数十メートル~数百メートルの移動が
最低限必要
○ オフィスから屋外が遠い場合、移動コストも馬鹿になららない
○ 一度の往復で5~10分かかる等
● 歩きスマホは大変危険
○ 不審者に間違われた...
テクノロジーを
過信しない
こんな事を言われたら
Androidアプリ起動時に、
特定の初期化処理を呼び出す。
想定
アプリ起動時に必ずやる処理
● スプラッシュ画面で前提条件を満たさせる
○ 必須Permissionを取得する、リソースダウンロード等も行える
○ Firebaseのログインとかさせる
● その他の仕様に干渉しない
○ 時間のかかる処理でも問題...
想定外
こんなパターンはどうなるだろうか?
戻るボタン連打 Activity起動
● Processは生きている
● staticな値はそのまま残り続ける
● 初期化処理する?しない?
こんなパターンはどうなるだろうか?
Homeボタンを押す アプリに戻る
● メモリが少なければProcess再起動
● Activityスタックが復元されるのでスプラッ
シュは経由しない
● 初期化処理する?しない?
こんなパターンはどうなるだろうか?
● AndroidはRecentから削除しても、
Process Killが保証されない
iOSのTask Kill AndroidのRecent
Androidアプリにおいて「起動」とは?
● Androidアプリにおける「起動」とはなんだろうか?
○ Processが立ち上がったとき?
○ Activityが立ち上がったとき?
○ Processが生きたままActivityが再起動した...
何気ない言葉の定義が
僕らの想定を傷つけた
こんな事を言われたら
今回のプロジェクトは1年くらい。CI
も構築する。
想定
● ソースコード管理はgithubで行う
● 基本的にはCircleCIを利用
● CI環境の構築は前例があるから1週間あれば十分
CIを構築する
想定外
CIの「構築」は見積もった
● CIは構築するだけではない
○ CIは運用するものである
● 継続した運用には、コストがかかる
○ build.gradleのProduct Flavorが増えたら?
○ Gradleの破壊的アップデートがあった...
CIが激重になった
● 当初想定していない処理もCIでやらせる場合もある
○ リソース圧縮をCI側で行う等
● 開発後半でビルド速度が落ちて開発に支障が出る
○ 1ビルド40分かかるのは、リリース直前だとかなり大きな痛手
○ それを放置すると自...
開発中にも、
運用は発生する
こんな事を言われたら
にんげん編
今回のプロジェクトは1年くらい。CI
も構築する。
想定
● ソースコード管理はgithubで行う
● 基本的にはCircleCIを利用
● CI環境の構築は前例があるから1週間あれば十分
● メンテのために毎月1人日を想定
CIを構築する
想定外
それ、
本当に信頼できる?
「それ、信頼できるの?」
● 必要以上にセキュリティを気にする
○ 自社サーバーで構築したサービス以外認めない
○ IPのホワイトリスト作成が必須
● クラウドサービスはハッキングリスクが高い
● 「オープン」なライブラリは認められない
○ 誰...
どうなった?
● 特定IPからしか接続できないリポジトリを構築
● 社内LANからしかつながらないJenkinsを構築
● OSSライブラリ全部はずして1からコーディング
● フォーマッタも信用出来ないからフォーマット禁止
● 全部想定外で、開...
「常識」を整理しよう
こんな事を言われたら
新規Androidアプリ開発案件。
リリースは1年後。
アプリの開発言語は……?
想定
使う技術の選定
商用未経験だけど
Xamarinがいい 商用未経験だけど
Kotlinがいい
商用未経験だけど
React Nativeがいい
Javaはみんな
商用経験あるよ
アサイン予定のメンバーからヒアリング
● みんなJavaは使ったことある
○ Kotlinを使いたいという意見が出た
○ React Nativeを使いたいという意見が出た
○ Xamarinを使いたいという意見が出た
● 複数種類の見積もりを...
想定外
メンバーのモチベーション低下
● プロジェクト方針として枯れた技術しか使えない
● 新しい技術を導入したいが、できない
● メンバーのモチベーションが低下し、コード品質が低下して
いった
● アサイン変更によって引き継ぎコストが発生した
開発者は、にんげんです。
モチベーションは、品質です。
こんな事を言われたら
新規開発案件。
とてもデキるエンジニアがいるけ
ど、一人では足りないので
追加人員を見積もった。
これで期間内に間に合うはず。
想定
メイン開発者とサブ開発者
メインで開発します
画面単位で開発します
メイン開発者とサブ開発者
● 「デキるエンジニア」に開発リードを行わせる
● メイン開発者はビジネスロジックの重要な部分を担当
● サブ開発者は個々のActivity単位で担当
○ 場合によっては細かい調べごとも行ってもらう
● メイン開発者が...
想定外
メイン開発者とサブ開発者
ここのコードがダメだか
ら修正して
作業したんですけど
……
メイン開発者とサブ開発者
● 開発リードがPull Requestに対して必要以上に品質を要求
した
● そもそも開発リードが怖くてPull Requestしづらい
● いつまでもマージできず、進捗が思わしくない
● 期間延長してメイン開発者が...
「個人」としてのスキルと
「集団」としてのスキルは
別物である
「状況に合わせて妥協する」
こともスキルの一つである
まとめる
今日の想定外
は
明日の想定内
Android案件を見積もる場合に
考えておくことリスト
https://goo.gl/PUCmVQ
Upcoming SlideShare
Loading in …5
×

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

25,548 views

Published on

DroidKaigi 2018
Day2 / 14:50- / Room3

Published in: Business
  • Be the first to comment

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

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

https://progressive.ua

×