Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Tech Leverages

March 27, 2024
Tweet

More Decks by Tech Leverages

Other Decks in Technology

Transcript

  1. | © Leverages inc. 2 • 名前:古川 修慈 • 所属: •

    レバテック開発部 新規開拓チーム • 慶應義塾大学 経済学部(4回生) • 趣味:ゲーム、漫画、アニメ 自己紹介
  2. | © Leverages inc. 3 目次 • 開発生産性との出会い • 開発生産性とは何なのか •

    開発生産性を学ぶ中で思ったこと • 文系大学生と学ぶ開発生産性 • 文系大学生と考える開発生産性 • おわりに  
  3. | © Leverages inc. 14 生産性 = 産出量(アウトプット) / 投入量(インプット) *

    投入と産出が具体的に何であるかは、何についての生産性かによって変わる 生産性とは
  4. | © Leverages inc. 16 具体的な指標 (1/2):4Keys • パフォーマンス分析を測る指標 ◦ 青字はスピードを、赤字は安定性を測る

    • デプロイ頻度   :実稼働環境にデプロイしたり、リリースしたりする頻度 • 変更のリードタイム:変更の開始点から変更の終了点までにかかる時間 • 変更障害率    :運用環境への変更またはユーザーにリリースされた変更によって生 じたサービス障害の内、その後修復が必要となる割合 • 障害復旧時間   :デプロイ起因によってサービスが障害になった後、サービスを復旧 するのに必要な時間
  5. | © Leverages inc. 17 • あるものについて開始から完了までの 1サイクルに対して実際にかかる時間 • 「あるもの」はサイクルタイムの種類によって変わります •

    ex: Pull Requestのサイクルタイム • 最初のコミットからPR作成まで • PR作成からレビュー作成まで • レビュー作成から承認まで • 承認からマージまで 具体的な指標 (2/2):サイクルタイム
  6. | © Leverages inc. 21 • 言っていることは理解できます ◦ 「生産性 = 産出量(アウトプット)

    / 投入量(インプット)」も、 4Keysでスピードと安定性を測るの も、直感的に理解できます • 理論は理解はできるが、 実際のプラクティスの話になると、実践するイメージがどうしても曖昧にしか 湧 きませんでした 腹落ちしない
  7. | © Leverages inc. 23 • 講演会などになると、どうしてもチームリーダーや事業責任者レベルの方 がメインで発表する ↓ • そうなると、内容は事業単位、小さくてもチーム単位での切り口

    (開発生産性向上の仕組みや成功事例)になってし まいます ◦ そもそも開発とは基本チーム単位で行うものなので、その単位で開発生産性を語ることは当たり前 ↓ • 僕自身がその立場じゃなかったから、そのレベルの開発生産性の話が腹落ちしなかった • 体感にも沿っていますよね ◦ 4Keysについても、定義自体は個人の生産性に適用できそうなものの、よく出る知見としては 「部やチームで どういうルールを設けたか」のようなものが多いです 一番納得する理由
  8. | © Leverages inc. 24 1. 事業責任者でもチームリーダーでもない自分(発表者)にとって、 個人と個人間の開発生産性(ミクロな 開発生産性)の方が腹落ちしそう 2. そういったミクロな開発生産性について

    もう少し話す機会があってもよさそう • これによって全体の開発生産性の向上にどれくらい寄与するかはあまりわかりません ◦ (正直、組織レベルに比べたらかなり低いとは思います) • ただ、(当たり前ですが) 別の視点から開発生産を眺めること 自体に意味はあると思います • そしてなにより、それぞれが自身の開発生産性を考えることで、僕みたいにどこかで「自分と関係 ないな」と一線を引いている人たちに、 開発生産性を身近に感じてもらう ことができます 示唆は二つ
  9. | © Leverages inc. 28 • シングルタスク ◦ 一度にひとつのタスクに集中し、それを完了させること(マルチタスクの対義語) • タイムボックス法

    ◦ 特定のタスクに割り当てられた固定の時間(タイムボックス)を設定し、その時間内に集中して作 業を行うこと • 優先順位付け ◦ 全てのタスクに優先順位をつけ、最も重要かつ緊急性の高いタスクから順に取り組むこと • ディープワーク ◦ メールやSNSの通知をオフにし、分断されることなく集中して作業を行う時間を作ること 個人レベルの典型的な開発生産性を向上させる手法(1/2)
  10. | © 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)
  11. | © Leverages inc. 41 みなさんだったらどうしますか? 資料を確認しますか? するならどうやって確認しますか? 1. 午後3時、明日の大きなプレゼンテーションの資料を作り終えました 2.

    次のタスク「バグの解消」に取り掛かりました • バグの原因が A や B に起因することがわかってきました 3. 急にプレゼンテーションを思い出す連絡があり、資料の誤字脱字やストーリーが不安に なってきました  ※ 全体のストーリーを俯瞰しちゃうと理想的な行動が思い浮かんじゃうので、 あえて文字の色を薄くしています  ※ 僕の実話なので結末があります
  12. | © Leverages inc. 44 A. シングルタスクをする(今のタスクに集中する) ◦ 「資料の見直しを行う時間」をスケジュールに入れ て、見直ししたい欲求を解消 B.

    進捗をサブ論点の分解とする ◦ 「このバグの原因はなんなのか?」を「このバグの原因は AやBのどちらなのか?」のサ ブ論点 (Asanaだったらサブタスク) に分解してから、資料の見直しに移る おそらくすべきだったであろうこと どちらも典型的な手法になります
  13. | © Leverages inc. 47 • パーキンソンの法則 ◦ 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する こと ◦

    つまり、「早く仕事を終わらせて帰る」というモチベーションが欠如しているから ▪ → 個人レベルでは自己成長などのモチベーションもありそう • 双曲割引 ◦ 将来の報酬よりも現在の報酬を過大評価すること ◦ つまり、開発生産性が向上する行動へのスイッチという投資的な行動がしにくいか ら ▪ → これ自体は知覚することで一定解決する節がありそう なぜこれらができないのか? 一般的に言われている理由
  14. | © Leverages inc. 49 個人にとっての開発生産性の現状(ASIS)が明確になりにくい (1/2) • まず、個人の現状をそんなに考えることがない です ◦

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

    になっています • 「現状を把握する」なんて言われなくても重要であると理解できますが、こういった背景とこの背景 自体の可視化のしにくさもあり、実践にまで落とせていないのだと思います
  16. | © Leverages inc. 53 ◦ なので、このプレゼンテーションを一つのきっかけにしようと思 いました ◦ 今回ケースで自分がどうするかをイメージをしていただいたのは、 現在自分が持っている開発習

    慣をできるだけ把握していただきたかったから です ◦ まさにネックであった現状 (ASIS) の把握を少しだけでもできたと思います この発表の本当の本当の目的
  17. | © Leverages inc. 55 1. 「『開発生産性の向上』という意味では、チームや部署レベルだけじゃなく、 最後の最後は自分 がやらなきゃいけない」という視点 2. こう言ってみるとすごく当たり前のことかもだが、

    自分の開発習慣を内省し続けないと腹落ちし ないこと • 理解して当たり前で終わらせがち(流暢性の罠)だが、そこから先の結果に繋げたいとい うこと 3. チームや部署レベルと個人レベルの開発生産性の投資対効果に優劣をつけたいわけではな く、あくまで偏って考えないようにしよう ということ この発表で伝えたかったこと
  18. | © Leverages inc. 56 ◦ プログラマー脳 ~優れたプログラマーになるための認知科学に基づくアプローチ ▪ より「プログラムをどう組む・読むか」に絞った内容が書かれています ◦

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