私はシステム開発会社に勤務しているソフトウェア開発者です。
親会社向けのWebシステムの開発や、親会社のお客様のシステムの受託開発が主なお仕事です。
CodeIQの出題者の仕事を個人として行っていて、そのきっかけで本業の一部として金曜日のみ別の会社の
システム開発をお手伝いすることになりました。これが2015年6月末のお話。
その時のエントリがこちら。
週1の現地勤務以外にも個人の時間で、個人としてリモートでもお手伝いしています。
今回振り返る内容はこの金曜勤務の会社の話のみです。
経緯
このエントリをまとめるに至った理由が実はありまして、今年は本業の開発が佳境にさしかかり、週に1回私が不在になるのがけっこうな痛手になってしまいました。
そのため、2016年6月末をもって金曜日に別の会社をお手伝いするのは終了になりました。
個人としては継続してお手伝いするのですが、リモートオンリーになり、主タスクが開発中心になってくるのである意味一区切りとなりました。
ちょうど参入して1年ということもあり、節目ということで振り返ってみることにしました。
ちなみに 2016/06/24（金）に最後のオフライン勤務を終えました。
関係者全員とがっちり握手をし、ここ1ヵ月ぐらいケアをしていた新人から菓子折りをいただきました。
リモート勤務は続くので辞めるわけではないですが熱い別れを初めて経験して嬉しいです。
本業の開発の状況次第では来年度からまたオフライン勤務が再開するかもしれません。
引き続きよろしくお願いします！
Before
私が参入する前の状況。 あるシステムの開発が2015年1月から開始して、2015年9月のリリースに向けて開発の最中でした。
- システムの要件は一部資料としてまとまっているが、初期作成後に変更された内容の最新化はまちまち
- 口頭のみでやりとりされて、記録が残っていない仕様がある
- 要件に関わる資料はある程度あるが、前任の開発者側がまとめた設計資料は一切なし
- 開発のタスクは前任の開発者の中で暗黙化されており、「何を作る必要があるか」「どこまで終わっているか」が全く管理されていない
- 前任の開発者は動くシステムを作り上げる能力はあったが、保守性・可読性の面で問題があった
- 要件提示側と開発者のやりとりはChatWorkが主。ChatWorkでやりとりした仕様に関する決定事項は「ChatWorkにしかない」状態
- 開発における業務フローが決まっていない
- 上記のような問題点が多かったため、本来リリース時点で整えるべきものが色々と滞っていた
- 前任の開発担当者がリモート協業なれしていない
というような問題がありました。
内部の情報をすべて出すわけにもいかないのである程度ぼかして書いてます。
After
以下の様な改善施策を行いました。
Slackへの移行
Slackを導入して、ChatWorkから移行しました。
外部連携の豊富さ 、 今後採用する開発者へのアピール 、 ChatOpsの導入 などを考えてSlackのほうが良いと判断しました。
結果、現在では
- チャンネル運用のガイドラインを決め、話題ごとにどのチャンネルを使うかが決まっている
- ChatBotが賑やかしてくれる
- 各種外部サービスからの通知が連携されている
- 分報で各自がひとりごとや困ったことや考えていることを垂れ流す
- ストックで扱うべきものは後述する esa にまとめる
のようになりました。
特にこの組織はリモート非同期で各自がばらばらの場所、バラバラの時間で勤務しているため、この辺りのリモートでの作業環境の整備は生産性に大きく影響を与える要素でした。
かなり良い環境になったのではないでしょうか。
オンラインのみのメンバーに状況を知らせるためには、どの情報を流しておく必要があるか？
各メンバーがそれを意識しながらチャットを活用する習慣がついてきました。
運用系の ChatOps については今後少しずつ入ってくる予定です。
esaの導入で暗黙知を可視化
参入直後、開発に関わる仕様のドキュメントなどの一部はGoogle Docsにあったものの、その他の情報はChatWorkの雑多な書き込みの中からかき集めなければならなかったり、そもそも資料として残っていない情報もある状況でした。
そこで、 esa の導入を決めました。
開発者以外のメンバーについても 全員問題なく Markdown で記事を書いてくれています 。
ありがたい。
導入にあたっては、序盤は徹底的に私が記事を書きました。
また社長が積極的に書いてくださる方だったので、この点も普及に好影響を与えたと思います。
今では記事数は社長が1位です。
若手は最初のうちは「何を書き残したらいいのか？」の判断に困っていたのかあまり書いていませんでしたが、今では各自の判断で必要な情報を書き残すようになってくれました。
この会社はWeb制作会社です。私がお手伝いしているシステム以外にも様々な業務情報があります。
多くの情報をesaで管理する習慣が付きました。
情報がなくて困ったら esa で検索。
なければ esa にまとめる。
そんな環境が整いました。
esa で管理している資料としては
- システムの仕様、手順、議事録など業務上必須の情報
- 技術情報、営業ノウハウなどTips的な情報
- 自己紹介その他、交流を円滑にする情報
- ポエムなど新たな企画のたねとなるもの
などがあります。
私は自社にも esa導入 をしたり、 情報会議 のスタッフをしているので、
そういったスキルを役立てることができました。
GitHub Issue, waffle.ioによる課題管理
課題が全く管理されていなかった状況からのスタートだったので大掛かりな改善でした。
まずは GitHub Issue による課題管理をはじめました。
こういったスタイルでの課題管理自体がはじめての組織だったため、Issueの記載についてもテンプレートを用意して記述する内容が厳密で、明確で、過不足ない内容になるようにサポートしました。
もちろんテンプレートだけあれば良いわけではないので、都度よりよい記載について説明しました。
幸い後から加わった優秀な中核開発者のIssueの記載内容が素晴らしく、生きた教材だったことも後押しになりました。
以前と比べ課題の内容が明確に管理できるようになりました。
雲泥の差です。
課題がしっかりと管理されていないと
- 作りたいものと別なものが仕上がってくる
- 作りたいものを明確にするのに多大な時間がかかる
などの悪影響があります。
これを改善することができました。
GitHub Issueには課題のステータスを管理する機能がないため、waffle.io を導入し、ワークフローを決めました。
これにより
- 課題の優先度が明確になった
- 各担当者の役割が明確になった（あれは誰がやるべきなの？）
- 各担当者の球持ちが明らかになった（あのタスク今誰が対応してるの？）
- 各担当者の現状が明らかになった（今あの人何してる？）
- 各週のIssueの消化状況などを把握できるようになった
などが達成されました。
細かな点としては、 Markdown を活用したわかりやすいIssueの書き方や、
Skitch を活用して画面・帳票などのどこに対する仕様、バグなのか認識の齟齬をなくしたり、Issueを短時間で把握できるできるようにする工夫などもレクチャーしました。
ワークフローの定義
GitHub + waffle.io のみではなく、業務においてワークフローが決まっているべき領域に関してワークフローが不明確であれば、内容を定義して esa にまとめて全体に説明し、フィードバックを受けながら改善していきました。
これにより
- 作業の抜け漏れ
- 担当が不明確なことによる待機時間
- ワークフローが不明確なことによるスピードの遅れ
などが解消されました。
イテレーション開発の導入
用語的にはスクラムの用語を用いて2週間単位でイテレーション開発を導入しました。
各開発者が非同期でバラバラに開発していることもあり、本来のスクラムのような十分な形での実施ではありませんが、与えられた制約においては良い形で運用できています。
- 優先度の管理
- 期間後の成果の管理
ができるようになりました。（継続改善中）
優秀な開発者の確保
参入時点で明らかにリソース不足でした。システム開発においてはこれは一番クリティカルな問題だったので、TOC（制約理論）でボトルネック分析を行い、この点を最も重視して対応しました。
多方面で動いていましたが、たまたまご縁のあったエンジニアさんに直接お声がけした結果手伝っていただけることになり、品質・生産性・保守性が圧倒的に高まりました。
他のエンジニアが14ヵ月かかる開発を1ヵ月ちょっとで仕上げる姿をみて全員唸っていました。
課題解決能力が非常に高い方なので自律して問題を解決してくれます。
私とともにここで上げているような改善自体にも尽力していただいています。
さらに、この方の参入をきっかけに私の友人2名が開発者として参入しました。
優秀な人と仕事をしたい開発者は多いので、最初にお声が消したエンジニアさんが参入してくれたからこそ、この展開があったのだと思います。
この2人も最初にお声がけした方と相互に尊敬しあうぐらい優秀なので、お互いにとってもよい刺激になっているんじゃないかと思います。
全員レベルが高く、その辺の市場で簡単に確保できる人材ではないので大きな貢献ができました。
優秀な人材とかって曖昧な表現ですが、ざっくりいうと
- 業務に必要な専門的な知識は十分にもっている
- その時点で必要な知識がなくても自分で調べて対応できる
- 自分がやるべきことを自分で把握し、指示待ちではなく自律して行動できる
- 問題点、課題などを自分で見つけて改善提案ができる
- ビジネス視点（お客様視点）で物事を考えて開発を捉えることができる
というようなレベルです。
私の紹介以外にも 1 名増員があったり、元々開発業務がメインではない方が開発業務にシフトしてきたりして開発リソースがだいぶ増えてきました。
ただし、サービスのビジネス要求も増えてきたので開発者が欲しい状況は継続していますけど。
心理的安全の確保
仕事をするのは人間です。
優秀な人は大抵良い成果をだしてくれます。
優秀な人が継続して関わってくれれば、結果は自ずとついてきます。
各メンバーが快適に仕事ができるようにケアをしてきました。
特にリモート非同期という点があるため、何もケアしないと各自が関わりをもたず
黙々とバラバラに作業をして、時には誤解をして歪みあったり、モチベーションを下げて「気づいたらAさんが組織からログアウトしていました」なんてことになりかねません。
そういうのはSI'erの下請け時代にたくさんみてきました。
そのためSlackの分報でやりとりを活性化したり、esaの自己紹介でお互いを知ったり、各自のやりとりが円滑になるようにたまにパスを出したり、各自が問題だと感じたり、やりにくいと感じているが言い出しにくいことを代わりに言って改善したり、あれこれとと動いてきました。
その成果なのか、最終オフライン勤務日に菓子折りをくれた新人から
「てぃーびーさんのおかげですぐに組織になじむことができました。ほんとうにほんとうにありがとうございます」
と感謝してもらいました。
こちらこそありがとうございます。
まとめ
一年間でこれほど変化のある組織も珍しいのではないか？というぐらい変化しました。
これはもちろん私だけの力ではありません。
仮に他の環境でこれを再現しろと言われてもかなり難しいと思います。
- これらの改善施策の提案 => 導入はほとんどノータイムで経営判断していただいた。予算が伴うものであっても
- もともと頭のいい人が多く、私が導入する各種しくみに対する学習コストが非常に低かった
- 元々私の友人や少なからず交流があった人の参入が多かったのでコミュニケーションコストが低かった
などが大きかったと思います。
逆にこの条件が揃うのであれば同じような貢献ができると思います。
