『GO OUT (ゴーアウト) 飛び出す人だけが成功する時代』を読んで

書籍紹介 読了


はじめに

『GO OUT (ゴーアウト) 飛び出す人だけが成功する時代』という本を飛んだのでアウトプットします。以降記事内では『本書』と省略します。

どんな本か

内容や目次は↓に記載されています。 d21.co.jp

なぜ読むのか

  • 自分に足りないもの(=ゴーアウトすること)について書かれているから
  • "T型人材"について理解を深めたかったから
  • 今後のキャリアの参考になればと思ったから


ざっくり感想

"T型人材"になることを推奨し、そのために"GO OUT"すべきであるという本です。外に出て人と会おう！という話だけではなく、医学や歴史、著者の体験談などを交えて"GO OUT"すべき理由や効果が書かれており、説得力がありました。

著者が凄すぎて、自分が真似できるかと言われると真似できないことも多そうです。自分は"GO OUT"があまりできておらず苦手なので耳が痛い内容もあり、自分を見つめ直すいいキッカケになりました。できることから少しずつ取り組んでいき、"T型人材"を意識して日々行動していきたいと思えました。

T型人材

T型人材についてメモしておきます。

本書から引用。

あるひとつの分野を極め、専門的な知識や知見、経験、スキルを持つだけでなく、ほかの分野にも優れた知見を持つ人材。

  • T型
    • 横軸：なんでも体験したことがプラスになる探索。
      • 探索：自分自身や会社の認知の範囲を超え、認知を広げていくこと。
      • 横軸の左右：片方が現在の仕事に関係あること、もう片方が現在の仕事と関係ないこと。
    • 縦軸：専門性を深掘りする深化。深化の周りはコンフォートゾーン。
      • 深化：探索を通じて見つけた専門性を深掘りして磨くこと。

二つ以上の専門性を深化させ、さらに幅広く探索を続ける"π型人材"が理想。

2種類の友人

『少しの「親しい関係」とたくさんの「緩いつながり」をつくる』という章は印象に残ったのでメモしておきます。

  • 関係性理論によると友達には「親しい関係」と「緩い関係」の2種類がある。
  • 「親しい関係」が3〜5人いると幸せ度が高い。
  • 「緩い関係」は150〜800人まで対応できると言われている。
    • 転職したり部署の変更で切れてしまう関係は含まない。
    • 3回会って構築できる。そうしないと顔と名前が一致しない。
  • 情報を持ってきてくれるのは「親しい関係」ではなく「緩い関係」の友人。
  • なので「親しい関係」と「緩い関係」の両方の友人が必要。


『GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ』を読んで

書籍紹介 読了


はじめに

『GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ』という本を飛んだのでアウトプットします。以降記事内では『本書』と省略します。

どんな本か

内容や目次は↓に記載されています。 www.shoeisha.co.jp

なぜ読むのか

  • マネジメントや組織作りに興味があるから
  • GitLabのやり方を知りたいから
  • リモートワークが好きだから
  • "徹底したドキュメント化"に興味があるから


ざっくり感想

GitLabの組織運営の方法や文化を学ぶことができ、リモートワークを取り入れた組織作りやマネジメント、ドキュメント化へのモチベーションを上げてくれる本でした。実際に運用されているルールがわかりやすく解説されており、それによる効果や予想される問題と対処法にも触れられています。

当然ある程度上の立場にならないと会社をGitLabと同じような仕組みにしていくことは難しいですが、自分のようなチームリーダーレベルの立場あるいはメンバーの立場でも真似できることは多く紹介されており、読んでいる最中も頭の中で「これは今のチームでやるなら…」とつい考えてしまいました。

仕組みを作る立場になくても、GitLabの取り組みと解説を読むだけでも面白いですし、リモートワークのメリットやリモートワークをしていく上での心構えを学ぶことができます。リモートワークを取り入れている、または取り入れようとしている組織に所属している人なら是非読んでほしい一冊です。

GitLabの取り組みを少しだけ紹介

詳しくは本を読んでいただきたいのですが、印象に残ったGitLabの取り組みを少しだけ紹介します。

何かを決める時はプロポーザルを用意する

紙の本143ページに書かれています。プロポーザルというものを読むまで知らなかったのですが、本書では"具体的な解決策まで踏み込んだ提案"と定義されています。GitLab内では"全ての会議はプロポーザルのレビューであるべき"と明言されているようです。

ちなみにプロポーザルが用意できない場合については続きに書かれており、オンラインでの会議については175ページに書かれています。

ネガティブなフィードバックはドキュメントとして書き留める

紙の本201ページに書かれています。ドキュメントに書き事実ベースに議論して改善することに合意できたら、どう改善するのか具体的な行動を言語化して、定期的に振り返って確認することで変化に繋げやすくするそうです。

そもそも"フィードバックは難易度が高い"と書かれおり、これだけ真似するとネガティブなフィードバックを受けた人が不快に感じたり、自信を失う可能性があります。"良い関係性が構築されていること"や"SBIモデルを使うこと"など工夫や前提を忘れないようにしたいです。

他メンバーの活躍を推薦するとボーナスがもらえる

紙の本250ページに書かれています。メンバーが他メンバーの活躍を推薦するし認定されると1000ドルのボーナスがもらえるという制度です。ボーナスは"推薦した人"がもらえるのか、"推薦された人"がもらえるのか、両方なのかが読んでいてわからなかったのですが、いずれにせよモチベーションにつながる面白い制度だなと思いました。


2023年の振り返り

振り返り


仕事

ビジネスチャットシステムの改修/保守（〜2023年8月）

2022年の10月から携わっていたが、サービス終了が決まったので別の案件へ。
サービス終了は残念だったが初めての技術を多く経験できて良かった。

初めて仕事で触れた技術

  • Swift
  • Realm
  • TypeScript
  • Firebase Authentication
  • Cloud Firestore
  • Spring Boot
  • Apache Kafka

DMPの管理画面の新規開発（2023年9月〜）

現在携わっている案件。
フロントエンドエンジニアとしてReactとTypeScriptでUIを作っている。
スクラムやフロントのテストコードなど初めての良い経験ができている。

初めて仕事で触れた技術

  • MUI
  • Vitest
  • Testing Library
  • Recoil
  • Tanstack Query

アウトプット

GitHub

仕事では使ってないアカウントの記録です。

リポジトリ作成

合計7つ作成しました。

コントリビューション

合計コントリビューション数は185でした。

ブログ

この記事含めて合計9記事公開しました。

Zenn

今年アカウントを作りました。
アウトプットとしてはScrapしか使いませんでした。

Scrap

合計7つ作成しました。

参加イベント

合計16のイベントに参加しました。
全てオンラインです。

読書

合計3冊読みました。
ブクログのスクショです。

LAPRASスコア

LAPRASのスクショです。

2023/08/24 ※LAPRAS登録日

2023/12/24

プライベート

  • 引っ越しをして初めての一人暮らし(今までは実家→ルームシェアだった)。今のところ大きな問題なく平和に過ごせている。
  • サッカーの試合視聴数は去年の315試合から減って272試合の見込み。
  • 人生初のスタジアムでのサッカー観戦に行った。
  • 2023年開始のアニメは79作品視聴。数え方は適当なので大体の数字。
  • 運動不足解消のために週1〜2回ランニングをするようになった。
  • 8月にNintendo Switchを買った。ほぼ毎日1日平均50〜60分ぐらいやっていた。プレイしたゲームは以下の通り。

振り返り感想

今年は小さいながらも色々新しいことに挑戦ができたので結構良かった気がする。新しく学んだ技術も多かったし、LAPRASに登録してアウトプットへのモチベーションも上がった。プライベートも楽しめている。
来年伸ばしていきたいのは読書数。今まで全然本を読んでこなかった人生だったので今年の3冊でも多い方なんですけどね。読みたい本はたくさんあるので、週1冊ぐらいのペースで年50冊を目標に読んでいきたい。プライベートではもっとゲームを楽しんでいきたい。特にNintendo Switch Online + 追加パックは契約更新するつもりがないので優先的にやっていきたい。

『3分間コーチ ひとりでも部下のいる人のための世界一シンプルなマネジメント術』を読んで

書籍紹介 読了


はじめに

『3分間コーチ ひとりでも部下のいる人のための世界一シンプルなマネジメント術』という本を飛んだのでアウトプットします。以降記事内では『3分間コーチ』や『本書』と省略します。

どんな本か

Amazonの商品ページをご覧ください。ノンアフィリエイトリンクです。


なぜ読むのか

Prime Readingの対象なので無料で読めるからというのが大きいですが、マネジメント系の本は今まで読んできておらず前々から読んでみたいと思っていたのと、タイトルからどんな内容か気になったので読んでみました。


ざっくり感想

部下のためだけに3分でいいから時間作って話そう！ということを伝えたい本だと思います。話すことが大事！なのですが、準備が大事だとか、上司と部下の視点で、考え方や心構えについて学ぶことができました。自分は部下がいるわけではありませんがマネジメントすることはあるので、できていることとできてないことが理解できて良かったです。

3分間コーチのイメージとして「コーチングのイメージは駅のホームです。電車が来るまで会話するようなイメージです。ただ雑談するのではなく、目標、スキルアップ、チームワーク、タスク、フィードバックなど的を絞った会話をします。」みたいなことが35ページあたりに書かれているのですが、この例はイメージしやすいなと思いました。


印象に残ったナレッジ

「何かあったら声をかけてくれ」だと相手は声をかけられない

これは仕事の中でもやってしまいがちだなと思いました。ある程度関係ができていて近しい距離感の人にならば気軽に声をかけられるのでこれは当てはまりませんが、上司と部下という関係が前提に書かれていることを考えると納得できます。ある程度具体的にどういう時に話しかけてほしいかを伝えることと、話しかけやすい状況作りは意識していきたいと思いました。


アクノレッジメントすることで部下を方向づけることができる

これは自分ができてないような気がしました。まずアクノレッジメントという言葉を知りませんでしたが、「承認」を意味します。うまくいっている(うまくいった)ことを事実として伝えることで、部下は自信を持てたり、成長を実感できたり、モチベーションの向上に繋がるという考え方です。「褒める」とは違うので、使い分けは難しそうだなと感じました。意識せずやれている部分もあるかもしれませんが、意識してやっていきたいです。


「それで私はどうなるのか？」部下はいつもそれを気にしている

WIIFM（What's In It For Me?）=「私が手にするものは何？」を認識しあうことが大切だということが書かれていました。ググったら「うぃーふむ」と読むらしいです。確かにこれは自分も理解して仕事したいと思うことがあるので納得の内容でしたし、マネジメントする立場にあるときは認識しあうことができるようにしていきたいと思いました。正直これについての説明はChatGPTの方がわかりやすかったので…短くまとめたものを以下に貼っておきます。

「WIIFM（What's In It For Me?）」は、個人が何らかの行動を取る際に、その行動が自分にどのような利益や価値をもたらすかを考慮する心理的な動機付けのプロセスです。

・職場でのプレゼンテーション
新しいプロジェクトをチームメンバーに提案する際、プロジェクトリーダーは「このプロジェクトに参加することで、最新技術のスキルを身に付けることができ、将来のキャリアアップにつながります」と説明することで、チームメンバーの関心と参加意欲を引き出します。

・教育やトレーニング
教育者やトレーナーは、新しい学習プログラムを紹介する際に、「このコースを受講することで、市場で需要の高いスキルを習得し、就職や昇進の可能性を高めることができます」と説明することで、受講者の学習意欲を高めます。

・個人的な目標設定
個人が新しい運動プログラムを始める際、そのプログラムが「健康の向上に役立ち、自信を高め、より活力に満ちた生活を送れるようになる」という個人的なメリットを理解することで、継続するモチベーションが高まります。

WIIFMは、個人が何かを決定する際に自分自身の利益や報酬をどのように評価するかを考慮することを強調し、効果的なコミュニケーションやマーケティング戦略に不可欠な要素となっています。


『レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』を読んで

書籍紹介 読了


はじめに

『レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス』という本を飛んだのでアウトプットします。以降記事内では『レガシーコードからの脱却』や『本書』と省略します。

どんな本か

内容や目次は↓に記載されています。 www.oreilly.co.jp

なぜ読むのか

『プリンシプル オブ プログラミング』を読んだ理由と近いのですが、より良いコードを書くためには、そしてより良いソフトウェアを作るためにはどうすればいいかを学びたかったからです。また、読み始めた当時は所謂"レガシーコード"に苦しんでいるチームで働いていたので、タイトルに惹かれました。単純に評判が良く、ITエンジニア本大賞2020にも選ばれているのも決め手の1つになりました。

www.shoeisha.co.jp


ざっくり感想

タイトルが『レガシーコードからの脱却』になっているので、既にあるレガシーコードをどうしていくかの話が書いてありそうに思えますが、レガシーコードを作らないためにどうしていくかがメインで書かれています。

基本的にはアジャイルの考え方が推されており、レガシーコードやこれまでの開発方法を改善していこうという話と、良いソフトウェアを開発するための9つのプラクティスが紹介されています。著者のソフトウェア開発や業界をよくしていこうという熱い思いが伝わってきて、プラクティスを実践する気にさせてくれました。但し紹介されている内容は開発の進め方に関する紹介が多く、1人のエンジニアが「やりましょう！」といってもチームに導入するのはなかなか難しいと思います。全部がそうではなく意識すれば1人で実践できることも書かれています。

ソフトウェア開発未経験者が読もうと思うような類の本ではないとは思いますが、ソフトウェア開発のプロジェクトに関わった経験や、進め方をある程度理解していないと、読んでもピンとこないことも多いかもしれないので注意が必要です。開発経験のある人、特にチームをマネジメントやリードしていくポジションの人には是非知っておいていただきたい内容が詰まっている本だと思います。

翻訳者の吉羽龍太郎さんが本書についてAWS DevDayで発表した時の資料を公開してますので、読むかどうか迷っている人は一度目を通してみると参考になると思います。

www.ryuzee.com


"レガシーコード"の定義

訳者まえがきから引用

修正や拡張、作業が難しいコード

裏表紙から引用

バグを多く含み、壊れやすく拡張が難しいコード

翻訳者の吉羽龍太郎さんの資料から引用

理由は問わず修正、拡張、作業が難しいコード


原則とプラクティス

原則

  • 目指すべき姿で、価値のあるゴール
  • 簡潔で明確に定義されてなければいけない
  • 何をやるべきかを教えてくれる


プラクティス

  • 原則を実現する方法
  • 3つの条件を満たす
    • ほとんどの場合に価値がある
    • 学ぶのが容易、教えるのが容易
    • 考えなくてもやれるぐらいシンプル


4.6 原則がプラクティスをガイドする に書いてある投資での例

原則 = 「安く買って、高く売れ」
プラクティス = ドルコスト平均法


9つのプラクティス

「詳細は本を読んでね」となりますが、自分用に簡単にまとめておきます。


1. やり方より先に目的、理由、誰のためかを伝える

マネージャーやプロダクトオーナーは、開発者に「やり方」ではなく「目的、理由、誰のためか」を伝えるべきという考え方です。「やり方」を伝えると開発者は「やり方」に縛られてしまい、良い実装になりにくくなるので、開発者に「やり方」は任せようということです。

5.8 本章のふりかえり から一部引用

これによって実装の詳細は隠れ、コードはよりシンプルで、拡張するためのコストも低いものになる。ストーリーが要求に代わり、開発が発見になれば、事前に洗い出そうとしていたときよりもより良いプロダクトを作れるのだ。


2. 小さなバッチで作る

タスクを小さく(短い時間で終わるように)しようという考え方です。タスクを小さくすることで以下のようなメリットがあります。

  • 理解しやすい
  • 見積もりがしやすい
  • 実装しやすい
  • テストがしやすい
  • より多くのフィードバックの機会があるのでリスクが少ない


3. 継続的に統合する

実装したものをビルドしながら常に(実装する度に)統合しようという考え方です。これを継続的インテグレーションと呼びます。常に統合することで問題を早期発見できます。継続的インテグレーションは実装する度に統合してデプロイしなければいけないということではなく、デプロイ可能な状態にしておくことです。


4. 協力しあう

一番価値のあるリソースは一緒に働くメンバーであり、 知識をグループに広げるために協働しようという考え方です。この章では協働を最大化するのに役立つ方法として以下のような方法が紹介されています。これらについては他の資料や実践を通してより深く学んでいきたいところ。

『8.9 常にメンター、メンティー』であれに書かれているスコット・ベインさんの言葉「常に誰かのメンターであれ、常に誰かのメンティーであれ」は改めて心がけていきたい。


5. 「CLEAN」コードを作る

良いコード =「CLEAN」コードを書こうという考え方です。「CLEAN」は以下の頭文字です。

  • Cohesive (凝縮性)
    • 凝縮性のあるコードは副作用を減らす
    • 単一の責任を持つべし
  • Loosely Coupled (疎結合)
    • 疎結合なコードはテストが容易である
    • 疎結合なコードは利用しているコードに対して間接的にしか依存しない
  • Encapsulanted (カプセル化)
    • カプセル化されたコードは簡単に拡張できる
    • 実装の詳細を外部の世界からは見えない状態にすべし
  • Assertive (断定的)
    • 断定的なコードはソフトウェアがモジュール化される
    • 絶えず他のオブジェクトを参照している = 断定的ではない
  • Nonredundant (非冗長)
    • 非冗長なコードは保守の問題を減らす
    • 同じことを繰り返さないこと

『9.8.2 保守しやすいコードを書く7つの戦略』にはいいこと書いてある。というメモだけ残しておく。


6. まずテストを書く

最初にテストを書き、次にテストに合格するのに必要なコードだけを書こうという考え方です。所謂テスト駆動開発、テストファースト開発です。安全なリファクタリングや仕様の理解に役立ちます。ここは自分が全くやったことないので、書いてあることはわかるがイメージできてないという状態です。


7. テストでふるまいを明示する

生きた仕様を作るために、テストにふるまいを記述しようという考え方です。1つ前の『6. まずテストを書く』と結構似ています。JUnitを使った実際のテストコードの例が書かれています。


8. 設計は最後に行う

章のタイトルと、自分の中での"設計"という言葉の理解がイマイチ噛み合ってないのですが、章の最初に「ソフトウェアの保守性を設計するのに最適なタイミングがコードとテストが書かれた後である」ということが書かれおり、そういう考え方ならなんとなくわかるな、と思った章です(？)。要するに保守性の高い作りにしていこう、そのために継続的に改善していこうという話だと理解しています。また、開発の中で学んだことを設計に反映していこうということも書かれています。


9. レガシーコードをリファクタリングする

これは章のタイトルそのままの考え方です。リファクタリングとは、外部へのふるまいを変更せずにコードを変えることです。リファクタリングは、既存のコードを学ぶための良い方法であるとも書かれています。「コードを読む回数は、コードを書く回数の10倍以上だ」が印象的でした。