TAMINIF’s blog

大阪在住のWebエンジニア。iOSアプリもやってます。勉強会にも参加してます。最近はマネージャー色強め

転職しました

表題の通りです。 一つの節目として、これまでやってきたことをまとめます。

From -> To

From: ウェブリオ株式会社(2015/11〜2021/01)
To: Repro株式会社

ウェブリオでやったこと

エンジニアとして入社しましたが、約5年の間で結果的に多くのことを経験させていただきました。

Node.js, Perl, Java, Swiftを使った開発

Webエンジニアとして入社しましたが、PHPしかできなかった自分でも多くの言語の読み書きができるようになりました。
特にNode.jsは、エンジニアの中だけで技術選定から開発・運用まで経験させていただき、そこからNode.jsに深く関わるようになって、関西Node学園のOrganizarまでやるようになったことは、人生の大きな影響の一つです。またオフラインで勉強会できるようになりたいね。。

開発チームの窓口となって、要件/仕様の調整

エンジニアサイド <-> ビジネスサイドの間に入り、ヒアリングから要件をまとめ開発チームに持ち帰って設計という、機能開発一連でマネジメントしてました。
当時のウェブリオの開発は、営業やマーケターの要望が開発者個人に依頼しており、誰が何を開発しているのかわからないという問題がありました。
そのため、情報を可視化するため窓口を一本化し、開発できるレベルに要件をまとめ開発チーム宛に展開するやり方に変えていきました。タスクやドキュメントの管理場所が変わっていったり、ヒアリングの際にエンジニアに同席してもらって業務知識を得てもらうなどやり方は今でも色々試していっているため、完成させたわけではありませんがその時の最適なやり方を作れたのではと考えています。

コードを管理し続ける経験

前職は受託開発だったため、テストコードを書いたことがなかったりレビューする文化がなかったりしたのですが、自社開発でコードを管理する経験を得ることができました。
特に、可読性・保守性の悪いコードを書いて、その皺寄せが帰ってきた時には、リーダブルコードの重要性を思い知らされました。
リーダブルコードも今では新人エンジニアに必ず勧める本になっています。またこの時に、今の自分が書くコードは、過去の別人が書いたコードだから記憶に頼らないコードを書くということを考えるようになりました。

開発チームのリーダー

2018年の夏から約2年半、開発チームのリーダーポジションを担当させていただきました。元々開発リーダーがいなかったこともあって、自分なりにリーダーとは何をする人か勉強しながらやっていました。
自分が他社のCTOポジションの人と交流がないため、聞いたことや勉強会で質問させてもらったことを元に、何が正解かをずっと考えていたと思います。
CTOやVPoEと呼ばれるポジションとは違って、役割に縛られず開発チームのためになることならなんでもやっていたと思います。

給与レイヤーと評価制度の作成

リーダーをやる上で、一番やりたかったことをやらせてもらいました。目的はエンジニアの評価の透明化と採用をしやすくすることでした。
社内では給与への不満と評価の不透明さを聞くことが多く、採用では応募はあり面接して内定まで進めても、条件面談で折り合いがつかないことも多く、今のエンジニアの市場にマッチしていない課題感がありました。そのため、エンジニアを別の給与テーブルで管理し、何をどこまでできるかでレイヤーを策定する制度を作りました。
チームメンバーへヒアリングして経営会議に稟議書を出して、説明して承認してもらう経験も初めてでした。会社の制度を変えるために必要な動きを経験することができました。

組閣

開発メンバー一人一人と対話する時間を設け、どんな技術に興味を持っているかやどういうものを開発していきたいかをヒアリングしつつ、プロダクトごとに開発チームを配置することをしました。
チームの人数をバランスで決めるのではなく、どうプロダクトを成長させるか、その際に最も適切なメンバーは誰かを限られた人数で調整しチームにアサインしていきました。(慢性的に人は足りませんでしたが。。)
チームに対して、人が抜けたから採用するのではなく、必要なメンバー要件を言語化してその要件を満たせる人材を探すという考え方もこの時に得られたと思います。

考課

メンバーの昇給を決める会議に参加し、メンバー全員の評価に責任を持つ立場を担当しました。このため、期末は大体憂鬱でした。
メンバーの成果を説明する必要があり、そのためには成果を可視化する必要があり、それが苦手なメンバーも多かったため、それに対するサポートも多くやりました。
面談の中で話を聞いていると、本人は成果と思っていないものの他の人が聞いたら成果と言えるものが大体の人は持っており、ヒアリングで引き出してあげる必要性や手段についても経験し学ぶことができたと思います。

採用

新しく開発者を採用するための一連の流れを担当しました。必要な人材の要件出しから、募集要項の作成、採用課題の採点、面接、条件面談とほぼ全て担当していました。
最初はただエンジニアであればと考えていましたが、試行錯誤する中で組閣と同じように全員が同じではないということに気づきアップデートしていきました。
あまり成功体験は持っていないのですが、多くのエンジニアと話をする中で多くの価値観に触れて、影響を受けたこともあったため、自分の成長はあったと思います。
「How Google Works」という本には、「採用は最も重要な仕事」という章があり、採用に関わることは大きな成長が見込めることであり、全ての社員は採用に関わるべきということの説明が書いてあるため、これもいろんな人にお勧めしてます。今後も採用には関わり続けたいと考えています。

できなかったこと

チャレンジしながら、結果的に力不足でできなかったこともあります。

マネジメントと両立したリード開発

リーダーになってから、一番影響を受けた資料が伊藤直也さんの問題から目を背けず取り組むです。元々は「ELASTIC LEADER SHIP」の伊藤直也さんの章で知りました。
どれだけ良い環境を作っても、それで問題が解決するわけではないという観点はとても影響を受けました。
ただ、特にコードにおいて問題点を自分で解決することは、開発リーダーになってからほぼできなかったことです。
コードを書く時間も確保して書いてはいましたが、リソース不足で機能開発をすることが多く、結果的に問題解決がそこまでできなかったことは力不足だったと感じた部分です。

チーム開発におけるメンバーへの成功体験の提供

自分がエンジニアとしてチームメンバーだったときは、機能開発やリプレイスなどでリリースしてからの成功や失敗も含めて体験することができました。
ただ、その経験をマネージャーとしてメンバーに還元できたかというと、それはできませんでした。
プロダクト開発の現場で一緒に開発することができなかったこともあって、会社の資産を有効活用できなかったという点でできなかったことの一つです。

学んだこと(考え方が変わったこと)

入社する前と今まででたくさんのことについて知ることができました。成長を感じられたと思います。

Team Geekはチームでやっていくためのバイブル

最初に見たのはどこだったか忘れましたが、今では自分が最初にお勧めする本です。リーダーとなった時にも改めて読み返しました。
チームで開発をしていくために重要なことや取り組む心構えについて書かれている本で、メンバー全員に読んで欲しい本だと思っています。
HRTの精神は開発チームのバリューにそっくりそのまま入れています。

自分が働くことの価値提供について考える

働くことにおいて、以下のことを考えるようになりました。

  • 自分はなぜこの会社で働いているのか
  • この会社で働くことで、自分に良い影響/学びはあるのか
  • 自分がこの会社にいることで、会社にどのような良い影響を与えられているか

ある人から教えてもらった「会社と社員はWin-Winであるべき」という考え方を自分も真似するようにしています。自分だけが得をしてもダメだし、会社が搾取している状況もNGだと考えています。
働いていて、やりたくないことや自分の成長が感じられないのであれば、その会社に固執する必要はないし、自分が働いていて会社のためにならないのであれば会社のためになるようにするためにどうすれば良いか考えて、お互いにメリットがあるようにすることを常に考えています。

自分はチームを作っていくことをやりたい

自分が一番モチベーションを持てるのは、目標のために、必要かつ最短距離で達成できるチームを作ることで、そのために自分ができることを全てやっている時だとわかりました。
ウェブリオでの経験で言うと、開発チームのリーダーを打診されて、開発チームを現状から打破するときが一番がむしゃらに働き勉強していたと思います。
そのために必要なことはなんでもやってきましたし、なんでもやることは全く苦ではありませんでした。
特にエンジニアという肩書きにこだわることもありませんでした。もちろん開発もしていたいですが、それが目標達成において最も必要かということが先に来るようになっています。
なので、これからの仕事探しは、現時点では基本的に上記のことを考えてやっていきたいと考えています。

まとめ

ここの話は全て職務経歴書にもまとめます。
上記の内容は、まだウェブリオでしか経験していないためN=1でしかありません。他社で同じことをやろうとしても上手くいかない可能性があります。
それでも、これまでやってきた経験を他社でも成果として出せれば、自信になると思っているので、どうにか自分の力に変えていきたいです。
最後に、多くの経験をさせていただいたウェブリオには感謝しかありません。入社して良かったです。
稚拙な文章ですが、ここまで読んでいただきありがとうございました。転職した理由などは今のところ書く予定はないので、Twitter等で質問してください。

「ピーターの法則」読んだ

ピーターの法則」という本を読んだ。法則の名前と法則の説明くらいしか知らなかったが、会社に本があったのと、自分も無能であるのかもとずっと感じつつあったので 一度本を読んでみることにした。

「階層社会では、すべての人は昇進を重ね、おのおのの無能レベルに到達する。」

例外のない法則

ピーターの法則に、例外はない。全ての個人にとって、最後の昇進は有能レベルから無能レベルになる。
もし、十分に時間があり、そして組織に十分な階層があるなら、全ての個人は、その人なりの無能レベルまで昇進し、その後はそこに留まり続けることになる。
じゃあ仕事をしているのは誰かというと、まだ無能レベルにまで到達していない人たちによって行われる。

今日、階層社会に例外はない

社会では、身分・等級・階級に従って構成されているので、ほぼ全ての人が階層社会に生きていると言える。
一会社という観点で見れば階層のないところはあるのかもしれない。だが、大学のヒエラルキーなど、社会という観点で見れば階層は生まれ、ピーターの法則は例外ではなくなる。

引きの昇進、押しの昇進

昇進の方法には、上司から引き上げられての昇進と、自分を高めての押しの昇進とある。
引きの昇進は、パトロンを見つけると良い。自分を引き上げてくれる上司に、引き上げる動機を与えてやれば、自然と昇進する。上司が引き上げられる限界を迎えれば、そのパトロンからは離れるべき。複数のパトロンを見つけ、引き上げられる確率を高める。
押しの昇進は、自分を高めることで成就できるが、引きよりも力は弱い上、押しの昇進でも昇進の最終到達点は変わらない。引きの昇進が期待できるならそちらの方が良い。

創造的無能のすすめ

無能にならないためにやることは、昇進を断ることではない。昇進を断った時点で、周りの人間を不幸にし、結果的に無能と判断される可能性がある。
無能にならないためにやることは、昇進を拒否するのではなく、初めから昇進の話を持ちかけられないようにし、有能のまま留まることである。これを創造的無能と呼ぶ。変人ぶりを発揮したり、一匹狼であったり、外見を演出するなど。
有能レベルに留まり、有益な仕事を成し遂げることが、成し遂げた人にしかわからない満足感を得ることが出来、それが幸せに繋がる。

読んでどう思ったか

これほど、辛い思いをしながら解決策を知るために先にどんどん進もうと思う本は初めてだと思う。
自分の気持ちとしてはこの法則を否定したいのだけど、今の社会をみている限り今のところは否定できず認めざるを得ないと感じている。
自分が有能レベルに留まっているかは「この人は有益な仕事を成し遂げつつあるか」の回答で判定できるので、社会に価値提供できているかで考え、価値のある仕事をし続けるしかないのかなと思った。

同時に、会社において、社員が有能か無能かを決定するのは、外部の人間ではなく、その組織の内部にいる上司とある。これは、仕事内容や上司によって、有能と判定される場所はあるかもしれないということになると思う。活躍できていないことは環境によるものという可能性もあるし、無能だと思われているのは今の上司だけの可能性もある。一つの色眼鏡で全てを決めるのではなく、外を見てやっていこうと思う。

ピーターの〇〇

本を読んでいるとこれが異様に多い。大体覚えていないけど、研究の中で明らかになった事象がすべて書かれている。以下抽出

  • ピーターの愛着
  • ピーターの悪循環
  • ピーターの頭打ち
  • ピーターの急がば回れ
  • ピーターの痛み止め
  • ピーターの受け流し
  • ピーターの逆説
  • ピーターの気休め薬
  • ピーターの結末予知
  • ピーターの処方薬
  • ピーターの特効薬
  • ピーターの難所
  • ピーターの微差
  • ピーターの必然
  • ピーターのふるい落とし
  • ピーターの本末転倒
  • ピーターの予防薬

まとめ

この本を読んで救われたとは思いづらいけど、覆すではなく、受け入れた上で自分が生きていける人生を進んでいきたいと思った。
この本を読んだことも、どこかで生かせれば無駄ではないし無駄にならないようにしたい。

マネージャーになったら身に付けたいファシリテーションスキル

この記事は、Engineering Manager vol.2 Advent Calendar 2019 2日目の記事です。

この記事は、エンジニアのマネージャーになって1年ほど経験した私が、マネージャーに必要なスキルの中から今自分が一番足りていないと思うファシリテーションについて書きます。
まだまだ若輩者のため、この記事へのご指摘はいつでもお待ちしております。

ファシリテーションとは

会議において、段取り・進行など会議を円滑に進めることや、参加者の意見の促進など相手の内面を引き出すことです。
MTGにおける司会者のような役割で、その役割を担当する人のことをファシリテーターと呼びます。
おそらくビジネス用語だと思うのですが、私は最初に聞いた時は全くわかりませんでした。(近くの同僚から聞いた)

なぜ必要か

マネージャーに就任して、当たり前ですがエンジニア内外関わらず人と関わる機会が多くなりました。
その中で、人とのやりとりでリードする立場を期待されることが多くなり、相手とのやりとりの中で最適解を見つけていくためには効果的なファシリテーションが必要だと感じるようになりました。
ファシリテーションスキルがあれば、MTGでも1on1でもディスカッションでもより早くゴールに進めることができます。

ファシリテーションスキルとは

ファシリテートとは「容易にする・楽にする・促進する」という意味です。

ejje.weblio.jp

そして、この言葉は「人は主語にならない」となってます。つまり、モノやコトに対して容易にする・促進するということです。

つまり、ファシリテートするとはただ司会の立場で場を回すのではなく、相手に対して「何か」を促進することです。「何か」というのは、その場によります。
イデア出しのMTGであればアイデアを出させること、目標を設定するのであればその人の内面を引き出してあげること、といったように、です。
前置きが長くなりましたが、ここからファシリテーションのスキルについて書いていきます。

ファシリテーションを意識する

スキルかと言われれば微妙かもしれませんが、一番重要なのは意識することだと思います。
ファシリテーションMTGの場で必要というのは自明ですが、1on1も席での会話も、広義で言えばMTGです。
その時、ただ会話するのではなくファシリテートを意識することで、普段の会話が1段階レベルアップすると思います。ましてや、マネージャーになったからにはあらゆることの調整をする必要があり、
そのための普段のコミュニケーションはとても重要で、どこにでも情報は転がっています。
それらの情報を見逃すことなく拾い上げていくことは、マネージャーにとって重要なスキルだと考えています。

知識を共有する・要約する・噛み砕く

主に相手から意見を出してもらいたい時、意見が出てこないのは質問の投げ方の問題かもしれません。
何より、相手は自分に何を求められているのか、理解していない可能性もあります。
なので、ファシリテートする際には、まず前提をお互いが理解しているかを確認し、もし前提が違う場合は相手に求めている情報を要約し、理解するまで伝えてあげることが大事です。

いきなり意見を求められて、自由に発言できるのは体感でおよそ1割程度です。
残りの9割の人たちは、正解がわかるまで話をしようとはしません。なので、正解があるものを出してあげる必要があり、そのために正解があるというように相手に要約して伝えてあげると、相手もその正解に沿った回答を出してくれて、その後のMTGがスムーズに進む傾向があります。

言われたことの意見を受け止める

相手が言ってくれた意見が、自分の意図したものではなかった場合でも、相手は何かしら自分の考えを持ってその発言をしているはずです。
ただ頭ごなしに否定するのではなく、自分の中に一度落とし込んで、その意見を話した意図を考えることで新しい発見があるかもしれません。
もしかしたら、間違っているのは自分で相手の発言の方が正しいかもしれません。受け止めたことで次の展開が良いものになる可能性は、常に意識する方が良いと思います。

最後に

自分もまだまだできていないですが重要だと思うことを書きました。
マネジメント系のAdventCalendar初参戦なんですが、こんな記事で良いのか不安ですが誰かの参考になれば幸いです。
他にもこういう点もスキルだというものがあればぜひ教えてください。

「ゆとりの法則」読んだ

ブログには書いていないけど、以前にピープルウェアを読んでいて、ピープルウェアとセットだと認識していたので読んでみた。

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

ピープルウェアが組織の中で仕事をするための本だったのに対して、こちらはプロジェクトを進める手法が書かれた本である
なぜゆとりを持つことが必要なのかと、ゆとりを持たないことで何が起きるのかが書かれている、いわば注意喚起のような本でいくつか印象に残ったところをあげる

本当に早く仕事をするには

この章では仕事を早く終わらせるための間違った方法を解説する

ゾンビ

仕事に執着しやがて燃え尽きてしまった社員のことをゾンビと総称し、ストレスのかかるプロジェクトを見渡すとゾンビになっている人が多いことに気がつく。
ゾンビとなった社員は辞めることが多いが、組織に残り続ける人もいて、そういう人が増えることでプロジェクトは停滞し続けてしまう。
この現象は心当たりがあるがこの見方をしたことがなく、ゆとりを表すバロメーターになるものだと思った。

人員過剰のパラドックス

人手が足りないことはチームのストレスの原因になるが、かといって間に合わない納期に人員を追加して解決する問題でないが、往往にして管理者はそのことを理解しない。
さらに管理者は人手を増やしたことで達成できる挑戦状を叩きつけ、結果恐怖の文化が生まれる。

契約にもゆとりを持つ

ゆとりを持つことは問題が発生した時に対応できる余裕を持つことである。そしてそれはプロジェクトだけではなく、契約の場合も同様である。
二つの契約を並べた時、一方が安ければゆとりを削っている可能性があり、トラブルによって訴訟に発展する可能性がある。自分が売り手の時は容易に想像できるリスクを盛り込んでおく。

誤った目標管理

目標管理は二つの面で誤りである。 - 目標管理はある状態が続くことを前提にしているが、物事は常に変化する。 - 目標の指標は必ず単純化されたものであり、その値を最大値に近づけようとして結果的に企業の貢献度が下がることになる。(ディスファンクション)

変化と成長

全く変化できない人は成長もできない。これは自明だが、変化できないのに成長を求める組織を多く見る。この章では組織の変化と成長を実現するというテーマに目を向ける

リーダーシップとフォロワーシップ

意志を生み出すのがリーダーの仕事である。
リーダーは一部のエリートが担うものであり、それ以外の人はリーダーについていくべきというのは、リーダーシップではなくフォロワーシップを植えつけているだけである。
リーダーシップは全員の任務であり、名案を思いついた人に従うのも任務である。リーダーシップは交代制で担うものである。

変化は中間管理層から

変化がトップから起きるというのは間違いである。重要な変化には再生が伴う。企業の再生のためにはトップにはわからないような日常業務との深い関わりが必要である。
変化が底辺から起きるのも間違いである。底辺の人々は再生するための願望もなければ、再生計画を遂行するための力もない。

変化は中間管理層から起きるのである。
変化には再生のためのゆとりと、有意義な変化を計画し実現するための協力が必要である。

まとめ

リーダーシップとフォロワーシップの話が一番印象に残った。自分がリーダーシップだと思ってやっていたことはフォロワーシップだったかもしれないし、リーダーシップはチーム全員が持てるようフォローするのもリーダーの仕事だと認識した。
ゆとりを持つことを、自分の手の届く範囲で周りに伝染させていければと思える内容だったので書評を書いたとともに実践していく。

HARD THINGS読んだ

働くことについて別の視点をいれてみたいと思って読んだ。

HARD THINGS

HARD THINGS

この本は筆者が体験したことを元に、倒産する時が見えているときに何をしないといけなかったを解説してくれてる本で、
最初の3章で会社が倒産するところから売却するところまで実際に何があったか書いてある部分で、それ以降の章は会社で起きたことをよかったこと悪かったことを合わせて書かれているのが読めてよかったと思える部分だった。

必ず起きてしまうネガティブな事象に上手に取り組むための本

良い製品マネージャ、悪い製品マネージャ

この章で良いマネージャとは、悪いマネージャとはが多く書かれている。

良いマネージャは素晴らしい製品を最適な時期に出すために必要なこと全てに責任を持つ。
悪いマネージャは山ほど言い訳をする。

良いマネージャは「WHAT」を明確にし、「HOW」ではなく「WHAT」が実現するまでを管理する。
悪いマネージャは「HOW」を思いついたときに最高の気分に浸る。  

ここにあげた内容は一部だが、この章だけでも読む価値はあると思った。マネージャの良い悪いはわかりづらいと思っていたが、ここに書かれている内容だけでおおよそ見分けはつくのではないかと思う。

大企業の幹部が小さな会社で活躍できない理由

一例では、大企業の幹部は、メール・電話・ミーティングと基本的に待つ体になっている。部下からの報告を待つのである。ベンチャー企業で働くにはミスマッチが起きるからである。
この章で、どの企業でも合う合わないはあるのだと思った。ミスマッチの検出という章で「仕事に就いて最初の一ヶ月に何をしますか?」という質問で自分がどう回答するかはどこで働く場合でも考えるようにしたい。ここでは「勉強」を強調しすぎる人は要注意とある。おそらく何があるかわからないが前提にきているのかもしれないが、わからなくても動いて解決していけるタイプを目指したい。

正しい野心

幹部を採用するときは「正しい野心」を持つ人を採用する。人は世界を見るときに何らかのメガネで見ている。そのメガネが「自分メガネ」なのか「チームメガネ」なのかで、「正しい野心」を持つ人とは「チームメガネ」で見ている人のことである。
過去の経験を話すとき、「自分の職務経歴にプラスになった」というような話をしたとして、状況を自分の経験に結びつけてしか考えられない人は全ての事象を自分本位でしか考えていないことが垣間見える。過去の経験で「自分」を主張しない人はチームを第一に考えていることがわかる。
一般社員の場合は自分のキャリアパスの充実を考えても良いが、経営に携わる幹部の場合は動機が重要である。

最近は実績を積んで自分の話を増やしたいと考えていることが多かったが、そのときに自分がどう成長したかを今までなら話していたと思う。
確かに個人で何をやったかは今でも話すことはあるが、チームにどういう実績を残したかを話せる人は少ないと思うのでそういった話をできるような実績を残すことを意識したい。

まとめ

目標設定の章で「チームに実現不可能な目標を与えれば士気は下がる」とあったが、ここでも孫子が引用されていたことには驚いた。孫子を読んだから気づくことかもしれないが、多くの人が参考にしているのだと思えた。
最後にあった「苦闘を愛せ」という言葉がもっとも印象に残った。世界中の助言と知恵を集めても、困難は困難である。その困難に立ち向かうことこそが困難を解決する唯一の方法なのだと考えた。
辛いと思うことは多くあるが、その辛さを解決するのも自分だけなので、嘆くより動くことをやっていきたい。

「サボタージュ・マニュアル」1時間で読んだ

サボタージュ・マニュアル:諜報活動が照らす組織経営の本質

サボタージュ・マニュアル:諜報活動が照らす組織経営の本質

東京出張の新幹線の中で読んだ。タイトル通り1時間程度でサクッと読めたので気になった人はぜひ読んでみてほしい。

この本を読んだきっかけ

サボタージュ・マニュアル自体は下記のブログで読んだことがあって知っていた。

chikawatanabe.com

会社の人がこの本を買っていて、軽く読めそうだなということで読んでみることにした。

どういう本か

CIAの前身であるOSS(米国戦略諜報局: Office of Strategic Services)が、敵国に対してスパイ活動を行うために作られたマニュアルがサボタージュ・マニュアルであり、それが公開されていて解説されている本である。
物理的な破壊工作の方法から、組織のコミュニケーションの際に行うことで混乱を引き起こす方法まであり、その中でも組織のコミュニケーションを焦点に、何をすることで組織は停滞するのか具体的な事例と合わせて説明されている。

読んでみて

「会議に必ず5人以上出席させよ」や「チーム内で衝突させろ」など、実践することで組織が悪くなる内容が書かれているので、アンチパターンとして参考にするべき本だった。

この本は組織を停滞させる手段が書かれていることから組織運営の本のように見えるが、実際には組織を作る人ではなく組織に所属する人にできるだけ読んでもらいたいと思った。
その理由は

  • サボタージュ・マニュアルはスパイ活動のためなので、組織の中にいる人がやることである
  • なので、自分一人が意識しても限界があり、各個人が意識してやらないようにしないといけない
  • チーム内に一人でもこのマニュアルの内容をやってしまうとそれだけで影響が出る

ためである。

以下の二つは、わかっていても特にやってしまいそうなことをまとめた。

集団は個人の活動を封じ込める

「三人寄れば文殊の知恵」というが、「三人集まってから課題を解決する」よりも「それぞれが解決策を考えてきてから集まる」方がより的確に課題を解決できたという研究結果が出ている。
また、集団になることで以下のマイナスのメカニズムが発生する。

  • 社会的手抜きの法則
    • 自分一人で仕事をするときはその評価が自分で確認できるが、集団で仕事をするときは個人の成果が見えにくいので人は手を抜きがちになる
  • 評価懸念による発言の抑制
    • 会議の場面では、人は課題解決よりも自身の評価を気にする。そのため、ベストな解決方法を知っていても、自分の意見が間違っていたら、間違っていることで上司から悪い評価をつけられたらと考えてしまい、自由な発言ができなくなる。
  • 沈黙の螺旋
    • A案とB案があった時に、自分はB案が良いと思ったがA案が多数を占めている場合、多くの人はB案の素晴らしさを主張するよりも黙る傾向にある。そして、A案の素晴らしさの主張はハードルが下がる。
  • 同調
    • そうして会議では多数派の意見しか発言が出なくなり、腹の探り合いが発生してしまう。
  • 調整損失
    • 会議で一番時間を使うのは、発言のタイミングを伺うことになっていないか、これは会議の人数が多くなるほど発生し、個人の時間を奪ってしまう。

そうして集団は個人の能力を封じ込める。
みんなで決めるという民主主義が、チームのスピードを遅くする。

「黒い羊」効果を生じさせよ

黒い羊効果とは、自分たちの所属する集団にとって都合の悪いものを阻害して排斥するような現象をさす。これによって組織内のいじめなどが発生しやすくなる。黒い羊を意図的に作り出すことで、集団内に問題を発生させることができる。
また、排斥されたメンバーが集団の活動を阻害するための攻撃を自発的に仕掛ける場合がある。これも組織内で大きなリスクになりうる。
組織のパフォーマンスが低下、場合によっては崩壊する可能性もある。

まとめ

本を読んで、こうやって書評を書いたことで特に意識してアンチパターンとして扱わなければならないと思った。
この内容を知らず、やってしまっている人はスパイになってしまっていることになるので、やっている場合は止めないといけない。
組織に所属する人は、一度手にとって読んでもらえるとチームが阻害される可能性が少なくなるので、
すぐ読めるものでもあるのでぜひ読んでみてほしい。

起業のファイナンスを読んだ

たまたま同じ日に読んだ記事の中で同じ本が紹介されていて、興味を持ったので読んだ。 まだ私の知識レベルでは全部を理解することはできなかったけど、とっつきやすくて面白かった。

最も印象に残った「計画する」ということ

第3章「事業計画の作り方」にあった、必ず計画を立てる話について書き残しておきたい。

未来を予測することは不可能

事業計画は事業がうまくいくように計画を立てることである。どれだけ計画を立てようが未来を予測することは不可能だが、それでも計画を立てる必要がある。
それはなぜか、計画を作ることができるということは計画を作れるレベルまで考えがまとまっているということであり、その事業を説明することができるためである。
エレベータ・ピッチと呼ばれる、エレベータの15秒で事業の魅力が語れるようにしておいて、常にチャンスを逃さないようにしておくことが大事である。

事業計画書はパワーとなる

  • 事業計画に要点がきちんと考えられていれば、それを読んで興味を持ってくれる人が出てくる。
  • 事業計画は事業に関係する人たちをやる気にさせられる「パワーの源」になる。
  • 根性や情熱で事業を始めることはできるが、継続させられる保証はない。

計画を作ることでリスクに立ち向かえる

計画が「いける!」というものになっていれば、それが「勢い」になる。「勢」というのは、すなわち、状況に応じて臨機応変な対応が行えるということ
孫子「計篇」参照

孫子では、戦を行うときに相手と自分を見てどちらが各方面において準備ができているか、戦力差を理解できているか、勝つ見込みがあるかを判断する。
勝ち目があると正しく判断できているのであれば、不思議と勝てるものである。
二ヶ月くらい前にたまたま孫子を読んでいたこともあってこの章はよく理解することができた。

事業計画は投資家へのコミットメント(約束)の一部を形成することにもなりえる

  • 「こうやれば100%成功する」なんて道筋はないから、状況に応じて変化することは必須で、事業計画が進捗を縛るものであってはならない。
  • 「絶対成功する」事業計画が立てられる訳ではないけど「明らかにダメ」な計画はわかる。
  • 計画が間違っていたり成功する可能性が低いことが見えているなら、その計画は成功する可能性は低いのでやらない方が良い。

まとめ

近いうちに一度事業計画を書いてみたいと考えていたこともあって、この章だけでも読む価値はあった。
今まで会社のことを勉強したことはなかったので、会社員でいる間でもなぜそうするのかを理解するためにも勉強してよかったと思う。
理解できていないことも多いので、他の事業計画を読んでみて事例を元に勉強したい。