無限に高さを増す積読の山からなんとか一冊を読み終えたので、 書評というほどでもないですが、学んだことを残しておこうと思います。
一口よりは文量が多くなりそうなので、ワンプレートくらいになると思います。
『生成AI時代の価値の作り方』
AI関連の書籍の中でも、プロンプトエンジニアリングやChatGPTの活用方法とは異なり 業務への導入に特化した書籍が増えてきたことで、気になった書籍はとにかく購入していました。
会社でタスクの一部をメンバーに移譲したことを契機に、 「ユーザーにどんな価値を届けることができるのか」「会社として事業貢献となる価値とはなにか」を考える機会が増えました。 基本は開発する機能の価値を高める方向で思考してはいますが、生成AIを事業活用することが必須になった昨今では どんなことが「価値」をもたらすのかを求めて購入した一冊です。
続きを読む『やり抜く力』感想の最終回です。
PART3の章立ては以下の通りです。
PART3「やり抜く力」を外側から伸ばす
過去分の感想はこちら
続きを読む前回後回しにした書籍『やり抜く力 人生のあらゆる成功を決める「究極の能力」を身につける』のPART2後半部分、第8章と第9章の感想を残します。
前回の記事は以下です。
PART3の投稿は結構遅くなるかもです。
この章を読んだ結果、自分はまだまだ浅いということを思い知ることになった。情熱を支えるには「興味」だけではなく、「目的」も必要ということはPART1でも語られていた。そして取り急ぎ立てた僕の目標は、「楽しくエンジニアとして働く」だった。
しかしこの章では「やり抜く力」の高い人は、「人々の幸福に貢献する」ような目的を持つ傾向が強いことが記されている。少し自分が恥ずかしくなった。
自分が浅い目標を立てたとはいえ、他者を中心とする「目的」が強固な「やり抜く力」を発揮するために必要なことは理解できる。「楽しくエンジニアとして働く」で止まらず、もう一段掘り下げる必要があったということだと思う。なぜ「エンジニアとして働く」のかというところに他者を中心とする「目的」を見出すヒントがあるように思う。
また、この章で自分に足りないと気付いたもう一つのことがある。それは「手本となる人物」に出会うことだ。人付き合いは不得意だし、人の良いところだけでなく悪いところも探してしまう性分だが、これは積極的に改善しなければいけないだろう。
この章の主題は、困難に遭遇したときに「やり抜く」には、何が必要かということだ。こう書くとなにか特定の手法やテクニックが紹介されているように感じるが、困難に遭遇しても努力を続けられる「思考のクセ」が紹介されている。
遭遇する困難として「学習性無気力」が取り上げられている。そして「学習性無気力」に陥りづらい、もしくは乗り越える事のできる気質として「楽観主義」が挙げられている。 自分の苦しみが一時的なもので特定の原因があると考えられるかが肝になる。失敗の原因が自身の能力不足ではなく、努力の不足（＝改善できるもの）と考えられるかということだ。
言葉と行動が「裏腹」になっていないか観察するという節には、ハッとした。自身のことは「楽観主義者」側だと思っているが、注意していないとちょっとしたことで、裏腹になってしまうことが多いように感じたからだ。
課題に前向きに取り組むことができるように、人間は成長できるということをベースとした言動を心がけたい。
前回に引き続き、読み進めている『やり抜く力』の感想を残しておこうと思います。 感想よりは個人的まとめ要素が強いかもしれません。
PART2の章立ては以下の通り。
PART2 「やり抜く力」を内側から伸ばす
前回の感想はこちら ih6109.hatenablog.com
感想が結構長くなりそうだったので、今回は6章と7章の感想のみになります。
続きを読む半年ほど前にインターネットを彷徨っていたところ、本書を紹介するブログを見つけたことがきっかけでポチり、打点の高い積読本の一部となっていたのですが、流石に消化しなければと読み始めた一冊です。
購入するきっかけになったnote記事はこちら
ご多分に漏れず、継続することの難しさを痛感しながら日々を過ごし、 継続力さえ身につけることができれば、大成できるんじゃないかという奢りと共に生きてきましたが、 この書籍を読んだ後にどう生きるかで、今後の人生が決まるんだろうなと考えています。
GRITの名称で知られる「やり抜く力」
この書籍では、3つのパートに分けて、GRITとはなにか、GRITを伸ばす方法が記されています。
PART1まで読み終えたので、ここまでの感想を書き残しておきます。
続きを読む久々にブログ書くモチベが出たので、最近読んだ書籍についてつらつらと書き残しておく。
『落合陽一責任編集 生成ＡＩが変える未来 ー加速するデジタルネイチャー革命ー』 https://www.fusosha.co.jp/books/detail/9784594621568
続きを読むこの形式で書評を書く場合は、過去記事は末尾においたほうがいいことに気づいたので、今回から過去記事は末尾にあります。
扱い切れない量の情報を出しても仕方がない。 ただし、どのくらいの情報が扱いきれないのかの見極めは難しそう。
見極めに労力をつぎ込むくらいなら、基本的に最小限に統一したほうがいいんだろうか。 チャットベースでは一度で色々情報を注ぎ込んでしまうタイプではある。 何度もやり取りするのが手間に感じてしまう。
とりあえず実践してみて感触をつかもうと思う。
日本のカルチャーが有利に働く事例が紹介されているのは、ホッとする要素ではあると思う。 準備をした上で、情報を最小限にして「かんたん」に伝える。 これは一部実践していると思う。 進捗の共有だったり、仕様の説明などではかなり有用である実感がある。
しかし、LT会などの技術プレゼン系ではあまり有用性を感じ切れていない。 おそらく「かんたん」にしきれていなかったり、準備が不足しているのが主な原因だと思う。 選択したテーマや聴衆の反応にも左右されていそうではある。
今までは情報を有していることによる優位性を意識して取り組んでいたことだったが、 もっとシンプルにそのほうが生産的という気持ちで取り組めそう。
相手が何を必要としているかは、常に気を配っている事柄ではある。 困ったことに必要な情報を相手が自覚しているとは限らないということがよくある。 ここはどんな問いをするのかでカバーするしかないと現状は感じている。
書籍の中で出てくる「メモを取る」や「人に伝えることを前提とした準備をする」は仕様や技術ドキュメントという観点で活用できるとは思う。
基本的にはリーダブルコードに準じていれば、そんなに問題になることはないと思う。
具体的な例は著者の人がnoteに記事公開している note.com
音声のほうが情報量が多いのは実感している。 業務で困ったときにミーティングでヘルプを求めることは実践している。
「メンタルモデル」や「コンテキスト」がない場合は、すぐにクイックコールすることを推奨している。 ただ、誰も「メンタルモデル」「コンテキスト」を有していない場合どうすればいいのか。 そのあたりも深堀りしてほしかった。 １章にあるように時間をかけて「理解」するしかないという結論なのかもしれないが。
大切なのは理解しているが、一番むずかしいと思う。 自分が実践してもあとが続かない。 その空気が醸成されているか分かりづらい。 など難しさを挙げればきりがない。
とはいえ自分だけにメリットがあるわけではなく、チーム全体にメリットがあることなので、諦めたくない事項ではある。
自己解決してしまうことが多い性分なので、確認という名目で小さなことでも聞くことを徹底してみようと思う。
基本的に意見交換は好きだ。 でも皮肉というかブラックジョークを交える傾向があるので、TPOをわきまえる必要があるというのは自戒すべきだ。
相手のことを理解して認めるということは、できるタイプの人間ではあると思うが、カロリーも相当に必要する。
意見が対立しても否定しないということは、この書籍に限らず、どこでも指摘されている事項だが、 これが実践できているかは常に不安に思う。 皮肉を交えているということは少なからず否定的なニュアンスを伝えているということなので、不安になるんだと理解はしている。
「自分の意見では」という接頭辞はかなり便利に思う。 コードレビューでコメントを付けるときに活用したい。 正解が一通りではない問題の中で頻繁に出会うのがコードレビューだと思うので。
