sireikan

東京在住のエンジニア。 読書メモなどを書いていこうと思います

sireikan

東京在住のエンジニア。 読書メモなどを書いていこうと思います

最近の記事

『WHITE SPACE』読書メモ

今回読んだのはこちら。 働いていく上で戦略的にホワイトスペース(考えに耽る時間)を作り回復や内省をして次の行動に活かそう、というような内容です そもそもとしてホワイトスペースがないのはなぜなのか、という点に対して以下のこと等が挙げられています ・もっと仕事をしたい、自分はもっとできるという欲求からどんどん仕事をしてしまい燃え尽きてしまう ・他人がやっているから自分も同様にやらなければいけないという同調圧力 ・よくわかっていないが仕事自体の価値を意識せずに価値の低い仕事に没

    • 『APIデザイン・パターン』読書メモ

      今回読んだのはこちら APIに関してGoogleのAPI設計をもとにしたベストプラクティス集の本です Amazonのレビューにもありますがちょこちょこは翻訳があやしいところはありました 概要 APIと一言に言っても実現したい処理が無数にあります 本書はそれぞれのケースに沿ってどういった考えで実装していけばよいのかを詳しく解説しています 結構分厚い本だったのですべてを書くと何回にも分けて書くことになりそうなのでかいつまんで書いていこうと思います 序盤 最初の方はデザイ

      • 『ドメイン駆動設計 サンプルコード&FAQ』読書メモ

        今回読んだのはこちら BOOTHでの本なのでAmazonではありません DDDの目的 主にソフトウェアの機能性、保守性の両方を高めること ・ドメインエキスパートと共に行うドメインモデリング(機能性) ・頻繁なモデルの更新に耐えられる実装パターン(保守性) 複雑なドメインの問題を解決する時に使うと良く、何にでも万能というほどでもない モデリング、実装パターンはどちらからだけやっても構わない ポイントとしては「責務」を意識してそれが何をするクラスなのか?を考え高凝集、低結合

        • 『こうして社員は、やる気を失っていく リーダーのための「人が自ら動く組織心理」 』読書メモ

          今回読んだのはこちら。 こういう系の本をいくつか読んできましたが具体的寄りの本だったと思います。 やる気は個人の問題か? 最初にこのテーマがありました 会社で働く人のやる気に関しては会社の問題と考えて良さそうです 周囲との関わりであったり、制度、待遇といったものもあるでしょう こういったことでやる気を下げてしまう要因を取り払っていくことが重要です 具体例 2章でいくつかのやる気を下げる要因のケースが挙げられていました 実際こういう上司だったらやる気は下がりますね

        『WHITE SPACE』読書メモ

        • 『APIデザイン・パターン』読書メモ

        • 『ドメイン駆動設計 サンプルコード&FAQ』読書メモ

        • 『こうして社員は、やる気を失っていく リーダーのための「人が自ら動く組織心理」 』読書メモ

          『国際エグゼクティブコーチが教える 人、組織が劇的に変わる ポジティブフィードバック』読書メモ

          今回読んだのはこちら。 ポジティブフィードバックの位置付け 本書では通常のフィードバックは「評価」、ポジティブフィードバックは「承認、成長への導き」と示しています ポジティブフィードバックを行うことで方向性に間違いがないかの導きとなり、やる気を上げ余裕を持って作業にあたれるようになります さらにこまめに実施することでより高品質なアウトプットへ繋げます こういった良いループを形成することで信じて仕事を任せることができるようになり人も組織も良い方向へ向かうことができそうです

          『国際エグゼクティブコーチが教える 人、組織が劇的に変わる ポジティブフィードバック』読書メモ

          『エッセンシャル思考 最少の時間で成果を最大にする』読書メモ

          今回読んだのはこちら。 いわゆる啓発本?ですかね エッセンシャル思考とは より少なく、しかしより良く、を追求する考え方です より多くのことをやり遂げるのではなく正しいことをやり遂げる技術 自分で選択肢を考え優先順位を決めて行動していくこと 多すぎる選択肢は大事なことを見失い、何が最優先かわからなくなります そうならないための考え方のヒントとなりそうです 減らす、選ぶ いろいろなことを考えるというよりもよりシンプルに考える、というのがよく出てくる考え方だと思いました。

          『エッセンシャル思考 最少の時間で成果を最大にする』読書メモ

          『新 コーチングが人を活かす』読書メモ

          今回読んだのはこちら。 久々のマネジメント系の本です。 読んでいてメモしたポイントだけ書いていきます。 相手の話を聞いていることを伝える、そして質問する 一方的に話を聞いているだけだとちゃんと聞いているのかな? という気持ちになると思います。 リアクションや返答、質問があってこそのコミュニケーションです。 一緒に答えを発見する気持ちで動きましょう。 質問の仕方 抽象的な答えに対してはっきりしたい部分を質問する いきなり大きい質問をしない なぜ、ではなく、なに、に

          『新 コーチングが人を活かす』読書メモ

          『リフレクション(REFLECTION) 自分とチームの成長を加速させる内省の技術』読書メモ

          今回読んだのはこちら。 内省という側面から振り返りについて書かれた本になります。 メタ認知 本書では何回も出てくる用語です。 あらゆる事象についてリフレクションをする際には俯瞰して状況をみることでその場にある4つの要素を掴み取ることが重要とのことです。 4つの要素 意見・経験・感情・価値観の4つをリフレクションの要素とします。 意見:結果としてどう感じているか、どう思っているかということ 経験:意見が結果として出るに至った背景となる経験・根拠 感情:経験や知識に対

          『リフレクション(REFLECTION) 自分とチームの成長を加速させる内省の技術』読書メモ

          『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』読書メモその2

          前回の続きです。 イテレーション スクラム開発ではイテレーションを区切って開発をしていくことになります。 イテレーションで達成するものに向かって全力で取り組むことは大事ですが、ただこなすだけではなくリリースという大きい目標に向かってやっていることを常に意識しておかなくてはいけません。 リリースのためには何が求められているのか、いつまでにどんな機能が必要なのか、そこに向けてイテレーションでは何をしていくのがよいか、優先順位は今のままでよいのか、といったことを定期的に見直し、

          『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』読書メモその2

          『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』読書メモ

          今回読んだのはこちら 結論から書くと総じて勉強になった本でした。 実務をしていてもこういうケースはどうすれば、というところに触れられていて参考になりました。 計画作りとは 本書での計画作りとは、一言で言うと価値の探究です。 価値とは、何を作るべきなのかを明確にしていくことであり、最適な答えに少しずつ近づいていくことが価値の探究ということです。 その過程で不確実性のある問題にどう向き合い、プロダクトをよくするためにどういったアプローチを選択するかといったことが具体的な行動

          『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』読書メモ

          『AI分析でわかった トップ5%リーダーの習慣』読書メモ

          今回読んだのはこちら。 以前読んだものの続編ですね。 時間に余裕を持つ 以前の社員版のほうとの違いとして最初に5%リーダーは歩くのがゆっくりとありました。 意図的に時間と気持ちに余裕を持っているという見解でした。 会議なども時間通りに終わらせることで余裕を生んでいるようです。 時間に余裕のある人の方が声をかけやすいため、意図的にまわりに余裕がありますよ、と示しているんですね。 会議 会議については必ずなんのために会議を行なうのかという意義や目的を実施前に宣言します。

          『AI分析でわかった トップ5%リーダーの習慣』読書メモ

          『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』読書メモ4

          https://note.com/helt19981201/n/n3528fb9be8ac 前回の続きです。4部作になるとは思いませんでした。 最終回です。 チーム以外にギルドを作る ギルドとは共通のゴールを持った集団のことを指します。 チームとは関係なく、関心やテーマごとにわかれた全社を横断した情報共有の場みたいなものでしょうか。 会社が大きくなるにつれて、他のチームでやっていることが見えなくなっていくと思います。 そうなることで他のチームではすでにやっていた開発を再

          『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』読書メモ4

          『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』読書メモ3

          さらに前回の続きです。 ビジネスサイドの人と関わりを持つ ビジネスの最前線にいる人たちは提供するサービスがもっている課題を身を持って体験している人たちだと思います。 そういった人たちと関わりを持つことで、本当にインパクトの大きい改善とはなんなのかの認識を持つことができます。 またそういった人たちが将来の会社のキーマンとなり自分のキャリアにも有効に働くかもしれません。 メンタリング、コーチング どちらも近い要素に思えますが、メンターのほうが指導という側面が強そうです。

          『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』読書メモ3

          『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』読書メモ2

          前回の続きです。 自己実現欲求 欲求にはいくつか種類があり、所属の欲求や承認の欲求などがありますが、高次の欲求に自己実現の欲求があります。 自己実現の欲求は上限がなく、継続して生まれ続ける欲求です。 自ら学び、成長する継続的な機会を持てること 新しいスキルを学ぶための環境を提供すること 自由なアプローチで問題解決に当たれること といったものになります。 その実現のためにはどういったアプローチができたらよいでしょうか。 難しいタスクをジュニア、シニアのペアで当たらせ

          『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』読書メモ2

          『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』読書メモ

          今回読んだのはこちら。 発売前から気になっていた本です。 内容はボリューミーですが、エンジニアリングマネージャとして各場面でどういうふるまいが必要かといった事柄が書いてあるのでシーンごとで必要な章を読むでもよさそうでした。 最初にやるべきこと 序盤の章はとりあえずやってみることが書いてあります。 上司、メンバーからチームの状態についてのヒアリング メンバーの最近の作業について 他のメンバーについてどう思うか メンバーが集中したいときはどんなタイミングか ヒアリン

          『エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法』読書メモ

          『良いコード/悪いコードで学ぶ設計入門』読書メモ

          今回読んだのはこちら。 社内の人が気になるといっていたので読むことにしました。 全体を通して DDDやモデリングといったことをできるように極力難しい言葉を使わずに順序立てて実施できるように書かれているなあ、と感じました。 モデリングなどは後半そのまま用語として出てきますが、そこに至るまでの説明が丁寧だったのではないかと思います。 命名 クラスや関数の命名にきちんと意味のあるものをつける。 古からある昔のコードや本などをみると名前だけでは何をしているかわからないものも多

          『良いコード/悪いコードで学ぶ設計入門』読書メモ