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

Slide 1

Slide 1 text

文系大学生と学び考える開発生産性レバテック開発部　古川修慈

Slide 2

Slide 2 text

|　© Leverages inc. 2 ● 名前：古川修慈 ● 所属： ● レバテック開発部新規開拓チーム ● 慶應義塾大学経済学部（4回生） ● 趣味：ゲーム、漫画、アニメ自己紹介

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

1. 開発生産性との出会い

Slide 5

Slide 5 text

|　© Leverages inc. 5 インターンを初めて２週間ぐらい！ちょっとずつ業務になれてきた！勉強も順調だ！僕

Slide 6

Slide 6 text

|　© Leverages inc. 6 メンターさんお疲れ様〜！だいぶ業務に慣れてきたね！ありがとうございます！僕

Slide 7

Slide 7 text

|　© Leverages inc. 7 開発生産性についても意識していって、個人についてもチームについても開発の意識を上げていけたらいいね！はい〜

Slide 8

Slide 8 text

|　© Leverages inc. 8 ところで開発生産性ってなんですか？

Slide 9

Slide 9 text

|　© Leverages inc. 9

Slide 10

Slide 10 text

|　© Leverages inc. 10 ほぉ〜れ（※超意訳）ｷﾞｬｯ!

Slide 11

Slide 11 text

|　© Leverages inc. 11 開発生産性についての本とカンファレンスを勧められる

Slide 12

Slide 12 text

|　© Leverages inc. 12 こうして開発生産性を学ぶ道のりは始まりました。。。

Slide 13

Slide 13 text

2. 開発生産性とは何なのか

Slide 14

Slide 14 text

|　© Leverages inc. 14 生産性 = 産出量（アウトプット） / 投入量（インプット） * 投入と産出が具体的に何であるかは、何についての生産性かによって変わる生産性とは

Slide 15

Slide 15 text

|　© Leverages inc. 15 開発生産性とは広木大地著『開発生産性について議論する前に知っておきたいこと』より一部引用

Slide 16

Slide 16 text

|　© Leverages inc. 16 具体的な指標 (1/2)：4Keys ● パフォーマンス分析を測る指標 ○ 青字はスピードを、赤字は安定性を測る ● デプロイ頻度　　　：実稼働環境にデプロイしたり、リリースしたりする頻度 ● 変更のリードタイム：変更の開始点から変更の終了点までにかかる時間 ● 変更障害率　　　　：運用環境への変更またはユーザーにリリースされた変更によって生じたサービス障害の内、その後修復が必要となる割合 ● 障害復旧時間　　　：デプロイ起因によってサービスが障害になった後、サービスを復旧するのに必要な時間

Slide 17

Slide 17 text

|　© Leverages inc. 17 ● あるものについて開始から完了までの 1サイクルに対して実際にかかる時間 ● 「あるもの」はサイクルタイムの種類によって変わります ● ex: Pull Requestのサイクルタイム ● 最初のコミットからPR作成まで ● PR作成からレビュー作成まで ● レビュー作成から承認まで ● 承認からマージまで具体的な指標 (2/2)：サイクルタイム

Slide 18

Slide 18 text

|　© Leverages inc. 18 主目的：事業の利益の向上 ↓ サブ目的：市場競争力の向上、コスト削減、顧客満足度の向上 ↓ サブ目的：開発生産性の向上なぜこれらを上げなきゃいけないのか

Slide 19

Slide 19 text

3. 開発生産性を学ぶ中で思ったこと

Slide 20

Slide 20 text

|　© Leverages inc. 20 まっったく腹落ちしない。。。僕

Slide 21

Slide 21 text

|　© Leverages inc. 21 ● 言っていることは理解できます ○ 「生産性 = 産出量（アウトプット） / 投入量（インプット）」も、 4Keysでスピードと安定性を測るのも、直感的に理解できます ● 理論は理解はできるが、実際のプラクティスの話になると、実践するイメージがどうしても曖昧にしか湧きませんでした腹落ちしない

Slide 22

Slide 22 text

|　© Leverages inc. 22 これはなぜなのか？

Slide 23

Slide 23 text

|　© Leverages inc. 23 ● 講演会などになると、どうしてもチームリーダーや事業責任者レベルの方がメインで発表する ↓ ● そうなると、内容は事業単位、小さくてもチーム単位での切り口（開発生産性向上の仕組みや成功事例）になってしまいます ○ そもそも開発とは基本チーム単位で行うものなので、その単位で開発生産性を語ることは当たり前 ↓ ● 僕自身がその立場じゃなかったから、そのレベルの開発生産性の話が腹落ちしなかった ● 体感にも沿っていますよね ○ 4Keysについても、定義自体は個人の生産性に適用できそうなものの、よく出る知見としては「部やチームでどういうルールを設けたか」のようなものが多いです一番納得する理由

Slide 24

Slide 24 text

|　© Leverages inc. 24 1. 事業責任者でもチームリーダーでもない自分（発表者）にとって、個人と個人間の開発生産性（ミクロな開発生産性）の方が腹落ちしそう 2. そういったミクロな開発生産性についてもう少し話す機会があってもよさそう ● これによって全体の開発生産性の向上にどれくらい寄与するかはあまりわかりません ○ （正直、組織レベルに比べたらかなり低いとは思います） ● ただ、（当たり前ですが）別の視点から開発生産を眺めること自体に意味はあると思います ● そしてなにより、それぞれが自身の開発生産性を考えることで、僕みたいにどこかで「自分と関係ないな」と一線を引いている人たちに、開発生産性を身近に感じてもらうことができます示唆は二つ

Slide 25

Slide 25 text

|　© Leverages inc. 25 この発表の本当の目的：個人レベルの開発生産性のあり方について考えること文系大学生と学び考える開発生産性 ↓ 文系大学生と学び考える個人レベルの開発生産

Slide 26

Slide 26 text

4. 文系大学生と学ぶ開発生産性

Slide 27

Slide 27 text

|　© Leverages inc. 27 個人の開発生産性を向上させる典型的な手法はいくつもあります

Slide 28

Slide 28 text

|　© Leverages inc. 28 ● シングルタスク ○ 一度にひとつのタスクに集中し、それを完了させること（マルチタスクの対義語） ● タイムボックス法 ○ 特定のタスクに割り当てられた固定の時間（タイムボックス）を設定し、その時間内に集中して作業を行うこと ● 優先順位付け ○ 全てのタスクに優先順位をつけ、最も重要かつ緊急性の高いタスクから順に取り組むこと ● ディープワーク ○ メールやSNSの通知をオフにし、分断されることなく集中して作業を行う時間を作ること個人レベルの典型的な開発生産性を向上させる手法（1/2）

Slide 29

Slide 29 text

|　© 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）

Slide 30

Slide 30 text

|　© Leverages inc. 30 へーシングルタスクに優先順位づけね！なるほど。。。

Slide 31

Slide 31 text

|　© Leverages inc. 31 そんなこと知ってるよ！！！！！！聞き飽きたわ！！（特に前の方）

Slide 32

Slide 32 text

|　© Leverages inc. 32 でも。。。

Slide 33

Slide 33 text

|　© Leverages inc. 33 でも。。。僕「自分はそれを実践できている」と100%自信を持って言えますか？

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

|　© Leverages inc. 35 今から言うケースを自分に置き換えてイメージしてください

Slide 36

Slide 36 text

|　© Leverages inc. 36 ● 午後3時、明日のプレゼンテーションの資料を作り終えましたイメージしてください (1/4)

Slide 37

Slide 37 text

|　© Leverages inc. 37 ● 次のタスク「バグの解消」に取り掛かりますイメージしてください (2/4)

Slide 38

Slide 38 text

|　© Leverages inc. 38 ● 何となくバグの原因が A や B に起因することがわかってきましたイメージしてください (3/4)

Slide 39

Slide 39 text

|　© Leverages inc. 39 ● 急にプレゼンテーションを思い出す連絡があり、資料の誤字脱字やストーリーが不安になってきましたイメージしてください (4/4)

Slide 40

Slide 40 text

Slide 41

Slide 41 text

|　© Leverages inc. 41 みなさんだったらどうしますか？資料を確認しますか？するならどうやって確認しますか？ 1. 午後3時、明日の大きなプレゼンテーションの資料を作り終えました 2. 次のタスク「バグの解消」に取り掛かりました ● バグの原因が A や B に起因することがわかってきました 3. 急にプレゼンテーションを思い出す連絡があり、資料の誤字脱字やストーリーが不安になってきました　※ 全体のストーリーを俯瞰しちゃうと理想的な行動が思い浮かんじゃうので、あえて文字の色を薄くしています　※ 僕の実話なので結末があります

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

|　© Leverages inc. 44 A. シングルタスクをする（今のタスクに集中する） ○ 「資料の見直しを行う時間」をスケジュールに入れて、見直ししたい欲求を解消 B. 進捗をサブ論点の分解とする ○ 「このバグの原因はなんなのか？」を「このバグの原因は AやBのどちらなのか？」のサブ論点 (Asanaだったらサブタスク) に分解してから、資料の見直しに移るおそらくすべきだったであろうことどちらも典型的な手法になります

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

|　© Leverages inc. 47 ● パーキンソンの法則 ○ 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張すること ○ つまり、「早く仕事を終わらせて帰る」というモチベーションが欠如しているから ■ → 個人レベルでは自己成長などのモチベーションもありそう ● 双曲割引 ○ 将来の報酬よりも現在の報酬を過大評価すること ○ つまり、開発生産性が向上する行動へのスイッチという投資的な行動がしにくいから ■ → これ自体は知覚することで一定解決する節がありそうなぜこれらができないのか？一般的に言われている理由

Slide 48

Slide 48 text

Slide 49

Slide 49 text

|　© Leverages inc. 49 個人にとっての開発生産性の現状（ASIS）が明確になりにくい (1/2) ● まず、個人の現状をそんなに考えることがないです ○ マネジメントは小さい粒度でもタスク単位であり、個人単位でどういうプロセスを経て取り組んだかは顕在化しません ○ チームにとってのレトロスペクティブみたく、きっかけがないと「開発習慣や生産性の現状」を把握することは難しいです ● さらに言うと、それらを明確にするコストが高いです ○ 主に自分の思考回路に基づくので、他のメンバーからレビューを受けて修正するというより、内省して言語化していくべきですが、これは非常に難しいです ○ さらに「個人の開発生産性について考えよう！」とその効用を明示しないまま実行するほど、皆さんは暇じゃないです。日々の業務があります

Slide 50

Slide 50 text

|　© Leverages inc. 50 個人にとっての開発生産性の現状（ASIS）が明確になりにくい (2/2) ● 特に個人の開発生産性の話が出ても、いくつかのプラクティス（ + TOBE）が独り歩きしている状態になっています ● 「現状を把握する」なんて言われなくても重要であると理解できますが、こういった背景とこの背景自体の可視化のしにくさもあり、実践にまで落とせていないのだと思います

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

|　© Leverages inc. 53 ○ なので、このプレゼンテーションを一つのきっかけにしようと思いました ○ 今回ケースで自分がどうするかをイメージをしていただいたのは、現在自分が持っている開発習慣をできるだけ把握していただきたかったからです ○ まさにネックであった現状 (ASIS) の把握を少しだけでもできたと思いますこの発表の本当の本当の目的

Slide 54

Slide 54 text

6. おわりに

Slide 55

Slide 55 text

|　© Leverages inc. 55 1. 「『開発生産性の向上』という意味では、チームや部署レベルだけじゃなく、最後の最後は自分がやらなきゃいけない」という視点 2. こう言ってみるとすごく当たり前のことかもだが、自分の開発習慣を内省し続けないと腹落ちしないこと ● 理解して当たり前で終わらせがち（流暢性の罠）だが、そこから先の結果に繋げたいということ 3. チームや部署レベルと個人レベルの開発生産性の投資対効果に優劣をつけたいわけではなく、あくまで偏って考えないようにしようということこの発表で伝えたかったこと

Slide 56

Slide 56 text

|　© Leverages inc. 56 ○ プログラマー脳～優れたプログラマーになるための認知科学に基づくアプローチ ■ より「プログラムをどう組む・読むか」に絞った内容が書かれています ○ メタ認知で〈学ぶ力〉を高める: 認知心理学が解き明かす効果的学習 ■ より「自分の状態・行動をどう知覚するか」に絞った内容などが書かれています ■ 心理学の学術系の本ですが、特に前半は開発生産性にも通ずる内容です ○ 畑村式「わかる」技術 (講談社現代新書) ■ より「メンタルモデルをどう作るか」に絞った内容などが書かれています ■ こちらもアカデミア寄りで、失敗学の延長線にあると思います ○ 戦略「脳」を鍛える―ＢＣＧ流戦略発想の技術 ■ より「構造を実践でどう使うか」に絞った内容などが書かれています余談：個人の開発生産性を向上させる有名な本（ありがたい。。）あえてIT系以外から多く選びました（文系大学生なので）

Slide 57

Slide 57 text

|　© Leverages inc. 57 開発生産性は、確かにある側面では、理論と数式で表現された、リーダーだけの関心ごとのように見えますが、また別の側面では、見えにくい形で、みなさんのすぐ隣に常にある、良くも悪くもとても身近な存在なのだと思いますこれをきっかけに、ふとした瞬間に「ちょっとあの開発生産性を上げる手法をやってみようかな」などと思ってもらえたら嬉しい限りですおわりのおわり