テレワークで始めたドキュメント駆動業務

こんにちは。電通デジタルでEMをしている河内です。エンジニアにおける採用・評価、スクラムマスターなどを担当しています。今回はすこし実装プラクティスから離れた話題になりますがお付き合いくださいませ。

弊社もご多分に漏れず完全テレワークを実施しており、かれこれ4か月が経ちます。その中で見えてきた課題とエンジニアチームとしてどう対峙したか、そしてそこで得た気づきを綴っていきたいと思います。この内容は、過去に開催したオンラインイベントでお話した内容になります。

テレワーク環境で私たちのエンジニア部門で急務と感じた課題

テレワークが開始された2月後半、プログラミングやシステム開発プロジェクトを生業とする私たちの部では「リモート？全然OK。支障無いっす。」とタカを括っておりました。しかし開始されて間もなく、やっぱり慣れていない事が判明・・・。テレワークを経験されている読者の多くの方が感じていることと同様の悩みにも直面しました。

・運動不足が激しい
・Web会議で誰か1人はいるネットワーク難民
・ミュート解除せずに独り言を続ける孤独
・「子」ワーキング（子どもの乱入）

でも私たちが一番課題視したのは、主業務以外の業務が思った以上に死角になる。という事でした。

主業務とは勿論プロダクト開発ー設計、コーディング、テスト、リリースーをすることです。ここで主業務以外と分けたのは、例えば、

・率先して技術共有してくれる人
・困っていそうな人に横から手を差し伸べる人
・業務支援フローを自然と型化してメンバーに教えている人

といったもので、チームの成長にとって、絶対に外せない業務がリモートになると見えづらくなりました。これは上長が部下を見る、ということもそうですが、メンバーが互いに認知し合うことも希薄になると感じました。

主業務であればソースコード、設計書、企画書等アウトプットが明確でメール、Git、Slackなどで情報流通がされやすいのですが、主業務以外の個々人の上記のようなメタ情報というのは意識的に流通させないと認知しづらいという性質がありました。この「個人メタ情報」の流通、認知が無ければ個々の成長、チームの成長も鈍化し同じ組織で働く意味も見いだしづらいと感じたのです。

GitLabハンドブックとの出会いと導入

そんな中で出会ったのがGitLab社が公開しているGitLabハンドブックです。どのようなものかは、「スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ」に分かり易く解説されている記事がありますので是非参考して頂けたらと思います。

ざっくりいうと会社で業務を遂行するためのあらゆる指針、ルール、業務マニュアルが記載されたドキュメント群なのですが、その中でも参考になる仕掛けやマインド（個人解釈）として、以下のことが挙げられます。

1．（たぶん）全社員が編集権限を有し、現場の集合知として『育て』られている点。
人から言われるより、自分が策定に絡んだり考えたりしたルールの方がモチベーションあがりますよね・・・また、『学習する組織』で言うところの「チーム学習」「共有ビジョン」にも通じるものがあり、何よりチームの業務プロセスそのものが自分事化される仕組みと言えます。

2．ドキュメント自体に変更理由や経緯、議論が全て記録されている
GitLab社なので、やっぱりドキュメントもGit管理です。書かれている業務ルールに疑問や不足があれば、Merge Request（GitHubでいうところのPull Requestに相当するもの）してGit上でディスカッション。みんなの合意が得られればMasterにマージされます。必然的に議論された内容しかハンドブックには記載されません。

3．テスト駆動開発を通常業務に転用している
テストコードを書いて、それに沿ってプロダクションコードを書いてプログラミングを行う、というエンジニアにとって馴染みのあるテスト駆動開発を業務そのものに取りこむやり方です。
業務を行う前にハンドブックを見る。書いてなければ、新たにハンドブックを書く。その次に業務を行うという、いわば「ドキュメント駆動業務」であるという点です。
一見、煩わしいのですが、何も考えずに脳死状態で業務に入るより、一旦客観的にプロセスを考えるという時間が生まれます。

早速これを我々のチームに、全員でディスカッションを重ねて導入してみました。我々が使っているソース管理はGitHubなので、ここに専用のリポジトリを作成し、例えば、

・自己紹介ページ
・部のミッション・価値観
・効率的なSlackルール
・各開発チームで決めた業務ルール
・新メンバーのオンボーディングプロセス

などをMarkdownでリポジトリにPushし、Masterにマージされたら自動的にHugoでS3にパブリッシュして部内公開される。といった仕組みを作っています（構築中・・・）。

上記のような仕組みでパブリッシュされ、実際にホストされたハンドブックの画面イメージは見出し画像の通りとなっています。

ただし、「それなら、あそこに書いてあるだろ！みとけや！」といったマサカリを投げつける行為は厳禁としています笑

気づきと学び

やってみて気づいた点がいくつかあります。1つは、全員の業務の入り口を押さえる形になり、全員が同じリポジトリをメンテナンスするので、前述のメタ情報の死角が少なくなります。そして、業務プロセスを省みる時間が生まれ、ソースコードの書き方、環境構築方法、Linter設定のベストプラクティスなどがどんどん提案されると、そこが個々のプレゼンスを発揮する場になります。

2点目は、非同期コミュニケーションの文化醸成です。我々エンジニアはSlackやメールを使った非同期コミュニケーションに慣れていると思っていました。しかし、実際は思いっきり口頭伝承、対面会議といった同期型コミュニケーションに大きく依存していました。どちらが良いというのではなく、この気づきから、同期/非同期どちらが適切かを考えるプロセスが生まれたことが学びと感じました。それは、Pull Request上での仕様策定のディスカッションに慣れていないという事でもありました・・・

3点目は、我々の業務の性質に寄与しそう、ということです。私たちエンジニアは社内のコンサルタントのテクノロジーに関する後方支援になります。変わりゆく多様なマーケティング課題に対し、私たちは適切な処方箋を薬箱から取り出し現場供給したり、テクノロジーの進化に伴い先回りしてツールを開発したりしなければなりません。ハンドブックはそういったテクノロジー知見の弾薬庫になり得るといった可能性を感じています。

まだまだ道半ば

とはいっても、トライしてまだ数ヶ月です。完全に軌道に乗せるために必要だと感じた仕掛けは、

「見える化」から「見せる化」への転換
設計レビュー、半期や四半期の個人レビューについてもこのハンドブックを利用することにより、半ば強制的に人の目に触れるようにすることが必要だと感じています。いまの私たちのエンジニア規模だと良いのですが人数が増えてくると露出のフリークエンシーが文化浸透スピードの鍵になります。

ジョブローテーション・スキルトランスファーの推進
新しいジョブへの挑戦機会は洗練されたハンドブックを育成させます。そして良く出来たハンドブックであれば、新しいジョブへのローテションハードルが下がり、人数規模の拡大に繋がるのではと期待できます。

まだまだ、課題は残されていますが、良いプラクティスが発見出来れば、また記事にしていきたいと思います。

一緒に働く仲間を探しています

私自身、採用も担当しており、ここからはちょっとお約束的なコンテンツを・・・
電通デジタルでは、一緒に働いてくださるソフトウェアエンジニア・データサイエンス仲間を募集しております！

エンジニア系
・ソフトウェアエンジニア（サーバーサイド）
・ソフトウェアエンジニア（フロントエンド）
・ソフトウェアエンジニア（SRE、サイトリライアビリティエンジニア）
・エンジニアリングマネージャー

データサイエンス系
・データサイエンティスト
・アナリスト