今回の講習は、全3回のうちの第2回目です

株式会社リーデックス様にて、全3回の講習を行わせて頂く機会があり、今回は第2回について簡単に書いてみます。第1回目及び第3回目に関しては以下のリンク先を見て下さい。

講習は元々以下の内容でやる予定でした。

  • 1回目: 開発及びリモート開発を効率良く進めるための方法
  • 2回目: 確実に黒字を出す受託開発
  • 3回目: 技術の学び方、（と、1月からやっていた案件の技術的な話）

ただ、第1回ではリモート開発の話に辿り着く前に終わってしまったので、今回は、以下の2つのお話をしてきました。

  • リモートファースト開発のポイント
  • 確実に黒字を出す受託開発及び営業方法

後者は、弊社の体験談的な話が多くなってしまうので、前者に時間を多めに割いて説明しました。

第2回「リモートファースト開発のポイント」

第2回（の前半部）のタイトルは「リモートファースト開発のポイント」です。まぁ、大体その名の通りの内容で、具体的には以下についてお話しました。

  • 普段のリモート開発の状況
    • 人数、規模等
  • 非リモート開発との違い
  • リモート開発を円滑に進めるポイント

「普段のリモート開発の状況」は飛ばして、残りの2つについて、簡単に概要をご説明します。

非リモート開発との違い

通常の（非リモートの）開発とリモート開発での違いについては、色んな方がブログなどで経験談などを書かれていますが、まとまった情報が少ないように思えるため、主要な論点を整理して説明しました。

まず、違い、長所・短所を考える際に、立場によって異なると思いますので、

  • 開発者
  • 会社・組織（経営側）

のそれぞれの立場に関しての長所・短所を説明していきました。

簡単にまとめると以下の通りです。

  • 長所
    • 開発者として
      • (話しかけられる等の)割り込みを減らせる
      • 通勤に時間を取られない
      • 比較的、家事・育児・介護などと両立しやすい
      • 好きな場所で働ける
    • 会社・組織として
      • 優秀な開発者を採用できる
      • ワークフローの見直しにつながる
      • オフィススペースを節約できる
      • 災害時なども業務を継続できる
      • 地方のお客様への対応がやりやすくなる、場合もある
  • 短所
    • 開発者として
      • コミュニケーションの量が減る
      • 文字ベースのコミュニケーションに慣れる必要がある
      • 入ってくる情報が少なくなりやすい
      • 誘惑が多い、周りの目がないので、だらけやすい
      • 働き過ぎても、誰も止めない
      • 運動不足になりやすい
      • 時差があると、ミーティングの時間などに制約がある
    • 会社・組織として
      • メンバーがちゃんと働いているか分かりづらい
      • 労務管理が難しい
      • 就業規則の整備などが必要
      • 評価制度を変える必要が出てくる場合がある
      • 情報漏洩などに、より気を配る必要がある

それぞれの項目で、色々な補足説明などをしたのですが、それに関してはここでは省略させて頂きます。

その他の話題として

  • リモート開発に向いているプロジェクト、そうでないもの
  • リモートと非リモートの違いにどう対処するか

といった話もしました。

リモート開発を円滑に進めるポイント

次に、リモート開発を円滑に進めるポイントについてお話しました。前回の「型を持って、効率よく開発を進める」でお話した内容と重なる部分は軽く触れるに留め、リモート固有の話について説明しました。

こちらも世間で色んな方が情報発信していますが、まとまっている情報が少ないように思えたので、そうした内容をまとめるとともに、私達が経験していくなかで得られたプラクティスについても説明しました。

色んなポイントがあるのですが、ここでは重要なものをいくつか紹介します。

  • リモート開発を導入する際に、（例えば育児等で）必要性がある人から導入する、というのはやめる
    • 導入するのであれば、チーム・プロジェクト・会社全体で導入する
  • リモート開発の導入にあたり、以下のような仕組み・制度も整備・修正していく必要がある
    • 勤怠
    • 評価制度
  • コミュニケーションの量が減りがちなので、コミュニケーションの質・量・方法が適正になるように気を配る

後半は、契約関連の話で盛り上がりました

後半1/3くらいは、「確実に黒字を出す受託開発及び営業方法」というタイトルでお話させて頂きました。具体的には、

  • 受注元、プロジェクトの選別方法
  • 見積り方法
  • 契約形態

についてお話しましたが、一番最後の「契約形態」は、最近話題になる事も多いため、質問なども比較的多く頂きました。

主な契約形態とアジャイル開発

システム開発の一般的な契約方式は、以下の2つである点は、特に異論はないかと思います。

  • (一括)請負契約: システム一式X万円
  • 準委任契約: Y万円/日

ただ、アジャイル開発の場合、上の2つの契約形態（特に前者）だと無理が生じるため、各社色んな契約形態・ビジネスモデルを模索しているようです。

10 Contracts For Your Next Agile Project

アジャイル開発と契約形態に関しては、結構前ですが Peter Stevens さんという方が書いた「10 Contracts For Your Next Agile Project」が色々と示唆に富むので、それをベースに解説しました。

英語の原文は、元々は本人のブログだったようですが、現在はページが存在しません。ただ、丁寧に検索すれば、本人のプレゼンテーションの PDF が見つかるので、それを参考にしても良いですし、日本語での解説記事があるので、そちらを参照しても良いと思います。

日本語の解説記事は、以下のページで「アジャイルソフトウェア開発に適した契約」というキーワードでページ内検索をしてみてください。

http://www.csaj.jp/column/index.html

弊社でも、少し特殊な方式の契約を結ぶこともあり、それらに関しても説明しましたが、実際に契約形態を選ぶ前に

  • そのプロジェクトではどういったリスクが゙発生する可能性が高いか
  • そのうち、どのリスクをを防ぎたい・減らしたいか

の2点をを明確にする必要があると思います。

質疑応答

今回も最後に質疑応答の時間を取りました。全部は紹介できないので、いくつか抜粋します。

Q1. リモート開発の短所にどうやって対処しているか。
A1. 各短所と具体的なポイントのどれが関連しているかを回答しました。

Q2. リモート勤務中に、お客様から会社にその開発者宛の電話がかかってきたらどうするか。
A2. 会社携帯を持ってる開発者であれば、チャット等で会社携帯から折り返すように連絡する。あるいは、そもそも電話を使わず、ビデオ会議をメインのコミュニケーション手段とする。

Q3. 仕様が決まっていない場合、どうすれば良いか。
A3. 準委任契約にする、あるいは、仕様策定フェーズと開発フェーズで別契約にする、などが考えられる。

Q4. 正式契約前だが「人を確保しておいて」と言われたらどうするか。
A4. まずは、確度を考慮し、それに応じて、必要と言われた人数の一部だけを確保する。
また、重要なポイントとして、プロジェクト間で人を動かしても問題なく開発が回るような仕組みを構築しておく事が挙げられる。

最後に

今回も、資料を作る際に色々考えが整理されてきましたし、様々なご意見・ご質問などが出て、こちらとしても参考になりました。

第3回も実施済みですので、追って書いていこうと思います。

追記: 第3回目はこちら→ エンジニアの技術習得に関する講習を行いました

技術セミナーの依頼等、お問い合わせはこちらから。