みなさん こんにちは。
livedoor Blog の担当をしている眞子です。
今回は、「受注案件を効率的に遂行するチーム作り」について、説明させていただきます。
【01】ディレクター中心型
以前、私は“ディレクターが情報の要”にいるような、いわば、「ディレクター中心型」のやり方を行っていました。
図1:ディレクター中心型

この図1のモデルでは
・営業とディレクター間で受注内容を確認する。
・ディレクターと各技術者との間で作業内容を確認する。
ことを表しています。
ディレクターが中心となって指示する型式です。
この方法の良い点と注意点には次のようなものがあります。
■良い点
・発注内容のボリュームが大きく、各技術者が細部まで把握することが負担になる場合、その負担を軽減することができる。
・営業から見ると、情報を伝達する人はディレクターのみでよく、情報伝達コストを下げることができる。
■注意点
・ディレクターは高い能力を要求される。
・指示内容を構成書にしっかりと落とし込むことが必要で、その資料づくりに時間がかかる。
・ディレクターが他の作業に忙殺されているときなどディレクターからの情報共有が滞るとプロジェクトがそこでストップしてしまう。
・ディレクターが常にメールに気を使っている必要がある。
受注案件の数が多くなるほど、この作業が大変になり、ディレクターの私にとっては大変な負担となっていました。
複数の受注案件を抱えているときには、自分がボトルネックになっていることも感じました。
「このままではいけない」と、やり方を変更したのが次の図です。
【02】ディレクターはまとめ役型
図2:ディレクターはまとめ役型

この図2のモデルでは
・チームのメンバーで受注内容を共有する。
・情報共有の流れは、それぞれが自発的に行う。
ことを表しています。
進め方は次のようになります。
1)営業より受注案件の作業依頼が発生する。
2)各技術者をアサインする。
3)アサインされたメンバーを skype のグループチャットに入れる。
4)グループチャットが情報共有の起点となり、メールや ITS(※)で依頼したときにはここに一報を入れる。
5)営業を含め、各技術者がこの場を通してチームのメンバーで情報を共有する。
という型式です。
(※)ITSとは、ライブドア社内で利用しているバグトラッキングシステムです。参考『Web ディレクターをやるなら、うまく活用したいツール紹介』
ディレクターはみんなをまとめる作業に徹します。
この方法の良い点と注意点には次のようなものがあります。
■良い点
・各技術者が連携を取り合うのでスピードが圧倒的に速い。
・グループチャットを通して、その場で確認することができる。
・チームのメンバーが自由に発言できる雰囲気を構築するこで、さまざまなアイデアを生かすことができる。
・受注内容を共有できている。
■注意点
・主なやりとりが skype に偏ってしまいログが残らない。
議論で決まったことや、正式な依頼のときにはメールなどでログを残すようにしています。
・チームの人数が多すぎない
人数が増えすぎるとまとめることが難しくなります。
・チームのメンバーの雰囲気づくりが非常に大事。
自由に発言できる雰囲気を構築するのは、ディレクターの役割です。
チームを作っただけで放置では何もなりません。
この方法に変えて、それぞれ技術者の能力を最大限に生かすことができるようになりました。
もっと優れた方法があるかもしれません。都度、検証しながらやり方をブラッシュアップさせていきたいと思います。
ライブドアではチームを盛り上げるのがうまいディレクターを募集しております。ご応募お待ちしています。
livedoor Blog の担当をしている眞子です。
今回は、「受注案件を効率的に遂行するチーム作り」について、説明させていただきます。
【01】ディレクター中心型
以前、私は“ディレクターが情報の要”にいるような、いわば、「ディレクター中心型」のやり方を行っていました。
図1:ディレクター中心型
この図1のモデルでは
・営業とディレクター間で受注内容を確認する。
・ディレクターと各技術者との間で作業内容を確認する。
ことを表しています。
ディレクターが中心となって指示する型式です。
この方法の良い点と注意点には次のようなものがあります。
■良い点
・発注内容のボリュームが大きく、各技術者が細部まで把握することが負担になる場合、その負担を軽減することができる。
・営業から見ると、情報を伝達する人はディレクターのみでよく、情報伝達コストを下げることができる。
■注意点
・ディレクターは高い能力を要求される。
・指示内容を構成書にしっかりと落とし込むことが必要で、その資料づくりに時間がかかる。
・ディレクターが他の作業に忙殺されているときなどディレクターからの情報共有が滞るとプロジェクトがそこでストップしてしまう。
・ディレクターが常にメールに気を使っている必要がある。
受注案件の数が多くなるほど、この作業が大変になり、ディレクターの私にとっては大変な負担となっていました。
複数の受注案件を抱えているときには、自分がボトルネックになっていることも感じました。
「このままではいけない」と、やり方を変更したのが次の図です。
【02】ディレクターはまとめ役型
図2:ディレクターはまとめ役型
この図2のモデルでは
・チームのメンバーで受注内容を共有する。
・情報共有の流れは、それぞれが自発的に行う。
ことを表しています。
進め方は次のようになります。
1)営業より受注案件の作業依頼が発生する。
2)各技術者をアサインする。
3)アサインされたメンバーを skype のグループチャットに入れる。
4)グループチャットが情報共有の起点となり、メールや ITS(※)で依頼したときにはここに一報を入れる。
5)営業を含め、各技術者がこの場を通してチームのメンバーで情報を共有する。
という型式です。
(※)ITSとは、ライブドア社内で利用しているバグトラッキングシステムです。参考『Web ディレクターをやるなら、うまく活用したいツール紹介』
ディレクターはみんなをまとめる作業に徹します。
この方法の良い点と注意点には次のようなものがあります。
■良い点
・各技術者が連携を取り合うのでスピードが圧倒的に速い。
・グループチャットを通して、その場で確認することができる。
・チームのメンバーが自由に発言できる雰囲気を構築するこで、さまざまなアイデアを生かすことができる。
・受注内容を共有できている。
■注意点
・主なやりとりが skype に偏ってしまいログが残らない。
議論で決まったことや、正式な依頼のときにはメールなどでログを残すようにしています。
・チームの人数が多すぎない
人数が増えすぎるとまとめることが難しくなります。
・チームのメンバーの雰囲気づくりが非常に大事。
自由に発言できる雰囲気を構築するのは、ディレクターの役割です。
チームを作っただけで放置では何もなりません。
この方法に変えて、それぞれ技術者の能力を最大限に生かすことができるようになりました。
もっと優れた方法があるかもしれません。都度、検証しながらやり方をブラッシュアップさせていきたいと思います。
ライブドアではチームを盛り上げるのがうまいディレクターを募集しております。ご応募お待ちしています。

コメントする