見出し画像

社員に動いてもらう技術

多くの社会人は会社で働いていると思うが、会社で働いて大変だと思う瞬間にはなにがあるだろうか?

色々あると思うが他部署の社員に仕事を依頼すること自部署の配下のメンバーに仕事を依頼することは大抵の場合かなりストレスフルだ(少なくとも自分は10年以上働いていてこれがストレスフルでなかったことは一度もない)。

なぜストレスに感じるのか?それは上手く行かないことが多いからだ。それは当然だろう。なぜならそれはその人の本来の仕事ではないからだ。やってくれないのは当たり前だ。その小さな業務はjob descriptionに書かれているか?おそらく書いてない。少なくとも優先度の高い仕事ではないと思われているだろうし、実際に優先度はあまり高くないのだろう。

こういう類の話は多い。

  • 新規プロジェクトを始めるとき、そこにアサインされたメンバーはゼロだ(まだ始まっていないのだから)。プロジェクトを0人あるいは1人だけで進めるのは無理だから多くの人に手伝いを頼むことになる。

  • エンジニアは採用の手伝いをお願いされる、あるいは(エンジニアの採用計画をコミットする)採用担当はエンジニアにお願いをしなければならない。

  • バックオフィスのほとんどの業務は会社の全メンバーに影響する。言い換えると、バックオフィスのメンバーは会社の全メンバーとコミュニケーションを取る必要があり、逆もまた然りである。

  • マネージャーは期初の目標設定と異なるタスクをメンバーに与えるときがある。メンバーは嫌がるだろうが、マネージャーも好きでやっているわけではない。

  • 仕事をどう進めていいか皆目検討もつかないが、締切が今日中だということだけはわかっている。自分以外の誰かの助けが必要だということは論理的に明らかである。

こういう問題は組織デザインによって解決できる場合もあるし、できない場合もある。組織デザインは万能ではない。

心理的安全性の高い会社文化をつくりあげているならストレスはかなり減るだろうが、人に頼んだり頼まれたりすることがストレスなのは変わらない。

導入だけで長くなってしまったが、今回書きたいのは人を動かすための情報には必要条件があるという話だ。ストレスの原因は不安だから、必要な情報が過不足なく揃っていればこれを最小化することができる。ベストを尽くしていると信じきれる状態だと人はあまり不安にならなくなる。

ドミノを並べる

『More Effective Agile』にとても良い話があったのでこれを利用する。

この本の趣旨はアジャイルの導入だが、教科書的にスクラムを導入することよりも現実的にチームの生産性を高めるためにはどうすれば良いかに重点を置いている。すなわち組織の問題を現実的にどう解決するかである。

第23章より、著者がドミノ変革モデルと呼ぶ考え方を引用する。

ドミノ変革モデルでは、組織変革を成功させるために次の6つの要素が必要となる。

■ ビジョン
■ コンセンサス
■ スキル
■ リソース
■ インセンティブ
■ アクションプラン

変革が成功するのは、これらの要素がすべて揃ったときである。ただし、要素が1つでも欠けていれば、変革は起きない。然るべき場所に配置されていなければならないドミノのようなものをイメージしてみるとよいだろう。ドミノが1つでも欠けていれば途中で止まってしまう。(後略)

これは組織変革の話だが仕事の依頼もこれと同じだ。

よくありそうな話

ここでよくありそうな話をしてみる。他部署の社員を呼び出して適当な説明をする(内容によらず楽しくはなさそうだ)。このとき不満が返ってくるとする。こういうときはだいたい似たようなパターンがある。

  • なんのためにやるのかわからない、目的を教えてほしい

なるほど。次に説明するときはこれを反省して目的を説明することを加えることにしよう。すると、

  • 背景がわからない、その目的ならこういうことをしたほうが良いのではないか

なるほど。次は背景に重点を置いてみる。

  • 要点がよくわからない、もっと詰めてきてほしい

うーむ。もっと丁寧に詰めてみる。

  • いきなり言われても困る、もっと早く言ってほしい。

ぐぬぬ。もっと早くに言ってみる。

  • 具体的にはなにをやるの?これだけだと判断できない。

ぐぐぐぐ。そもそもやることを明確にする能力が自分にないから手伝ってほしいのだが・・。

  • 優先度高いと思わない。他の人に頼んでほしいしそもそもそれはあなたの仕事ではないか

・・・。なぜこんなにすれ違うのか?我々は同じミッションに向かうスタートアップのメンバー同士ではないのか?

それはドミノが揃っていないからだ。先のモデルに戻って6つの要素を考えてみる。

ビジョン

ビジョンとはそれを行なう意味定義、および望ましい最終状態である。なんのために、なにを行い、どういう恩恵がもたらされるのか。

コンセンサス

理解されないものを無理強いして上手くいくものはない。上記のビジョンに対するフィードバックを得ることはコンセンサスを醸成することにとても役に立つ。

スキル

能力がない人になにかを無理強いすることはできない

More Effective Agile ~“ソフトウェアリーダー"になるための28の道標

できないものはできない。忙しいといって断る人がいるならそれは能力的に不安があるからそう言っているだけなのかもしれない。そういうときは工数の相談をしても意味がなく、スキルをサポートしてあげるのが最善となる。

リソース

できないものはできない。リソースに該当するのは人、時間、お金、それにマインドシェアだ。忙しいといって断る人がいたらその人はおそらく工数の話をしていない、「俺のフロー状態を潰すな」と言っているのだ。

インセンティブ

ビジョンは組織のためのものだが、インセンティブは個人のためのものだ。その人にとって「良い」ものでないなら誰だってやろうとはしない。

アクションプラン

アクションプランがなければ、導入は行き詰まってしまう。然るべき人に然るべきタスクを割り当て、タイムラインを決める必要がある。アクションプランは関係者全員に知らせる必要がある。アジャイルの導入では、それは「全員」である。これは基本的なことだが、見過ごされがちである。導入を後押しするためには何をすればよいのかがわからなければ、誰もそうしないだけである。

More Effective Agile ~“ソフトウェアリーダー"になるための28の道標

完璧なものでなくても草案があればフィードバックを受けられるし、フィードバックを受けられればコンセンサスを醸成できる。

ドミノとコミュニケーション

6つの要素は、業務依頼のコミュニケーションにおいて必要な要素とも言える。これくらい揃っていればだいたい話が通じる。

また、ドミノを揃えるのは改善のプロセスとして捉える必要がある。ウォーターフォール的に依頼を一発で通そうとしてはならない(いずれにしてもコンセンサスをつくる必要があるのだから)

おわりに

もともとは『More Effective Agile』を読んでいた時に「ええ話やん!むしろエンジニア以外に読んでほしいわ」と思ったのが本記事の始まりである。最初のタイトルは「メンバーを動かす15の要素」だった(内容も違う)のだがなぜかこんな内容になってしまった(これは次に書くと思う)。


この記事が気に入ったらサポートをしてみませんか?