(cache) 鬼速リモートな開発チームを支えるツールと仕組みとマインドセットの話

web系スタートアップ開発チームが仕組みもへったくれも無い状態からすったもんだありつつリモートワーカーも交えて良い感じにワークする体制で開発できるようになったなぁと言って良いところまで来たと感じたので、ここらでひとつ段落をつけて開発体制とか組織設計、体制作りみたいなところの話をまとめておきたいと思います。

サービス開発の現場に仕組みや体制を引く目的と意味

まず開発チームに体制や仕組みを引く意味、目的について。

開発速度の向上

これ１点に設定しました。

開発スピードで市場ごと引っ張る

展開中の事業ドメイン（教育）は今、ほっといても急成長中の市場でタブレット端末の導入がどんどん進んでいます。が、私立やいけいけの公立を除いて大体の公教育の現場では単純に既存のパソコンと置き換えてコスト削減に利用するだけだったり、まだまだ端末の普及が途中です。 IT機器の導入が教員の業務効率化や教育そのものの質の向上に寄与してそれが認められるようになるまでにはもうちょっとかかるか、といった感じです。

端末の普及速度に関して言うと、これはプレステ３が売れないとか、プレステ４が売れないみたいな話だと思ってます。

言い換えると「FF出たら買うわ」とか「ドラクエ出たら買うわ」って話で、ヒットアプリケーション、ヒットソフトウェア無しにハードは売れないという話です。

ソフトウェアの開発速度が端末普及速度に比例して、ひいては市場開拓の速度、教育そのものの改善速度に影響する。

鬼速で開発して教育というテーマにフィットした、先生、生徒、保護者、学校法人経営者、サービスプロバイダ、ハードのベンダー、行政、etcの「教育」のステークホルダー全員がAllHappyな製品の鬼速開発、鬼速提供によって市場開拓へ貢献しながらより良い教育のあり方を現場の先生方と一緒に鬼速で探していく所存です。

スピード改善に向かう生態系の構築

やったほうが良いことなんて無限にあるので

検証の必要無く明らかにやったほうが良いこと
効果が出るまで時間がかかりそうな早めに手をつけだしたいこと
効果が大きくすぐ実施できること
これやりたい！でも効果は未知数！

みたいな順で優先度つけながらやっていきます。

それはスピードを上げるか、と問い続ける

自分たちの習慣や成果を定期的に振り返って悪習を絶ち、振る舞いを改善していくという一連の流れを構築していく時に１つの効果検証の軸としてその施策は「スピードを上げたか」を基本的には評価します。ワークした施策は継続して微妙だったものはオペレーションから剥がします。

仕組みを用意する

以下の３点でエラーキャッチ、改善の提案、タスクレベルまで切って人員のアサイン、効果の測定までをカバーします。

コードレビュー
チーム内ステータスの見える化
KPT法を使ったPDCAの習慣

最低限この３つがワークしてれば大体の問題が回収できます。

GitHubのプルリクベースで行うコードレビュー

プルリクベース開発の細かいワークフローなんかについてはともかく、もたらす作用としては、開発者がソフトウェアに加えようとしている変更に対して他の開発者が改善案を提案したりバグを指摘したりしやすくしてソフトウェアの品質を高めるみたいな事です。

スクリーンショット 2014-07-10 1.08.32.png

コードレビューを通してバグの摘出のみならずエンジニア同士でノウハウの共有が行われたりもします。

https://github.com/

trelloを利用したチーム内ステータスの見える化とKPT法PDCAサイクル

タスク管理

trelloはめっちゃ簡単なタスク管理ツールみたいなものです。

ホワイトボード+付箋
Pivotal Tracker
asana
Backlog

タスク管理は上記、全部試した結果すべて入力と編集がめんどくさくて定着しませんでした。その点trelloはhtml5、JSゴリゴリのリッチUI実装で何かツール上でアクションを取る度にいちいち画面遷移が無いのでストレス無く頻繁に編集することが可能で重宝しています。

スクリーンショット 2014-07-10 14.12.13.png

誰がいつ、何をやっていて、計画に対する進捗はxxで、新規で入りそうな要件案件はどんなで、チームとして上がってる課題が何でそれに対してどんな施策を実施中で…

みたいなところまでを開発チーム内はもちろん、経営陣や他部署からも参照可能にします。

weekやmonthで見れたりもします。スクリーンショット_2014-07-10_14_12_35.png

ダメそうなとこはモザイクかけました。

https://trello.com/

KPT（Keep、Problem、Try）、PDCA（Plan、Do、Check、Action）

KPT法とは

振り返り、課題整理の１つの手法で、

Problem（問題点）
Keep（継続したいこと）
Try（問題点に対して取るアプローチ）

の３つでカードを管理して良い習慣の可視化と問題点の回収が成されたかどうかを定期的に振り返ってチームの習慣を改善していきます。

スクリーンショット_2014-07-10_14_18_57.png

このボードの中身を定期的に開発チーム全員で確認して問題点の洗い出しとそれに対するTryの提案を行うことでPDCAサイクルを回しています。

リモートで働きやすい文化をつくる

米yahooのアリッサメイヤーが元々yahooにあったリモートワーク文化をぶっ壊して会社来いやー！ってやって業績めちゃ上げた話は有名ですが、じゃあリモートってやっぱダメじゃんというのは些か乱暴な話です。

xxだからオフィスが良い、xxだからリモートが良いというのは文脈が多すぎて一概には言えないところで、ある場合ではオフィスに集まるのが良いと言えるし別の場合においてはリモートのほうが良い事もたくさんあります。

僕はどっちかというとリモートでちゃんと成果あげられる前提なら

高い家賃払ってオフィス借りて環境整えてってやんなくて良いし
旅したいやつは旅に出ながら仕事すればいいし
家借りて住んでる人は低かった稼働率が家から働ければめっちゃ上がるし
子供ちっちゃくても面倒見ながらできるし

みたいな事で、リモート派です。働き方アップデートしてこうぜと思ってます。ただどっちも必要かなと思うのでメインリモートでたまに集まるみたいにできればいいなぁと思ってます。

リモート波乗りエンジニアとリモート院生エンジニアの存在

家庭の事情で京都住みなので完全リモートのサーファーエンジニアと、少し耳を悪くしているのでチャットベースのコミュニケーションが楽な院生エンジニアがいます。

なので会議をGoogleDocsの同時編集機能とかチャット機能、コメント機能を使ってテキストベースでやるようにしていたり

スクリーンショット_2014-07-10_15_46_52.png

Sqwiggleを使ってリモートで不足しがちな表情が分かるフィジカルなコミュニケーションも取れるようにしています。

スクリーンショット 2014-07-10 15.51.22.png

https://www.sqwiggle.com/

性質、分量、頻度で役割の異なる複数のコミュニケーションチャネルを持つ

リモートでもそうでなくてもチーム開発で重要なのはコミュニケーションです。くだらない雑談も超重要事項の共有もそれぞれ均等に開発チームを組織していく上で大切なコミュニケーションだと考えています。

チャット（Slack）
プルリクベース（GitHub）
ビデオチャット（Sqwiggle）
wiki（GitHub）
Qiita::Team
日報（Gmail）

上記のメソッドをうまいこと要所要所に当て込んで性質の違うコミュニケーションがたくさん発生するようにしてます。

チャットベース

チームチャットはSlackを利用しています。

https://slack.com/

スクリーンショット 2014-07-10 16.34.26.png

HipChat：質素過ぎた。ぱっと見誰が喋ってるか不明
Skype：ファイル管理とか弱い
Chatwork：死ぬほど落ちる
Slack：機能充実、ビジュアルもいけてて全員すぐ気に入った

GitHubやtrello上のコミットやマージ、タスク追加などのアクションは全部Slackに流して共有しています。

スクリーンショット 2014-07-10 16.40.20.png

Qiita::Team

Qiita::TeamにはWikiに入れるとカオスになりそうなくらいの粒度の情報なんだけどチャットに投げるにはでかいしあんまり流れてほしくないみたいな投稿がされます。議事録投げたり技術調査の結果投げたり個人的なメモ投げたり結構自由で無法地帯になってますがコメントがいっぱいついたりしていてとても活発です。出勤した時とか帰る前とか、休憩中とかにのぞくと誰かしらが新しい投稿投げてたりしてそれを元に色々な情報交換やコミュニケーションが発生してます。

https://teams.qiita.com/features

screenshot-timeline-822a0ccd1cdb8d5082e29f0bac1b9045.png