見出し画像

成果をあげる習慣

Takashi Suda / かんた

「成果をあげることは習慣であり、それは他の習慣と同様に身につけることができる」…と言うのが現代経営学の父P.F.ドラッカーの主張です。これには私も同感です。個人依存の感覚や経験則だけではビジネスはできません。個人ビジネスならまだしも、企業という体裁をとらないと成立しない組織ビジネスでは「再現性」のある活動の組み合わせでないと永続的に成長することができません。成長どころか、存続することだって難しくなるでしょう。

もしそれでも属人的なスキルに頼った経営や事業運営をするのであれば、それは「自分たちさえ良ければ、あとはどうなっても知らない」という意思の表れなのではないかと思っています。

…ので、そんな環境に甘んじて改善しようとしない人を、私が信用することはありません。

1. なされるべきことを考える
2. 組織のことを考える
3. アクションプランをつくる
4. 意思決定を行う
5. コミュニケーションを行う
6. 機会に焦点を合わせる
7. 会議の生産性をあげる
8. 「私は」ではなく「我々は」と考える

これはドラッカーの「成果をあげる八つの習慣」ですが、私が30代の頃に考えていたことをほぼほぼ似通っていて非常に嬉しくなったことを今でも覚えています（私もご多分に漏れず、もしドラが出たあとにドラッカーを読み始めた人種なので）。

「私は」ではなく「我々は」と考える…簡単に思えて案外難しいものです。特にソフトウェア開発ではチーム意識をしっかり持っているエンジニアというのは決して多くありません。チームを作っても所詮「個人の集まり」でしかないのです。

マネージャーも進捗さえ問題なければいいと思っているから、チームの効果を最大値化しようなんて発想を持ちません。「進捗を管理するために」ルールを作ったり、チームに指示を出したりはするでしょうけど、それ以外は個々人に丸投げしているマネージャーも多いのではないでしょうか。

　チームの効果を最大値化

そのために段取りや準備を行ったり、マネジメント方法を身につけ模索するのがマネージャーの仕事のはずなのですが、残念なことに日本ではマネジメントというと

　「最低限の情報を管理する」
　「顧客との打ち合わせにとにかく全部出る」
　「なんかよくわからないけど、エンジニアより責任が重い」

仕事…程度にしか考えていないので、どうすれば今のチームメンバーがそれぞれ「これ以上のパフォーマンスが出せないっ」という状態にまで持っていけるかなんて考えもしません。

プロジェクトマネジメントの勉強…と言っても、所詮PMBOKのガイドやビジネス書を読んで暗記する程度のことしかしないでしょう。あいにく、PMBOKの中には明示的にチームの効果を最大値化するとは記載されていない以上、「書いてなければやらなくてもいい」という言い訳を自分に課すのではないでしょうか。

しかしこれができてこそ尊敬され、組織を率いて成果をあげられます。事実、私が過去に行ってきた新人研修でも上記８つの習慣のいくつかを若干異なるアプローチではあるが進言してきました。

いくつか例にとってみましょう。

「私は」ではなく「我々は」と考える

さきほどの『「私は」ではなく「我々は」と考える』というのは、私なりに

　ビジネスにおけるチームワークは
　"Team+Work"であってTeamworkではない

ということはよく言ってきました。チームワークというと「共同作業」と意訳されることが多いと思いますが、ビジネスでは１つのことを共同で行うことはありません。一人ひとりに役割があって手分けしています。よって「共同作業」ではなく

　「複数の人がそれぞれの役責を果たすことで、
　　初めて１つの仕事が完成する業務」

のことを私は"Team+Work"と呼ぶようにしています。言い方はアレですが、要するに「1つの完成品を構築する『良い部品』たれ」ということをいいたいわけです。一人ひとりがそういった姿勢でプロジェクトにあたれば、悪い結果になるはずがありません。

まぁだからと言って講義を受けてきた新人たちが言われたとおりに実施すると言うことはないと思います。また仮に良い部品たろうと努力しても、こうした講義を受けておらず、またそうした自覚のない先輩や上司と一緒に仕事をしていると、その先輩や上司が自分だけ楽をしようとしたり、自分のエゴで仕事をしようとしたりする『悪い部品』であれば、いくら良い部品たろうと思って努力していても、いずれ疲れてしまうし、同じように悪い部品に引き込まれてしまう子も出てくるかもしれません。

それに、痛い目にあってから思い直すことだってあるかもしれません。研修中は意識していても、配属後には配属先での「やり方」があって、思うように進めることができないケースだってあるかもしれません。

ですが大事なのはそう言った考え方、姿勢を育む「機会」を作ってあげることです。きっかけや気づきが無ければ一生そうなることはないのですから。

何から何まで受動的に吸収するだけでは成長は難しいかもしれませんし、結局そう言った知識や意識を活用する機会を設けなければ陳腐化してしまうだけかも知れませんが、こうした習慣は身につける時期が早ければ早いほど、組織への貢献は大きくなっていきます。


機会に焦点を合わせる

ただ、『機会に焦点を合わせる』というのはなかなか難しいかもしれません。理解し、チャレンジしようとするのも難しいですが、それ以上に

　「継続できるか」

という問題が出てきます。要するに「いずれ来るチャンスのために努力する」ということです。プラス方向へのリスクマネジメントと言ってもいいかもしれません。当然、マイナス方向でも同じなんですけど。

実際にそうなるかどうかもわからないけど、いざ来た時のために今のうちから努力しておく／準備しておくというのは、ゴールがどこかもわからずとにかくマラソンをしている状況に似ています。

普通の人ならもっと目先のことに目がいってしまって、実際に起こるかどうかもわからないチャンスやリスクなんてロクに考えようともしないはずです。

たとえば数年前にデータ不正などで色々話題をにぎやかにさせた某大手企業や、たとえば東日本大震災の際に津波等で多くの死者・行方不明者が出たのも、2019年に台風19号で70名以上の死者・行方不明者をだしたのも、すべて

　「まさか」

が原因です。

　「今までこれでやってきたのに」
　「生まれてこのかた、今まで津波なんて来なかったし」

といった、正常性バイアス（自分にとって都合の悪い情報を無視したり、過小評価したりしてしまう人の特性）と呼ばれる心理が影響します。そのせいでいずれ来るかもしれない機会まで本当に来るかどうかもわからない、無駄になるかも知れないという不安と闘いながら延々と継続できるか？というとなかなか難しいことでしょう。おそらく多くの人は

　「そんなものよりもっと優先度の高いものはいくらでもある」

と言って見向きもしないのではないでしょうか。まぁ気持ちはわかりますが、そのせいで「まさか」が起きた時に真っ先に被害に逢うということは忘れないようにしましょう。


会議の生産性をあげる

これまでにも何度か触れて決ましたが、私は基本的に「会議」が嫌いです。

もちろん必要があればやりますよ。必要があれば。
でもそれはどんなに数えても年に数回あれば良い方…それくらいのものだと思っています。少なくとも１日に何回も参加するようなものでありません。

そもそも雑談で済む内容なら雑談にすればいいんです。

手を動かして他の仕事をしながら、片手間にできるようなものさえ、変な理屈をこねてなんでも会議にしないと気が済まない人たちの無駄な人生の使い方に巻き込まれるのは非常に不愉快なんです。

特に能力等が認められて役職等があり、自分で解決する責任があるような人が、とにかく権力を用いてなんでもかんでも有識者を集めて、自分の代わりに解決させようとする会議ほどムカッとくるものはありません。仮に10人あつめて会議を1時間実施すれば、それだけで非生産的な時間を1.2人日ほど消耗してしまうわけです。仕事の手を止めてそこに召集された人たちの貴重な人生も１時間ずつ失わさせることにもなります。

エライ立場になると何を勘違いするのか、とにかく自分は動かずにすべて部下等に情報を出させるだけの楽な仕事の進め方をしようとします。

その部下たちにはそれぞれ割り当てられた仕事がパツンパツンに設定されているのに…です。そういう名ばかりの上司たちをたくさん見てきました。

ですから、私は私がマネージャーや上司になった時にはこの『会議体』に対して１つ明確な決め事を課しています。それは

　「自分１人では解決が困難な場合に、
　　解決が可能なメンバーに助けを求める場合」

にのみ実施するというものです。これは少なくとも私自身に限って言えば、かれこれ15年以上徹底してきた自分ルールの１つです。

それ以外で会議なんて開きません。

情報を共有するのであれば記録に残る別の形の方がいいですし、どうしても会話の方がいいというケースでも、無理に会議体にしなくていいのであれば雑談で十分と考えています。

とにかくTeamのWorkを自分の都合で乱さない。乱さざるを得ない時は、乱した分に見合った効果を引き出すことを目的とするくらいの覚悟で行います。だから、会議の中身も常にシンプルです。本当に困った時にだけ実施するので複数の議題なんてまずありませんし、ゴール設定も明確です。最短で必要最小限の議論ができれば十分ですから、パフォーマンスも否応なく高まります。

多くの場合

　『会議』

というのは、マネジメント対象タスクから除外されていることがおおいものです。みなさんもプロジェクトの計画を見てみてください。「コミュニケーションマネジメント」には会議体の設定が記載されているかもしれませんが、ＷＢＳやスケジュールでは一切管理されていないことがわかります。

一日を８時間、一週間を40時間、一ヶ月を160時間で計算しているはずで、その時間の中で遊びが出ないタスクの割り振りをしているはずなのに、その管理対象の時間とは関係ないところで好き勝手に会議体を実施しようとしているマネージャーが山のようにいることだと思います。

つまり「強制的に」残業を余儀なくするマネジメントをメンバーのみなさんに強いているということです（そんな権限どこにもないでしょうに）。

これはドラッカーの掲げる習慣とは相反していると私は考えています。

会議を真に効率的に、かつ生産性を高くしようとするなら、ただ「会議の中身」ばかり見るのではなく、

　・そもそも本当に会議にしなければならないことはなにか
　　（本当にそれが最も効率的なのか？代替も利かない唯一解なのか？）
　・そもそも会議に参加しなければならないメンバーは誰か
　　（本当に指定する全員が参加しないと目的が果たせないのか？）

と言ったところも吟味していかないと、組織の効果を最大値化することはできないのではないでしょうか。

いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。