sireikan

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

sireikan

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

最近の記事

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

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

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

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

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

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

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

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

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

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

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

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

          『リフレクション(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やモデリングといったことをできるように極力難しい言葉を使わずに順序立てて実施できるように書かれているなあ、と感じました。 モデリングなどは後半そのまま用語として出てきますが、そこに至るまでの説明が丁寧だったのではないかと思います。 命名 クラスや関数の命名にきちんと意味のあるものをつける。 古からある昔のコードや本などをみると名前だけでは何をしているかわからないものも多

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

          『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意』読書メモ

          今回読んだのはこちら。 以前読んだこちらの続きのような本ですかね。 スクラムマスターはどう動けばいいのかという観点で書かれていました。 スクラムマスターが実現すること 一言で言うと、「ハイパフォーマンスなチームを作り上げる」ことがスクラムマスターがいる意味と言えそうです。 とりあえず連携できている、会話ができているいわゆる「いいチーム」に終わるのではなく常により良くできないかチームで高めていける状態にもっていくことが必要になりそうです。 自己組織化 スクラムに限らず

          『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意』読書メモ

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

          今回読んだのはこちら。 シリーズで出ている本屋さんにいったら結構置いてある本ですね。 トップ5%社員 本書は360度評価などで評価が高かった上位5%の社員について特徴的な行動はなんだったのかを分析している本になります。 評価が高い=会社が求めている人材=アウトプットの質が高い ということだと考えられます。 特徴 序章にざっくりと5%社員の特徴が書いてあります。 こういう行動ができる人と一緒に仕事をするのは気持ちよさそうですね。 評価をするポイントが経緯ではなく結果

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

          『モブプログラミング・ベストプラクティス』読書メモ

          今回読んだのはこちら。 TDDと同様に気になるプラクティスでしたので読みました。 分散知識 モブプロとは同じ場所で参加するみんなの知識を集めて作業することです。 各々で分散されている知識が集約され問題解決をスムーズに進めていきます。 ペアプロとの違い 本書ではペアプロでいうドライバー、ナビゲータをタイピスト、モブと呼んでいます。 モブプロではモブが複数人いるため、参加者の意見が対立していてもこう着状態になりにくくなります。 複雑な問題に対して、2人より3,4,5人の

          『モブプログラミング・ベストプラクティス』読書メモ