文系大学生と学び考える開発生産性

目次
・開発生産性との出会い
・開発生産性とは何なのか
・開発生産性を学ぶ中で思ったこと
・文系大学生と学ぶ開発生産性
・文系大学生と考える開発生産性
・おわりに

Transcript

1. 文系大学生と 学び考える 開発生産性 レバテック開発部　古川修慈
2. |　© Leverages inc. 2 • 名前：古川 修慈 • 所属： • レバテック開発部 新規開拓チーム • 慶應義塾大学 経済学部（4回生） • 趣味：ゲーム、漫画、アニメ 自己紹介
3. |　© Leverages inc. 3 目次 • 開発生産性との出会い • 開発生産性とは何なのか • 開発生産性を学ぶ中で思ったこと • 文系大学生と学ぶ開発生産性 • 文系大学生と考える開発生産性 • おわりに 　
4. 1. 開発生産性との出会い
5. |　© Leverages inc. 5 インターンを初めて２週間ぐらい！ ちょっとずつ業務になれてきた！ 勉強も順調だ！ 僕
6. |　© Leverages inc. 6 メンターさん お疲れ様〜！ だいぶ業務に慣れてきたね！ ありがとうございます！ 僕
7. |　© Leverages inc. 7 開発生産性についても意識していって、 個人についてもチームについても開発の意識を上げ ていけたらいいね！ はい〜
8. |　© Leverages inc. 8 ところで開発生産性ってなんですか？
9. |　© Leverages inc. 9
10. |　© Leverages inc. 10 ほぉ〜れ（※超意訳） ｷﾞｬｯ!
11. |　© Leverages inc. 11 開発生産性についての本とカンファレンスを勧められる
12. |　© Leverages inc. 12 こうして開発生産性を学ぶ道のりは始まりました。。。
13. 2. 開発生産性とは何なのか
14. |　© Leverages inc. 14 生産性 = 産出量（アウトプット） / 投入量（インプット） * 投入と産出が具体的に何であるかは、何についての生産性かによって変わる 生産性とは
15. |　© Leverages inc. 15 開発生産性とは 広木大地 著 『開発生産性について議論する前に知っておきたいこと 』より一部引用
16. |　© Leverages inc. 16 具体的な指標 (1/2)：4Keys • パフォーマンス分析を測る指標 ◦ 青字はスピードを、赤字は安定性を測る • デプロイ頻度　　　：実稼働環境にデプロイしたり、リリースしたりする頻度 • 変更のリードタイム：変更の開始点から変更の終了点までにかかる時間 • 変更障害率　　　　：運用環境への変更またはユーザーにリリースされた変更によって生 じたサービス障害の内、その後修復が必要となる割合 • 障害復旧時間　　　：デプロイ起因によってサービスが障害になった後、サービスを復旧 するのに必要な時間
17. |　© Leverages inc. 17 • あるものについて開始から完了までの 1サイクルに対して実際にかかる時間 • 「あるもの」はサイクルタイムの種類によって変わります • ex: Pull Requestのサイクルタイム • 最初のコミットからPR作成まで • PR作成からレビュー作成まで • レビュー作成から承認まで • 承認からマージまで 具体的な指標 (2/2)：サイクルタイム
18. |　© Leverages inc. 18 主目的：事業の利益の向上 ↓ サブ目的：市場競争力の向上、コスト削減、顧客満足度の向上 ↓ サブ目的：開発生産性の向上 なぜこれらを上げなきゃいけないのか
19. 3. 開発生産性を学ぶ中で思ったこと
20. |　© Leverages inc. 20 まっったく腹落ちしない。。。 僕
21. |　© Leverages inc. 21 • 言っていることは理解できます ◦ 「生産性 = 産出量（アウトプット） / 投入量（インプット）」も、 4Keysでスピードと安定性を測るの も、直感的に理解できます • 理論は理解はできるが、 実際のプラクティスの話になると、実践するイメージがどうしても曖昧にしか 湧 きませんでした 腹落ちしない
22. |　© Leverages inc. 22 これはなぜなのか？
23. |　© Leverages inc. 23 • 講演会などになると、どうしてもチームリーダーや事業責任者レベルの方 がメインで発表する ↓ • そうなると、内容は事業単位、小さくてもチーム単位での切り口 （開発生産性向上の仕組みや成功事例）になってし まいます ◦ そもそも開発とは基本チーム単位で行うものなので、その単位で開発生産性を語ることは当たり前 ↓ • 僕自身がその立場じゃなかったから、そのレベルの開発生産性の話が腹落ちしなかった • 体感にも沿っていますよね ◦ 4Keysについても、定義自体は個人の生産性に適用できそうなものの、よく出る知見としては 「部やチームで どういうルールを設けたか」のようなものが多いです 一番納得する理由
24. |　© Leverages inc. 24 1. 事業責任者でもチームリーダーでもない自分（発表者）にとって、 個人と個人間の開発生産性（ミクロな 開発生産性）の方が腹落ちしそう 2. そういったミクロな開発生産性について もう少し話す機会があってもよさそう • これによって全体の開発生産性の向上にどれくらい寄与するかはあまりわかりません ◦ （正直、組織レベルに比べたらかなり低いとは思います） • ただ、（当たり前ですが） 別の視点から開発生産を眺めること 自体に意味はあると思います • そしてなにより、それぞれが自身の開発生産性を考えることで、僕みたいにどこかで「自分と関係 ないな」と一線を引いている人たちに、 開発生産性を身近に感じてもらう ことができます 示唆は二つ
25. |　© Leverages inc. 25 この発表の本当の目的：個人レベルの開発生産性のあり方について考えること 文系大学生と学び考える開発生産性 ↓ 文系大学生と学び考える 個人レベルの 開発生産
26. 4. 文系大学生と学ぶ開発生産性
27. |　© Leverages inc. 27 個人の開発生産性を向上させる典型的な手法はいくつもあります
28. |　© Leverages inc. 28 • シングルタスク ◦ 一度にひとつのタスクに集中し、それを完了させること（マルチタスクの対義語） • タイムボックス法 ◦ 特定のタスクに割り当てられた固定の時間（タイムボックス）を設定し、その時間内に集中して作 業を行うこと • 優先順位付け ◦ 全てのタスクに優先順位をつけ、最も重要かつ緊急性の高いタスクから順に取り組むこと • ディープワーク ◦ メールやSNSの通知をオフにし、分断されることなく集中して作業を行う時間を作ること 個人レベルの典型的な開発生産性を向上させる手法（1/2）
29. |　© Leverages inc. 29 • 構造を頭の中にストックする ◦ これによりバグの原因や変更の影響度の把握が容易になる ◦ ex: 木構造（依存と変更の伝播、レンダーツリーなど）、メンタルモデル（シーケンス図、インター ネットの通信の流れなど） ▪ メンタルモデル：「ああなったらこうなる」というアクションのイメージ • 二分法によるバグ探索 1. 1~X行までバグを探索するとき、まず真ん中 (X/2行) でロギングする 2. ログの結果がおかしかったら 1~X/2-1行に、正常であれば X/2+1~X行にバグがある a. バグがある範囲が1/2に狭まる 3. 狭めたバグがある範囲の真ん中でさらにロギングする 4. これをバグがある行を特定するまで繰り返していく ◦ 闇雲に探索して最悪行うロギングの回数を Nとするとlog₂Nで済む 個人レベルの典型的な開発生産性を向上させる手法（2/2）
30. |　© Leverages inc. 30 へーシングルタスクに優先順位づけね！なるほど。。。
31. |　© Leverages inc. 31 そんなこと知ってるよ！！！！！！ 聞き飽きたわ！！（特に前の方）
32. |　© Leverages inc. 32 でも。。。
33. |　© Leverages inc. 33 でも。。。 僕 「自分はそれを実践できている」と100%自信を 持って言えますか？
34. 5. 文系大学生と考える開発生産性
35. |　© Leverages inc. 35 今から言うケースを自分に置き換えてイメージしてください
36. |　© Leverages inc. 36 • 午後3時、明日のプレゼンテーションの資料を作り終えました イメージしてください (1/4)
37. |　© Leverages inc. 37 • 次のタスク「バグの解消」に取り掛かります イメージしてください (2/4)
38. |　© Leverages inc. 38 • 何となくバグの原因が A や B に起因することがわかってきました イメージしてください (3/4)
39. |　© Leverages inc. 39 • 急にプレゼンテーションを思い出す連絡があり、 資料の誤字脱字やストーリーが不安になってきました イメージしてください (4/4)
40. |　© Leverages inc. 40 みなさんだったらどうしますか？ 資料を確認しますか？ するならどうやって確認しますか？
41. |　© Leverages inc. 41 みなさんだったらどうしますか？ 資料を確認しますか？ するならどうやって確認しますか？ 1. 午後3時、明日の大きなプレゼンテーションの資料を作り終えました 2. 次のタスク「バグの解消」に取り掛かりました • バグの原因が A や B に起因することがわかってきました 3. 急にプレゼンテーションを思い出す連絡があり、資料の誤字脱字やストーリーが不安に なってきました 　※ 全体のストーリーを俯瞰しちゃうと理想的な行動が思い浮かんじゃうので、 あえて文字の色を薄くしています 　※ 僕の実話なので結末があります
42. |　© Leverages inc. 42 • 特に何も考えずプレゼンテーションの資料をチェックします 結末 (1/2)
43. |　© Leverages inc. 43 • 終えた後にバグの解消に戻ると、 「あれ、バグってどこまで調べたんだっけ。。？」となった 結末 (2/2)
44. |　© Leverages inc. 44 A. シングルタスクをする（今のタスクに集中する） ◦ 「資料の見直しを行う時間」をスケジュールに入れ て、見直ししたい欲求を解消 B. 進捗をサブ論点の分解とする ◦ 「このバグの原因はなんなのか？」を「このバグの原因は AやBのどちらなのか？」のサ ブ論点 (Asanaだったらサブタスク) に分解してから、資料の見直しに移る おそらくすべきだったであろうこと どちらも典型的な手法になります
45. |　© Leverages inc. 45 たとえ知っていても これらが意外とできないできないことがあります
46. |　© Leverages inc. 46 なぜこれらができないのか？
47. |　© Leverages inc. 47 • パーキンソンの法則 ◦ 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する こと ◦ つまり、「早く仕事を終わらせて帰る」というモチベーションが欠如しているから ▪ → 個人レベルでは自己成長などのモチベーションもありそう • 双曲割引 ◦ 将来の報酬よりも現在の報酬を過大評価すること ◦ つまり、開発生産性が向上する行動へのスイッチという投資的な行動がしにくいか ら ▪ → これ自体は知覚することで一定解決する節がありそう なぜこれらができないのか？ 一般的に言われている理由
48. |　© Leverages inc. 48 　　僕自身が開発生産性を考える環境で感じている理由は、 個人にとっての開発生産性の現状（ASIS）が明確になりにくい ということ
49. |　© Leverages inc. 49 個人にとっての開発生産性の現状（ASIS）が明確になりにくい (1/2) • まず、個人の現状をそんなに考えることがない です ◦ マネジメントは小さい粒度でもタスク単位であり、個人単位でどういうプロセスを経て取り組んだか は顕在化しません ◦ チームにとってのレトロスペクティブみたく、きっかけがないと「開発習慣や生産性の現状」を把握 することは難しいです • さらに言うと、それらを明確にするコストが高い です ◦ 主に自分の思考回路に基づくので、他のメンバーからレビューを受けて修正するというより、内省 して言語化していくべきですが、これは非常に難しいです ◦ さらに「個人の開発生産性について考えよう！」とその効用を明示しないまま実行するほど、皆さ んは暇じゃないです。日々の業務があります
50. |　© Leverages inc. 50 個人にとっての開発生産性の現状（ASIS）が明確になりにくい (2/2) • 特に個人の開発生産性の話が出ても、いくつかのプラクティス（ + TOBE）が独り歩きしている状態 になっています • 「現状を把握する」なんて言われなくても重要であると理解できますが、こういった背景とこの背景 自体の可視化のしにくさもあり、実践にまで落とせていないのだと思います
51. |　© Leverages inc. 51 どうきっかけを作るか どうきっかけのコストを下げるかは。。。
52. |　© Leverages inc. 52 どうきっかけを作るか どうきっかけのコストを下げるかは。。。 正直わかりません！
53. |　© Leverages inc. 53 ◦ なので、このプレゼンテーションを一つのきっかけにしようと思 いました ◦ 今回ケースで自分がどうするかをイメージをしていただいたのは、 現在自分が持っている開発習 慣をできるだけ把握していただきたかったから です ◦ まさにネックであった現状 (ASIS) の把握を少しだけでもできたと思います この発表の本当の本当の目的
54. 6. おわりに
55. |　© Leverages inc. 55 1. 「『開発生産性の向上』という意味では、チームや部署レベルだけじゃなく、 最後の最後は自分 がやらなきゃいけない」という視点 2. こう言ってみるとすごく当たり前のことかもだが、 自分の開発習慣を内省し続けないと腹落ちし ないこと • 理解して当たり前で終わらせがち（流暢性の罠）だが、そこから先の結果に繋げたいとい うこと 3. チームや部署レベルと個人レベルの開発生産性の投資対効果に優劣をつけたいわけではな く、あくまで偏って考えないようにしよう ということ この発表で伝えたかったこと
56. |　© Leverages inc. 56 ◦ プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ ▪ より「プログラムをどう組む・読むか」に絞った内容が書かれています ◦ メタ認知で〈学ぶ力〉を高める: 認知心理学が解き明かす効果的学習 ▪ より「自分の状態・行動をどう知覚するか」に絞った内容などが書かれています ▪ 心理学の学術系の本ですが、特に前半は開発生産性にも通ずる内容です ◦ 畑村式「わかる」技術 (講談社現代新書) ▪ より「メンタルモデルをどう作るか」に絞った内容などが書かれています ▪ こちらもアカデミア寄りで、失敗学の延長線にあると思います ◦ 戦略「脳」を鍛える―ＢＣＧ流 戦略発想の技術 ▪ より「構造を実践でどう使うか」に絞った内容などが書かれています 余談：個人の開発生産性を向上させる有名な本（ありがたい。。） あえてIT系以外から多く選びました（文系大学生なので）
57. |　© Leverages inc. 57 開発生産性は、 確かにある側面では、理論と数式で表現された、リーダーだけの関心ごとのように見えますが、 また別の側面では、見えにくい形で、みなさんのすぐ隣に常にある、 良くも悪くもとても身近な存在なのだと思います これをきっかけに、ふとした瞬間に 「ちょっとあの開発生産性を上げる手法をやってみようかな」 などと思ってもらえたら嬉しい限りです おわりのおわり