ugo's 読書感想文

読んだ本のまとめや学んだことを書いていきます。

エンジニアとして世界の最前線で働く選択肢

エンジニアとして世界の最前線で働く選択肢を読んだので、得た知見などのメモします。

 

 

概要

海外、とりたてアメリカで働くことを中心に紹介されている本です。

などがメインとなっています。

 

読む時に、世界の最前線で働くエンジニアが多い環境で働くことはどういうことなのかを想像していたのですが

 

全体的に面接やビザの話がメインで、エンジニアが普段どのように考え、どのように仕事に立ち向かっているかといったところはほとんどなかったのは、少し想像と異なっていた部分でした。

 

ただ、アメリカへの道筋という観点でいえば、良いノウハウがいくつか紹介されていたので、参考になりました。

 

アメリカ文化でのエンジニアの立ち位置

エンジニアの立ち位置は一般的な日本の企業とは異なり

エンジニアのキャリアパスというのが確立されているようです。

 

日本では、エンジニアを経験すると、次のキャリアパスとして管理職(つまり、マネージャー)のようなパスしか用意されていなく

 

その線からズレてしまうと、なかなか戻れないといったことがあります。

 

アメリでは、そのようなことはなく、自分が適しているのであればエンジニアとしてのキャリアパスを貫くという選択ができます。

 

ただ、やはり年齢とともに集中力や体力の衰えなどもあり、続けるのが困難な場合も発生するので、そこでパフォーマンスが出せなくてなれば、

厳しい現実が待っているため、そこの見極めが重要になります。

 

一度管理職に行き、合わないと感じたらまたエンジニアに戻るという選択肢があるのもアメリカでのキャリアパスの一つとして用意されています。

日本でも、最近の企業だと、そのようなキャリアパスが多くなっている傾向はあります。実際、私の会社でも挑戦という気持ちを大事にするので、まだ規模が小さい会社だからというのもありますが、キャリアについては割と柔軟に選べます。

 

なので、取り立てアメリカだからといったことはないとは思います。

しかし、やはりアメリカなので交渉の仕方など、キャリアパス以外の障壁などが立ちはだかることは多くなるとは思います。

 

パフォーマンスの重要性

パフォーマンスは日本よりも重大に捉えられていて

特にレイオフという概念においてパフォーマンスが一番に影響を受けるもののようです。

 

特に、自分が昇進したり、キャリア変更をした際には、慣れない状況でのレイオフがあると、真っ先に対象になる可能性があるため、タイミングにはより注意を払う必要があるようです。

 

日本だと、キャリアが変わったばかりだからであったりとか、成長見込みなどもあって、そもそもレイオフという考え自体がほぼないので気にしない人も多いかもしれないですが、アメリカだとシビアに見られる可能性があるようです。

 

レイオフ

アメリカがレイオフがよくあるとは有名な話ではありますが

企業側もそう安易とレイオフをする訳ではないようです。

 

在籍し続ける従業員のモチベーションや、訴訟文化のアメリカにおいて不当な理由や、手当などを提示せずにレイオフすると訴訟を起こされたりと、会社の評判にも関わるためです。

 

そして、レイオフの対象もそれぞれの職位により程度は決められています

 

新しく入った人がパフォーマンスが良くないのは当然で、そうすると新人ばかりがレイオフ対象になってしまうため、そこらへんの考慮というのはしっかりしているようです。

 

とは言え、日本より確実にレイオフが行われることもあり、社員だからといってうかうかしてもいられないというのはあります。

 

最近でも、アメリカ大手テック企業がレイオフを立て続けに行いました。

レイオフ自体がどのように行われて、どのような条件などが提示されるのかなど、やはり実際に立ち会わないとなかなか分からないところに関しても、参考になりました。

 

基本的にレイオフが決まった社員は、その決定に対して交渉の余地がないことや、何ヶ月分の給料は保証されるなど、心構えがあるのとないのとではショックの度合いや、実際に立ち会った時に理解が追いつかないなどがありそうなので、どういうことがありそうかだけでも見聞きしておくのは重要そうです。

 

英語力

一番日本人が気になるところだと思います。

私自身、大学では英文学を専攻し、プライベートでも英語の勉強に長い時間を注ぎ込み、留学もした身ではあるので、ある程度は障害になるとは思っていないものの

やはり、エンジニアとして働く上であったり、面接時にどこまで重要視されているのかまでは分からなかったので、気になるところでした。

 

シリコンバレーでは基本的に英語能力で判断はされないというのが結論のようです。

 

実際、2010年時点ではシリコンバレーの技術者の割合では、英語ネイティブの方が少ない(アジア人50.1%, 白人 40.7%)のようです。

 

ある程度コミュニケーションが取れて、コードが書ければ特に問題がないというのが実情のようです。

 

とは言え、やはり心配になるところではあると思います。

ある程度コミュニケーションが取れるとはどのような状態なのか、など不安要素は多いです。

 

大事なことは「情報伝達速度」になるようです。

つまり、発音や文法は間違っていて、ゆっくり話すとしてもちゃんと理論立っていて、受けてが納得できることを言えていれば、発音や文法が完璧でスムーズに話せたとしてもそれは情報の伝達ができていないため、意味がないということです。

 

ニュアンスで伝わらない状態は良い状態と言える

英語で話していて、ニュアンスの間違いで相手が理解できなかったり、誤認識してしまった時の話です。

 

ニュアンスで間違いなのだからダメなのでは?と思うかもしれないですが

逆に言えば、ニュアンスさえ合っていれば問題なかったということになります。

 

日本人の不安になる面として、まず言いたいことをどう英語で言えばいいか分からないということが大きな問題になると思います。

しかし、それをクリアした上でニュアンスでミスリードになってしまったというのは、上達している証でもあります。

 

悲観的にならず、ニュアンスの問題で躓くレベルまで上達したと考える方が良いです。

 

ビザ問題

日本人に限らず、どの外国人も当たる問題だと思います。

とりたて、日本人で言えば、やはり日本企業からの海外パスがあれば一番の近道になります。

海外に支社がある、本社が海外といったパターンですね。

 

それ以外では、H-1B、L-1、Oビザ などもあるようです。

H-1Bは、高度な専門職に発行されるビザです。

L-1は、社内転勤でアメリカに来る時に発行されるビザで、一番ハードルの低そうなビザです。

Oビザは、海外企業から著名な人に対して直々にオファーがあった時に出るようなビザです。(論文などで海外でも認められる必要があるため、ハードルはとても高いです)

 

転職

アメリカでの転職でも、レジュメを書く必要は当然あり

そこに書く、Objectivesという項目では、自分の達成したいことを書きます。

 

これには、簡潔に伝えたいことのみに焦点を当てる必要があります。

自分が一番スキルを発揮できるポジションのために、どういったスキルがあり、どういった実績があるかといったものが必要になります。

 

サイト

  • LinkedIn.com
  • Monster.com
  • Dice.com

など

最初はリクルーターから連絡があり、そこから電話面談になり、エンジニアやチームリーダー、マネージャーなどと面談する流れのようです。

リクルーターは技術者ではないので、あくまで適正や問題のない人間かを判断するためのものらしいので、技術的な細かいことはエンジニア面談の時に聞くようにするのが良さそうです。

 

そして、リクルーターはノルマ的なものがあるらしく、とにかく問題ない人間であれば数うちゃ当たる精神で連絡が来るようなので、リクルーターからの連絡にあまり一喜一憂しない方がいいです。

 

住所が日本とかになると、それだけで少し壁が発生してしまうので、リクルーターとしても連絡はしにくいようですが、一度アメリカという土俵に立つことができれば、比較にならないほどの連絡が来るようなので、しっかりと自分に適したポジションなのかどうかを見極める必要があります。

 

特に、自分のスキル欄に少し触ったことがあるだけの技術などを書くと、それでリクルーターがその技術のポジションで連絡することもあるので、自分が希望している技術でない限り、自分に合ったポジションに関わる技術に絞って書いた方が良さそうです。

 

面接

面接では、ホワイトボードにコードを書くようなコーディングテストなどもあるようです。

大事なことは、そこで全てを解き切り100%の答えを作るのではなく

  • 答えに導くための考え方
  • 不十分な情報を埋め合わせるための面接官とのコミュニケーション
  • 問題がある場合、その問題へのアプローチや代替案の提示

このようなことができることが重要となります。

 

特に、不十分な情報のまま書き始めてしまうなどは実際の仕事においても致命的になりうるため、いきなりコードを書き始めるのではなく、しっかり十分な情報を揃えてから書かないと印象は悪くなってしまうので注意が必要です。

 

思考についても、書いてる途中に補足することも重要になります。

「この関数は後で書くつもりだ」や「この書き方だとこういう問題があるので、問題への対処法を考える必要がある」といったことをしっかり面接官に伝えるだけでも印象は全然違います。

 

上記からも分かるように、面接官とのコミュニケーションは大事で

面接の前に席に座る前などでも、少し小話で面接官を笑わせるくらいの気持ちで行く方がいいようです。

やはり、一緒に働く人はコミュニケーションに華がある人の方がいいですからね。

しかしやはりそこはエンジニア。やはり反応が薄かったり、コミュニケーションが苦手そうな面接官も中にはいるようなので、臨機応変に話の内容を変えて行く必要がありそうです。

 

まとめ

やはり、多少留学経験はあれど、労働経験はないのでこういった実際に働くといったことになると、無知なことも多く、非常に参考になることも多かったです。

特にエンジニアに特化したというところは大きく、

日本人でもエンジニアとして海外で働くことに対するモチベーションは上がったように思います。

 

この記事では触れていない、実際に面接で問われる技術的質問であったり、より細かいレイオフの話、面接の流れなど、一読の価値はあると思います。

 

もっと世界へ繋がる道を自分で見出していかないといけないなと実感しました。

エンジニアリング組織論への招待

エンジニアリング組織論への招待を読んだので、学びをまとめておこうと思います。

概要

前回の記事に引き続き、エンジニアという立場から見た、マネージングや組織論というところで基礎を作るためにまずはがむしゃらなインプットをしようということで相談したところ、当書を紹介していただいたので読み始めたのがスタートでした。

300ページもの本でボリュームもあり読み応えがある本でした。 今回は、全くの無知という訳ではなく、前回の本であるエンジニアリングマネージャーのしごとを読んでいた事もあり、多少被る知識の部分があったということで、読みやすい部分もあれば、アジャイル開発、スクラムなど体制の話も盛り込まれていた事もあり、少し調べながら読む必要がある部分もあったので、良い負荷がかかったインプットができたと思います。

1回読んだだけでは噛み砕けていない部分もあるので、期間を空けてもう1回軽く通しで読んでみるなどをしてみようかと思います。

当書を通して得る概念

エンジニアリングとは、「不確実性を解消すること」です。

不確実性というのは、抽象度の高い事柄であり、人が不安に感じる根源のこと。 不安に感じる要因としては、未知のものに対して無意識にでも恐怖を感じるという人間の本能からきており、「避けたいもの」という認識が働く事柄。

この不確実性が高い状態のことをエントロピーが高い状態と言います。 逆に少しでも不確実性が低くなると、エントロピーが低い状態に近づくという感じです。

このエントロピーを下げていく工程をエンジニアリングと言い、そのための手法が全体を通していろんな観点から、いろんな手法が書かれています。

構成

1~4章では、5章に向かって下地を固めていくという構成になっています。

1章では、全ての前提の知識となる事柄に触れ 2章で相手との対話について触れ 3章ではチームでの取り組みについての手法や歴史について触れ 4章ではその手法を使ってチームへの作用の解説 という構成になっています。

5章で組織という大きな枠組みの中でどのような問題が存在していて、どのように不確実性の解消をしていくのかを紹介しています。

用語ピックアップ

経験主義と仮説主義

不確実性という問題を解決をするためには、思考のリファクタリングが必要です。 その手法として以下のものがあります。

経験主義

情報を得るために、行動を起こしてその結果から問題解決に向かう手法

仮説主義

問題に対して、少ない情報から全体像を想定し、その像を確認するで問題解決に向かう手法

4つのイドラ

https://studyhacker.net/columns/omoikomi-dasshutsu

認知の歪み

ネガティブな感情により生まれる思考 以下のような、個々人の持つ印象や感情による歪曲された認知

ゼロイチ思考

「常に」「全部」「決して」といった断定的な思い込み 中間にあるグラデーションを認識できない思考

一般化

小さい事例をあたかも全体の事例のように認識し 一般化させてしまうことにより、大きな問題へと発展させてしまう思考

これはレッテル貼りへ発展し、一般化させた結果 当てはまる人はこうであるに違いないといった決めつけが発生する。 こういったところから認知の歪みが発生する。

すべき思考

Should構文で考えてしまう思考。 〜すべき、〜であるべき などの固定観念から自分自身を追い詰めてしまう思考。

選択的注目

朝の占いなどで、ラッキーカラーを知った時にその色のものがよく目に入る現象のネガティブバージョン。 人に対して、一度ネガティブな印象を持つと、その人が何をしてもネガティブに捉えてしまうという認識。

結論の飛躍

例えば、既読スルーするつもりがなかった相手に対して、 ネガティブな思い込みをすることによって発生する認知の歪み。

環境不確実性

行動と観察に生じる不確実性の種類 「未来」という不確実性からくる不安が生まれる。 未来が近づき、現実に近づくにつれて確実なものへと変化していく。

通信不確実性

コミュニケーションに生じる不確実性の種類 「他人」という、自分がコントロールできないものに対する不確実性。 自分が伝えたことを100%認識してもらう事は不可能であると同時に、 どれくらいの理解度なのかを押し測る事も不可能であることから不安が生じる。

不安への対処法

不確実なところから、不安な事柄へと発展します。 そして人には、不安なものへの恐怖がありそれを避ける傾向があります。 これをタスクベースで落とし込むと、不確実性の高いタスクに対して恐怖を感じることになります。 結果として、確実性の高いタスクを優先的に行おうとしてしまう傾向が現れます。 これによって不確実性なタスクが最後に残り、スケジュールギリギリになって不確実なものが残り、見積りとズレてしまうという事象が発生してしまいます。

この現象を回避するために、不確実性の高いタスクを優先的に行うことでエントロピーを高めることで不安を解消するようにするのが良いです。

アジャイル

ここで、アジャイルウォーターフォールの話が出てきます。 ソフトウェアの開発ではよくウォーターフォール開発があげられますが、アジャイル開発での成功確率の方が高いそうです。

プロジェクト初期に関しては、まだエントロピーがかなり高い状態で始まります。 その状態でプロジェクトを最後まで構想し作り始め、最後の最後に結局顧客のニーズと異なるものができてしまったという事例が多くなってしまうのがウォーターフォールでの開発。

対して、アジャイルであれば、マーケットフィットを模索しながらになるため、小まめの調整を行う事が多いことから、大きく失敗するということをなくし、コストを最小限に抑えることができるという点でアジャイルの方が成功率が高いということになります。

プロジェクトマネジメントとプロダクトマネジメント

まず、マネジメントの言葉の定義として 対象となるものの資源・資産・リスクを管理し、効果を最大化する とあります。

プロジェクトマネジメントに当てはめると 「対象となるプロジェクトの資源・資産・リスクを管理し、効果を最大化する」 プロダクトマネジメントだと 「対象となるプロダクトの資源・資産・リスクを管理し、効果を最大化する」 となります。

プロジェクトは、はじめと終わりがあり、終わりに向けて取り組むのに対し プロダクトは、はじめはあれど終わらないようにすることが目的となってきます。 その点で、不安となる要素が変わってきます。

ウォーターフォールアジャイル

上記によって、ウォーターフォールが悪というような形になってしまっていましたがそういう訳ではないです。 どちらが良いというにはまず、この二つを比べるために、この二つが同等の性質のものとして捉える必要があります。 そうすると、この二つの不安要素である不確実性のスコープを見比べる必要があります。

ウォーターフォールで生み出される不確実性 - 方法不確実性 - 目的不確実性 アジャイルなチームで生み出される不確実性 - 方法不確実性 - 通信不確実性 - 目的不確実性

上記の通り、アジャイルが持つ不確実性は、ウォーターフォールが持つ不確実性のスコープを包含しています。 それぞれが不確実性の解消の目的が異なるため(プロジェクトとプロダクト)、比べられるものではないのです。 具体的に落とし込むと、「何を作るか考える人」と「どう作るか考える人」との対立が発生してしまうのです。 それによって引き起こされる認知の歪みにより、通信不確実が方法不確実へ発展してしまうことがありえます。

組織化

セルフマスタリー

まず、チームとして理想の形態というのは各々が「セルフマスタリー」状態になることです。 つまり、自分で目標に向かって行動できているという確信が持てていることになります。 未来の自分が今の自分をメンタリングしているような状態になることが良い状態になります。 将来の目標がハッキリしていて、すでに道筋が見えていて、そこに向かって行動している状態ですね。

SECIモデル

Socialization(共同化) Externalization(表出化) Combination(連結化) Internalization(内面化) の構成から成るモデル。

問題意識への暗黙知から形式知への浸透が広まっていくモデル。 明文化されていない知識を「暗黙知」といいます。 逆に明文化されている知識を「形式知」といいます。 この暗黙知と広めていくことが組織の発展に繋がります。

例えば、自分達が見落としがちな問題に対して、 見落とさないようなルールを作って実践していく中で、メンバーの中での暗黙のルールとなる。 そうしているうちにルールにしなくとも、組織内で同じ問題に対する対応の意識というのが浸透することで、 また新たな問題へ目を向けられるようになるといった好循環を作る事ができるのである。

自分のチームでもこれは実践していて、定期的にエラー通知の結果をチーム全員で確認し、対応をどうするかと言った話し合いをし形骸化しがちな問題に対して意識を向けるという流れができて、組織全体へと広まっていくというような循環を作っていっています。

しかし、これには時間もかかるし、根気のいることなので実施するにはそれなりの覚悟が必要なので 効果が出るまで粘り強く広めていく必要がありそうです。

技術負債

技術的負債がないプロダクトは存在しないと言われるほど、プロダクト開発にはつきもので これに対処するには、経営層と非経営層とでの情報の非対称性が存在する。

これについても、負債についての可視化と、工数やコストといった観点で不確実性を解消する必要がある。 可視化については、ソースコードの複雑性の証明(if分岐の数など)、コードの依存関係の証明、バージョン管理などによる誰がいつどこを触ったかなどの証跡などの証明によって可視化する事で経営層への認識を伝えることへの助けになります。

さらに、お互いの認識を共通のものにするために「ユビキタス言語」を作成したり、経営層がどういう戦略を考えているかの透明化をすることで、それをアーキテクチャに当てはめるという逆コンウェイ作戦といった手法を取る事を検討できます。

また、ビジネスフェーズに合わせて、アーキテクチャの再設計(モノシリックからAPI化であったり、マイクロサービス化といった)を行うことで、いかにしてコストを減らすための技術負債を少なくするかといった戦略を考えていくこともできます。

まとめ

当書を通して、かなり自分の中で組織やマネジメントという面の知識の糧になったと思います。 他にも - アジャイルの誤解 - アジャイル経営学に取り込まれていた時の歴史 - スクラムによるタスク管理と計測 - 認知の歪み、通信不確実性に対する対処法 などなど、非常に参考になる事柄が多く書かれており、また他の本を読んで知識や実践を通した上で、もう一度読みたい本だと思いました。

今、恐らく組織論という不確実性を抱えている自分のような人がターゲットになっているような本だと思うので、同じような境遇な人は是非一度手に取ってみて欲しいです。

エンジニアリングマネージャーの仕事

エンジニアリングマネージャー(以降、EM)のしごとを読んだので、総括していこうと思います。

経緯

エンジニアとして仕事をするにあたって、 EMの仕事を知っておくことで相互作用を起こすような働きができたらと思ったところが始まりでした。

現在自分はEMではなく、EMとしての知識はほぼ0なので、知識だけでも少し詰め込まねばというところでググったところ ドンピシャなタイトルのこの本が出てきたので読み始めました。

どうせ読むならメモ代わりに、自分が参考になりそうなところを書いていこうと思ったのでピックアップして記事を書くことにしました。

読んでみて

感覚的に分かっていた事は言語化されていて、 半信半疑だったものは明確になりました。

自分は全然知識がなかったので どういったことをマネージャーが行うのか どういう考え方が必要なのか などが断片的なものでしか見聞きしていなかったので 知っているものも含めて体系的に知る事ができたのは良かったと思います。

教育や独学で学んできたエンジニアリングと違って、EMは事前の学習などがない状態で就任する人が多いです。

何をしたらいいのか、どんな問題が待ち構えているのか、どのように解決していくのかというのが未知の状態で進むことが多く、 この本で事前にある程度事前学習できたら、少しでもそのキャリアを諦めないように進めるような道標が詰め込まれている本になっています。

ただ、マネージャーとしてすでに経験のある人にとっては既知の情報が多いかと思うので、あくまでこれから就任すると言う人や、就任直後の人向けの内容になっているのではないかなと思います。

要所ポイント

マネージャーのアウトプット

本書の中で一貫して使われる言葉です。

マネージャーのアウトプット = 自分のチームのアウトプット + 自分が影響を与えた他のチームのアウトプット

1on1

マネージャー就任時にまずやらないといけないこと、かつ継続して行っていく必要のある最重要事項です。 何より情報が必要な仕事であるため、1on1から情報を集めていく必要があります。 情報というのは

  • チームメンバーの考えや感情、性格
  • プロジェクトの進行状況、ボトルネックとなっている部分、プロジェクトの文化
  • 上司が持つ「組織の中での自分の役割」

こうした情報を週に1度、1on1を設定し、通して集めていき、適用していくことが理想となります。 就任直後や、入社直後のマネージャーはプロジェクトの状態が全く頭にない状態でスタートするため、情報収集のため、この辺りから始めるのが良いです。

上司との1on1

上司との1on1では、上司から言われる前の行動によって、より成長の機会を増やすことに繋がります。 - 組織内で1階層上がったレベルでの懸念事項について話す - 他のチームへの状況の確認ができ、アドバイスをする機会を得ることで、上司を助けることができる - 自分の興味が現在の業務の範囲外にもあるということを伝える などなどができます。

自分の状況、関心を伝える上で、週次の1on1の前に30分程度サマリーを作成する時間を設けるのは良い方法です。 その中に、(前回からの)進捗、問題、問題へのアプローチ、メンバーの状況を書き連ねておくのが良いです。 終わったら上司に送るなどをしておくと良いです。

ナッジング

EMとしての自分の観点を提供することで決定に影響を与えること。 意思決定を下すわけではなくても、決定に影響を与えることができるため、 自由に意見ができる時はその事を念頭に置いておく必要があります。

委譲

タスクの責任を他人に委譲することを指します。 委譲には、アンチパターンが2つあります。 - 委譲できてないパターン - 丸投げパターン

委譲できていないパターン

優秀なエンジニアからEMになった時になりがちなパターン。 自分がやった方が早いであったり、精度を高められるという点から、重要な部分は自分でやってしまうという状況。 これにより、中途半端な委譲によって仕事の品質が下がりイライラしたり、メンバーも信頼されていないと感じることに繋がります。 イライラしたからといって、スタッフに委譲したタスクを取り戻すようなことをする事も良くないことです。

丸投げパターン

逆に、委譲し切ってしまい、タスクの存在すら忘れてしまうパターン。 これによって、タスクの状況も忘れられ、品質の管理もされないため、品質が保証されず期限も守られないということになり、お互いに良くない状況に繋がります。

説明責任

上記のような極端なパターンがアンチパターンになるため、バランスを取る必要があります。 そこで出てくるのが説明責任になります。 説明責任とは、タスクを求められる品質で完了させる責任を持つということ。 EMとしては、この説明責任を持ち続ける事が理想となります。

対となる言葉に、実行責任があります。 タスクを実際に自分で行うことです。 実行責任は、スタッフに委ねられるものになり、スタッフにとってチャレンジングなくらい委譲されるものであるべきです。 そうすることで、スタッフも挑戦し、成長することで、一緒に成し遂げられるようになります。

欲求の階層

上昇思考の強い人は今の仕事をより良くしようと思っています。 エンジニアのスタッフの人たちもそのように感じることが多いです。 その人たちにEMの立場からできることとして、マズローの欲求階層に当てはめて考えることができます。

  • 生理的欲求: 自分がしたことへの適性な給与が欲しい

  • 安全欲求: 安定安全な労働環境が欲しい

  • 所属の欲求: チームや上司といい関係を築きたい

    • EMができること: ・自分とスタッフと組織をうまくつなぎ、チームが大きな何かの一部であると感じられるようにする。
  • 承認欲求: 自分がしたことへの評価を公式・非公式双方でしてもらいたい

    • EMができること: ・賞賛と批判を通して、確実に評価する。 ・スタッフのレベルに合わせて職位と責任を持たせる ・スタッフが自信を深め能力向上できるように指導と誘導
  • 自己実現欲求: 継続的にスキルの向上のため挑戦していきたい。次のキャリアがあるというのを実感したい。

    • EMができること: ・トレーニングやカンファレンスへの参加を通して、新しいスキルを学ぶための機会の提供 ・スタッフが選ぶ方法で問題解決への自由を与える

最近接領域

学習者が「好奇心」に任せて上達することができるのが理想の形になります。 最近接領域とは、タスクの難易度の一つの領域を意味するもので、以下の三つの領域に分けられます。 - 学習者が支援なしにできるタスク - 学習者が支援ありでできるタスク (ここが最近接領域) - 学習者が支援ありでもできないタスク

この最近接領域のタスクを行うためには 「タスクの完成を支援する豊富な知識を有する適任者」 の存在が必要です。

タスクレベルで言うと、難易度の高いものに対してはペアプロなどを通してやってみるのもオススメされています。 これによって、ジュニアな人はプログラミングスキルが向上し、シニアな人はメンタリングのスキルが向上します。

キャリアレベルで言うと、自分の目指す最終ゴールに対して、いきなりそこに向かうのではなく、ステップ形式でサブゴールを決めて、順序に沿ってレベルアップしようという考えを取り入れます。

例えば 「国際的なカンファレンスで話す」という目標に対し -> そのレベルで講演するのに必要な話すスキル -> 国際的なカンファレンスで興味を引けるプロジェクトに取り組む といったゴールを用意し、最終的な国際的なカンファレンスで話すことを実現するということです。

大聖堂とバザール

このモデルのイメージに近いものは、トップダウンボトムアップに近しいものを想像してもらうのが良いかと思います。

個人レベル

大聖堂モデルとバザールモデルは個人レベルでも当然当てはまる考え方で 大聖堂モデルのような考えの人もいれば、バザールモデルのような考えの人もいます。 ただ、そこに良いも悪いもなく、個々人の考え方によって、マネージャーとして適切な委譲、与える機会、働く環境を考える必要があります。

大聖堂

プロジェクトの保守管理は、長いプロジェクトになればなるほど、初期に関わっていたメンバーやコアなメンバーによって意思決定が行われ、他の意見などの雑音を少ない状態で、しっかりと管理されているような状態です。

エキスパート気質なところが多く、深く学ぶことを得意とし、深く学ぶまで新しいものに手を出さないようなタイプです。 自分がエキスパートとなった領域を他の人に伝えることで恩恵をもたらし、楽しみます。

バザール

プロジェクトの保守管理は変化が起こるものとして捉え、その中でバグが出たとしても多くのコントリビュータによって、即座に対応できるという考えの元、管理する状態。その方がメンバーのモチベーションも高まるとされている。

多くの新しいものを試したがります。それに伴って、プロトタイプなども構築しては捨てるというような試行を繰り返すことが好きなタイプです。大聖堂モデルとは違って、変化を好むタイプなので、長期に渡るプロジェクトというよりは定期的に考えが異なるようなプロジェクトへの機会を持たせるのが良いです。

機密情報

当然ですが、情報の共有には非常に慎重になる必要があります。 1on1を通して話したこと、たまたま立ち会った立ち話で聞こえてきた話、組織の決定について 全てにおいて誰にどのタイミングで伝えるか、もしくは伝えない方がいいのかといったことについては細心の注意が必要になります。

これも三つの領域に分けて考えると分かりやすいです。 - 完全機密: 1on1などの関係ある特定の人以外には知られてはいけない情報。 - 密閉箱: 存在は知っているが、詳細は知るべきではないこと。(例えば、給与テーブルなどは誰もが知っているが、個人の給与については知られてはいけない) - 解放箱: みんなに知られるべき、知られても良い情報

PIP

この概念は、日本にはないものだったので少し衝撃的だったため書こうと思いました。 人が去っていくことは、避けられないことであり、受け入れるしかないことではあるのですが それにも2つの原因があります。 - 自発的な離職 - 不本意な離職

になります。 前者は説明がなくても理解はできるかもしれないですが、後者については日本においてあまり意識しないこともあり、想像し難いものかもしれないです。 PIPは、Performance Improve Plan の略で、不本意な離職の際に行われるものです。

パフォーマンスの悪いスタッフに対して、改善提案を行い、改善が見られなかった場合に解雇や契約解除ということにすることを意味します。 しかし、これは最終手段なので、あらゆる他の手段で改善を試みて、改善が見られなかった場合に行われるものになります。

PIPを行うにもいくつか注意を払う必要があります。 PIPの内容では、その人がなぜPIPの対象になってしまったか、いつまでPIP期間となるかなどが記載されるのは当然ですが、どうなったら改善されたかということの記載と、その改善はその人にとって無理難題なものではないことが明確になっていることが重要になります。

まとめ

自分にとって特に重要そうな箇所についてピックアップしてメモとして書いたものですが それ以外にも参考になる内容が多く、入門としても良い本だと思いました。

将来EMとしての道に進むかどうかは別として考え方を知っておくのは 誰にとっても損にはならないと思うので、時間に余裕があって考え方に幅を広げたいと思う方は読んでみても良いかと思います。