P. F. ドラッカーの『ドラッカー名著集1 経営者の条件』を読んだ。
読んだ、と書いたが、読んだのは記録によると2017年4月29日だ*1。この記事のベースは読んだときに書き留めていたメモであり、公開するつもりはなかった。しかし、下記のブログで紹介されていたことから、誰かの役に立つこともあるかもしれないと考え、公開することにした。
ほぼ本文を切り貼りしただけのメモだったため、公開に際して、コメントを拡充し、引用の体裁を整えた。
組織全体の業績に責任を持とうとする者こそマネジメントである
肩書や地位がいかに高くとも、権限に焦点を合わせる者は自らが単に誰かの部下であることを告白しているにすぎない。これに対し、いかに若い新入りであろうと、貢献に焦点を合わせ成果に責任をもつ者は、最も厳格な意味においてトップマネジメントの一員である。組織全体の業績に責任をもとうとしているからである。（79）
入社1ヶ月の時期にこの本を読んでこの一節をメモっているのは我ながらいじらしい。あるいは、入社1ヶ月という時期だからこそ大真面目にメモすることができたとも言えるかもしれない。自分はすごいことができるわけじゃないんだ、ということを1年半を通して痛感させられ、（正当だとは思うが）一定程度の無力感を抱えるようになった今この一節を読むと、複雑な気持ちになる。
知識の全領域に自らの知識を位置付けるゼネラリスト
ゼネラリストについての意味ある唯一の定義は、「自らの知識を知識の全領域に正しく位置づけられる人」である。いくつかの複数の専門領域について知識をもつ専門家もいる。だがたとえ複数の専門領域をもっていてもゼネラリストとはいえない。単に、いくつかの専門領域のスペシャリストであるにすぎない。たとえ三つの領域に通じていても、一つにしか通じていない人と同じように偏狭でありうる。 しかし自らの貢献に責任をもつ者は、その狭い専門分野を全体に関係づけることができる。もちろんたくさんの知識分野を統合するなどということは決してできない。だが彼らは、自らの仕事の成果を生かしてもらうには、ほかの人のニーズや方向、限界や認識を知らなければならないことを理解する。（91）
当時の自分は、何を思ってこの一節をメモしたのだろうか。未経験でソフトウェア業界に入って、当初から「自分はスペシャリストにはなれない」、「でもゼネラリストにならなれる」、と考えていたのだろうか。
この1年半の間のうちの多くの時期で、自分の頭を支配していた問いがある。それは、「技術で生きるか、マネジメントで生きるか」というものだ。「ゼネラリストでなければ」という命題でもって、この問い自体を消滅させてしまうことはできないが、マネジメントで生きていくなら技術は要らないとか、逆に技術で生きていくからマネジメントは要らないとか、そういう話はできないな、と改めて思う。
また、以前、勉強会で川口恭伸さんが紹介していた、MITの石井裕さんの言葉を思い出した。生半可な「ゼネラリスト」ではなく、MITメディアラボ教授という文句なしのスペシャリストの言葉は重い。
一人の人間がすべてでなきゃいけない。 すなわち、ひとつのラベルを貼って、レッテルを貼って、 あなたは技術者、あなたはCognitive Science(認知科学)、あなたはSociology、 といった時代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、 人間、その信義、そのsociety、commitと、 これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう終わっている。
石井裕先生の2005年の講演のときにとったメモ - kawaguti’s diary
「あなたに何を期待すればいいですか」と問う
上司が部下に何かをいおうと努力するほど、かえって部下が聞き違える危険は大きくなる。部下は、上司がいうことではなく、自らが聞きたいことを聞き取る。 ところが仕事において貢献する者は、部下たちが貢献すべきことを要求する。「組織、および上司である私は、あなたに対しどのような貢献の責任を期待すべきか」「あなたに期待すべきことは何か」「あなたの知識や能力を最もよく活用できる道は何か」を聞く。こうして初めてコミュニーケーションが可能となり容易となる。その結果、まず部下が、「自分はどのような貢献を期待されるべきか」を考えるようになる。そこで初めて、上司の側に、部下の考える貢献についてその有効性を判断する権限と責任が生じる。（93）
上司に対して、「自分に何を期待すべきか」を伝えようという話が、ドラッカーの別の本でもされていたように思う。それが強く印象に残っていて、半年前まではかなり上司に「自分はこう貢献できると思う」と伝えようとしていた気がする（うまく定式化も論拠づけもできていなかったが）。
数ヶ月前に、プロジェクトの中で、自分なりにボトルネックを探したつもりになって色々と動いてみていた時期に、上司から「お前に期待しているのはそこじゃない」という明確なメッセージをもらった。あのときはかなり落ち込み、上司に対しても不満を覚えたが、事あるごとに話に付き合ってもらって少しは状況が見えてきた今となってみれば、あれは上司にとって「部下の考える貢献についてその有効性を判断する権限と責任」を果たした行為だったんだろうと思う。
上司の強みを生かし、自分を活用させよう
企業、政府機関、その他あらゆる組織において、「上司にどう対処するか」で悩まない者はいない。実のところ答えは簡単である。成果をあげる者ならばみな知っていることである。上司の強みを生かすことである。これは世間の常識である。現実は企業ドラマとは違う。部下が無能な上司を倒し、乗り越えて地位を得るなどということは起こらない。上司が昇進できなければ 部下はその上司の後ろで立ち往生するだけである。たとえ上司が無能や失敗のために更迭されても、有能な次席があとを継ぐことはない。外から来る者があとを継ぐ。そのうえその新しい上司は息のかかった有能な若者を連れてくる。したがって優秀な上司、昇進の早い上司をもつことほど部下にとって助けとなるものはない。しかも上司の強みを生かすことは部下自身が成果をあげる鍵である。上司に認められ、活用されることによって、初めて自らの貢献に焦点を合わせることが可能となる。自らが信じることの実現が可能になる。
あまり大きくない所帯に勤めていて、かつまだ最初の昇進すら経験していないので、ピンとくるわけではないが、この指摘は重要なのだろうと思う。自分の上司の強みが何か、というのは普段あまり考えることはない。自分が、自分が、というのが先に来てしまっていて、上司もまた一人の組織人であることを忘れていたかもしれない。
やらないことリストこそが大事
状況からの圧力は、未来をより過去を、機会よりも危機を、外部よりも内部を、重大なものよりも切迫したものを優先する。実は、本当に行うべきことは優先順位の決定ではない。優先順位の決定は比較的容易である。集中できる者があまりに少ないのは、劣後順位の決定、すなわち取り組むべきでない仕事の決定とその決定の遵守が至難だからである。延期とは断念を意味することを誰もが知っている。延期した計画を後日取り上げることほど好ましからざるものはない。後日取りあげてももはやタイミングは狂っている。タイミングはあらゆるものの成功にとって最も重要な要因である。（149）
青字の箇所が、メモを取った当時の強調で、赤字の箇所が今回つけた強調である。赤字の箇所は、アジャイルの文脈でよく言われる「やらないことリスト」を遵守することの重要さと難しさを指摘している。
青地のものについては、以前紹介した『Clean Coder』の一節と通ずるところがある。下記の引用は、やや強い主張ではあるものの、大事なことを言っているといつも思っている。
緊急時になれば、自分が何を信じているのかがわかる。規律を守っていれば、その規律を本当に信じていると言うことだ。逆に言うと、緊急時に普段の行動を変えてしまえば、その行動を信じていないと言うことだ。平常時にTDDの規律を守り、緊急時にそれを守らないとすれば、TDDの効果を心から信じていないということだ。平常時にコードをクリーンに保ち、緊急時に乱雑にするのであれば、乱雑が速度を落とすことを信じていないのだ。平常時にペアを組まず、緊急時にペアを組むのであれば、ペアのほうが効率的だと信じているのだ。緊急時に安心して守れるような規律を選ぼう。そして、それを常に守ろう。規律を守ることが緊急時から逃れる最善の方法である。ピンチに陥っても行動を変えてはいけない。規律が最善の方法であれば、緊急時になっても守るべきである。（156）
Clean Coder を読んだ - こまどブログ
読んだときの感想と再読に向けて
さすがにドラッカー先生で、正しそうな洞察に満ちている。
それが本当に正しいかどうかは、現実を見ることによってしかわからないだろう。
これは以前の感想。1年半という短い時間ではあるものの、多少なりとも「現実を見る」ことをした今の自分には、果たしてドラッカーのこの本はどう読めるだろうか。時間があればゆっくり読み直したい。
*1:入社後1ヶ月も経っていない時期。
