僕は外的自己認識高めだと思う
読んだ本
insight(インサイト)――いまの自分を正しく知り、仕事と人生を劇的に変える自己認識の力
- 作者:ターシャ・ユーリック
- 出版社/メーカー: 英治出版
- 発売日: 2019/06/26
- メディア: 単行本
感想
自己認識の話
自己認識とはなんでしょう？内的自己認識とは自分自身を明確に理解する力、外的自己認識とは周りが自分をどうみているかを知る力とこの本には書いてある。そもそも僕らは自分を認識することをあまりやってこなかったのではないだろうか？認識しなきゃいけないの？っていう人すらいるように思う。普段自分の身に起こったことや自分が起こしたことに対して考えたりするが、自分について考えることは非常難しい。いや、考えることは簡単だが、明確に理解することは極めて困難に思う。その方法やそういったエピソードをふんだんに盛り込んで説明してくれる本だった。
なぜから何の話
本書の中で、「なぜ 」という問いは基本的に自分の周りを理解する際に役立ち 、 「何 」という問いは基本的に自分を理解する際に役立つ、とあった。これにはとても大きな衝撃を受けた。僕は本質を追求して原因を特定し対処する、というのが当たり前だったからだ。その対象が自分であっても。幸いにも僕の性格的に抱え込むような性格ではないのでなぜを繰り返しても本書にあったような被害者意識にはならない。しかしこの言葉は、自分自身が嫌になってしまうような人たちの助けになる言葉なんじゃないかと思った。自分自身は何をしてきたか、何をしたのか、何をしたいのかを考えるのはなぜを考えるより簡単で、行動に則していればそれが根拠となり、揺るぎない自分自身の理解になりそうだ。
反芻の話
よく何かをしでかした時に、あーなんでこんなこと言ってしまったんだろう、みたいな思考が常に付き纏う時がある。これを反芻と言い、この考えが堂々巡りしてずっと抜け出せないという成長する観点からは非常に無駄なことがたまに起きる。これは自分のことを考えているが自己認識には繋がらないということが説明されていた。つまり反芻が起きたらさっさとその考えをやめなければならないということだ。「たいてい周りは 、こちらのミスについてこちらが思っているほど気にしていないのだと思い出すこと」と書かれていたが本当にこれに尽きるように思った。反芻が起きることを理解し、反芻することはほとんど意味をなさないことを理解し、さっさと振り払う。これはすぐに出来そうな行動なので是非ともやってみてほしい。僕はこれを知ってから1週間たったが一度振り払ったことがあるが、非常にすっきりする。
僕は外的自己認識高めだと思う
上記を読めばタイトルにも書いたこの文の意味が理解できるようになっているのではないだろうか。僕は周りからの見られた方を気にするタイプだ。特に仕事上でそう感じる。エンジニアとしてコードを他人に見せる時にもよく推敲してから見せるようにしてるなぁとこの本を読んで思った。それは僕が書いたコードという僕の一部を見てもらうような感覚であって、これを見て他人がどう思うかをすごく気にする。コードの意図が伝わる書き方か、フォーマットが整ってるか、些細なミスをしてないか。僕にとっては信用問題に繋がるような気がしてならず、その点で外的自己認識が高いんじゃないかと考えている。
さいごに
自己認識力を高めて日々の成長に繋げたいという思いでこの本を読んだ結果、見事に普段考えなかった視点と成長のための道具を手に入れたように思う。自己認識なんて考えたことなかったっていう人からもっと学びを深めたいという方までオススメできる本だった。
失敗の本質を読破したった
本の紹介
大東亜戦争における日本軍の敗戦を取り上げ、その失敗にはどんな原因があったのか、それは本質的には何がダメなのかを解説するという本。非常に面白いアプローチであり、結果的に近代的な日本の企業においても転用されている日本軍の考え方が、このままで大丈夫なのかを問うというもの。
なぜ手に取ったのか
僕はソフトウェアエンジニアであるがフリーで仕事を請けているのではなく、一つの企業に属して仕事をしている。この企業がかなり大規模で○千人が所属する企業の一人なのだが、それと同じような規模のグループ会社も数社存在している。そして兼務していたりミラー組織として横に展開するような関係を持っている。かなり大きな組織に属している身として、組織における失敗とはなんなのか、アンチパターンは何かということが気になった。
本の感想
内容の感想とは違うが、まず最初に思うのが個人的には本を読むのに一苦労したというのが大きい。最後はやっと読み終えた〜という感じであった。なぜかというと、本自体が少し古いこともあって現代人の読みやすさには合っていないのと、取り扱う内容が戦争ということで少し難しい漢字が出てきたり、理解が難しい内容があったりしたためだったと思う。が、全然読めないわけではなく、ただ単に読み終えた時の達成感が今までの本と違って大きかったということである。
本書の中では失敗の本質は多く上がっていたが僕が気になったのは3つ。
- 目的が曖昧で多義性がある
- 戦略策定が帰納的
- 人的評価がプロセスとやる気
これらのことは日本軍や大企業のような大きな組織に言えることばかりではなく、一つの事業やその中のプロジェクトチーム、はたまた個人にまで同じことが言えることだろうと思っている。
失敗①：目的が曖昧で多義性がある
企業は将来のビジョンを掲げ、プロジェクトチームにはミッションがあり、個人には達成するべきタスクが存在している。しかしこれら大から小までの組織の目的が曖昧であれば、その下に属する組織の目的がズレ、向かうべき方向がわからなくなりまとまりがなくなって、戦争であれば負け、プロジェクトであればミッション未達成となってしまう。
失敗②：戦略策定が帰納的
帰納的の対義語として演繹的という言葉がある。僕はこの2つがなかなか頭に入ってこなかったので、帰納的を場当たり的、演繹的を軸を持っている、という風に読み替えて読んでいた。何か戦略を決めるときに、何かの軸を持ってその軸に沿った戦略を策定するべきところを、軸が持たないせいでその場しのぎの、場当たり的な戦略策定になってしまったというのが失敗になる。これは失敗①の目的が曖昧というところからも繋がってきている。個人としても何かを決める際には何を持って決めるかの軸がなければ決められなく、とりあえず場当たり的に決めて進んだところで失敗するような気しかしないので、まさにこれはアンチパターンの一つだと思うし、それを確かめられた。
失敗③：人的評価がプロセスとやる気
これは社会人になってから先輩によく言われたことだった。僕は高校の時スポーツをしていたが、スポーツで勝つことはもちろん大切だが、それに至るまでの努力ややる気を評価してもらって試合に出させてもらえていたような感覚もあった。そのため社会人になってからも努力ややる気を見せていたが、それだけではダメで結果を出さなければならない、と教え込まれた。努力ややる気ももちろん必要だが、最終的には結果にコミットしなければ組織が前に進んだとは言えないので当然のように、今は思える。
まとめ
日本軍の失敗を糧に組織が成功するために、少ない記録から戦争で起きたことを詳細に洗い出し、そこから分析を行ってこの本を書いてくれた著者に感謝を言いたい。多くの失敗はアンチパターンとして社会や組織に根付いているように思えたが、日本軍がそうだったように失敗したくて失敗しているわけではなく、日本人として文化や性格的に失敗の本質に向かいやすいという性質を知って、組織を動かしていきたいと感じた。
1兆ドルコーチを読破した
本の紹介
1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え
- 作者:エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2019/11/14
- メディア: 単行本
本の内容
シリコンバレーの名だたる企業でコーチを務めた一人の男の話。読者へのアドバイスや心構えを考えさせるようなエピソードがたくさん盛り込まれていて、ひとつひとつ言いたいことがはっきり伝わるように工夫されていました。
なぜ手にとったか
この11月に転職をして新たなチームにジョインしたこともあり、今一度チームの正しいあり方やどうすれば素早く会社に貢献できるのかを考えたかったためです。また、いままで見てきたグループの規模を遥かに超えるところに入ったことで、グループ内のチームをまとめていくことが必要になるであろうと考えたことと店頭にでかでかと宣伝されていて気になって手に取りました。
本の感想
チームへの貢献を一番に考えること、これがこの本を読んだことで得た学びでした。この言葉自体はよくある言葉だと思います。例えば、チームワークを大切にしようとか2019年の流行語大賞にも選ばれたONE TEAMもそれに似た言葉です。しかし昔からよく言われてきたこういう言葉が形骸化されて実際にはちゃんと身に染みていなかったんだということに気づかされました。
本の中で、「マネージャーの最優先課題は部下のしあわせと成功だ」「辞める人を手厚く扱うことは会社に残るチームの士気と精神的安定を保つためにも大切だ」「人に求めるべき最も重要な資質は〜すばやく学習する能力と厳しい仕事を厭わない姿勢、誠実さ、グリット、共感力、そしてチーム・ファーストの姿勢である」と言っています。チームを見守るマネージャーの立場、チームを率いるリーダーの立場、チーム内で実際に実行するメンバーの立場、この3つの立場でチームに対して貢献する方法と心構えをアドバイスしているのです。どの立場の人が読んでも、チームへ貢献することが一番大切だということに気付くと思います。
さいごに
この本を読む前は、転職して早く認めてもらえるように会社に貢献しなければという気持ちが強かったです。これ自体悪いことではないですが、チームとして成功しようという気持ちではなく、個人で成果をあげようという気持ちのほうが大きかったように思います。この本を読んで、まずは僕がチームに出来ることを精一杯やるべきだと感じました。
リクルートのすごい構創力を読破したった
リボンモデル
非常に有名だけどなんかちゃんと理解してなかったのかもって思った。カスタマーとクライアントの不を発見してそれを結びつける。便利なものを作って世に出したいと思う僕は便利なもの便利なものって思ってたけど、そうじゃなくて、何かしらの不を見つけて解決しなきゃいけないんだって気付かされた。リボンモデルはプロダクトだけの話じゃなくて、例えば一つ一つの小さい機能もそうだし、逆に国と国みたいな大きなものでも当てはめられるんじゃないかって思う。
価値KPI
どの指標を上げれば企業価値が上がることにつながるのかのカギとなる指標のこと。これの発見にめちゃくちゃな時間をかけてる。ただの数値分析だけじゃなくて、行動に移しテストして分析している。これが新鮮だった。今までKPIはMAUかDAUか入会率かとかだった。でもそれだけじゃない勝ち筋を見つけにいく、そしてそれに向かってみんなが動いていく。「購入に効いているのは最後のステップだと考えて、その指標だけを見てしまう」という典型的な間違いを指摘していたけどよーくわかった。
お前はどうしたい？
日々の追求にうんざりするんじゃないのかとか思ってたけど、そんなことはないように思うし、逆にこうだからこうしたいって考えて自分の意見を話してみたりできて、かつそういうプロセスを踏むことで圧倒的な当事者意識ができていくように思えた。そしてこうだからこうしたいって言ってそれを認めてもらえた時の嬉しさはきっと大きくあるんだろうなと思う。これは人によって合う合わないがあるような気がするし合わない人はリクルートにはいないんだろうなとも思う。
おわりに
リクルートって超巨大企業だし人多過ぎなんだけど、だからこそ仕組みが整っていて新規参画者でもはやく成果出せるように共有する仕組みがあってそうやって個人が成長していって、また仕組みやノウハウがアップデートされて残されてという良いサイクルが出来上がってるんだって思った。そしてまだまだテック企業とは言えないので営業が強い会社でテックもイケてるって思われるようになりたいなーと思う。そんな会社世界のどこにもないと思うから。
Designship2019に行ったら将来を考えさせられた
考えさせられたって書いたけど、キャリアを考えるきっかけをもらったという意味です。
バックキャスティング思考
このワードがなんどもなんども出てきたけど初めて聞いた。50年後の未来を予測してどうなっているか、どうなっていてほしいかを考える。じゃあ25年後の時点でどうなってなきゃいけないよね、10年後にはどうなってなきゃいけないよね、じゃあ来年はこうなっていよう、みたいな未来からの逆算で考えること、だって認識した。面白い考え方。これは自分自身のキャリアにも当てはめることができるし、今担当しているプロダクトにも当てはめることができる。今担当しているプロダクトだったらその将来をみんなで共有することが大事そう。じゃないと将来像が違っていたら来年に向けてやることも違ったりするから。価値KPIがあればズレないって思うかもしれないけど、その先の目線を合わせておくのも大事だし、それもデザインに含まれる。目に見えるものには全てデザインが入っているっていう話を聞いたけど本当その通りだなって思った。
レゴ マインドストーム
こんなのあったんだー。面白そうだし子供も興味持ちそうだから息子と一緒にやるのいいかもしれない。父親である僕が一番ハマってしまいそうだけど。
BTC人材（Business Technology Creativity）
三角形を描いてどこに向かっていくかで違う領域へ越境していこうという話。僕はエンジニアなのでTechnology、TC型、TB型になっていくのが良い。まずは5年くらいやって一つの領域のプロになるのがいい。Technologyの中もそれぞれ、Creativityの中でもそれぞれ、色々な領域がある。例えばUXエンジニアはその中の一つでCreativityの中にはUI,UX,アート,音楽などがあって、Technologyの中にはソフト,ハード,組み込みなどがある。その中から一つずつ何かを極めていくとUXエンジニアになっていく、みたいな。あーわかりやすいなーって思う。会社に必要な人材は事業のステージによって必要になる組み合わせが違うのかなーと思った。別に会社に合わせていくつもりはないけど、ここは深く考えたい、キャリアの築き方がわかったような気がする。非常に面白かった。
おわりに
デザインのカンファレンスなんだけど、スピーカーのテーマに物語が入ってたから僕にとってはキャリアを考えるイベントでもあって非常に良かった。スピーカーの活躍とそこに至るまでの物語（キャリア）をエンジニアに置き換えて捉えたり、そうなるための具体的なロードマップを引いている人もいたりしてめちゃくちゃ参考になった。また来年も行きたいです、運営ありがとうございました。
正しいものを正しくつくるを読破したった
要求、要件、仕様という構図
当たり前のことだけど整理しておく。
要求はユーザーやクライアントが満たしたいこと。満たしたいことが満たされるなら、どんな実現方法でもいい。
要件は要求を実現するための条件。ユーザーやクライアントが満たしたいことを実現するためになにをやらなければいけないかを示したもの。
仕様は要件を満たすための詳細な条件。実際にプログラムに落とし込む際にどう実装すれば良いかに大きく関わってくる。
ここの区別がいままでは自分の中でつけられていなかった。いや正しくは、付けられていたけど思考上で構造化できていなかったので、区別できていなかった。
いままでの業務は要求と要件は暗黙的に認識していた。言語化して共有されることは少なく、なんとなく感じていた要求と要件を理解して仕様を考えたりしていた。
プロダクトバックログには要求を書くのか、要件、仕様を書くのか。仕様を書くことはほぼないにせよ、要求か要件、どちらを記載するものなのかをはっきりさせておかないと混乱を招くことになりそうだとも思う。
ゴールデンサークル
Why、How、Whatを中心から外に向かって考えるもの。知らなかった。よく言われてるとおり、HowとWhatだけ考えていてWhyは抜けがちになる。なぜなぜ質問みたいなのが本当のWhyを考えるためのものなのかな。○○で△△したい！みたいなことはよく思う。SwiftでiOSアプリをつくりたい！みたいな。Why？ってことですね。エンジニアは結構Howから考える人多いんじゃないだろうか。
守破離
まずは型通り守って物事を進める。慣れたらそれを破ってみて型の外側へ。そしてそれが型から離れていく。いきなりいろいろ工夫して始めるんじゃなくてまずは型通りやってみようよってこと。経験としてはVIPERというiOSアプリのアーキテクチャを採用したときに必要そうなクラスを追加して進めてたが途中でいらないと気づいたことがあった。守破離るべきだった。
QCDS
QCDは知ってたけどSって？って感じ。Scopeだった。この4つでトレードオフにはならないかな？なにかを構造化するときに使えるかも。てかこの構造化の大切さっていうのは現職に入って初めて気づいたしメンバーも結構それを悩みながら進めてる感じだった。ここらへんの知識はもう少しつけておきたい。
情報と知識は違う
この本で一番ハッとさせられたところがこれ。なにかをインプットしても情報として処理されるか、知識として定着するかってすごい違い。情熱を捧げられるものや直近で必要になるものに対してインプットするべきだと思った。
同調圧力、確証バイアス
同調圧力は少数派を暗黙的に多数派に引き合わせること。確証バイアスは自分が信じることを検証するときにプラスなことばかり集めてマイナスなことは無視してしまうこと。この事象があるってことを意識しておかないと絶対これになるわ。とくに確証バイアス。僕は結構掛けてしまう傾向ある。でも今回それを意識できたことは大きい。
終わりに
ワードで拾ったので「正しいものを正しくつくる」の本の感想でもなんでもないけど、これは実際にアジャイル開発してるなかで課題が見えたときに読まないと身にならないと思った。知識ではなく情報として捉えてるので。でも拠り所を見つけたという意味では良い本に出会えた。
SwiftcKaigi #1 に行ってきた
swiftc、つまりSwift Compilerの勉強会に行ってきました。
Swiftを書いている身としてはやはりSwiftがどうやってコンパイルされて動いているのかは気になるわけです。毎日コンパイルしているので。
ABI安定化
Logger.swiftとmain.swiftを使ってABI互換性を壊しながら知見を得ていこうという発表があった。@frozenのAttributeは見たことあったけど全く使い所がわからなかったのに今日出てきて、ABI互換性の話と繋がったらすんなり理解できた。要はこれはもうInterfaceは変わらないので凍結として扱ってもいいですよと宣言するという感じ。（実際にはメモリレイアウトがこれ以上変わらないよという宣言）@frozenしたのにプロパティを追加したりメソッドを生やしたりすると再コンパイルが必要になる。だからABI互換性があるとは言えない状況になっちゃう。でもiOSエンジニアからしたら基本的に外部フレームワークも含めて一度全部コンパイルしちゃうので別にいいじゃんっていう気持ちにもなった。
mangle / demangle
今日何度もこの言葉を聞いていたが、ちゃんと解説するスライドもあって非常に嬉しかった。mangleはswiftc上でモジュール名や型名、メソッド名、引数などをひとまとめにした名前にすること。swift demangle するとSwiftで読める形にすることができる。これが参考になった。
オブジェクトの参照カウンタ
これは初めてのiOSDCで聞いた内容だったので知っていたけど、久しぶりに聞いたのであぁそうだったなという感じ。オブジェクトはstrongの参照カウンタとweakの参照カウンタが存在していて、どちらも0になったときに初めて解放されるというもの。質問の中ではヒープ領域にはアドレスは残っていてオブジェクトにアクセスしたときに初めてnilを返すようにする仕組みだとか言っていたけど、あまりよくわからなかった。
vtable / witness_table
一昨年のiOSDCでよく聞いた話だったけど、実際にそれは何かっていうのは全然意味がわからないままになってた。今回はあるSwiftの事象を紐解く過程で出てきてなんとなく理解できた。言っていたことは理解できたけど、まあ勉強不足であまり腹落ちはしていない。まあでもクラスメソッド呼び出しかwitnessメソッド呼び出しかの違いで、インスタンスのメソッドなのか、プロトコルが持つメソッドなのかでdispatchの方法が違う、っていうくらいの理解でとりあえずいいかな〜と勝手に思っている。
SILOptimizerのPass
Passの作り方をデモをしながら教えてくれた人がいた。IntのオーバーフローはSILOptimizerで検知されている内容とかが結構興味深かった。自分で勝手にPass作ってオレオレ検査swiftcを作っちゃえばなんか面白ことができるんじゃないかとかも思ったりした。SILInstructionを読んでいくのが結構辛そうな感じだったけど。
わからないことだらけだったけどキーワードは拾えたし興味が出たら触ってみようという気持ちになった。この分野は目に見える形がわかりにくいので難しいなーと思った。swiftcを体系的にザーッと理解できるような本を1冊作って欲しいくらいな感じ。面白かったので2回目もあったら行きたい。
