kazukiyunoue-work

働くを考える

マイクロマネジメントの発生は上司ではなく、部下からなのかもしれないとも思った話

悪しきマネジメントスタイルとして語られることの多いマイクロマネジメント。上司の不満を列挙する記事には必ずと言っていいほど登場します。原因は上司の経験や気質、組織の文化や伝統等、これらが大きく影響しているのは間違いないでしょう。しかしそんな上司も昔は部下だったはずですし、現場からの生え抜きであればそれこそ直前までその部署の部下だったはずです。では一体、どこでマイクロマネジメントは発生するのでしょうか。

些細なきっかけ

社内の良くある風景として、部下から上司に以下のような問いが投げかけられるケースがあるでしょう。

  • 「○○の件、いつ頃実施しましょうか?」
  • 「この部分、何色が良いですかね?」
  • etc

実はこの何の変哲も無い些細なやりとりこそが、マイクロマネジメントの始まりではないだろうかとも考えます。なぜ部下はこのように聞くのでしょうか?それは単純に言えば楽だからです。自分の頭で考えず、ある種の答えを聞く方がよっぽど簡単ですので、このような動きになるのは合点がいきます。そして真面目な上司ほどそれに対して、「自分が考えてあげなければ」、「部下が困っているから助けなければ」といった思いから関与を強め始めるでしょう。多くの必要な情報を要求したり、聞かれる前に多くの指示をしたりするようになるかもしれません。初期こそ上司によるスピード感のある意思決定がなされるものの、いずれ現場の変化によって上司の決定がボトルネックになり得ます。そうして損益分岐点を上回る時に、まさしくマイクロマネジメントになるのではないでしょうか。

できること

大切なのは上司と部下との線引きです。当然部下が全てを決めて執り行うことは難しいので、どの部分はどちらがどれくらい実施するのか、そういう観点での議論と定義付けが適切なバランスを生むはずです。例えば、Management 3.0 のデリゲーションポーカーが活用できるでしょう。
management30.com
デリゲーションポーカーとは2者間での権限移譲を、命令する、説得する、相談する、同意する、助言する、尋ねる、委任するの7段階を用いて認識の相違を解消していくツールです。これらを定期的に行うことで、時代の変化、組織の変化に合わせられ、上司がダークサイドへ堕ちずに健全な組織運営がなされるものと考えます。

チーム内表彰制度をやってみた結果と振り返り

はじめに

以下の目的でチーム内表彰制度を実施してみました。

  • 社内の表彰制度の候補者選びの参考
  • チームメンバー相互の情報共有の促進

やり方は、月に一度、今月もっとも頑張った人を他薦で募ります。G suiteにて自分の名前、頑張った人、コメントを投稿できる簡単なフォームを作り、マネージャーだけが管理画面から得票数やコメントが確認できるようにしました。

結果

事前に課題認識はあったものの、得票数が大体1-2票、多くても3票という結果になりました。チームメンバー同士が(近しい人を除いて)お互いに誰が何をやっているのか、ということが全く見えていないということがよくわかる結果となりました。一方で個々人がチームメンバーを観る視点であったり、マネージャー層からは見えにくい頑張りであったりを拾い上げる場としてはかなり有用で、メンバーそれぞれの特性を垣間見るには良い機会だったと言えるでしょう。また、チーム内にしろ、当月のナンバーワンに選ばれたメンバーは多少のモチベーション強化にもつながっていたようです。

振り返り

“社内の表彰制度の候補者選び”としてはまずまずの情報が得られました。しかし、”チームメンバー相互の情報共有の促進”という意味では、表彰制度だけでは難しいと言わざるを得ません。別記事"確かにBasecamp社の6週間プロジェクトは組織の一体感を醸成できるのかもしれない"のようなプロジェクトスキームやチームのワークフローを確立したり、日報や週報等のレポートを強化したりすることで、促進されるのかもしれません。今は一旦、チーム内表彰制度を取りやめ、チーム内のプロジェクトスキーム作りに取り掛かっています。

ピッチからはじめよ(不十分なタスクを始める前に)

多くの組織でプロジェクト管理、タスク管理ツールを使っていると思います。多くのツールはタスク(課題)を1単位として扱い、それぞれにタイトル、説明、期限、担当者などを入れて、組織活動の見える化と前進を強く後押しする非常に便利なツールです。使っていない組織は稀と言っても間違いではないでしょう。一方で、雑談の中で生まれたアイディアやふと気づいたやりたいこと、やらなければいけないことなども、備忘録やシェアという意図で、プロジェクト管理ツールのタスクに登録されるケースがままあるように感じます。しかしこれは非常に危険な行為ではないかと思うようになりました。

不十分なタスク

不十分なタスクが生まれるといくつかの弊害が生まれます。

  • 情報や背景が十分でない

基本的にタスクはタイトルだけでも作成でき、十分な情報や熱意が抜け落ちてしまう可能性があります。例えば完了の定義が不明確なままタスクを引き継ぐと、誰も完了できない"消せないタスク"になってしまいます。

  • タスク化することでTo-dosになる

まだその優位性や要件が十分に議論されないまま、タスク化してしまうことで、Why?を通り越し、How?に話が移りやすく、メンバーが正しく意図を理解しないまま、納得感のない案件を嫌々こなすことに繋がりかねません。

  • 見えないコストの増加

長すぎるTo-dosリストはモチベーションを下げる一方、進捗確認の管理コストは上がってしまいます。また、タスクを多く抱えることが"やっている感"を示す方法になってしまうと、パフォーマンスの低下を招く可能性も十分にあるでしょう。

タスク作成の前にピッチでやろう

ピッチとはビジネス用語で、自分のアイディアや考えを短い時間で伝えるもの(こと)です。
careerpark.jp
www.key-press.jp
もしアイディアや気づきがあれば、プロジェクト管理ツールにタスクを追加するのではなく、まず組織のCMSコンテンツマネジメントシステム)やコラボレーションツール、連絡用の掲示板等にピッチを書くことを強くお勧めしたいと思います。エレベーターピッチでも良いですし、スタートアップ向けのピッチフォーマットでも良いでしょう。もちろん、図や表、データがあればなお伝わりやすいと思いますが、実際のところフォーマットはそこまで気にする必要はなく、十分に伝わる文章であれば、エッセイのようなものでも良いと思います。効果は沢山あって、

  • 背景や熱意を残せる

ピッチには誰にとって、どんな価値が?が重要視されます。時間が経って見返しても、失われることはありません。一方で、伝わらない、共感されないかはすぐに確認でき、注目されなければ掲示板の奥底に沈むだけです。タスクのようにいつまでも目のつくところには残りません。

  • メンバーのフィードバックを得られる

多くのCMSにはコメント機能があり、各人の意見を追記すれば、アイディアを非同期にブラッシュアップできる有益な議論が可能です。

  • 実現性の試金石になる

頭の中では壮大な完成予想図を描けていても、実際に実現しようとなると難しいことがあります。その前段として、文章化、資料化できないことも基本的に実現できないと考えれば、実現性における良い試金石となるでしょう。

おわりに

プロジェクト管理ツールであるBasecampのBasecamp社でも、カスタマーサポートツールであるHelp Scoutと内部で使うプロジェクト管理ツールはシステム連携をせず、人の判断を経た上で、通常利用するプロジェクトとは別のプロジェクトにストックしているようです。
m.signalvnoise.com
ピッチから始めることで、誰でも意見が言える心理的安全性の高いチームとなり、タスクに溺れない日々を過ごせたら良いなぁと思う今日この頃です。
ちなみにタイトルはイシューからはじめよ―知的生産の「シンプルな本質」から引用させていただきました。

ウォーターフォールとアジャイルの違いはコンテクストのスイッチングコストで説明できる、気がした

ウォーターフォールアジャイルの違い、そしてそれに順ずる利点と欠点についてずっとぼんやり考えていました。具体的には、「アジャイルは素早いウォーターフォールの繰り返しと何が違うのか?」という問いに対する根本的な解です。これはコンテクスト、つまり物事に対する考え方や見方のスイッチングコストに対するアプローチの違いとして、導き出せるのではないかと思うようになりました。

 

コンテクストスイッチングコスト

全ての物事には必ずいくつかの工程やサイクルがあり、それぞれに異なったコンテクストが存在します。システム開発で言えば、要件定義、設計、開発、テスト、デプロイ、運用などになるでしょうか。それぞれは必要な、または自然的な収束によって適用されるコンテクストは異なります。「チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ」を参考にさせていただくと、大きくはルーチンの業務、複雑な業務、イノベーションの業務に分けられますでしょうか。そしてその不確実性、アプローチや失敗の扱われ方もまたコンテクストによって大きく異なります。例えば要件定義は、世の中にない製品を作ったり、顧客満足度を圧倒的に変えたりという視点であり、不確実性は高く、アプローチも試行錯誤的、失敗は称賛される傾向にあります。一方で運用は、安定的に製品やサービスを稼働させ続けたり、間違いなく操作を加えたりする視点です。不確実性は低く、アプローチも生産管理や安全管理的、失敗は非難される傾向にあると言えるでしょう。

 

アプローチの違い

ウォーターフォールではその期間設定や不可逆性から、工程を分離可能だとする立場にあります。しかしその場合、工程が切り替わるということは、今までのコンテクストを変えることであり、結果として考慮不足として手戻りしたり、工程ごとに担当を分けたとすれば、組織対立としてそのスイッチングコストが表出したりするでしょう。

アジャイルではプロジェクトに関して記すドキュメント"インセプションデッキ"という中で、「ご近所さんを探せ」という項目があります。このトピックはなんとなく軽視されがちな印象ですが、コンテクストの異なるチームや職種、ステークホルダーをそのプロジェクトの開始時に網羅しようという試みではないでしょうか。また、「何を諦めるのかをはっきりさせる」という項目では、品質やスコープといったトレードオフとなり得る観点を調整し、そのプロジェクトにおけるコンテクストを定義するという試みもあり、そのスイッチングコストを抑制するような機構が備わっているのではないかと感じます。もしかすると、もっと乱暴に言ってしまえば、スプリントという短期間で実行と振り返りを繰り返すリズムやダイナミクスによって、人々が偏ったコンテクストを認知する前にやってしまえ、ということなのかもしれませんが。

 

終わりに

コンテクストのスイッチングコストという観点で見れば、実際のところ、プロジェクトの運営方法はあまり関係がないのかもしれません。工程やサイクル、職能や製品特性といったそれぞれのコンテクストを常に収集し、その視座をプロジェクトや物事に投入するということが大事なのではないでしょうか。

確かにBasecamp社の6週間プロジェクトは組織の一体感を醸成できるのかもしれない

ウェブベースのプロジェクト管理ツールであるBasecampの運営会社"Basecamp社"は、幾つかの書籍を出版し、その先進的な経営手法、組織運営で知られています。そんな彼らの組織体制は、彼らのブログを読む限り、機能別組織のようです。エンジニアリング、デザイン(一般的にはプロダクトと呼ばれる領域。デザイン会社を出自としていることからこの呼び名を使っていると思われる。)、QA、カスタマーサポート、OPSといった具合です。機能別組織で考えられる懸念、それは端的にセクショナリズムの発生ではないでしょうか。カスタマーサポートチームはデザイン(プロダクト)チームが話を聞いてくれないと感じ、デザイン(プロダクト)チームは早く欲しいがエンジニアリングチームは意図が分からないと感じ、エンジニアリングチームはOPSチームからの"小言"を煩わしく感じ、などなど、この手のうまくいかない話は枚挙に暇がありません。

6週間サイクル

"How we structure our work and teams at Basecamp"と題されたブログ記事にBasecamp社内で実施している6週間サイクルについて言及されています。
m.signalvnoise.com
これは6週間の実行と2週間の計画を1ターンとするプロジェクトスキームで、1ターンに時間のかかる大きなプロジェクトを2つと小規模なプロジェクトを4−8実施するというものです。大きなプロジェクトにはそれぞれデザイナー(プロダクトマネージャーに当たる人物)が1人、エンジニアが1−2人、小さなプロジェクトをまとめて担当するデザイナーが1人、エンジニア1−2人を兼務のない形でアサインします。多くても3人までとし、複雑性を抑止する狙いがあるようです。また、QAチームは適宜実行中のプロジェクトを見て回ったり、プロジェクト側から声がかかったりして、案件に携わります。記事内で言及されてはいませんが、カスタマーサポートチームやOPSチームに関しても同様の関わり方なのかも知れません。6週間の実行を終えると、2週間をかけて次回のサイクルで実施するプロジェクトの選択とサイジング、そしてアサインする担当者を決めます。およそ2か月のこのプロジェクトによるダイナミクスは、確かにすべてのチーム、すべてのメンバーが同じ方向を向き、互いに協調する環境を醸成できるかもしれないなと感じました。

終わりに

当然プロダクトを厳選し、リソースを集約すること、また強烈な価値観を内外に向け発信し続けていることも組織を健全に保つ要因になっていることでしょう。ブログ記事内にはその他にもプロジェクトマネージャーを用意しないこと、アイディアの集め方、Cレベルメンバー(CEOやCTO)の関わり方等、組織運営における非常に示唆に富むトピックが満載のオリジナル記事は、組織運営に携わるマネージャーやリーダー陣は必読です!

チームメンバーと1on1ミーティングを行った振り返りと所感

はじめに

伊藤直也さんのスライド"開発組織マネジメントのコツ"にあった1on1ミーティングを、異なる2つのチームの統合を機に、実施することにしました。その時感じた効果や実施する上での所感を以下に記したいと思います。

speakerdeck.com

得られた効果

皆が一様に感じていることを知ることができる

基本的に7割くらいのメンバーが、共通の事物について語ります。そこからチームの総体としての課題であったり、優先度であったりが手に取るように実感することができました。

こちら側の考えや思想、目指すところを(部分的にも)伝えることができる

マネージャーがメンバーへ伝える時、どうしてもミーティング内の数分やメーリングリストへのメール送信等、どうしても伝える側の主観で不十分だったり、的確でなかったりする場合が多くなりがちです。その点、1on1なら確実に相手のレスポンスを感じながら伝えられることができました。

個性がわかる

1on1をすることで、メンバーそれぞれの個性を実感でき、適材適所の良い判断材料になりました。

所感

1 to allより会話が楽(個人差あり)

大勢の前で話すことが苦手な人でも、1対1なら話しやすいかなと感じました。とはいえ、相手の考えや思いを汲み取るための質問力を鍛える必要はありそうです。

勝手にしゃべる人と質問にシンプルに答える人ではっきり分かれる

勝手に喋ってくれる人は基本的には話を聞き、適宜こちら側の伝えたい情報をインプットする形になるでしょう。シンプル派には伊藤直也さんのスライドにもあったような事前のアンケート等でネタを集めておくのが重要かもしれません。

やはりオープンな場所が適切

閉ざされたミーティングルームだと堅くなりがちなので、やはり広い空間で多少ざわついていた方がやりやすかったです。

やるべきタイミング

定期的に発生する評価関連等のミーティングもあると思いますので、その間を埋めるようにマンスリー程度で配置できるのが理想です。

終わりに

メンバーの考えをくみ取りにくい、自身の考えを伝えるのに苦労をしているマネージャーの皆様が、1on1ミーティングを実施する上で少しでもお役に立てれば幸いです。

IT部門における全体最適と部分最適のジレンマを解決する顧問エンジニアの可能性

一般企業のIT部門やテック企業のインフラ部門で良くある課題、それは全体最適を目指すIT部門と部分最適を志向する事業部門とのギャップ、軋轢ではないでしょうか。独自の要求をする事業部門に対して、特例があることによる管理コストの増加を避けたいIT部門が、要求を断ったり現状の基盤との親和性検討のため時間がかかったりすると、IT部門は遅い、使えない、事業部門は会社のことを考えていないとなり、事業部門が独自にアウトソーシング等でシステムを構築、結果的にいわゆる田舎の温泉宿的な鈍重なシステムになってしまったなんていう話は決して珍しくないと思います。このあたりは木村さんの連載記事に詳しいです。

itpro.nikkeibp.co.jp

記事にあるようにCIOやCTO、部長ら幹部たちが、事業部門を含む経営陣としっかり握った明確な方向性を示すことが一番ですが、多くの組織でははっきりとしないまま、現場まかせになっていたり、バラバラの方向を向いてしまっていたりするのが実情ではないでしょうか。最適解である全体最適部分最適のその絶妙なバランスは組織ごとにも異なりますし、定型の解法というのも今はないでしょう。この命題が誰にとっても難しいのも事実のようです。ではどうしたらその解を見出せるでしょうか?

抽象レイヤーとしての顧問エンジニア

今仮説として検討しているのが、クラウドサービス大手のAmazon Web Services等が展開するサポートサービスであるTAM(テクニカルアカウントマネージャー)のような顧問エンジニアの存在を軸とする方法です。

aws.amazon.com

事業部門またはさらに細かい単位を顧客としてそれぞれ固定のエンジニアを配置、新規システムの構築や改修等のコンサルティング、日々の運用やトラブル時の対応、健全性を保つ提言、そして、電話やチャットといったストレスの少ない連絡方法を用意します。顧問エンジニアが各事業部門の様々な要望や課題を献身的に汲み取り、統一のITインフラストラクチャ基盤に落とし込むことで、顧問エンジニアが抽象レイヤーとしての役割を担います。非常に大変な業務だとは思いますが、日々エキサイティングですし、課題解決というもっとも知的創造活動だとも言えるでしょう。これを実現する上で注視した方がいいことが3つあるように思います。顧問エンジニアが潰れてしまっては元も子もないので、「緊急連絡はトラブル時のみ」などSLA(サービスレベルアグリーメント)を定義し、その持続可能性を留意する必要があるでしょう。顧問エンジニアの評価を、「担当数と満足度」の掛け合わせによって判断し、企業の評価基準とのマッチングを明確にすれば、モチベーション向上にも寄与するはずです。さらに顧問エンジニアのチームとインフラ基盤のチームで有機的な連携を計り、常に満足度を向上させるような改善を行うことも忘れてはいけません。このあたりをしっかり押さえていけばある程度形になるのではないでしょうか。

事例募集中!

現状はまだ全て仮説なので、小さいところから始めていきたいと思います。何か気づきがあればアップデートします。こういう制度や方式を取っている方がもしいらっしゃったら是非教えてくださいませ。