コーディングの時間・工数・見積についてのお話

Transcript

1. 2022/5/15 2022/5/15 コーディングの時間・⼯数・⾒積についてのお話
2. 2 CO PYRIGHT© CCG WO RKING HEADS 2 CO PYRIGHT© CCG WO RKING HEADS はじめに
3. はじめに ⾒積もり：何か作業を⾏う前にその作業⾃体にどれくらいの時間や費⽤が発⽣するのかを事前に予想すること 制作側(今⽇はエンジニアチーム)においても何かを制作する上でこの⾒積もりというタスクは 様々なケースで登場してきます。 今回は案件でコーディングを⾏う際にはこんな⾵に⾒積もりをやっているよというのを紹介していきます。
4. はじめに エンジニアの作業内容 ・設計 （どのように機能を実装していくかの⾒通し） ・デザイン切り出し （画像が必要な場合はデザインデータから画像を抽出） ・環境構築 （制作する環境を整える・サーバー準備やPC内に必要なファイルを作成） ・コーディング （プログラムコードの記述） ・動作確認・調整 （制作物が正しく動くか確認・必要に応じて修正） 企画提案 要件定義 作業⾒積 詳細スケジュール 作成 製作作業 動作確認 修正対応 納品・リリース 今回話すのはココ！ 凡その制作の流れ
5. はじめに ⽬的（Goal） ⾒積もりや時間感覚に関しての相互理解 スケジュール管理と作業⼯数については ディレクターの⽅々とエンジニアとが⼀緒に作業をするなかで重要とされる情報のひとつです。 今までなんとなく「⼯数出してください！」といわれたら「◦⼈⽇です！よろしくお願いします！」 と機械的に対応をしてきていましたが、 この機会をいただいてこの分野における共通認識のクオリティをアップさせることができればと思っています。 また、⾒積もりというものにはふわふわした部分が多くあるのですがそれをできる限りで⾔語化してみた という⾯もあるので⾄らない点や疑問点はツッコミよろしくおねがいします 🙇‍‍
6. 今⽇話すこと ・⾒積もりのステップ ・⾒積もりってむずかしい ・⾒積もりの精度が下がるケース ・制作例 ・最後に
7. 7 CO PYRIGHT© CCG WO RKING HEADS 7 CO PYRIGHT© CCG WO RKING HEADS ⾒積もりのステップ
8. ⾒積もりのステップ ① 何のための⾒積もりなのかを確認する ② ⾒積もる ③ 必要に応じて⾒積もりの根拠を説明する ④ (必要であれば修正する) 基本的には以下の４つのステップで⾒積もりをしています。 エンジニアの作業内 容 ・設計 ・デザイン切り出し ・環境構築 ・コーディング ・動作確認・調整
9. ① 何のための⾒積もりなのかを確認する ⾒積もりのステップ ① 何のための⾒積もりなのかを確認する ② ⾒積もる ③ 必要に応じて⾒積もりの根拠を説明する ④ (必要であれば修正する) ⾒積もりには必ず⽬的があります。 ・『制作⾦額を概算したい』 ・『開発期間(リリース可能時期)を知りたい』 ・『スケジュールを算出したい』 など、依頼している⼈がどんな⽬的でその⾒積もりが欲しいのかを確認・認識します。 ⽬的がわからないと⾒積もりを正しい精度で⾏うことができなくなり また、スケジュールと実際の作業時間に乖離があった際にその後のコミュニケーションがうまく噛み合わない というトラブルが発⽣したりします。 このステップを意識したことで以前より⾒積もりの 苦⼿意識が薄くなった気がします
10. ② ⾒積もる ⾒積もりを⾏うためには「⾒積もりの根拠」が必要です。 「⾃分が⾏う作業の⾒積もり」の場合 ① ⾃分が過去に経験した同じ事象 ② ⾃分が過去に経験した類似する事象 ③ 他⼈が過去に経験した同じ事象 ④ 他⼈が過去に経験した類似する事象 ⑤ 当てずっぽう ⾒積もりのステップ ① 何のための⾒積もりなのかを確認する ② ⾒積もる ③ 必要に応じて⾒積もりの根拠を説明する ④ (必要であれば修正する) ③④に関しては⾃分と別の誰かとの作業スピードの差を理解しておく必要があります。 そしてこれら⾒積もりの根拠は上から下にいくに従い⾒積もりの精度も下がっていきます。
11. ② ⾒積もる ⾒積もりの精度は経験の量に⽐例する 前述した①⾃分が過去に経験した同じ事象が最も⾒積もりの制度が⾼いため 必然的に経験量の差が⾒積もり精度の差に繋がります。 同じチーム内で情報を共有することで経験値の差を補えることもあります。 ⾒積もりのステップ ① 何のための⾒積もりなのかを確認する ② ⾒積もる ③ 必要に応じて⾒積もりの根拠を説明する ④ (必要であれば修正する) ⾒積もりに対してバッファを乗せる 制作を⾏う際には⼤⼩ありますが事前に想定していないトラブルや遅延はほぼ確実に発⽣します。 そのため⾒積もった時間に対してバッファ(余剰時間)を上乗せしておきます。 どの程度バッファを乗せるかはその時々で変化しますが、個⼈的には２〜５割の間で乗せる事が多いです。 バッファ量の精度も経験値次第です。。
12. ③必要に応じて⾒積もりの根拠を説明する ここでの重要なポイントは何を根拠にこの⾒積もりを⾏いどの程度バッファを乗せたかを 説明できる状態にしておくというところにあります。 『①で確認した⽬的が果たせているか』をこの説明によってすり合わせます。 ①と③の整合性が取れていない場合は相⼿の求めている情報になっていないので もう⼀度①に戻って⽬的を確認し⾒積もりをやり直すことになります。 (←④) ⾒積もりのステップ ① 何のための⾒積もりなのかを確認する ② ⾒積もる ③ 必要に応じて⾒積もりの根拠を説明する ④ (必要であれば修正する)
13. 13 CO PYRIGHT© CCG WO RKING HEADS 13 CO PYRIGHT© CCG WO RKING HEADS ⾒積もりってむずかしい むずかしいよねぇ。。。
14. ⾒積もりってむずかしい むずかしく感じる理由 実際作業してみた結果、想像以上に障壁が多く⾒積もった時間と差が⽣じてしまうことが 少なからずあるため(逆もまた然り) →それは⾒積もり失敗…？ ⾒積もりの段階で本当に重要なこと 必要なことを相⼿に伝えて⾒積もりに対して合意をとること。 「⾒積もりの段階」では作業結果を⾒ることはできません。 この時点で結果はそれほど重要でなくお互い納得の上で合意が取れているかが⼤切です。 →このスタンスがニガテ意識の克服とむずかしさを改善するコツになっていると感じます。 とはいえ個⼈的には⾒積もりと結果の差が⼤きいのはショックですし結果として精神的・⾝体的にすり 減るオチが待っているのでこれはこれで反省して経験値に変えていくように⼼がけてます。。
15. 15 CO PYRIGHT© CCG WORKING HEADS 15 CO PYRIGHT© CCG WO RKING HEADS ⾒積もりの精度が下がるケース ⾔い訳させてくれ。。。
16. ⾒積もりの精度が下がるケース どうしても⾒積もり精度が低くなる傾向にある典型的なケースを３つ紹介 ①実装難易度が⾼い ②元々別の場所で制作されたものを引き継ぐ ③０→１ではない状態の案件にヘルプで⼊る
17. ①実装難易度が⾼い 単純に⾃分の技術レベルと実装難易度のとの間に差があり経験からの予測がむずかしいケースを指します。 担当するという状態まで下りてきている時点で制作は可能と判断されているため、 どれだけ実装タスクを⾒通せるかが精度を⾼めるための鍵となります。 ⼼理的安全性*：普通 ⾒積もりの際に⼼がけるべきこと ⾒積もりの精度が下がるケース ①実装難易度が⾼い ②元々別の場所で制作されたものを引き継ぐ ③ ０→１ではない状態の案件にヘルプで⼊る →⾒積もりにかけることのできる時間確保 （事前調査をするための時間） https://rework.withgoogle.com/jp/guides/understanding- team-effectiveness/steps/introduction/ *⼼理的安全性： 「効果的なチームとは何か」を知る
18. ②元々別の場所で制作されたものを引き継ぐ 他社で制作されすでに運⽤されているサイトがあり、 諸事情により今後の運⽤を引き継ぐことになったケースを指します。 理由としては運⽤されていた期間が⻑いほど古めの技術が使⽤されていたり、 最悪スパゲッティコードを解析・改変・上書きして更新する必要があり作業が複雑化するためです。 ⼼理的安全性：低め ⾒積もりの際に⼼がけるべきこと ⾒積もりの精度が下がるケース ①実装難易度が⾼い ②元々別の場所で制作されたものを引き継ぐ ③ ０→１ではない状態の案件にヘルプで⼊る →通常よりもバッファを慎重に取る (バッファの精査や割増)
19. ③ ０→１ではない状態の案件にヘルプで⼊る 開発状況の事情により当初担当外であった案件へ急遽ヘルプとして既に稼働している制作のチームに加わり 作業を⾏うケースを指します。（主にスケジュール算出の⾒積もりを⾏う） 理由としては情報を共有する時間が短い、スケジュールの余裕があまりない、既に出来上がっている分の制作物に コードの傾向を合わせる必要があるなどの状況により準備が不⾜したり作業効率が著しく下がるためです。 ⼼理的安全性：低い ⾒積もりの際に⼼がけるべきこと ⾒積もりの精度が下がるケース ①実装難易度が⾼い ②元々別の場所で制作されたものを引き継ぐ ③ ０→１ではない状態の案件にヘルプで⼊る →可能な限り事前準備のための時間を確保する＆ 必ずバッファを割増しておく
20. ⾒積もりがむずかしい。。そんなときにできること 要件のクオリティをある⽔準で維持しつつ実装内容を再検討してみる これはディレクターとエンジニアの協⼒があってなせる技です。 これにより⾒積もりの精度を上げることができたり 限られた条件内にうまくハマるような⾒積もりを出すことができたりします。 具体例 (2022年1⽉下旬) 当時の状況 ・社外デザイナーのデザイン ・デザインデータ⽀給が遅れる ・デザイン性重視のサイト ・作業⽇： 5⽇間 → 2⽇間 検討内容 ・デザイン性は維持 ・仮デザインを先に⽀給 ・テキストはほぼ画像で実装 ・デザイン切り出し作業を分担 完成。 例えば①の場合
21. 21 CO PYRIGHT© CCG WO RKING HEADS 21 CO PYRIGHT© CCG WO RKING HEADS 制作例
22. 制作例 LPページの制作の場合① ・状況 スケジュール余裕あり(7⽇確保) ⼀般的なLPの制作⼯程 ・作業⼯程 デザイン切り出し・環境構築・コーディング・動作確認＆調整 ・⾒積もり 作業⼯数３⼈⽇ 内訳 項⽬ 時間(⼈⽇) 内バッ ファ デザイン切り出し 0.2 0.05 環境構築 0.1 0 コーディング 2.2 0.2 動作確認＆調整 0.5 0.1
23. 制作例 LPページの制作の場合② ・状況 なるべく早く(3⽇程度) ⼀般的なLPの制作⼯程 ・作業⼯程 デザイン切り出し・環境構築・コーディング・動作確認＆調整 ・⾒積もり 作業⼯数2⼈⽇ 内訳 項⽬ 時間(⼈⽇) 内バッ ファ デザイン切り出し 0.1 0.05 環境構築 0.1 0 コーディング 1.5 0.2 動作確認＆調整 0.3 0
24. 24 CO PYRIGHT© CCG WO RKING HEADS 24 CO PYRIGHT© CCG WO RKING HEADS 最後に
25. 最後に ⾒積もりのステップや典型的なケース紹介しましたが、 案件における状況というのは案件毎に多種多様で異なってくるものです。 その度にその状況に応じて⾒積もりの内容や精度も変化していきます。 そこでやはり重要となるのが前述した 「⾒積もりの⽬的」と「⾒積もりの根拠」 の整合性をとり 「⾒積もりに対して合意をとること」 にフォーカスすることだと思います。
26. 最後の最後に ⾒積もりにおいては ディレクターとエンジニアの間でのコミュニケーションによっても より精度を⾼められたり最適解が⽣まれたりすることがよくあります。 気になる点はぜひご質問ください！気軽に！ ⾒積もりや時間感覚に関しての相互理解を深めることは よりみなさんにとって快適なディレクションに繋がっていくはずです 今回話をした⾒積もりにおけるこれらの内容が少しでも今後の 皆さんの⾒積もり作業の⼿助けになれれば幸いです！ （実は⾃分も⾊々聞きたい…！！！）
27. 27 CO PYRIGHT© CCG WO RKING HEADS 27 CO PYRIGHT© CCG WO RKING HEADS ご清聴ありがとうございました