2022年1月の振り返り
業務として、週次の振り返りは行っているんですが、自分が当時何を感じていたのか？ってまとめている場所って無いなと思ったので、月1で何をしたのか？何を感じていたのか？をまとめていければと思います。
業務で行っていたこと・感じたこと
オンプレの分析基盤をクラウド移行させる開発が本格スタート
少し前までオンプレ志向だった弊社ですが、クラウド化を進めてます
僕はCloud composerでのワークフローをメインで実装中
terraformも初めて利用してますが、完全に理解した状態を越え、馬鹿の山から転げ落ちてます。笑
上記プロジェクトで、GCP上の開発DBへデータを転送する、ということも初めて行ったりしました。
embulkとプラグインでサクッと対応する予定だったのですが、外部IPと内部IPの問題で少々躓いたりしました。
本当にインフラ回りの知識が足りない。
GCPのプロジェクト整理
データ基盤の3分類を例にすると、DWH、データマートが分散したりしている状態です。
たくさんある訳ではないですが他社事例を参考にチームで議論しつつ、ある程度の原理原則が定まった状態です。
いずれこれは社内のテックブログにもまとめたい。
参考にした資料がたくさんあるのですが、ここら辺
上記はデータレイク→DWH→データマートまでの棲み分けの話で、そもそもプロジェクトってどうやって分けるの？というのはあんまり載ってない。
公式もこの程度の回答に留まってます。
なので会社が成長してデータが増えていったときに、カオスにならない分析基盤って何だろう？ということを考えてました。
一般的な推奨事項は、環境ごと、アプリケーションごとに 1 つのプロジェクトを使用することです。
エンタープライズ企業のベスト プラクティス | ドキュメント | Google Cloud
プロジェクトの分割はGCPのIAMとも密接に絡むので、以下の資料もめちゃくちゃ参考になりました。
具体的には、ビジネスのスケール観点でどうやってセキュリティを管理するの？という話ですね。
かなり先に未来になるけど、セキュリティガードレールの発想があれば、別に僕らがIAMを管理しなくてもいいじゃん、というセキュリティとビジネススケールのトレードオフにならない環境は作れそうだな、というイメージにも繋がりました。
データガバナンス整備
ガバナンスの観点だとDMBOK等にいくつもの観点が並んでいるとは思います。
まずは簡単に実装できる鮮度の問題から取り組みました。
BQのメタデータを利用して、複数プロジェクト、全データセット配下のテーブルの更新時間を取得
スプレットシート側に記載、SLAとして期待する時間を記載
これらを紐づけて、更新が間に合っているどうか？の可視化を実施
slack通知とかはまだ実装できていないですが、来月中には社内に展開したい..
問い合わせ多すぎ問題の解消
社内のデータ周りのナレッジが俗人化している、という問題があります。
まあそもそも人が少ないのもありますが..
グループメンションをお願いしたりしてますが、結局答えるのは僕、という状況でした。
これを解消するために問い合わせが来たら特定チャンネルにスタンプ押して集約
→朝会でナレッジシェアして回答、ということを進めてます
多少時間は掛かりますが、俗人化の解消のためには必要な時間です
受け入れ準備・課題集約
2月から、新しく社員さんがチームに入社することになりました。
それに伴って何をお願いするのか、ということを把握するために、そもそもの課題を洗い出し。
マイルストーンとかはまだ決まってないので、課題管理表を元に何やってくか？のイメージは大体固まってるので、MGR陣と認識合わせから。
受け入れ自体は個人的に初めてなので、上手くやっていけるか不安に感じてる自分もいますが、やっていき精神で取り組んで行ければ。
プライベート面
親への結婚報告
去年の12月にプロポーズはしていたので、お互いの両親に報告をしてきました。
顔合わせは2月にする予定ですが、コロナがまた増えてきたのでまずはオンラインで、という感じで進めていく予定
雀豪になりました
昇段した瞬間の画像とか無いんですが、年末年始麻雀熱が再発して、ぼちぼち打ってました。
放銃マン。というふざけた名称でやってますが、割と守備よりの打ち手だと思ってます。というか放銃率的にもそうなってる。
アークナイツ2周年
じゃんたま経由(作ってる会社が同じ)で知ったんですが、タワーディフェンスが好きで唯一やってるソシャゲがアークナイツです。
新卒のときにはソシャゲの分析とかしてましたが、バランス調整がえげつないぐらい凄いなと感じてます。
(担当していたやつはインフレが割と凄くて、初期キャラは使えないことが多かった)
あと、海外で作られてるゲームなのも影響しているかもですが、比較的財布に易しめ
続けて買おうかなと思った漫画集
全然知られてない奴を発掘する、みたいなことは全然してないので割とメジャーなものをサンプル読んで面白いか？で判断してます。
最近アニメ化したらしいですが、行動力に溢れてるコスプレ好きのヒロインと、人形技師を目指す主人公のラブコメ。
職人に憧れてる主人公がコスプレ衣装を作っていく過程で視野が広がっていく世界とか良いなあと思って読んでます。
1つのことを極めようとする上で他の事をするのって回り道じゃない？というのは、若い頃の自分が結構感じていた価値観で。
人間性の充実というか、関係ないと思っていた経験が、回りまわって紐づいていくことの面白さを感じている過程を、過去の自分になぞってるのはあるかも
有名な作家さんと漫画家が組んでいる、というクチコミを見て何となくサンプル読んでみたやつですね。
エンジニアとして凄腕でまじめなガクと、わがままで口が回るハルが、二人で1兆ドルを稼ぐっていうサクセスストーリー。
もう日々の生活は割と現実的なことばっかり考えてるので、ハルが盤外の一手を決めるところは痺れます笑
その一手が突拍子がありすぎる訳じゃなくて、確かにこれだったら行けるかも？と感じさせてしまうところも凄い。
2月も頑張るぞー
データエンジニアとアナリストを両立するキャリアパスを考えてみる(エンジニア編)
はじめに
ちょうど最近、上司とキャリアパスの話をする機会がありました。
その中で、データエンジニアとアナリストのどっちの道に進むか迷っている、という話をさせてもらいました。
またデータエンジニアとして吹っ切る、という考え方もあるとは思っています。
ただ現時点では、アナリスト要素をキャリアに取り入れたい、と何となく考えてます。
そこで、データエンジニアとデータアナリストとしてのキャリアを成功させる？ためにどんな要素が自分に足りないのか？をメモ書きとして残していこうと思います。
もうちょっとスペック的なことを書いた方が良いかもですが、分かっていること・分かってないことを書けば自明になるかなと思って省略します
私自身のキャリアの変遷
これまでデータエンジニアとして2.5年ほど、その前はデータアナリストとして2年ほど勤めてきました。
データアナリストをしていた頃は、SESの形態で客先に常駐して勤務をしていたため、扱いたいデータを全て触ることができない
また分析基盤と呼ばれるものも無い状態だったので、自分で分析用のデータマートを作って、消して、作って・・・、ということを繰り返していました。
その過程を通して、自分で分析基盤を構築して、データ分析ができたら最強なんじゃね？みたいに社会人1年ちょい過ごしてから感じたわけです。
あとはSESは力がないと現場を選べず、一旦正社員として勤務してスキルを高めないとやっていけないなあ、ということをやっと感じ始めた頃だったと思います。
そのため、新卒で務めた会社を1年半ほどで退職して、現在勤めている会社に転職することにしました。
転職した当初は、社内のデータに慣れるためにいわゆるデータ抽出業務と呼ばれるものを行って、Redash上に登録する、みたいなことをやってました。
そのため、最初はアナリスト要素の方が強かったです。
その過程で、embulkを利用して、BigQuery上にデータを集約するようなETL回りの業務を少しづつ、行うようになった感じでデータエンジニアとしての経験を積み始めた、という流れです。
転職後にデータエンジニアとしてやってきたことを書いていると本題に入れないので、キャリアの変遷はこの程度に留めたいと思います。
まずはキャリアパスを考える上で短期的にやる必要のあることと、長期的に行っていくことに分解をしていこうと思います。
ただ、自分に足りない要素を考えていく上で、自分が見えている範囲しか気付くことができない、という問題は強く意識する必要があります。
そこで、実は以前参考にしつつ挫折した、データエンジニアロードマップを再度参考にしたいと思います。
データエンジニアとして足りない要素
CS fundamentals
いわゆるコンピューターの仕組みに関する部分だったり、Linuxについて知る、ということが挙げられてます
ここら辺は、去年このロードマップをなぞって学習を始めたときに、社内のドキュメントにまとめたので、移植してみようかな..
Learn a programming language
ここでは、pythonやJava、Scalaが挙げられていますが、python自体も凄い書き慣れている訳じゃないんですよね..
今pythonで実装されているものの機能を拡充させていくとか、関数やclassを利用して簡潔に書く、ということをまずはやっていく必要性を感じています
pythonの開発者がtypescriptが素晴らしすぎて、pythonの4系が生み出されることが無い、みたいなことを発言して話題になっていた記憶はあります。
ただそれを見ても、何が良いのか？をあまり分かってない、というのが正直なところ
テスト観点
いわゆる単体テスト、結合テスト等はアプリケーションエンジニアではないから、という区分はおかしいかもですが、ほとんど意識せずに過ごしてきました。
直近、cloud composerを利用してワークフローを構築したりするようになったので、ここら辺はまだ業務で経験できるかも、と思っている自分はいます(本当か？)
RDBに対する理解
・BQが列志向で、RDBが行志向
・アプリケーションから参照される際に、BQは不向きだけどRDBは適している
などは、BQとの違いを理解する、という観点で勉強したり、調べたことがあるので理解はしています。
ただし、RDB自体は業務で扱う機会が少なく、理解が乏しいです。
embulkで参照する、ということは何度もやっているのですが..
DBAの方にインデックスを貼ってOKと言われて、対応したところ永遠に終わらない、という事件(自分の中で)ありました。
結局その後にDBAの方にフォローしてもらったりしたのですが、その過程でインデックスを貼る仕組みをやっと知る、というレベルです。
DBAの方「BigQueryは富豪ですよ」という言葉は忘れられないです。笑
DBを自分で建ててみる、というのが1から流れを理解できて良いのかな..
DWH
ここでいうDWHは、いわゆるデータ基盤の分類におけるDWHではないです。
少し前から話題になっているSnowflakeとか、BQやRedshiftの話ですね。
データ基盤をどこに構築するの？という技術選定を行っていく上で、これらの違いを理解することは必要だと感じています。
全く分かっていないことを優先すべき、という観点で考えるとこの辺りはちょっと優先度が下がります。
Monitoring and observability for data pipelines
ここら辺も全然経験出来てないですね。。
というか挙げられているサービス名で知らないものが多い、というレベルなので、まずは調べてみるところからか..
GCPのCloud loggingとは違うのかな？というレベルの分かってなさ
ZABBIXに近いのかな？
インフラ面のナレッジ
良くも悪くも現在のデータ分析基盤はGCPのBigQueryを採用しています。
そのためインフラ面はあまり理解していなくとも、分析基盤を構築することができてしまうと感じています..
例えば、GCP上にDBを建てた際にファイヤーウォールを設定して、とかそういったネットワーク回りの要素は全然分かっていないです。
既存の社内サービスはRDBを利用していて、インフラが社内ネットワークを構築しており、その中でBQ上にデータを集めるだけで良かった、という背景はありますね..
以前、社内勉強会で何となく参加して、フワッと読み終えたTCP/IPの本を再読すべきか？？
Infrastructure as Code
少し前にmecabでテキストマイニングを行う過程で、ユーザー辞書とシステム辞書を日次で更新する、ということを行いました。
その過程で初めてDockerを利用して、何となく理解できたことは良かったです
また先ほど挙げたCloud composerでのワークフロー構築の過程で、Terraformも使い始めています。
GCPのIAMを割り振っていく過程でも使えたらと思っているので、この部分も若干優先度が低そうです。
Dockerを使う必要性のある業務があんまりない、と現時点では思っているが、こういったことにも使うと便利だよ、ということを気付くことが必要な気がする..
CI/CD
ここは理解がめちゃくちゃ甘いです。
Jenkinsを社内では使っていますが、1から設定したことはほぼ無いです。
gitlabからgithubに切り替えていこうという動きが社内であったときに、ちょろっと新しいjenkinsを登録したぐらいですね
ただこの際も、既存の設定を参考に行ったので、細かい設定とかほぼ調べずに対応できてしまいました(良くも悪くも)
またGithub Actionsに関しては、一度も使ったことが無いので業務の改善タスクとして積んでみようかな..
時間を作っていくという観点を重要視したときに、この改善タスクは順位が上がりそうだと考えています。
今後の方針
業務の中で触れることが出来そうなことは、一旦は短期的にやる、で良いのかなと思ってます
それ以外の要素は長期的に、○○をいつまでにやる、という流れになるのか？と思っていますが、まずはMGRと相談かな..
もしもう少し調べるのであれば..
○○を作ってみる、なのか、××という資格があるからそれを取ってみよう、方法で達成すべきか？
ちょっと長くなってしまったので、上記を身に着けていく上でやっていくと良さそうなこと、それに掛ける時間とかでスケジュールを出してみようかなと思います
アナリスト編も考えていたのですが、それはまた次回以降考えてみます
チーム運営が機能不全に陥ったので、「あなたのチームは、機能してますか？」という本を読んでみた
目次
実際に読んだ本
2003年に発売されたので少々古い本ではあるものの、人が仕事をしていく上でチームの在り方に大きな変化はあまりないのでは？と感じていました。
チームビルディングの本は読んだことが無かったので、ストーリー形式だったのは良かったなと思っています。
なぜ、この本を読もうと思ったのか？
Twitterでこの投稿を見つけて、お気に入りにしておいたのがきっかけです。
自分のキャリアとして、PMも選択肢の1つになるなあと感じていたからですね。
2021年後半、自分のチームが機能不全に陥っていて、単純にタイトル自体が刺さった、というのも大きかったです。
5つの機能不全
この本の中では、チームが機能不全に陥っていく過程で、5つの落とし穴があると述べられています。それが以下の5つです。
下に記載された機能が前提、という意味ではマズローの欲求段階説とかに近いですね。
-
信頼の欠如
チーム内で弱みを見せようとしないこと。
メンバーが弱みを見せて、そうした弱みが利用されることが無い、と信じる必要がある。
信頼の欠如したチームは、チーム会議を嫌がったり、他人に助けを求めたり、支援を申し出るリスクを嫌がる、という記載がされていました。
後述しますが、助けを求めるのを嫌がる、というのは個人的に起きてしまった状況に近いです。
またこういった状況を防ぐためにリーダーに求められる役割として、率先して弱みを見せる、という記述もありました。
チームが機能していた頃に一緒に働いていたマネージャーは、自分のことはピエロで良いと言っており、積極的に弱みを見せてくれる人でした。
-
衝突の回避
信頼を築けないことで何が問題になるのか？
それは腹を割って激しく議論をぶつけることができず、表面的な合意に留まっている点だと指摘されています。
また効率のために衝突を避ける人も多いが、健全な衝突は時間の節約になるとも指摘されていました。
実際にチームが崩壊したときの自分を振り返って、頷きが多かった部分です。
業務が俗人化してしまい、システム設計において細かい議論をしなくなってしまいました。
コードレビューはしていましたが、設計がそもそもこれで良いんだっけ？みたいな議論ですね。。
これはホウレンソウの問題も絡みますが、そういった相談をすぐにする、という発想が出ない状況だったことが、信頼性の欠如に起因すると感じています。
そのタスクを他の方に引継ぎを行ったりしたのですが、欠陥が非常に多く、結局再設計してもらうことになりました。
2021年の中で一番悔しくて、不甲斐ないなあと感じた一件でした。
では第2の機能不全を克服するにはどうしたらいいのか？
衝突が生産的であることを認めることが必要です。
衝突を避ける傾向にあるチームでは、あえて「衝突を掘り起こす」ことが必要だと指摘されています。
またリーダーの役割としては、そういった衝突が起きた際は自制して、自然な解決を任せることが重要と記載されています。
その理由としては、議論を早い段階で中断してしまうとメンバー自身での衝突への対応能力を育てることができないため、ということで、チームの自立が狙いに含まれているなと感じました。
チームが機能してなかったな頃のエピソードを1つ紹介したいと思います。
3人のチームで業務をしていた際に、2人の意見と合わずに自分が意見を押し殺してしまった、ということがありました。
理由としては、2人の意見に反論するだけの考えを言語化できておらず、民主主義だから良いか、として流してしまったことですね。
自分の中のもやもやを言語化するのに付き合ってもらえば良かったな、と反省しかないです。
-
責任感の不足
チームにおける責任感には、「明確さ」と「支持」の2つの側面があり、責任感の不足の大きな原因は全員一致と確実性を求めること、という記載がされています。
全員一致は、個人的にもチーム的にもそこまで重要視したことはないです。
人数が多くなればなるほど時間が掛かりますし、当たり障りのない意見でないと通らないという問題が発生し得ると思ってます。
これは確実性を大切にすると起こりえる、という点とも近いですね。
そもそも論ここで大切なのは、なぜ確実性が不要なのか？という背景にあります。
健全な衝突が起きることで、知恵を振り絞った意見が生まれるという前提が、不確実性のある意思決定を可能にする、という考え方が記載されていました。
-
説明責任の回避
これまでの機能が、説明責任の回避とどのように関連するのでしょうか？
ここは本文の文章をそのまま引用しようと思います。
この機能不全の本質は、仲間の態度をとがめることによって対人関係が気詰まりになることに耐えようとしないことと、難しい会話は避けようとする人間の一般的な性質である。優れたチームは、このような本来の性質を克服し、他人との「危険領域に踏み込む」ことを選択する。
パトリック・レンシオーニ.あなたのチームは、機能してますか？(Kindleの位置No.2140-2142).株式会社翔泳社.Kindle版.
本当に、言うは易く行うは難しだなと感じました。
優れたチームのメンバーは、互いの責任を追求することによって、相手を尊敬していること、相手の仕事ぶりに高い期待を寄せていることを示し、それによって人間関係を向上させる。
パトリック・レンシオーニ.あなたのチームは、機能してますか？(Kindleの位置No.2146-2148).株式会社翔泳社.Kindle版.
ここまで行くと、コーチングの一種に近しいかもしれないですね。。
また、強力なリーダーは規律を引き受ける役割を一手に担って、チーム内に説明責任の空白を作りがち、ということも言及されていました。
要はリーダーが責任を追及してくれることを期待して、メンバー同士での責任追及が生まれない、という状況ですね。
これはチームとしてお互いが行っていること、期待されていることをしっかりと理解しないと、そもそも言及すらできないなと思いました。
この本を読んだ段階でのチームの状況は、まだその状況に近しいなと感じています。
-
結果への無関心
説明責任の回避すら達成できてないので、こちらも達成するにはまだまだ遠いです。
そのため、ここも引用を多めに使っていきたいと思います。
優れた組織は、必ず一定期間に達成すべき成果を計画している。これらの目標は、財務指標だけでなく、管理可能な短期的な指標のほとんどが含まれている。企業にとって究極の結果指標は利益かもしれないが、途中の過程で経営陣が自分たちのために設定する目標は、チームとしてどのような結果をめざして努力するかを表すものである。ひいては、これらの目標が利益を押し上げる。
パトリック・レンシオーニ.あなたのチームは、機能してますか？(Kindleの位置No.2184-2188).株式会社翔泳社.Kindle版.
私自身は現在、データエンジニアとして働いています。
この言葉を見て、ふと振り返ったときにエンジニアにとってのKPI的なものって中々設定しにくいな、ということを改めて感じました。
今、社内でもこの課題に対してアプローチを進めていこう、という動きは起きているので、一旦はそれが明確になって浸透すればいいのかなとは思っています。
こちらに関しては、テーマとして大きいのと、いずれブログネタとしても良いかも？とは思っているので、ここでは細かく言及しないことにします。
最後に
5つの機能不全に関しては、本の後半にまとめられていて、それまでは全てストーリー形式で語られています。
正直ドラマの世界かな？というぐらいに脚色がされていると感じるかもしれません。
ただ、自分のチームが機能不全に陥っていたので、最後のまとめ部分はかなり納得のいく部分が多かったです。
正直、衝突の回避をしてしまった負い目は感じているので、自分自身がチームメンバーに対して心を開くことが出来てないのかなとも感じてしまいました笑
ここ最近、問題の解消に動いている中で、今自分が進んでいる方向性自体は間違ってい無さそうだ、ということも感じることができた一冊でした。
2月から新しいチームメンバーも入ってくる予定なので、チームビルディング本を読み込んで早速実践していきたいと思います。
今さらながら名著と言われる「影響力の武器」を読んだが、章末の問題がかなり面白い
更新サボってたけど、気が向いたときに更新していきたい。
ということで、その第一弾。
研究止めてビジネスの世界に行くのはいいけど、研究の世界以上に分からないことだらけ。
浪人、院進学、休学という回り道をした結果、学部卒で働いてる人に早く追いつき、抜き去るにはどうしたらいいのか？
とりあえず本を読もう！
じゃあどんな本を手に取るか？と考えて、読んだのがこれ。
![影響力の武器[第三版]: なぜ、人は動かされるのか](https://images-fe.ssl-images-amazon.com/images/I/51cb7nbpZnL._SL160_.jpg "影響力の武器[第三版]: なぜ、人は動かされるのか")
まあ名著と言われるものを読んでおけば、大丈夫でしょ。笑
という安易な発想。
まじめに書くと理由は大きく分けて2つですかね。
1つは、人は変わらないということ。
確かに科学技術の発展によって世界はどんどん発展しているけど、人間の脳みそが進化した訳じゃない。
この本はおよそ四半世紀前に出版され、ベストセラーになった。
世界はどんどん発展しているのに、それだけ古いビジネス本が読み続けられるのはなぜか？
それはこの本に書かれている内容が、今でも通じるものであるからだと思ってる。
良い意味でも悪い意味でも、人は大きくは変わらない。
痛い思いをしない限りはそうだと、個人的には思ってます。
全く関係ないけど、アマガミ実況で「人は変わらねえ！！！」って叫んだのは名言だなと。
ちなみに彼は複数のヒロインを狙って失敗し、同じ過ちを犯しかけます。笑
2つ目は、自分を含む人の嗜好性を理解したいから。
この本では、素晴らしい成績を残しているセールスマンであったり、宗教団体が寄付を募る際の手法など、いろいろなものが紹介されています。
彼らはある手法を用いることで、多くの人に対してうまくアプローチをしている訳です。
言い換えると、多くの人に作用しやすいアプローチを”理解”しておくことで、うまく対処できるはず。
理解しておく、というのがとても大切だと思っています。
ちょっと異なりますが、最近そう感じた例としてランニングでの友人効果、というものを紹介してみたい。
僕自身も趣味でランニングをしており、SNS上で繋がってるランナーの方もいます。
負けず嫌いな性分なので、今日は〇〇㎞走った！！とか、〇〇マラソンに参加してきた！！というのを見ると、燃えてくるのが自分でも分かります笑
自分の嗜好性を理解していれば、それをうまく利用して対処することも可能になる訳です。
もっと多くのランナーと繋がることで、さらに自身を動機づけるということですね。
友人効果は良い意味で利用することができますが、影響力の武器ではマルチ商法などの、悪意のある勧誘の原理についても解説されています。
論理的に考えればおかしいはずなのに、どうしてうまく対処できないのか？
それには、人の嗜好性が変わりにくいことが関係してる。
だからこそ、理解して対処するためにかなり有用な本だと思います。
本を選んだ理由だけで、1300字もダラダラ書いてしまった笑
タイトル詐欺かよってことで、そろそろ中身の紹介しましょ。
「影響力の武器」は、全8章で構成されています。
個人的には3章が特に面白いと感じたので少し紹介してみたい。
3章は「コミットメントと一貫性」というテーマ。
いわゆる自己啓発本を読んだことがある人もいるでしょうか？
僕も何冊か読みましたが共通している内容として、「目標を書き記して言葉にして発する」というのがあると思います。
影響力の武器の内容から解説すると、
人が自己イメージを形成するために使う情報を提供し、その自己イメージが将来の行動を決め、その行動が新しい自己イメージをさらに強固なものにする。
これがかなりしっくり来る説明ではないかなーと思います。
この本では、章末ごとに確認問題みたいなものが含まれています。
回答はついていないので、読み返して本当に理解していないと答えられない。
アメリカンジョークなのか分かりませんが、3章の問題はめっちゃ面白くて、声を出して笑いましたねー
ただ、その問題を載せる前に「パブリック・コミットメント」について触れておく必要があります。
その言葉通り、意見を公表することによって、一貫した自分に見られたがる性質があるということですね。
例えば「週に1冊は本を読み、その感想をブログにまとめる」と宣言することで、そのように自分が行動させようとする、というものです。
では、3章の問題を1つ紹介します。
大々的に結婚式を行う理由を、コミットメントの法則から説明せよ。
結婚式では、新郎新婦が人々の前で互いの愛を誓いあう訳ですよね。
これをパブリックコミットメントを考慮して捉えてみると。。。
これ以上は書くのを止めておこうと思います、はい。笑
他の章を少し紹介してみると、4章では都市に住む人々が冷たいとよく言われますが、その理由について。
5章では、なぜデートでは食事がいいのか、人はスポーツに熱狂するのかを解説しています。
面白い内容が多すぎて、挙げていったらキリがない。
何度も述べていますが、多くの人に当てはまるであろう法則を分析しているので、自分や周りの人にも当てはまる可能性が高い。
何も知らずに相手の術中にハマって後悔するのではなく、理解して本当に良いと思ったらハマりに行けば良いと思ってます。
嫌なら対処すれば良い、というだけの問題。
仕事の経験は乏しいですが、ロジックだけではダメで、感情を利用する大切さを認識させられる出来事が少し前にありました。
そういう意味でも、やはり名著だなと感じる本ですね。
北海道大学大学院を中退しました。
卒業シーズンですね。
先日、北大でも卒業式があり、友人に会いたいのもあって参加してきました。
最初は保護者席で見ようと思ったのですが、同期に交じって参加しました。
私服で参加したので、ジロジロ見られて浮いてる感しかなかった笑
しかしながら、僕自身は休学中の身なので卒業しません。
それどころか復学せず、中退しました。
退学って意外とすんなり終わるんだなーというのが、書類を提出した時の感想ですね。
教授とかにサインもらって、提出したらお終い。
理学部での事務手続きは3分も掛かってないです笑
インドから帰国した段階で、大学院の中退は考えてました。
この覚悟はかなり前から何となく固めていて。
留学した段階で、博士に行くか退学すると思っていたので。
僕が留学したのは、博士課程、研究者になる覚悟が欲しかったから。
今思うと、もうちょっと自分に優しくしても良かったかなと思う。笑
自分の身をどこに置くか、ということを今後は意識していきたい。
ただ、自分の価値観の優先順位が、研究者とは合っていないと確信した。
だから帰国したし、中退した。
研究するモチベーションはいろいろあると思います。
社会貢献、ポストが欲しい、何かを解き明かしたいという知的好奇心。
研究者は、誰も知らないことを一番に解き明かしたい。
その欲求に純粋な人であると、個人的に結論付けました。
周りの研究者と話していて、本当にそう思った。
日本でも、教授やいろいろな先生方と話していて、そう感じていたはず。
でも気付かなかった。
考えるのを怠っていて、日本にいたときは言語化できなかった。
そうやって思考を止めているから、留学してしばらくして、違和感に再度襲われた。
何かが根本的に違う。
何が、なにが彼らとは違うのか？
キラキラしている彼らの目、彼らの情熱に触れて分かった。
そこでやっと腑に落ちた。
絶望的な温度差を痛感して気付かされた。
僕自身は何かを知りたいという欲求より、人の役に立ちたいという欲求の方が圧倒的に強かった。
何かを解き明かしたところで、知は周知の知に変わる。
何かを解き明かすと、また新しく分からないことが生まれる。
そうして先人たちが積み重ねた英知の上に、今の研究がある。
抗癌剤の研究をやりたかったのも、誰かのために役立ちたい。
そういう欲求が根底にあったから。
それを通して、自分が評価されたいという欲求があった。
実際の研究は地道で、孤独で、反復作業の繰り返しで、つまらないと正直感じてしまったことが多々あった。
ときどき生まれる成果や進捗でのフィードバックが、自分のやる気を潤してくれた。
だけど、そのスパンの長さに僕の飢えが満たされなくなった。
研究者は、知への欲求が上位に来るからこそ、その飢えが苦にならない。
だったら研究は向いている人に任せて、ビジネスの世界に飛び込もう。
そう思ったら、復学して修士論文を書く時間が惜しくなった。
大学院は研究者になりたいから進学したので、違う道に行くなら未練はない。
正直、かなりすっきりしてます。
幸い内定を貰うことができて、今は働いています。
ただ、こうやって決断を下したけれども、忘れちゃいけないことがある。
ずばり、お前は本当に本気で研究をやったのか？ ということ。
ここ最近、ずっと心に留めていることがあります。
何かをすると決めるのは自分だけど、評価を下すのは他人、ということ。
今の話であれば、僕は研究を本気でやったしベストを尽くした。
多少経験を重ねたので、もっとやりようはあったなと振り返って思うことはある。
だけど、当時の自分はその経験値がなかったから。
もちろん無いなら無いなりにベストを尽くした。
でもそれは誰が評価する？
どこまでやれば、自分はベストを尽くしたと明確に言える？
それを決めるのは自分なのか？
そんなわけない。
他の誰かが、自分が本気でやったと認めなければ、それは本気でやったことにはならない。
実際に面接でも言われました。
君は本気でやったのか？
そりゃそうだ。
企業としては、研究を切り上げて帰国して、大学も中退して、成果も何も残してないやつをどうやって評価すればいいのか。
だから思った。
仕事を全力でやるしかないと。
明確な成果を出すと。
今はそれしか言えません。
中退することは、親から強く反対されました。
浪人して、なんとか北大に入って、留学までさせてもらって、期待してもらったんだなと思う。
親と話していて思うのが、絶望的な言葉の遠さ。
日本語で話しているはずなのに、価値観が違い過ぎて、言葉が遠く感じた。
一応、理解はしてもらいました。
だけど、成果を出して納得させたい。
あの時の自分の選択が間違っていなかったと、誇れるように。
今の場所で全力を尽くす。
だたそれだけ。
中退したときは、こんなことを考えていたなと振り返りたいですね。
