🐕

フロー状態を促進するためのDevExアプローチ

に公開

概要

皆様、寒い中お疲れ様です!
こちら見てからブラックフライデーがちょっと違う日に感じるようになりました。

https://last-mile-movie.jp/

開発者体験をちゃんと自分のために整理したいと思い、
まずはフロー状態から。

  • ソフトウェア開発におけるフロー状態とは
  • フロー状態をDevExアプローチで向上させるには

結論はこちら

経緯

自分は以下のような状況なので、
開発生産性に対して特に興味があります。
というのもあり、DevExの主な要素の一つであります、
フロー状態を記載したくなった次第でございます。

[ざっくり現在の自己紹介]

  • BtoBマーケティングソフトウェア会社のエンジニア
  • エンジニア組織のマネジメントがメイン
    • 兼務:データパイプライン・チューニングあたりのドメインの一連の開発プロセス実施
    • 兼務:開発生産性向上(プロセス改善・自動化)の一連の整備プロセス実施
    • 時期によってはテックサポートだったりも実施

フロー状態

目の前の課題に深く没入し、時間を忘れるほど集中した状態

https://solution.jma.or.jp/column/c250523/

こと今回取り扱う、
フロー状態とはなんぞやに関しては以下記事等が参考になります🙇

システム開発において、
開発者が長時間深く集中して業務を継続し続けれるような状態

と認識している。

https://queue.acm.org/detail.cfm?id=3595878
https://github.blog/jp/2024-01-24-good-devex-increases-productivity/
https://tech.findy.co.jp/entry/2024/06/27/090000

なぜ重要か

もう有識者の方が実験していただいておりますが、
単純に生産性が上がります。
生産性が上がることによって顧客への価値提供が大きくなります。

生産性が上がったというのは数字上での結果であり、記事等では理由を詳細には記載していません。
が、フロー状態がエンジニアのみならず、
物事への集中力の非常に高い状態のことを指しており、
高い思考能力(課題/問題解決能力・論理的思考力・状況管理能力・言語化能力 etc)が必要なソフトウェア開発において、
通常の状態より生産性が上がることへの結びつきは自然かと存じます。

https://github.blog/jp/2024-01-24-good-devex-increases-productivity/

フロー状態作れている?

フロー状態に入るにはDevEx視点で何ができるか。

  • チャレンジとスキルのバランスを取る
    • スキルセット理解:メンバーのスキルセット理解
    • タスク設定:ストレッチゾーンのタスク設定
    • タスク補助記載:迷った時の回復アイテムとしての指針記載
  • 明確な目標
    • 短期目標設定:タスク達成条件の明確な記載
    • 短期目標設定:タスクチケットテンプレ整備等による情報量均一化
    • 短・中期目標設定:要求・要件定義書の記載粒度統一
    • 短・中期目標設定:プランニングでの目標合意形成
    • 中・長期目標設定:OKR等の目標設定の民主化
    • 中・長期目標設定:予実管理自動化によるpdca促進
    • 中・長期目標設定:開発生産性計測自動化による施策結果可視化
    • 中・長期目標設定:1on1等を通しての目標設定へのギャップ調整
  • 集中を逸らす通知の制限
    • ミーティング:形態の最小化(必要な人数のみの開催)
    • ミーティング:効率化(事前記載・共有した上での開催・ai議事録原則必須化)
    • ミーティング:機会圧縮化(バラけず、特定時間帯のみへのミーティング集約)
    • ミーティング:集中タイムカレンダー登録(自分へのタスクタイムへの配慮)
    • テキストコミュニケーション:Slack等、メッセージグループ整備(何でもかんでもメンションが飛んでこないか)
    • テキストコミュニケーション:集中タイム等への配慮(Slackのステータスを元に即レスが来ないことを配慮)
  • マルチタスクをやめる
    • シングルタスク化:1日の内の主業務として集中状態を試みるタスクは一つに向き合えている状態
    • マルチタスクに対するai対応:不確実性をaiを用いた並列稼働で一気に倒して、シングルタスクの配分を最適化してしまう「不確実性解消タイム」確保
    • https://zenn.dev/activecore/articles/578eaef79aaad2
  • 無理をしてフロー状態に入ろうとしない
    • パフォーマンス量:毎週同じパフォーマンス量を求めていないか
    • 環境整備:パフォーマンス量の揺れを理解しつつ、アプローチが必要な箇所のヒヤリングが行えているかどうか
  • 迷ったら、好きなことをする
    • 意思決定コミュニケーション:しなければならないではなく、したいどうかという問いベースで意思決定を行なえているかどうか
    • ※もちろん例外はあるが、したいを尊重した意思決定が結果として顧客に価値を最も届けるような開発者体験を整備する最適解という認識であるということ。
    • noncore業務の効率化:しなければならないはなるべくシステム or aiで自動化・最小化を試みているか

https://asana.com/ja/resources/flow-state-work
https://github.blog/jp/2024-01-24-good-devex-increases-productivity/

これから

  • 羅列しただけでもメンバーがフロー状態を維持するために、まだやれることがあるなと思っている内容多くがある。
  • このやれることがあるなをやった結果、
  • 何がどのようになってフロー状態に近づいており、
  • 開発生産性が向上しているかを可視化できているかを意識して
  • 開発者体験を論理的な数字・証拠に基づいたアプローチで整備しつつ、
  • メンバーのやりたいという感情に心理面での配慮ができる環境を整備していきたい。

参考資料

https://solution.jma.or.jp/column/c250523/
https://codezine.jp/article/detail/19022
https://asana.com/ja/resources/flow-state-work
https://github.blog/jp/2024-01-24-good-devex-increases-productivity/
https://www.jooto.com/contents/gtd/

Discussion