ガントチャートに含めておく情報とは

ラノベ風に書いた昨日のテーマを別の観点で。

なぜか、イケテナイPMやSEリーダが作るとメンバがデスマになるガントチャートガントチャートがデスマの原因のように言われることが多いけど、それ違うから。ガントチャートが悪いのではなく、使うエンジニアのレベルが低いから。道具はエンジニアを選ぶのですよ。

ガントチャートの目的

ガントチャートの目的は、WBSでプロジェクトの成果物を作成する作業項目をスケジュールとリソースに割り当て、完了する日程を明らかにすることです。

マイルストーンなどの情報を書き加え、様々な制約条件とリソース投入時期の調整で納期を確保するための計画ツールです。

ガントチャートの構成要素(例)

ガントチャートを作成するために必要な情報には以下のような項目があります。例を参考に確認しましょう。

 

  1. アクティビティID
  2. 分類
  3. アクティビティ 
  4. 成果物
  5. 工数
  6. 担当者
  7. 予定開始日
  8. 予定完了日
  9. 実績開始日
  10. 実績完了日
  11. 依存アクティビティID

 

アクティビティID(W)
…作業のID。昔はワークパッケージとも称したものです。
 IDがあったほうがメンバに伝えるときに便利ですがアクティビティが増えていくと番号を振り直すのが面倒です。

分類(W)
…アクティビティを括るカテゴリ。
 詳細設計書、章節項など、成果物、成果物の構成要素で括ると良いです。
 成果物のない付帯作業は大分類を別に分けておく方が良いです。
 付帯作業には、開発環境の維持など成果物を作成するために必要だけど、成果物を直接作る作業ではないもの、としておけばいいです。

アクティビティ(W)
…実際の作業。
 アクティビティを行うことで成果物又は成果物の要素が完成する必要があります。
 どこまで細かくするかはプロジェクトの進捗を把握したい=報告したい粒度に合わせるか1つ小さいレベルにしておかないと大変なことになります。
 マイルストーンを工数0で設定する技があります。

成果物(W)
…アクティビティを行った際に得られる成果。
 これがないものは作業として扱いません。

工数
…成果物を得るために必要なリソースの消費量。
 エンジニアの場合の単位は時間。

担当者
…アクティビティを作業するリソース。
 通常はエンジニアの名前。

予定開始日
…アクティビティの着手を予定している日にち。

予定終了日
…アクティビティの完了を予定している日にち。

実績開始日
…アクティビティを着手した実績の日にち。

実績終了日
…アクティビティを完了した実績の日にち。

依存アクティビティID(W)
…このアクティビティを始める前に終わっていないと始められない先行するアクティビティID

 

項目の後ろに(W)があるもの

(W)が付いている項目が本来のWBSで必要な構成要素です。

それ以外はWBSには不要です。

ガントチャートに線を引く

予定開始日から予定完了日、実績開始日から実績完了日をアクティビティIDごとに線を引きます。

線を引くのはあくまでもガントチャートをみるエンジニアやステークホルダが見やすいための便宜上です。

期間の線がなくても、開始日と完了日の情報があるので本来は不要なのですが、暦形式で視覚化しないと締め切りを認識しないというエンジニアへの対策です。

 

 

 

マンガでわかるプロジェクトマネジメント

マンガでわかるプロジェクトマネジメント

 

 

逆引きでガントチャートを作るからプロジェクトを失敗させる

「お疲れ様でーす。先輩はなんのプロジェクトでしたっけ」
「ああ、お疲れさん。どこのプロジェクトって、あ、そうか先月で終わったからね。それは教えてなかったな。そーか、それじゃ久しぶりだ」
「そうなんですよ、私もこう見えても売れっ子で忙しいんです。先輩の相手ばかりしてられないんですよ」
「それは助かるな。もっと忙しくなるとこうやって邪魔されずに仕事に…あ、痛っ」
「どうしたんですか、天罰じゃないんですか。神様ってちゃんといるんですね」
「最近の神様は随分とカジュアルな格好しているんだな、ってもう…」
「久しぶりなんですからもう少し嬉しそうにサービスしてくれてもいいでしょ」
「先に賽銭を要求するところも神様だな」
「暇なんですよね、コーヒー奢ってください。どこがいいかな。たまには隣のビルのcカフェに行きましょうか」

「それで今日は何を相談したいんだい」
「別に相談なんてありませんよ。売れっ子ですから問題ありません」
「(相変わらず面倒だな)キミじゃなくてチームで困りごとがあるんだろう」
「(あっ)そうなんですよ、さすが先輩です。ほんと、困っているんです。どうしたらいいかって。もうって感じです」
「まあ、チームの問題はメンバ全員に何かしら問題があるからなんだけどな。それで」
プロマネはベテランの人なんですが、押し付けるんですよ。スケジュール。相談もないし、ヒヤリングもないし、一方的なんですよ」
「スケジュールって工程表のこと」
「そうです。WBSを展開して工数を見積もってからカレンダを当てはめるじゃないですか。大体、稼働だって100%じゃないんですから。予定あるんですよ。カンファレンスとか年休とか。事務処理だってあるのに」
「何と無く想像つくけどもう少しわかりやすく」
「だ・か・ら、プロマネが工程の枠を決めて、その中で作業を終わるようにWBSを作れって言うんですよ。おかしいですよね、絶対。先輩はそんなやり方しないじゃないですか。それでもうチームの中が荒んでいるんですよ。もう、殺伐ですよ」
「なんとなくわかった。質問なんだけど成果物が後から追加されることが頻発しているんじゃない、どう」
「そうなんですよ、無理なスケジュールになっているのにそこに『漏れていた、顧客からのリクエストだから』と言って追加してくるんです。おかしいですよね、顧客の追加要望なら契約見直しじゃないですか」

「と言うことは、元の契約を変えずにやっているのか。聞きたくなかったな。それとなくPMOへインプットしておかないと。知ってしまったからなぁ」
「そんなことは後回しでいいですから。どうしたらいいです、先輩」
「抜けてくれば」
「そんなことできるわけないじゃないですか。みんなの仕事が溢れているんですから。バカなんですか、先輩は」
「ひどいなぁ、心配しているのに」
「心配するならみんなの、あ、プロマネはいいですけど他のメンバは助けてあげたいんですよ」
「そうだなぁ、客観的な情報が足らないな。それを揃えて実現性を見て、あとは内部監査チームを動かすしかなさそうだな」
「大事になっちゃいます…よね。やっぱり」
「どれだけひどいのかがわからないだろう、今は。だから基本は最悪のシナリオで考えておかないと。契約不履行になったらシャレにならないし。いいかい、例え小さなプロエクトであっても赤字になってしまったら契約金額の3倍のインパクトが費用として発生するんだぞ、覚えておくんだよ」
「3倍って…3000万の案件なら1億のインパクトになっちゃうんですか」
「契約した分でパーになるのが3000万、立て直して当初のスコープを履行するのが3000万、リカバリするのに他所からリソース追加で投入するのと管理コストが何倍も増えるから合わせて3000万、ざっくり1億」
「…ええぇそんなに…勿体無い。その7000万私に欲しいです」
「それは違うから。でもさ、そのくらいの腹づもりしておけばどうにかなるよ。最悪のケースだからさ」
「はあ…」
「それでさ、作ってたりしないの。メンバ版のWBSとアクティビティのネットワーク図とか工数見積もったりとか、カレンダに当て嵌めた日程とかさ。作ってあるよな」
「それはもちろん…だってそう必ずしろって先輩が言うから」
「よしよし、偉い。褒めてあげよう」
「いいですって。私にとっては当たり前なことですから」
「そのベテランPMはなんでそんなやり方をしているか知らないし知りたくもないけど。経験知でやっているんだろうな。それをトップダウン型のプロマネと勘違いしている。トップダウン型こそ統制を掛けるために作業見積もりをしっかりやって失敗しないプロシージャを組み立て、習得しないとミスると元に戻せないんだ。自律したチームになっていないからな。
 ところで、そのあれだ、キミが作っているWBSや工程表でだと進捗はどうなの。オン助だったりするんじゃないの。え、そうかアウトプットが増えるからずれていくのか。なるほど。それを除いたら…。だろう、やっぱりな」
「それでどうしたらいいですか、先輩」
「わかった、外の方の上の方から落としてもらおう。無知なPMのせいで赤字を垂れ流されては迷惑だからな。俺の黒字をもっと積めって言われても限界あるしな」
「なんか大事になってしまって…どうしよう…言わなければよかった…」
「違うな、大事になる前に話してくれてよかったんだよ。これで問題が小さければそれで済む話だし。第一、キミからクレームを挙げたことにはならないからそこは大丈夫」
「それは別に構わないんですけど」
「いや、プロジェクトはやり切ってもらったほうがいいからね。変にギクシャクして退場させられるとそれはそれで本望でもないだろうし。よし、心配しないでいいよ。今は自分たちのスケジュールでやることと、みんな残業を規制させたほうが良い。ま、それもあっちの方からくるからいいか。自分の仕事をしてて。
しかしな、今時、なんの都合でスケジュールありきで工程を刻んでガントチャート作って、納期ありきで逆引きでやり切れっていうPMがいるんだ。もう絶滅したかと思ってたよ」
「先輩、変なお願いになってしまってすみません」
「しょうがないだろう、神様から災いのお告げがあったんだから」
「あー、神様から。ならしょうがないですね。あーよかったー」
「(ほんとしょうがない神様のお願いだ…)」

スコープをクリアにすることに慣れておかないといけない理由

プロジェクトのデリバリを真剣にQCDを守って成功させたいなら、QCDにもう1文字追加しないとまず成功は実現できないのです。

これまでプロジェクトで成功してきた例は、意識的か無意識にもう1つの文字をやってきていたからプロジェクトの目的を達成することができていたのです。

答えはSです。そう、スコープ。標題に書いているので問題にもならないですが。

スコープがクリアである必要性

 なぜプロジェクトにおいてスコープがクリアである必要があるのでしょうか。

それは、プロジェクト活動の基準となるもので、スコープはプロジェクトで実現したい目的を表したものなのです。

プロジェクトにおいて、スコープがプロジェクトで実現する対象となることから、スコープの実現を計画し、スコープの変化の有無を監視し、変化があればトレースしなければなりません。

スコープはプロジェクトを実行している間、つまり、プロジェクトの契約からプロジェクトの終結までの間ずっとクリアな状態を保つ必要あります。

なぜなら、クリアな状態を保てなければ、プロジェクトの目的であるスコープを実現できたかどうかを評価できないからです。

慣れの必要性

 プロジェクトで考えるとプロジェクトマネジメントの知識があれば当たり前だと思うでしょう。

ではそれに慣れておく必要がある、と言われたらどうでしょうか。つまり、日常の業務の中でも常にスコープはクリアであることを意識して仕事をしなさい、という意味合いになるのですが。

あるチームにあるメンバがいて、そうですね、イメージを持ってもらうためにペルソナを設定すると以下のようになります。

40代
NW技術を持つ
割と周囲に対して興味を持つ
仕事は積極的に取り組む
仮説検証型の仕事の仕方は得意ではない
一度決めたことの変更はしたがらない
前提を置いてしまうと変更に文句を言う
言葉遣いは曖昧さを残す
キーとなる決めの対象をはっきりしないまま進める

このような特徴を持つメンバは推進力があり、だいぶ頼りになりますがいくつかの特徴のせいか、いわゆる詰めが甘い状態を残したまま進んでいることが多いのです。

不思議なことに、決めたことを変更することを嫌う(ように見えていた)のに、本人の言動やキメないとまずい(とこちらには見える)ことを詰切らずに進めて最後になってひっくり返されることがままあるのです。

なんでかな、と思っていたのですが、言動とキメのところでそう言うことかと気づいたのです。

仕事はできる方だけど、スコープ設定が下手

なんですね。なので細々としたトラブルを抱えることが多いいんですよ。結果、つまりトラブルのでストレスを抱えることになってやたらと文句を言う。

それはどこに本因がるか自己分析をしないと解決しないし、スコープ設定が下手ということは原因をクリアにして向き合うということも下手ということです。きつい言葉を使うなら、逃げるんですね、嫌なことから。

そうならないためにも、スコープをクリアにしがら仕事をしないと思うように回らないよ、と。

 

スコープをクリアにしないでいると100%手戻りが発生するか説明ができなくなるんですけどねぇ…。

 

アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう!?

アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう!?

 

 


 

優秀なエンジニアと出来るというエンジニアが言う暇の違い

もちろん、仕事をアサインされているエンジニアに限るよ。

仕事が出来るから暇だと自慢するエンジニア

エンジニアになりたての頃、職場の繋がりだったか何かで当時10歳くらい年上のエンジニアがいて、俺は仕事できるぜーアピールがひどかった印象を受けたんですよ。まだエンジニアになりたてのひよっ子にだってなんだか胡散臭い、近づかないようにしようと思うような感じだったもの。

今は、パッとしない身なりで社内システムのお守りをしているみたい。社内システムだって社員の事務処理や情報共有を高めようとする攻めのシステムだったり、基幹システムで落とせないしミスれないようなミッションクリティカルなのだってあるけれど。さて、その人はどうなんだろうか。

確か、俺はできるから暇なんだよと言っていたけれど、できる人ってそんなこと言わないよね。それしか出来ないのかな、と思うわけですよ。出来るエンジニアなら外からいくらでも仕事の声が掛かるし、その中で興味を持てる仕事をしようと思うし、でき続けるためにインプットを自分にするものですから。

だからこそ、インプットは調整弁になるので割り込みの対応だって暇(というより余裕代ですね)の幅に合わせて手助けするわけですし。依頼されたのが余裕代より大きければ肝心なところだけやってあとは戻したりね。そういう仕事をするものです。

プロジェクトでは暇なエンジニアを作ろう

以前のエントリでも書いたけれど、プロジェクトの進捗がオンスケであればエンジニアが暇な方が良いし、健全な状態なんですよ。アホなプロジェクトマネージャやリーダはアイドルしているようなエンジニアを見かけると反射的に予定外の仕事を突っ込もうとするけれど、それは無駄でしかないのですし。

確かに、計画より時間を余してしまうと不安になる気持ちもわかりますよ。でも、それは仕事を突っ込むよりプロジェクトマネージャ自身がタスクの見落としをしていないか、品質の検証漏れがないかを判断しなければならないことで、間違ってもエンジニアに予定がまだ先のタスクを突っ込むことじゃないんですよ。

なぜ、予定を早めて仕事を突っ込んでしまうのがダメなのかがわからないのは考え方の違いだけれど、もう少し勉強して実践を繰り返すといいと思うんだ。

ただ、暇のままにするんじゃなくて、今の作業プロセスを作業の手間暇が減っても作業品質を維持できる改善を考えて試したり、予定している作業の技術的な調査をするのはいいと思うんだよ。でも、あくまでも予備調査というかフィージビリティスタディ程度にして寸止めさせることがポイント。

なぜ寸止めさせるかというと、通常、作業は段階的詳細化で進めるので、ある作業だ先走ってもしょうがないんですよ。たった1つのタスクだけを深掘りしてもね。

やっているエンジニアは面白くなるかもしれないけれど、全体から見たらやり過ぎなんだ。全体を揃えないと横横の関係が歪になってわからなくなってしまうからね。

プロジェクトマネージャもリーダも元々がエンジニアだから、詳細化して具体化すると口を挟みたくなるし。でも、そんなことをやっていたら全体が見えなくなってしまうんだ。

もちろん、他のメンバが遅れていたり、難しい問題に嵌っていたらそれこそ手が空いているメンバ全員で解決してしまう方がいい。今風にいうとモブするわけです。タスクを。

 

 

ワーク・ルールズ!―君の生き方とリーダーシップを変える

ワーク・ルールズ!―君の生き方とリーダーシップを変える

 
サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法

サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法

 
HARD THINGS

HARD THINGS

 

 

 

 

忙しいエンジニアは筋の悪いサラ金に手を出して雪だるま式に時間をすり減らしているだけ

40代、50代のエンジニアが部下のマネージャに悩みがあるとするなら、それは40−50代のエンジニアが今持っているスキルだけで今の仕事をやろうとしていることではないかなぁ、と思うのです。

「別にいいのでは、今持っているスキルで仕事ができることは、その仕事に必要であるチームのスキルを充足しているのだから」と思う人がいるかもしれないです。

確かに、その考えはプロジェクトを始める際のある意味事前条件なのでそれはそれで正しいです。ただ、やってみると技術的に必要な知識を持っているし、それなりの基礎スキルも持っていればやり切ってくれるでしょう。

忙しいと気付けるか

今持っているスキルでやり切れればそれはそれでいいのだけれど、過去に身につけたスキルがジャストフィットするかといえばそんなことはほどんどなく、スイートスポットを外しながらもなんとか仕事をやっているのが現実なのです。

そうした状況を客観的に識別には労働時間が一つの見極める指標です。作業の見積もりが定時内で終わるなら、それをオーバーランしている実態があるなら何かしら見積もりを超える要素があるということです。

労働時間が長いからといって全ての原因がエンジニアにある訳ではないですが、他責だったとしてもそれに巻き込まれてしまっているなら、それはそれでなんとか現状を改善しなければその問題が解決するまで振り回されるだけです。

忙しい状況にあるのだと気づくことが楽をするための第一歩です。

忙しいことは悪である

忙しいとミスを起こしやすいです。人はいくつものことを同時で考えて処理はできないということを改めて認識した方が良いです。同時並行でテキパキと捌いているように見えても、よくよく見れば、タイムスライスして高速処理しているだけの話で、TSSのようなものでしかありません。

事象として残業をしている場合、どこが原因で残業をしているのか本因に辿り着かなければ単なるモグラ叩きで終わってしまうことを覚悟しなければなりませんが、まずモグラ叩きをしている人はそれに気づかないのでずっとモグラ叩きをしているんですよね。

残念なことですが。

まずは、忙しい状況で仕事している状況を気づき、放置することは悪であることを知らなければ始まりません。

ですので、まずは「今忙しいんだ」と認識することが大事なのです。

忙しい、はどこにあるか

では、忙しいが悪であるなら忙しいは自分の仕事のどこにあるかをどうやて調べましょうか。

  • 前段取り
  • 作業
  • 後段取り

一つの切り口は、何かしらの作業の着手が遅いケースです。忙しいと締め切りで動く締め切り駆動型で仕事をやっつけでやり始め、それがいつの間にか普段の仕事の仕方になってしまうパターンです。

やっつけでやっているのでリファクタリングという考えをしませんし、そんな時間の余裕はないから締め切り駆動型になっているのですけれど。

少なくともやっつけでやるなら、後工程か作業を手放す前にリファクタリングを差し込まないと、次の作業を始めてから先に手放したはずだった作業の手戻りが割り込んでくるので悪循環から逃れられません。一度筋の悪いサラ金に手を出して雪だるま式に利息が増えていくようなものです。

  • 手法が合っていない

持っているスキルが今やっている仕事にフィットしているかどうか、その評価をし続けなければなりません。少なくとも見積もっていた作業工数より時間が掛かっている場合は、使っている道具が間違っていることを疑わなければなりません。

チェーンソーを使わなければならないのに、糸鋸で切ろうとしてもそりゃ無理筋だって気づきそうですが忙しいとそう思わないところが忙しくなると感覚が鈍ってきて危ないところなのです。

エンジニアは技術を使って仕事をしているのですから、使っている道具が合っているか、手入れを十分できているかのチェックは運行前点検のようものですし、監視通知のモニタリングの機能でもあるのですが。

  • 感情が強すぎる

最後に作業をしているエンジニアの仕事に対する感情が強すぎると大体ろくなことにはなりません。

思い入れが強すぎれば私が作るのだからと要求されていないほどの無駄な作り込みをしようとしますし、私の作品にしてしまうと指摘されるとムキになって反論をし始めますし。

  • 自分はこれだけ頑張っているのに

おまけで、自分がこれだけ忙しく頑張っているのにという感情も忙しいから抜け出せない感情です。別に誰もそんなに頑張ってとは言っていないのですけれど、当の本人は私が良かれと思って巻き取った仕事を誰も評価してくれないとか、指摘されてなんでこんな目に合わないといけないのかとか、いう事態になっていたら、それは勝手にサクリファイスして被害者意識を持って自己陶酔しているだけなんです。

まあ、これも本人が気づくことはないのですが。

 

 

まあ、忙しいと言っている人にろくなアウトプットは出てきた試しがありませんけど。

 

 

 

マキタ ロボットクリーナー(本体のみ) RC200DZ

マキタ ロボットクリーナー(本体のみ) RC200DZ

 

 

チームに仕込まれる不安定性

個人的な嗜好としてチームを構成する際には、ロールを分ける方が好きですね。

まあ、分けるといっても、プロマネかそれ以外=エンジニアの二択ではあるのですが。エンジニアのロールはフラットかと言えば、そこはリーダなり、アーキテクトを置いてエンジニアはエンジニアの世界で自治ができるような世界観を作りたいと思うタイプです。

プロマネが専門のPM

 エンジニア上がりのプロマネの場合は、PM専門家と呼んでいいのか微妙な感じが若干しますが、業務ドメインの知識を持っていると言い替えると、ありかな、という雰囲気が醸し出されていい感じになりますね。

プレイングマネージャだとプロマネとしても口を出されるし、技術でも口を出されるのでどうかなと思うんですよ。

プロジェクトをマネジメントする立場のプロマネはプロジェクトのビジョンとチャレンジをエンジニアに与えるとしても、事細く口を出して、までするのはどうかと思うんですね。一歩間違えるとマイクロマネジメントになってしまうので。

プロマネが専門家の場合の良い面には、リスクの芽吹きするかしないか時点でリスクを識別したり、小さいうちにリスクをコントロールしようとするからです。そう考えるとプロマネが専門家なのにトラブちゃうのって、どれだけなんですかねー。その案件のおばけ具合。ということにしておきます。

仕込まれる不安定性

 事細かく口出ししないということは、箸の上げ下げまで仔細に口を挟まない、ということです。

これって、エンジニアに対して自由裁量を会えているということなんですよ。姑のようにあれこれ口をだすPMって煩わしいじゃないですか。

でも、丸投げするようなプロマネはPMじゃないとも思うんですよ。ちゃんとプロジェクトのビジョンと何にチャレンジしないといけないかを示さないプロマネは存在意味がわからないです。

そういう観点で言えば、仕込んだ不安定性を用意するのができるプロマネなんだと思うんです。

チームとして手に入れるものはどこにあるのかをキチンと示しつつも、その手に入れたいものの手に入れ方はチームで見つけなさい。

こうしたことを言い切れるプロマネとチームに必要なのは信用ではなく、信頼ですね。必ず、やり切ってくれる。無理を押し付けるのではなく、実現できるやり方を相談し、聞いてくれる関係。

その上で、プロマネでもチームのエンジニアでもなく、プロジェクトの目的を実現できるかどかで判断しているチームであるかどうか。

そういうチームで働いているときはパフォーマンスが出ますよねぇ。

 

 そうそう、Echoがやってきましたよ。

Amazon Echo (Newモデル)、チャコール (ファブリック)

Amazon Echo (Newモデル)、チャコール (ファブリック)

 

 

継続的コミュニケーションとしての朝会

プロジェクトで朝会をやるのはトラブルが起きてからでは遅くて、トラブルが起きる前、つまり、プロジェクトの最初からやるのが一番良いのです。なにせ、プロジェクトの開始時点から初めてしまえばプロジェクトの期間ずっとやることになり、ひと月も経てばすっかりチームの習慣になっているものです。

あるプロジェクトでは顧客まで巻き込んで朝会をやり続けたことがあります。そんなのあり得るの、と思ったかもしれません。確かに、その顧客は朝会をやる文化はなかったのですが、こちらから

「朝会やりましょう、でも15分ね」

と提案して、始まってしまえばこっちのものです。あとはスケジューラに繰り返しの予定として入れておけば

「朝会は毎日やるものだ」

と刷り込み完了です。

朝会を報告する場にしない

朝会が苦手(時間的な意味合いではなく)に思っているメンバがいたら、それは朝会で報告しなければならないと思っているからだと思うのです。

「えっ、報告するじゃん」と思ったら…確かに昨日の実績、今日の予定、困ったこと、特に昨日の実績を作業報告だと思わなくもないですよね。いや、やはり報告と受け止めるのが普通なのかも。

朝会を報告する場だと思って参加すると、やはり言ったことに対してアレコレといちゃもんがつけられるのではないか、実際、あれこれ言われてしまうと責められている気がしてきてやになってしまいますよね。

だったら、朝会を報告する場にすることをやめてしまいましょう。だって辛いでしょう。そんな朝会。やめましょう、報告するのは。

朝会を強制的に伝える場に

朝会でも進捗会議でもなんでも全く気にしない人がいます。ええ、ワタシもそうですけれど。

どうして辛いと思ったりしないかというと、報告する内容を聞いてもらうと思っていないからです。どう思っているかというと、

「自分のやっていることを強制的に伝える場」

だと思っています。

どういうことかというと、自分のやっていること、例えば、今日やる予定でワタシの作業を進めるために関係するメンバの時間を確保したり、するためだと思っています。
つまり、協力を得るために強制的に聞いてもらう場に位置付けているということです。

「今日はこれをするから、時間をあけて手伝ってね、よろしくね」

 と言っているのと同じです。それもチームメンバ全員の前で。

継続的コミュニケーション

 朝会は毎朝行います。プロジェクトが続いている限りは。言い換えれば、継続的なミーティングです。しかも、強制的に伝える場に変えてしまうなら、継続的に(半ば強制的に)コミュニケーションをとるということです。

そう、継続的コミュニケーションの誕生です。
#ちょっとかっこいい

継続的コミュニケーションには次の特徴があります。

  • メンバを巻き込んで強制的に伝える場で行うので結果に責任を持てるように準備する
  • チームの中の個人としての説明責任がはっきりする

そりゃそうですよね。巻き込むのに結果に責任を持たなければ誰も付き合ってくれませんし、巻き込む以上、何をしたいか説明するのは自分ですし。

 

 

 

影響力の武器[第三版]: なぜ、人は動かされるのか

影響力の武器[第三版]: なぜ、人は動かされるのか