タグ

ブックマーク / blog.shibayu36.org (72)

  • 本の内容が頭に入ってくるのは結局は知見まとめノートを作っている時 - $shibayu36->blog;

    最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうなを2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理

    本の内容が頭に入ってくるのは結局は知見まとめノートを作っている時 - $shibayu36->blog;
    luccafort
    luccafort 2024/02/20
    “自分にとっては「自分の言葉でまとめる」というフェーズを経ないと理解ができないようだ。”ぼくも割とこっち派でいっぱい本を読んでる人とは読み方が違うんだろうなーと思うことがある。
  • 文化による知覚・認識・行動への影響を知る - 異文化理解力を読んだ - $shibayu36->blog;

    文化理解力というおもしろいと聞いたことがあり、興味があったので読んだ。想像以上に面白く夢中になって一気に読んでしまった。 異文化理解力 ― 相手と自分の真意がわかる ビジネスパーソン必須の教養 作者:エリン・メイヤー,田岡恵英治出版Amazon このは、国ごとの文化が、そこに属する人々の知覚・認識・行動へどれほど影響を与えているかを教えてくれる。指標として8つを提示し、それぞれの中で各国がどのような位置にいるかを相対的に示してくれる。8つの指標とは次のようなものだ。 コミュニケーション:ローコンテキストvsハイコンテキスト 評価:直接的なネガティブ・フィードバックvs間接的なネガティブ・フィードバック 説得:原理優先vs応用優先 リード:平等主義vs階層主義 決断:合意志向vsトップダウン式 信頼:タスクベースvs関係ベース 見解の相違:対立型vs対立回避型 スケジューリング:直線

    文化による知覚・認識・行動への影響を知る - 異文化理解力を読んだ - $shibayu36->blog;
    luccafort
    luccafort 2024/02/08
    これめっちゃいい本で確か daiksy さんが教えてくれて読んだんだけど結構忘れてるかも知れないので読み直そうかな。
  • 特定ファイルを更新したマージコミットを探す - $shibayu36->blog;

    あるファイルが最近どの程度の頻度で更新されたのか、マージコミット単位(≒PullRequest単位)で調べたいことがあった。git logのコマンドを使ったら簡単に調べられたのでメモ。 たとえば1年以内に https://github.com/x-motemen/ghq のレポジトリで .github/ 以下に変更を加えたマージコミットを取得したい場合はこんな感じ。 $ git log --merges -m --first-parent --pretty=format:"%cd - %an: %s(%H)" --since="1 year ago" .github/ Sun Apr 16 23:27:26 2023 +0900 - Masayuki Matsuki: Merge pull request #359 from x-motemen/coverage(e7f736f22376d

    特定ファイルを更新したマージコミットを探す - $shibayu36->blog;
    luccafort
    luccafort 2023/09/20
    たまに必要になって調べるもすぐに忘れてしまうやつだ。めっちゃ助かる。
  • コード変更で抜け漏れやミスを少なくするための習慣 - $shibayu36->blog;

    自分はこれまでの仕事で、バグ修正や機能追加でPullRequestを送るときに、考慮の抜けもれやケアレスミスが非常に少ない方であると思っている。振り返ってみて、これは自分に課している習慣が大いに効いていると思っているので、メモしておく。 毎回のcommit時 必要な部分だけをgit addし、git diff --cachedによって差分をセルフコードレビューした上でcommitする PullRequest作成時 filesの内容をセルフコードレビューし、直した方が良い部分は直す + わかりにくい部分にGitHub上でラインコメントを行う + コード上にコメントを残した方がいいならコメントする ユーザーの導線に影響するコードなら、必ず自動テストだけでなく、自分自身でユーザーの行動をトレースし、違和感がある部分が存在しないかチェックする。チェックした流れについては、PullRequest上に

    コード変更で抜け漏れやミスを少なくするための習慣 - $shibayu36->blog;
    luccafort
    luccafort 2022/04/25
    PR作成時のふるまいはやってるものがあるがcommitするときまでここまで細かくやったことはなかった。これだけではないと思うが真似することで得られるものがありそう。
  • 意図せず外部へのネットワークアクセスをしているテストを、WebMockを使って徐々に外部アクセスを減らす話 - $shibayu36->blog;

    最近担当しているRubyプロジェクトで、テスト実行中に外部のサービスに意図せずアクセスしている(たとえばexamle.comへGETリクエストしていたなど)ケースがあった。これはまずいなと思い、WebMockを使って徐々に外部アクセスを減らしていっているので、その話を書く。 課題: テスト中に意図しない外部アクセスがある 現在のプロジェクトではWebMock gemを使って外部へアクセスしないようにモックしながらテストをしていた。しかしWebMockを、外部アクセスするメソッドのテストをする時だけWebMock.enable!し、終わったらWebMock.disable!するとしていた。つまり必要に思った時だけ以下のようなコードを使い、外部アクセスしないようにしていた。 around do |e| WebMock.enable! e.run WebMock.disable! end この

    意図せず外部へのネットワークアクセスをしているテストを、WebMockを使って徐々に外部アクセスを減らす話 - $shibayu36->blog;
    luccafort
    luccafort 2022/01/26
    Rails触りたての頃に例として上がっているようなコードを書いてしまい、意図しない外部アクセスが生まれてしまったことがある。そのときは限定的だったのですぐ直せたがちゃんと直す方法が丁寧に書かれて参考になった
  • 「Scaling Teams 開発チーム 組織と人の成長戦略」を読んだ - $shibayu36->blog;

    開発組織をスケールする方法を学びたい - 「ユニコーン企業のひみつ」を読んだ - $shibayu36->blog;に引き続き、開発組織が拡大しても、一人当たりの生産性を落とさずに、かつ顧客にとって当に必要なものを作り続けるにはどうしたら良いのかのヒントを得るために、「Scaling Teams 開発チーム 組織と人の成長戦略」を読んだ。 Scaling Teams 開発チーム 組織と人の成長戦略 (Compass Booksシリーズ) 作者:David Loftesness,Alexander Grosseマイナビ出版Amazon めちゃくちゃ良かった!このでは、組織のスケールで重要な局面を採用・人事管理・組織・文化・コミュニケーションの5つとし、それぞれに対して何を気をつけるべきかについてまとめてくれている。特に自分の興味と合致する「採用」「組織」の部分は当に参考になった。例えば

    「Scaling Teams 開発チーム 組織と人の成長戦略」を読んだ - $shibayu36->blog;
    luccafort
    luccafort 2021/10/27
    買ってはいたけど積ん読されてしまっていたのでいま読み勧めているものを読み切ったら読んでみようかな。Wantedlyさんが必読書として買われてた中にも含まれてたので多分良書なんだろうな。
  • 「THE MODEL」読んだ - $shibayu36->blog;

    SaaSをちゃんと学び直そうということでTHE MODELを読んだ。SaaSに関する営業活動のやり方全体を学べた。 THE MODEL(MarkeZine BOOKS) マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス 作者:福田 康隆翔泳社Amazon 以下の内容が個人的に印象に残った。 営業活動をマーケティング、インサイドセールス、フィールドセールス、カスタマーサクセスマネージャーと顧客の状況ごとに分業するモデル 商談に至らないリード、失注、未フォローを再び商談化のプロセスへリサイクルする。ビジネスが続けば続くほど効果的となる 人間はグループに分けられると敵対しやすい。関係を良好化するには、接触回数増加・コミュニケーションの内容改善だけでは不足。共同で作業することによって達成可能な共通の目標が有効 読書メモ * あれば便利だが、なくても業務が回るものは、その必

    「THE MODEL」読んだ - $shibayu36->blog;
    luccafort
    luccafort 2021/10/05
    “人間はグループに分けられると敵対しやすい。関係を良好化するには、接触回数増加・コミュニケーションの内容改善だけでは不足。共同で作業することによって達成可能な共通の目標が有効”なるほど〜
  • 株式会社アンドパッドに入社しました - $shibayu36->blog;

    2021/10/01から株式会社アンドパッドに入社しました。初めての転職なので緊張しているけれど、早めに馴染みたい。 andpad.co.jp 転職活動をしている中でいくつかオファーをもらっていたが、以下の理由で株式会社アンドパッドに入社を決めた。 裏側よりの難しい課題をクラウドネイティブな設計で解決するタスクができそう 組織規模が急拡大していて、組織マネジメントの経験が深まりそう 採用フローがしっかりしていて、今後も良い人がどんどん入ってきそう 裏側よりの難しい課題をクラウドネイティブな設計で解決するタスクができそう これまでのエンジニア経験の中ではインフラ〜フロントまで全体的に触ってきたが、自分の中ではインフラ領域〜バックエンド領域の中間くらいのエンジニアリングに最もモチベーションが湧いていた。またクラウドネイティブな設計をもっとできる機会があればなあと思っていた。 このように考えてい

    株式会社アンドパッドに入社しました - $shibayu36->blog;
    luccafort
    luccafort 2021/10/04
    “今後会ってみたい人について必ず質問され、自分が知りたかった情報を集めやすかった”これは確かにいいなぁ。個人ではなくても○○に携わっている人や関係者と話したい…みたいなのはあるからなー。
  • 株式会社はてなを退職しました - $shibayu36->blog;

    2021年8月13日の日が最終出社日でした。しばらく休暇を取り、10月から別の会社でエンジニアをする予定です。 はてなには2010年4月にアルバイトとして入社し、2012年4月からは社員として入社したので、アルバイト2年、社員9年4ヶ月と非常に長い間所属した。仕事の中で、周囲の人の優秀さに圧倒されながら学習とアウトプットをし続け、またいろんなチームや職種を経験させてもらえたおかげで、自分自身がかなり成長できた。はてなに入社できたことで、エンジニア経験がほぼないところから大きく成長できたため、誇張なく人生が変わったと思う。 はてなで経験できたこと 当に色々経験できたのだが、自分の中で当に良い仕事ができたなーと思ったことはこんな感じ。 世界規模で動く通知システム はてなブログMediaの立ち上げ カクヨムの立ち上げ 魔法のiらんどのリプレース ブログチームでのチーム改善や、Mackere

    株式会社はてなを退職しました - $shibayu36->blog;
    luccafort
    luccafort 2021/08/14
    次の職場はどこなんだろう?これからも京都にいるということなので今後もよろしくおねがいします!!!
  • 「独学大全」読んだ - $shibayu36->blog;

    Twitterとかで見かけて気になってたので読んだ。 独学大全――絶対に「学ぶこと」をあきらめたくない人のための55の技法 作者:読書猿ダイヤモンド社Amazon 習慣レバレッジ、カルテ・クセジュ、検索語みがき、目次マトリクスあたりが自分の中で興味深い技法として知れたのが良かった。 読書メモ * 習慣レバレッジ:自分のやりたい独学を、いつもやっている日課をトリガーに引っ掛けて習慣づける 1489 * 1. 一日のうち頻繁に行う習慣(例: スマホを見る、トイレに入る)を選ぶ * 2. その習慣の直前に新しい習慣を行う。簡単ですぐ取り掛かれて短時間で終わるもの(例: 英単語1個覚えるなど)。習慣を作ることが目的なので、覚えきれなくても良い * 3. 2を繰り返し、少しずつ重い習慣に変えていく * 現状のグラフ化や目標などを壁に貼っておくと、誰かの目に触れるかもしれないという可能性だけで、ノート

    「独学大全」読んだ - $shibayu36->blog;
    luccafort
    luccafort 2021/05/18
    買っても絶対積ん読して読みきらないだろうなーと思っていたので買わなかったけど気にはなるんですよね。書店でもくじを読んだ感じはよさそうにはみえた。Kindle版あるし買ってもいい気はするが……。
  • オフィスでの仕事で何が生まれていたか a.k.a リモートワーク時代でも取り戻したいもの - $shibayu36->blog;

    この一年、オフィスのオフラインでの仕事から、一気にリモートワークのオンラインでの仕事に切り替わった。その中で色々困っていることが共有されているが、特に雑談がしづらくなったというデメリットを見かけることが多い。 そこで今回は、リモートワーク時代でもオフィス時代のメリットを享受するためのヒントを得るために、オフィスの仕事で何が生まれていたかを少しだけ掘り下げて考えてみたい。 僕はオフィス時代では次の3つが生まれていたと考えていて、リモートワーク時代でも取り戻したいと考えている。 偶然のアイデアの発見 複数人が勢いで何かをやっていく熱量 自然な知見の横展開 偶然のアイデアの発見 オフィス時代ではその辺で会話していたら、それを周りで聞きつけた人が別職種・別チーム問わずやってきて、簡易ブレストみたいになることがあった。それにより新しい機能アイデアとか、ちょっとした改善アイデアが偶然発見されたりしてい

    オフィスでの仕事で何が生まれていたか a.k.a リモートワーク時代でも取り戻したいもの - $shibayu36->blog;
    luccafort
    luccafort 2021/04/20
    オフラインにおけるシームレスさの濃淡をオンラインではまだまだ表現しにくいんだよなぁ。どうしても分断がされてしまうのでその良さを知っていると不便に感じることがある。
  • プロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行する - $shibayu36->blog;

    プロジェクトマネジメントにおいて、見積もりをどのように行うかは結構難しい。僕は理想日見積もりの形式も、相対見積もり(ストーリーポイント)の形式も試したことがあるが、どちらも一長一短であった。 最近色々試す中で、プロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行するという方式がやりやすいと感じた。今回はその様子を紹介してみる。 理想日見積もりと相対見積もりそれぞれのメリット・デメリット 見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察の記事を読むと、理想日見積もりと相対見積もり(ストーリーポイント)それぞれのメリット・デメリットがさっと把握しやすい。自分としては、それぞれ以下のように思っている。 理想日見積もり : 他の割り込みが全くなく、1日中タスクに取り組んだ場合を1理想日とする見積もり方式 メリット: 他に基準となるタスクがなくてもとりあえず雑に出せる。相対見積

    プロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行する - $shibayu36->blog;
    luccafort
    luccafort 2021/04/06
    双方の見積もりに一長一短あるのはわかるんだけど軸を混ぜてうまくいくイメージがわからなかった。これ覗き見してみたいなーwどうやって進めているんだろう?気になる。
  • Renovateを使ってライブラリアップデートの自動マージ - $shibayu36->blog;

    利用しているライブラリのアップデートは常に行いたいが、中々コストの掛かる作業でもある。その時にテストが通ったらOK・型検証が通ったらOKみたいなライブラリ(例: TypeScriptなら @types/系やjestなど)なら人間の目を通さずに自動でPullRequestをマージしてくれたら、その分コストが減り、人間の目が必要な作業を行う時間が増える。 そこでRenovateを使って上記のようなことをやってみたのでメモしておく。 出来たもの https://github.com/shibayu36/typescript-cli-project/pull/10 のように、Renovateのbotが勝手にPRを作り、勝手にApproveし、テストが通ったら(GitHubのchecksが通ったら)勝手にマージしてくれるようになった。 実現するためにやること Renovateを有効にして、自動マージ

    Renovateを使ってライブラリアップデートの自動マージ - $shibayu36->blog;
    luccafort
    luccafort 2020/11/11
    可能な限り自動化によせていきたい……。まずはそのための環境作りに投資しないと、なんだけど。
  • Jamboardを使ってオンラインでプラニングポーカーをする - $shibayu36->blog;

    Jamboardを使ってオンラインでプラニングポーカーをするお試しをしてみたので知見を共有します。 課題 リモートワークで全員がオンライン前提となり、かつプライベートエリアなのでミーティングではビデオを付けたくないメンバーがいる。もちろんミーティングの円滑化のためにビデオを付けることを強要したくはない。 しかし、プラニングポーカーはこれまで指でフィボナッチ数を出すというモデルでやっていた。ビデオを付けない人がいる場合、このやり方ではプラニングポーカーができない。 こういう状況で、どのようにプラニングポーカーで見積もりを行うかが課題となっていた。 Jamboardを使ってオンラインでプラニングポーカーをする解決案 GoogleのアプリでJamboardというホワイトボードアプリがある。これを使ってプラニングポーカーをしてみた。 やり方 付箋でフィボナッチ数とカーソル置き場を並べたJamboa

    Jamboardを使ってオンラインでプラニングポーカーをする - $shibayu36->blog;
    luccafort
    luccafort 2020/09/03
    muralで投票する形のプランニングポーカーが一番やりやすかったかなぁ。あれは1分以内に投票とか1分以内でも投票打ち切れたりするので比較的やりやすかった印象がある。
  • 現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;

    最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が

    現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;
    luccafort
    luccafort 2020/08/18
    いくつかの箇所で「ウッ……できてない」と思ってしまった。9月中旬くらいになったら時間ができるはずなのでそこで一気に読んでしまおう。
  • 長い期間、継続的にブログを書き続けるための工夫 - $shibayu36->blog;

    10年前からブログを始めて、10年間コツコツコツコツ学んだことや考えたことを記事として書き続けてきた。その結果、ついにブログの記事総数が1000記事近くになってきた。10年間かなり頑張ってきたなあと感慨深い。ありがたいことに読者数も1000人ほどいて色んな人に見てもらえるようになり、これも継続的に書き続けたおかげだなあと思う。 また、ずっとブログを書き続けてきたことで、以下のような多くのメリットを受けることができた。 ブログを書くこと自体が自分の頭の整理に繋がる その後知識を忘れたとしても、ブログを見返せば思い出せる 初めからブログに書くつもりで勉強すると、勉強の効率が上がる 反対意見とかツッコミを入れてくれる人が出てきて、自分の思い違いを正したり、より考えを洗練させることができる 記事を書き続けていると意外と読者が増えていて、気合を入れた記事を書いた時もみんなに見てもらえる 完全公開の場

    長い期間、継続的にブログを書き続けるための工夫 - $shibayu36->blog;
    luccafort
    luccafort 2020/07/17
    "推敲は最大2回"なるほど、無限に推敲は時間取られるんだよなー。
  • React Hooksを学んだ - $shibayu36->blog;

    React学習メモ - $shibayu36->blog;にてReactを学習したので、続いてReact Hooksを学んだ。Reactのドキュメントはわかりやすくて良い... 以下メモ書き。 全体を通して感じたこと 基React Hooksの方が非常に見通しが良くなりそうだけど、今後クラス型コンポーネントを使う意味って何かあるのかな? useEffectの副作用関数とクリーンナップ関数は毎回呼ばれるので、パフォーマンス問題に気をつけよう。基は第二引数指定し、関係する変数の更新があったときのみ実行するようにしたら良い ルールがいくつかあるので、linterは必ず使ったほうが良さそう 各ドキュメントごとのメモ https://ja.reactjs.org/docs/hooks-overview.html useStateはいままでsetStateで使っていたようなものを、useEffec

    React Hooksを学んだ - $shibayu36->blog;
    luccafort
    luccafort 2019/11/01
    KyotoJSで昔やってたReactコールドリーディング、いま改めてやってみたいなって読んでて思った。
  • 「FACTFULNESS」を読んで、自分の会社の長期的な変化にも目を向けたいと感じた - $shibayu36->blog;

    FACTFULNESSというが面白いという話を聞いたので読んだ。前評判どおり、非常に面白く読んで良かったなと感じた。 FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣 作者:ハンス・ロスリング,オーラ・ロスリング,アンナ・ロスリング・ロンランド日経BPAmazon このは「10の思い込みを乗り越え、データを基に世界を正しく見る習慣」を教えてくれるであった。このが事例として挙げているのは世界の情勢や貧困などであったが、自分が働いている会社など自分を取り巻く環境にも同じ考え方が適用できるなという印象を持った。 例えば自分の会社について、「最近全然だめで最悪だ」と思うことはないだろうか。僕は何か悪いことが続くと、このようなことが頭によぎってしまうことが多い。しかしこのの「ネガティブ能」という章に書かれている内容を読んで、ハッとさせ

    「FACTFULNESS」を読んで、自分の会社の長期的な変化にも目を向けたいと感じた - $shibayu36->blog;
    luccafort
    luccafort 2019/07/09
    悪いニュースのほうが目に付きやすいってのはまあそりゃそうなんだろうなとは思うんだけどとはいえ必然的に目にするのはネガティブになりがちでその辺どうコントロールするんだ?って気になった。
  • Gotanda.EM #1 で「グレードイメージ具体化のため昇格理由を公開する」という発表をしてきました - $shibayu36->blog;

    Gotanda.EM #1 - connpassというイベントが開催されたので、「グレードイメージ具体化のため昇格理由を公開する」という発表をしてきました。 発表内容を要約すると グレード役割定義だけでは、グレードごとに期待される具体的な行動やスキルが分からないという声が上がった その解決として、ジョブディスクリプションを作るなどの解決方法もあったが、グレードの昇格理由の公開という形での解決を図った 具体的な行動が少しずつ積み上がっていき、以前よりは具体的にイメージしやすくなる効果があったと感じる 副次的な効果として、評価者のスキルを育てることにもつながると感じる 今回は2年ぶりの発表だったので非常に緊張したのだけど、ある程度評判も良さそうだったので安心しました。懇親会や二次会でも話す内容に困らず濃い話が出来たので発表してよかったです。 Gotanda.EM当に楽しかったです。運営をして

    Gotanda.EM #1 で「グレードイメージ具体化のため昇格理由を公開する」という発表をしてきました - $shibayu36->blog;
    luccafort
    luccafort 2019/04/03
    昇格の理由をクローズにする理由ってあまりないしいいんじゃないかな。納得感あったり昇格するモチベーションにある程度寄与する部分があるように感じる。
  • 問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト - $shibayu36->blog;

    自分の置かれた環境で問題意識を感じることってありますよね。例えば 上司全然ちゃんとやってくれないじゃん!最悪! 会社にこういう問題あるじゃん!なんで直らないの!最悪! みたいな感じ。 昔はこういう問題意識を持った時、自分で「良い状況に変える」ことに苦労をしていました。しかし、最近は自分の意識を変えることで「効率的に良い状況に変える」ことをしやすくなったなと感じています。そこで今回は、どのように自分が意識を変えたかということと、問題意識を感じた時に最近試しているアクションについて書いてみようと思います。 昔に自分がよくやっていたアクション 問題意識を感じた時、昔に自分がよくやってしまっていたのは 飲み会の場で愚痴る 上司に詰め寄る 問題意識だけを提起する というようなアクションです。このようなアクションをした時、良い上司はちゃんと話を聞いてくれて、実際に問題が解決することも多くありました。

    問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト - $shibayu36->blog;
    luccafort
    luccafort 2019/03/05
    これに加えてぼくはやったことの振り返りが結構重要だと思ってて「こういうことやりました」→「あれ変わって楽になったよ」というフィードバックがあると周りももっとポジティブに受け取ってくれるなと感じる。