少人数プロジェクト途中経過 その2
プロジェクト開始から3ヶ月ほど経過し、残り1ヶ月といったところです。
おさらいのため、メンバ構成や進め方を少し紹介します。
私を含め、プロジェクトメンバは全員で3人です。
私以外のメンバはオフショア先のメンバですが、1人は必ず日本にいるような体制にしてみました。理由は前述のとおりです。
少人数プロジェクトの特徴
距離が近いのもあって、お互いのパーソナリティや仕事の進捗具合、得意・不得意がよくわかります。
また、状況がコロコロ変わってもその場ですぐに伝えられるのは大きいです。
離れていると、どうしても絵とセットで説明したドキュメントを用意したり、テレビ会議の時間を確保したりと、コミュニケーションコストと時間が掛かりますが、
隣にいれば裏紙を使って5分程度で状況の変化や指示を伝えられます。
少人数プロジェクトのいいところ
上記のとおりなので、あまりツールに頼らなくてもコミュニケーションが原因でミスをするリスクは低くなっています。
逆にツールを使って進捗を管理するほうが、時間のロスに感じることもあります。
進捗はFace to Faceで、お互いの気になるところ、心配なところを中心に毎日15分〜30分ほどやっておけば、大きな問題は発生しないように思います。
気をつけるポイント
オフショアだからというものは、あまりないかもしれません。
現在、進捗に影響する要員として、どうしてもメンバに割り込みで他の作業が入る、というものがあります。
ただ、進捗に大きく影響するのは、日本人だけのプロジェクトでも同じだと思います。
あと、現在のメンバは開発経験が長めで、多くの指示を出さなくても自分で考えて行動することができるため、もし1〜2年目のメンバだけだと同じようなプロジェクト運営は難しいかもしれません。
離れた場所で働くチームのコミュニケーション
ソニックガーデンの倉貫さんのブログのエントリに
「離れた場所で働くチームの作り方」
というものがありました。
離れた場所で働いていたのは日本人ですが、働く場所が異なる状況でチームとして仕事をする上で参考になることがたくさん書かれてあったので、紹介と自分の意見を記していきたいと思います。
#この記事以外も、倉貫さんのソフトウェア開発に対する考えはとても興味深いです。
記事の中では、ステークホルダーや開発者がどのようなツールを活用して仕事をしているかが紹介されていました。
わたしは、離れた場所で働く場合に重要になるもののひとつは、コミュニケーションだと思っているのですが、紹介されているコミュニケーションツールやその使い方は、その点を非常に考慮された結果になっているように感じました。
日頃の社内の雰囲気や会話が伝わるように、常時接続されているSkype。
これはいつでも話しかけられたり、話しかけたいときに使われているようです。
大げさなテレビ会議システムだと、設備の予約や準備が必要で、電話でも「電話を掛ける」というのは「気軽に話しかける」とは違った感覚的な壁があります。
常時接続のSkypeなら、離れていても隣で一緒に働いているのに近いコミュニケーションが取りやすくなります。
電話やメールじゃだめなの？とか考えてしまう人もいるかもしれないですが、
一見ささいな違いなように聞こえて、「常時接続」と「電話を掛ける/メールを送る」ではコミュニケーションの効果に大きな差があると思います。
話しかける気軽さとでも言ったものでしょうか。
次に、youRoomというツールですが、Skypeで話しかける雰囲気じゃないけど
話しておきたい、回答がほしいときなどに使われているようでした。
Skypeで相手側の状況がわかるからこそ、いまは話しかける時じゃないなというのがわかります。
ただ、それでもあとでキチンとお話して結果を残しておきたい場合などに使うようです。
記事でも説明してますが、メールよりも手軽で、複数人でのコミュニケーションに向いているみたいです。
わたしも個人的に漠然とですが、「メールで仕事するのは前時代的なのかな」と感じているのでyouRoomのようなツールが社内やお客さんと共通で使えたらいいなぁと思っています。
そして、仕事はチケット駆動開発で進めるためのツール(Pivotal Tracker)を使っていました。
似たようなツールは、わたしも自分のプロジェクトで試しに使っているのですが、お互いの作業の見える化にもなるし、無駄な作業や誤解が減るように思います。
このように、コミュニケーションの性質や特性に合わせて、適切なツールを使い分け、いかに離れているという制約をハンデにしないかがとても考慮されている仕組みだなと思いました。
ただ、いくらいい仕組みが用意されていても、仕組み以外にも気を配らないといけないことがあります。
無意識にやっていたことでしたが、記事を読んで「なるほど」と思った仕組み以外にも大切なことは、「チームの信頼関係は事前に築いておく」ということです。
ソニックガーデンでは、リモートで働いている人を外部リソースとは捉えておらず、
チームの一員として共に働いている感覚でいると述べられています。
オフショアの開発でも、わたしは海外のメンバをただの外部リソースとは扱っていません。
同じプロジェクトのチームの一員として、たとえ3、4年でどこかにいなくなってしまう現実が
あっても、相手を信頼し共に成長しながらプロジェクトを成功させようと行動しています。
コミュニケーションの中で、送り手から受け手に正確に情報や考えが伝わるメカニズムがあるのですが、
そのコミュニケーションの第1ステップとして「相手の背景・価値観の理解」が必要です。
おなじ日本人同士ならまだしも、オフショア開発では国も文化も世代も異なる相手と一緒に仕事をするので、
背景・価値観の理解は本当に重要だとつくづく感じます。
ソニックガーデンでは、離れたメンバと食事を一緒にとるということもやっていたのですが、
やはり背景・価値観の理解をするのは仕事上のコミュニケーションだけでは難しいことが
考慮された結果だと思われます。
オンもオフもコミュニケーションを取って初めて、その人の人となりが理解できるのではないでしょうか。
オフショアだと休み時間も合わないため、オフを一緒に過ごすのは出張以外だと難しいのですが、テレビ会議のちょっと空いた時間に仕事と関係ない話を無理やりでもするように心掛けています。
実際に仕事とは関係なくても、このコミュニケーションの積み重ねが相互の理解と信頼を築くことに繋がると信じています。
ソニックガーデンの人たちの取り組みを知り、改めてまだまだ自分の置かれている環境はコミュニケーションに改善の余地があることに気付くことができました。
同じ仕組みの実現は難しくとも、重要な要素を意識してオフショア先のメンバを
コミュニケーションを取って行きたいと思います。
少人数プロジェクト途中経過
少人数プロジェクトで1ヶ月ほど経過したので、状況や気付きなどを記録。
プロジェクトに必要な技術要素がほぼ未経験分野だったため、情報収集や小さなトライアルをしながら進めています。
いろいろ訳あって、オフショア先のメンバを1人日本に呼んで開発を進めることになりました。
いまのところの感触としては、呼んでおいて正解だったと思います。(利益はないに等しいですが・・・)
やはり、いちいち変わる考えや予定を、限られた時間と手段で伝えるのはロスが多すぎて、完全にオフショアでっていうのは今回のプロジェクトには合わなかったように思います。
ただ、1人は呼んでいないため、仕事の環境だったり進め方の違いが分かるので、興味深いところもあります。
例えば、日本だったら簡単に手に入る参考書が、オフショア先だと輸入の関係で数週間かかってもなかなか購入したいものが手に入らなかったり、日本語でアクセスできる情報が英語だと見つからなかったり(逆もありますが)します。
あと、プロジェクトのメンバとは今回のプロジェクトで初めて一緒に仕事をすることになったのですが、お互いを理解するため、仕事以外のコミュニケーションが日本だと取りやすいのも非常に大きな要素だと感じています。
最近、オフショア開発でも参考になるような、気になる記事を見かけたため、近々「離れた場所で一緒に働く」ということについて記事を書いてみたいと思います。
少人数プロジェクトを試してみる
考えるだけだと意味がないので、実際に少人数プロジェクトを試してみることにしました。
日本人スタッフは私1人。オフショア先のメンバは2人。
開発期間は年内なので、4ヶ月。
どんな結果になるのか、あとで報告できたらいいなと思います。
短期×少数でのオフショア開発を考える
例えば、開発期間3ヶ月、日本側スタッフ1人、オフショア先の開発リソース3人。
単純にコストだけでみると、日本人4人でやる場合の半分ほどでリソースを確保できそう。
いろんなケースでどんな条件だとプロジェクトが成功するか考えてみました。
- 全員日本に招聘し、日本で開発する
これはちょっと、オフショア開発という趣旨から本末転倒な感じですが、結構1発目のプロジェクトで、スクラッチから開発する場合は利益率に目を瞑って多くのメンバを招聘する場合があります。
場所が離れていることで発生するコミュニケーションコストや、手戻りのリスクを最小限に抑えられるため、ほぼ日本人と仕事をしているのと同じように開発ができる気がします。
ただし、本当に採算度外視というか、全員招聘してしまうと赤がでると思われます。
開発メンバが多少経験浅くても、その場でフォローできるため、ある程度メンバの質にばらつきがあっても、失敗はしにくいように思います。
また、お客さんが英語でのコミュニケーションに抵抗がない人なら、日本人スタッフが休んでしまっても仕事が止まることなく回せるような気がします。
- 日本側のスタッフが出張し、現地で開発メンバと一緒に開発する
招聘するよりは、ずいぶん安くつくし、場所に制限があまりない開発なら日本人はどこにいても同じようなものなので、ありかも。
ただ、慣れない土地で生活することになるので、日本人スタッフの負担は大きく、体力的にも精神的にもある程度タフな人でないと、体調を崩す可能性があります。
プロジェクトが成功するかどうかという観点で見ると、これもうまくいきやすい形のように思います。
- 作業のロケーションは別々なままで進める
オフショア開発でいちばん現実的なパターンで、リスクを下げる施策をなにも準備しないと失敗しやすいケースです。
まず、コミュニケーションコストが上記2ケースに比べて格段に上がります。
コミュニケーションの効率も質も下がってしまうし、特にそのプロジェクトが1発目のまったく新しい経験したことのない分野の開発ならなおさらです。
また、開発体制の人数自体も少ないため、プロジェクトの成否が人の能力に大きく影響を受けるでしょう。
ただ、逆に言うと、出来る人がアサインされればロケーションが別々という条件でもプロジェクトが成功しやすくなるということだと思います。
実際に、ある成功したプロジェクトの振り返りをしたときに、成功した要因がオフショア先の現場のリーダーがものすごくできる人だったからということがありました。
続きもののプロジェクトなら、多少スキルはぼちぼちでも経験を積んでいるメンバが含まれていれば、すごい人がいなくてもプロジェクトはまわせるきがします。
深い考察ができたとは言い難いですが、まとめると少人数でオフショアのプロジェクトを成功させるには、呼ぶか行くかする。
それができない場合は、もしプロジェクトがスクラッチからの開発になるならすごい人をオフショア先のリーダーにつけてもらう。
続きもののプロジェクトなら、経験者を開発メンバの半分くらいつけてもらう。
でしょうか。
スクラッチからの開発で、すごい人がアサインされなかったから失敗する、、というつもりはないですが、属人的な要素が強くなるため、+αな成功のための条件は必要な気がします。
オフショア向きの仕事とリソースの確保のバランス
以前、同じようにオフショアで開発をまわしているエンジニアの人と話をする機会がありました。
その話の中で、数々のプロジェクトをこなしていくと、うまくいきやすいプロジェクトと向いていないプロジェクトがあるよね、という話になりました。
うまくいきやすいプロジェクトとは、ある程度長いプロジェクト(最低1年〜)で、そのプロジェクト特有の知識や経験をオフショア先のメンバに蓄積できるようなもの。作るモノの仕様は変わっても、そのモノに関する固有名詞や常識がある程度長い間変わらないもの。
人命に関わるため高信頼性が要求され、時間を掛けて製品を作り上げるような開発などが、オフショア開発でうまくいきやすいプロジェクトではないか、ということでした。
逆に、オフショアに向かないプロジェクトとは、製品開発サイクルが数ヶ月で、仕様書がテスト直前に固まるようなギリギリのスピードで進むような、ゲームソフトや情報家電などの開発。
頻繁に情報のアップデートがあり、現場のメンバでも自分である程度判断していかなければならないような開発などです。
私はたまにゲームをするのですが、クリア後のスタッフロールで、結構なボリュームのゲームでもプログラマ3人だけとかはよくあります。
実際は多少ヘルプが途中で入っているにしても、ゲーム開発のプログラマとかは基本的には少数精鋭なのかもしれません。
人数が増えると、それだけコミュニケーションコストもかかりますし、少数精鋭がゲーム開発の最適化された体制なのかもしれません。
長めの開発をしていると、どうしても要件検討フェーズも長くなる場合があります。その際、開発契約の見積りをすると工数の配分がどうしても日本人側に多く付き、オフショア先にはあまり工数が付けられない状況になります。
お客さんに請求する金額に、実際に開発が盛り上がるときに必要な人数をプールするためのお金を盛るわけにもいきません。
ただ、なにもせず必要最小限のオフショア先リソースを確保してしまうと、ただでさえ人の入れ替わりが激しいのに、無条件でリソースを切ってしまったために、組織としての知識、経験も一気にガクンと落ちてしまいかねません。
このように、開発の谷間でもオフショア先のリソースを確保できるだけの仕事のとり方ができればいいのですが、うまくいかない場合は自社またはオフショア先の身銭を切ってでも、リソースを確保するための投資開発をする必要があるような気がします。
あと、オフショアのプロジェクトがうまくいく理由として、やはりとても優秀な人がオフショア先のプロジェクトをまわしてくれたから、というものがあります。
運が良ければ、そういう優秀な人に仕事を振って、日本側のニーズに応えられる成果を出してくれます。
しかし、そういう人のニーズはどこも高いため、その人を確保するためのお金が払えないと、ほどなくして他所に行かれてしまいます。
かと言って、そんな人たちばかりを確保してしまうと、人件費がかさみ、オフショアなのにあまりコストメリットがない組織になってしまいかねません。
お金がすべてではないと思うのですが、オフショア先の優秀なエンジニアをいかに確保するのか、は難しい問題です。
プロジェクト管理ツール Trac, Redmine
以前、情報共有の方法について
オフショア開発でのコミュニケーション(3) 情報共有 - Lahiのオフショア開発日記
で記事を書きました。
メール、共有サーバ、wikiでのコミュニケーションについてお話しましたが、今回はプロジェクト管理ツールについて。
フリーのものでもいろいろあるみたいですが、私はTracまたはRedmineを使ったことがあります。
どちらがどんな機能などのお話は別に詳しく書かれているところを参照してもらうとして、今日はプロジェクト管理ツールを使うことのオフショア開発でのメリットをお話したいと思います。
ツールを導入することで改善する1番のポイントは、やはりコミュニケーションです。
メールベースでアイテムの確認や指示、成果物の受け渡しをしていると、人間なのでどうしても忘れたり、見落としたり、過去のディスカッションの内容を紐解くのに苦労したりすることが絶えません。
両ツールとも、作業アイテムは「チケット」と呼ばれるものを発行するため、基本的に支持した作業が何かに埋もれたり、忘れ去られることはなくなると思います。
また、チケットには進捗情報を表すことが可能なため、チケットベースで進捗の確認も可能となります。
情報共有したい場合、情報の質、残したい形によってwikiや掲示板ライクなコメントリストなどに情報を貯めることが可能になります。
ただ、ツールの紹介ページでも説明されているように、便利な機能があるツールとはいっても、道具は使いようですので、みんなが守れる最低限のルール、使い方は共有しておく必要があります。
プロジェクト管理ツールを使い始める際に注意したいのは、
「こんなことができるようになるから使ってください」
ではなくて、
「今コミュニケーションの問題としてこんなことやあんなことがある。」
「このツールを使うとこれらの問題がこんな風に解決できるかもしれない。」
「どういうルールでどの機能を使うとよいか、一緒に考えよう」
という風に、オフショア先のメンバと一緒に課題解決する姿勢で、できれば彼らが能動的にツールを使い出すようにツール導入していくことです。
何かの改善施策など、新しいことを始める場合に日本側だけで考えた施策を押し付けるのではなく、彼らと一緒に考えて導き出した施策をやって、彼ら自身でやってよかったということを経験させるのが一番効果的です。
毎回毎回は手間で難しい場合もありますが、押し付けた施策は形骸化しやすく、意味も目的もわからないままやらせてしまうよりはいいように思います。
実際にTracやRedmineを使い始めると、特に明確なルールを決めなくても、暗黙のルールをお互い意識して、アイテム管理や情報共有をすることができています。もし、指示漏れや報告の聞き逃し、忘れなどが発生している現場があれば、プロジェクト管理ツールの導入を検討されてはいかがでしょうか。
