人に教える事で考えが整理できた
先日、ソフトウェア開発全般、そしてリモート開発に関して、取引先様で講習を行わせて頂く機会がありました。（講習の詳細は別エントリーにしようと思います。）
追記：第1回講習の詳細をこちらに書きました。
講習資料をまとめる過程で、今まであまり整理されていなかった考えなどがまとまって来た部分もあり、それを少し書いてみます。
講習で話した内容（リモート開発に関する部分）としては以下の通りです。
- 弊社のリモートワークの現状（規模・メンバー等）
- リモート開発の長所・短所
- リモート開発に向いているプロジェクト・向いていないプロジェクト
- リモートと非リモートの違いにどう対処するか
- リモート開発を進める上での、具体的なtips
このうち、リモート開発の長所・短所、及び具体的なtipsに関しては、色んな人が書いていますし、私自身も以前どっか別の場所で書いた記憶があるので、ここでは触れません。
今回は、リモート開発に向いているプロジェクト・向いていないプロジェクト、そしてそれを進めるためにどういうチームにすべきかについて書いてみます。
向いている・向いていないプロジェクト
前提
前提として、我々がやっている開発は以下の様なものです。
- Web系の開発が半分以上
- 規模は、1人〜数人で、数週間〜数ヶ月がほとんど
- チームメンバーは、フルタイムは少なく、パートタイムが大半
コミュニケーション関連が大きなポイント
リモートワークの特性として、通常の開発に比べると、コミュニケーションに関して以下のような違いがあります。
- コミュニケーションの量は少ない
- コミュニケーションはテキスト情報がメイン
要因1: やるべき事が明確か
従って、所謂「密にコミュニケーションを取って」開発を進めることは難しいです。ここから次の内容が導かれます。
- 要因1: 頻繁なコミュニケーションが必要となる、仕様・やることが未確定あるいは曖昧なプロジェクトの場合は、リモートワークとの相性が悪い
- 要因1′: 言い換えると、仕様がかっちり決まりやすい以下のようなプロジェクトは相性が良い
- プラットフォーム（OS・ミドルウェア）、フレームワークの移行
- 既存のシステムに対する、機能追加
なお、「やることが明確かどうか」と「仕様書の有無」には、そこまで強い相関は無いというのが個人的な感想です。仕様書があっても、内容が古かったり記述が曖昧だったりするとやることは不明確ですし、仕様書が揃って無くても、メールとかチャットとかでしっかり補足してもらえれば、そこまでやりにくさはありません。
要因2: 技術的な不確実性はないか
また、やることが明確かどうかという観点でいくと、新しい技術・不慣れな技術を使ったプロジェクトの場合、仕様が明確だったとしても、技術的にどう実装するか不明確な場合が出てくるため、不確実性が増します。
不慣れな技術を使ったプロジェクトの場合、メンバー同士で一緒に試行錯誤したり情報交換をしたりしながら、その技術に対する習熟度を上げていく事になります。リモートでも出来ないことはないのですが（後述します）、同じオフィスで顔を突き合わせて頻繁にコミュニケーションをしながらの開発の方が向いていると思います。
- 要因2: 慣れていない技術を使ったプロジェクトの場合、非リモートに比べて不確実性が高い
要因3: 階層が多くないか
リモートの場合、コミュニケーションの量がどうしても少なくなるので、コミュニケーションロス・ミスコミュニケーションが発生しがちです。従って、組織構造が多階層の場合、それが積もり積もって無視できない量になります。（伝言ゲーム）
- 要因3: 多階層の組織は、リモート開発に向かない
- 大規模プロジェクト
その他の要因
要因4: 既存の暗黙知が多いか
コミュニケーションに関する内容と関連しますが、リモート開発の場合、テキストベースのコミュニケーションになり、知識の伝播もテキストベースとなります。
- 情報をテキストでやりとりしなければいけないので、必然的に形式知に変換されやすい
- 言った言わないは発生しづらい
- 反面、チャットの投稿・通知が沢山発生するため、情報に埋もれやすい
- 既存の暗黙知の量が多いと、テキストにして伝えるのが大変で、一人に固定化されやすい
従って、次の事が言えます。
- 要因4: 既存の暗黙知が多いプロジェクトは、リモート開発には不向き
- 長期で行われているプロジェクト
要因5: リモートワークに理解がない
最後に根本的な話ですが、お客様・取引先・あるいは同僚がリモートワークに理解がない場合、無用な不信感を与えがちで、リモート開発には向きません。当たり前の話ですが。
- 要因5: お客様・取引先・あるいは同僚がリモートワークに理解がない場合、リモート開発は行わない方が無難
- （社内だけの話であれば、トップダウンで変革は可能）
対策
ここまでの話をまとめると、リモート開発が適用できる範囲は非常に限定されているような印象を受けたかもしれませんが、ちょっとした工夫をすることで、かなり改善することは可能です。
そして、リモート開発ならではのメリットも最大限活かすことで、比較的広い範囲のプロジェクトで効率的にリモート開発を行えるようになると思います。
分割が鍵
色んな要素を少し細かめに分割して疎結合にすることで、コミュニケーションが発生する箇所を減らすことができ、結果としてコミュニケーション関連のデメリットは減らせます。
対策1: タスクを分割
まずはタスクの分割です。例えば、雑に「○○画面の開発」みたいなタスクを大雑把に作ってチームに投げるのではなく、デザイン・マークアップ・テーブルの追加・APIの実装・フロントエンドの実装、のように分割するというのがあります。
タスクを分割するに当たって、アーキテクチャや設計で曖昧な部分があると分割出来ないことも多いので、ソフトウェア開発タスクを分割するというのは、ソフトウェアの設計を進めるということと意味的に近いものになるかと思います。（なお、これは、必ずしも各タスクをミニ・ウォーターフォールにするという意味ではありません。）
対策2: システムを分割
タスクを分割する以外に、システムを分割して、マイクロサービス的なアーキテクチャにするというのも有効な方法だと考えます。これが有効な理由は、タスクの分割と同様です。
最近では、仮想化・コンテナ化の技術が進化していますので、例えば Docker を使って、マイクロサービスアーキテクチャの思想を取り入れたシステムが増えているように感じます。
対策3: チームを分割
システムの分割と関連しますが、経験上、非リモート開発に比べて少しチームを小さめに保っておいたほうが、効率的に開発を行えると思います。
出来る範囲でコミュニケーションを増やす
いくら構成要素を分割しても、プロジェクトにコミュニケーションは不可欠です。少ないコミュニケーションで、最大限知識を移転出来るような仕組みを組み込んでおくと良いと思います。
対策4: ペア作業
このアイディアの源流は eXtreme Programming のペアプログラミングですが、プログラミングに限らず、多くの作業を複数人で行うことにより、効果的に知識の移転が出来るようになります。
リモートの場合、画面共有を行ってペアプログラミングを行いますが、ここでいう「ペア作業」は、必ずしもリアルタイムで2人が同じ作業を行う場合だけでなく、非リアルタイムを組み合わせることも可能です。
具体的には、作業量の見積もりなどは、2人が個別に値を出して、最後に2人で話し合ってそれをすり合わせる、といった事をやっています。
また、レビューも必ず複数人で行っています。これは、複数の方が問題点を発見しやすいというのもありますが、レビュー対象のコードを複数人が把握することが出来るというメリットも大きいです。
対策5: 非公式の情報共有の場を作る
これは、リモート開発に限らず実践している会社・チームも多いと思いますが、以下のようなものを作って、そこでの情報発信を推奨する事で、コミュニケーションが促進される効果があります。
- チャットの情報共有用チャンネル
- 社内 wiki
まとめ
リモート開発では、コミュニケーションの量が減りがちなので、それを緩和する対策（分割及びコミュニケーションの促進）を取ると共に、リモート開発ならではのメリット（本エントリーの対象外）を組み合わせることで、効率よい開発が出来ると思います。
弊社でフルリモートの開発を行ってみたいエンジニアの方は、以下のページよりお気軽にお問い合わせ下さい。
コメントを残す