KESSAI(以下MFK)の近藤です。前職はスマホゲームのクライアントをC++で書いてたり、受託案件のサーバーをPHPで書いてたりしましたが、いまはモリモリGolangでサーバーのコードを書いてます。MFKでは開発の方針としてフロー効率を重視しています。今回はMFKでのフロー効率を意識した開発の進め方を紹介します。そもそもフロー効率がいいとはフロー効率のいい状態とは、処理待ちになっているタスクが少なく、タスクの着手から完了までの時間が短い状態です。一方でリソース効率がいい状態とは、開発者の作業待ち時間が少なく、常になんらかの作業ができている状態です。詳しくは下のスライドをご参照ください。「フロー効率性とリソース効率性について」なぜフロー効率を重視し始めたのかMFKではスクラムのスプリント期間を1週間として開発を進めています。1週間以内に完了していないタスクが多数あるというケースが頻発しました。個人にアサインされて一人でそのタスクをこなしていて、すこしでも詰まったりするとスプリント計画を達成できないというケースがそこそこあり、みんなで改善案を出すことになりました。そこでフロー効率を重視してみてはどうかという案が出て、1つのタスクに複数人をアサインして素早く確実に潰していこうということになりました。いう風にやっているのか大型ディスプレイによる自然発生的なモブプロオフィスには55インチの4Kモニターが置いてあり、予約なしでいつでも使えるようになっています。エンジニアは大体このモニター前にいることが多いので、わからないことがあればここにディスプレイをつなぐとその辺にいる人が教えてくれます。わからないことがあれば速攻で解決することがほとんどなので、みんな気軽にディスプレイをつなぎにきます。_)m」とか頼まなくても自然発生的にモブプロが始まります。大きなタスクは子タスクに分割してみんなで共有ひとりで終わるだろうと思ってタスクを始めたものの、実はめちゃくちゃ大変でやんなきゃいけないことが次から次へ出てくるなんてことありますよね?そんなときに一人で悩むのではなく、やるべきタスクを洗い出してみんなと共有します。みんなでその子タスクを潰しにかかります。「このタスク、めちゃめちゃ重いけど一人でやらなきゃいけないのマジで辛い」とか思う必要はありません。みんなに共有してみんなで潰すのがMFK流のやりかたです。WIPでPRを出す途中のコードでも他の人にどんどん見てもらいます。タスク用のブランチを切って一度でもコミットをすれば、GitHubに[WIP]という文字をつけてレビュワーのアサインなしのPRを作ってもらうようにしています。作りかけでも他の人が見えるようになることで無駄な実装をしていないかわかりますし、自分のタスクと関連があれば事前にコードをみて適宜調整することで手戻りを少なくできます。途中でも全くかまわないので他の人がコードを見れる状態にしておくことを重視しています。実際やってみてどうだった?ドメイン知識が共有されて属人化しなくなったみんなで同じタスクをやることで自分が関わっていないタスクが少なくなります。「いつの間にか知らないテーブル追加されてた」みたいなのがまず発生しなくなります。個人的には一番デカいメリットだと感じています。コミュニケーションが増えてスムーズにタスクを進めることができるようになった途中で行き詰まって実装が止まったり、実装したものが無駄になるケースが確実に減りました。実装に行き詰まれば周りに聞いて解決すればいいし、思ってたのと違って方針を変更したい時にもその場で話してすぐに決めてしまえばいいんです。理由もなくいきなりモブプロを始めてもいいです。開発速度が上がったひとりで悩むより周りに助けを求めた方がやっぱり問題の解決は早いです。悩んで疲れた頭で考え続けるよりも、まだその問題を触っていないフレッシュな頭を持った人がサクッと解決することって結構あったりします。周りに助けを求めてみよう!メンタルヘルスが向上したタスクに対する責任を個人ではなく全員で持つのでメンタル的に楽になりました。個人の責任が薄くなるということはないですが、一人で責任を抱え込むのではなく、ちゃんと頼れる仲間がいると思えるので心理的な負担は減りました。デメリットってなんかある?今のとこ特にない気がしています。おわりにMFKに入社以前はフロー効率とは完全に真逆の考え方で開発を行なっていて、正直フロー効率ってどうなの?って思ってましたが、やってみると結構よくてフロー効率推しになっちゃいました。早くフロー効率のことを知っておきたかったと割とマジで思っています。KESSAIにご興味をもたれた方はぜひ採用情報からご連絡ください。カジュアルな面談でも大歓迎です。安心で、世の中をなめらかに。