サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
Switch 2
note.com/dora_e_m
発売から半年近くが経ち、Advent Calendarにも目標づくりの知見が集まり、自律的に目標づくりに取り組む現場が広がっていることを感じています。 目標づくりは一度やって終わりではない本書をお読みになった方はおわかりかと思いますが、目標づくりは一度やって終わりではありません。達成したら終わりでもありません。ひとつの目標にむけた旅路が終わりを告げるとき、また新たな目標を追い求める旅が始まるのです。 そして、このようにして目標づくりの経験を積み重ねることで、自分なりの目標の立て方が出来上がっていきます。 目標づくり習慣化の第一歩目標づくりの経験を積むためには、実際に目標を立て、そこに向かって行動し、達成する/達成できないということをやっていく必要があります。そのときにおすすめなのが、一日単位の小さな目標を立ててみる、ということです。 日常でも小さく目標を立ててみる日常のルーチンになっている
今年は出社回帰の年だったAmazonが出社を義務化した、LYがリモートワークを縮小、など、とにかく出社回帰の動きが目立つ1年でした。 フルリモートでも、人と会うのは大事私の今の会社はフルリモートで、オフィスには全社員分の座席はありません。たまに出社しても全然人がいなかつまたりするのですが、おぎじゅんさんがいると珈琲を淹れてくれたり、その珈琲のまわりに人が集まってきて、違う部署の人たちと交流するきっかけになってたりします。 テキストベースのコミュニケーションを仕組みとして整備する、All-Handsのような全体の意識を揃える場を高頻度に設ける、など、仕組みでフルリモートをワークさせることはできます。 けれども、人間のウェットな部分でのつながりってやっぱり大事です。数カ月に一回でも直接顔を突き合わせて、同じ目線で話すことでチームとしてのまとまりがでてきます。 だから、出社するのは大事だし、わり
これはEngineering Manager Advent Calendar 2024 3日目の記事です。 エンジニアリングマネージャーの大切な仕事のひとつ、「後任の育成」について書きます。 信頼という武器、信頼という鎖エンジニアリングマネージャーにとって、周囲の信頼を獲得することは重要です。信頼があればこそ様々な意思決定や仕組みづくりがスムーズに承認され、浸透し、自分のチームやその周辺のチームの成果を最大化していくことができます。 そして、築きあげた信頼は、ときに自らを縛り付ける鎖にもなります。 新しいチャレンジをしたい。その相談を周囲にするも、「いやいや、〇〇さんじゃないとここは任せられないから！」と言われ現状に留まることを余儀なくされる。必要とされている事自体は嬉しいけれども、チャレンジできないもどかしさ、新しい経験が得られないことへの危機感が募っていきます。 10年ほどマネジメント
エンジニアリングマネージャーの育て方本日（2024/11/19 いいいくおの日）に開催されたEMゆるミートアップで、「2人目EMをどう育てるか」という話が盛り上がりました。 私がマネージャーになったばかりの頃は、エンジニアとしてキャリアを積んでマネージャーになるパスがほとんどだったように思います。最近ではマネジメント適性を見込まれて早い段階でEMになる、または自身がEMを目指すというケースが増えてきている感覚があります。 エンジニアから登るエンジニアとして実績を積み、その結果としてEMになる場合、少なくともその組織でエンジニアチームのとりまとめを任せたいと思うくらいにはエンジニアリングで成果を出している、つまりスキルがあると考えられます。 私が経験してきたキャリアの中では、このパターンが多かったです。そして、この登り方の場合、エンジニアリングマネージャーとして職務をまっとうするためにはマネ
これは何？2013年に初めて「マネージャー」と冠されたロールを担うようになり、気がつけば10年以上「◯◯マネージャー」として過ごしてきた筆者が、そのキャリアをふりかえった文章です。何が自身の成長につながったのか、に焦点をあてています。 なぜnoteに書くの?個人的なふりかえりなのでチラシの裏にでも書いておけばいいのですが、◯◯マネージャーの道を歩む・これから歩む人にとって役立つ可能性があると考え、公開することにしました。 なぜこのタイミングで?初めてマネージャーになったのは2013年4月なので、10周年という区切りからすると中途半端な時期です。ではなぜこのタイミングで書こうと思ったかというと、10/23に誕生日を迎えるので自分的区切りとしてまとめたくなったというのがあります。 あと、そーだいさんが「30代でやってよかったこと」をまとめていて、それがめちゃめちゃよかったので、自分も他の人に役
カレンダー埋まっていませんかふぇぇ…一日中会議に明け暮れて気がついたら夜だよぉ…そんな経験はないでしょうか。 キャリアを重ねていくと責任範囲が広がっていきます。責任範囲が広がっていくと、様々な情報共有や意思決定のためにミーティングが増えていきます。気がつけば一日中ミーティング。新しいことを始める余力なぞ午睡の夢、という状況に陥っていきます。ああ、時間がない。 これまで「ミーティング減らそう！」という主張はしてきたけど、そういえば肝心の「どうやって減らすか」についてはまとめていなかったのでまとめます。 以下ではカレンダーに登録されたミーティングが参加するべきものか、もっというと実施するべきものかを判断するためのチェックポイントを紹介しています。 そのミーティングにはアジェンダがありゴールが明瞭かOARR（Outcome, Agenda, Role, Rule）が定義されていれば、自分が参加す
初のYAPC私が所属するカケハシがPlatinum SponsorとなったYAPC函館に、ブーススタッフとして参加してきました。 前夜祭から熱気がすごい本編は土曜日開催なのですが、前日にはrejectcon（本編では採択されなかったプロポーザルで構成されたミニカンファレンス）を含む前夜祭が開催されました。 ガバクラの話などアツい技術トークが連発されるrejectconは大盛りあがり！ シニアのセッション。これはおぎじゅんさんのスライド残念ながら現地登壇が難しくなったあらたまさんのセッションは、YAPCで参加者同士の交流を促し学び合いの輪をつくる素晴らしい内容でした。 叫んでいたのは私ですすみませんなにげに初めてのスポンサーブース張り付き今回、カケハシはプラチナスポンサーとして、そしてドリンクスポンサーとして参加していました。 参加者マップコーヒーを淹れるおぎじゅんさん参加者マップでどこから
1年経ちましたカケハシにジョインしたのが2023年10月1日。これを書いている2024年9月30日で、丸一年働いていたことになります。あっという間だったような、もっと長い時間を過ごしてきたような不思議な感覚です。いい機会なので、この一年間で得た学びや所感をふりかえってみようと思います。 EMとしてどうだったかマネージャーというのは、成果がわかりづらいロールです。「あのひと何やってるかよくわからないよね」と言われがちな存在です。また、マネージャーが仕事を円滑に進めるには、周囲の人間との間に形成された信頼関係が必要不可欠です。外部からきた人間が最初からマネージャーをやるというのは、なかなかハードルが高いことです。 そんなEM業ですが、チームメンバーの椎葉さんが以下のような素敵な記事を書いてくれました。 めちゃくちゃ嬉しかったし、ここに書かれていることをしっかり全うできているか？は常に自分に問い
時間がない！！マネージャーの皆さん、マネージャーではないけれども割り込みタスクに忙殺されているみなさん、おはようございます。 先日、友人と会話しているときに「いつもレスが速いけど、どうやって処理してるのか」と聞かれました。何って…ただ目の前にきた問い合わせを素早く処理してるだけだが？と思いつつ会話を進めていくと、ああ自分がやっているタスクのさばき方は一つの技術なのかもしれない、と思い至ったので書き記しておきます。なお、基本的にはGTDの考え方でやってます。 前提:人間はシングルコアであるまず前提として、人間はシングルコアです。同時に二つ以上のことはできません。（じゃあギターボーカルはどうなるんだとかそういう話は今回のスコープじゃないので置いておきます。） では、シングルコアしかない人間は、どうやって割り込みタスクに対処すればよいのか。 簡単に捌けるもの（自分が知っていることに関する質問）で
開発生産性の教科書！開発生産性カンファレンスの大盛況ぶりからもわかるように、近年、開発生産性への注目度は高まる一方です。そんな中、満を持して出版されたのが「エンジニア組織を強くする 開発生産性の教科書」です。 ある程度開発生産性について知っているつもりではいるけれども、自分自身の体験でしか知らない。そんな中、開発生産性のプロ中のプロともいえるファインディさんから、しかもCTO自ら筆を執った本が出るということで、これはぜひとも読んでみたいと思い、手に取った次第です。 Why->How->Whatでの構成全9章+Appendixの本書は、おおまかに以下のような構成になっています。 Why なぜ開発生産性向上に取り組むべきか 第1章 How 開発生産性をどのようにして向上させるか 第2章 第3章 第4章 What 開発生産性が向上することで何が起こるのか 第5章 第6章 第7章 第8章 第9章
求められるコミュニケーション能力ソフトウェア開発の業界に身をおいて10数年。「ソフトウェアエンジニア（以下、エンジニア）なら人と話さなくても仕事できていいな！」なんて思っていた私ですが、エンジニアとはいえコミュニケーション能力が求められる場面は少なくない、という事実と日々向き合っています。 エンジニアに求められるコミュニケーション能力には以下のようなものがあります。 技術的な内容を分かりやすく説明する力 チーム内での協力、情報共有 相互の建設的なフィードバック 問題解決のための議論、および調整 ドキュメント作成、メンテナンス 確かにこれらの能力は必要です。何かAPIを使いたいとおもったとき、API仕様書がfuncA,funcBといった名称だとどんなAPIかわからないですし、内容を知ろうとしたときにドキュメントがなければそのAPIを使いこなすことは難しいでしょう。わかりやすい説明ができず、ド
「OKRはツリーではない」から約1年半以前、「OKRはツリーではない」というタイトルで登壇したことがあります。OKRを採用している多くの現場で、組織レベルのOKRから個人レベルのOKRまでをツリーでつなげる「OKRツリー」で運用しているけれど、OKRはツリーじゃなくてもいいんだよということを伝えたい発表でした。 「ツリーじゃなきゃいけないと思っていたけど、ツリーじゃなくてもいいんですね！」など、様々な反響をいただきました。 それから1年半。「OKR」というキーワードを入れてGoogleで画像検索すると、OKRをツリーで捉えた画像がたくさんでてきます。この状況は1年半前とあまり変わっていません。それだけ、目標を組織全体で連携させていくことは重要だということの表れです。 ツリーで扱うときに気をつけておきたいことOKRをツリーで扱うことは、組織ーチームー個人の目標をアラインメントさせるという点に
はじめにイベント終了直後に、失いかけた意識の中で参加レポートを投稿しました。8時間寝て元気が出たので、あらためて加筆修正して投稿します。 スクラムフェス神奈川2024春の陣でキーノートやってきたよいってきました、スクラムフェス神奈川。 プレイベントを挟んで、スクラムフェス神奈川主催としては初めての本格的なカンファレンス(しかも合宿)でキーノートを担当させていただくという身に余る光栄に預かりました。 さて、スクラムフェス神奈川いったいどこでやるのかというと、なんと小田原でした。小田中が小田原へ。 ロマンスカーの神様、今日もありがとうスポンサーLTから最高イベントはまずスポンサーLTから始まったのですが、これがもう最高でした。 スクラムフェスという場を盛り上げるための、マスコットキャラクターの名付けから始まり、モブプロでチームに起こった変化、自分のチーム鬼速で最高！という熱い話が立て続けに繰り
バリューストリームマッピングリーン生産方式の技法の1つである、バリューストリームマッピング(以下、VSM)。価値が生み出されるまでのプロセスを明らかにし、リードタイムを短縮するためのポイントを捕まえることができるVSMと初めて出会ったのは、MSの牛尾さんがきっかけだった。 VSMは、ものすごくざっくりいうと「関係者が全員で、リリース時点からプロセスを逆算して洗い出し、手戻りや待ちなど無駄が発生している箇所を誰から見てもわかるようにする方法」だ。 「いちばんやさしいアジャイル開発の教本」p.51 図表12-4をもとに改変 もう少し詳細にプロセスを書くと、こうだ。 1. 開発サイクルに関係するシステムを確認 2. 開発サイクルの概要を確認 3. 全員でプロセスを書く 4. 手戻り率を書く 5. プロセスのグルーピング 6. 無駄にマークをつけていく 7. 改善案を記載する詳細な説明は、こちらの
はじめに自分たちのチームがどういう状態なのか推定するための指標として、開発生産性フレームワークSPACEの活用を試みているところです。いまのところは概要記事を読んで、元の論文をざっくり読んで、それをもとに「自分たちで追いかけるならこういう指標かな？」って考えて、チームに共有して、みんなでどうするといいだろうねって考える段階。だからnoteとかにまとめるのは、もうすこしカッチリ言語化できたり、その指標を追うことで何か変化が起こったタイミングにしようと思っていました。 先日参加した「EMゆるミートアップ vol.6〜LT会〜」で、HACOBUのけんにぃさんが「チーム実績をSPACEで表現してみるチャレンジ」という発表をされていました。なぜSPACEで表現してみようと思ったのか、何に気をつけているのかなどがコンパクトにまとまった良いLT資料なのでぜひ目を通していただいたのですが、この発表を聞いて
人気すぎて参加できなかった勉強会去る1/15、本来であればこの日に「t-wadaさんが後世に残したい、実録レガシーコード改善」に参加するはずだった私は、PCの前で途方に暮れていました。connpassにログインできなかったのです。 SNSを覗くと、同じように「ログインできない！」という嘆きが多数、観測されました。2,000人を超える参加者が殺到したため、connpassが耐えきれなかったのかもしれません。 主催のFindyさんがYoutubeでも配信するなど救済措置を講じてくれましたが、早々にあきらめてしまった私は結局、この日の講演に参加することは叶いませんでした。 ところが数日後、X上でt_wadaさんから嬉しいサプライズが報告されました。 なんと再放送当日、t_wadaさんがチャット欄に参加するとのこと！再放送してもらえるだけでありがたいのですが、この投稿で俄然テンションが上がっていき
「GRIT やり抜く力」を読んだ2024年、最初に読み切った一冊がこちらの「やり抜く力」でした。以前から存在は知っていたし、有名な書籍であるがゆえにどんな内容かはなんとなく知っていましたが、そういえばちゃんと読んだことないなと思い立ち手にとりました。 情熱と粘り強さを持って物事にあたり、最後までやり切る力。 やり切るためには高い目的意識が必要であり、それと同じくらいにそれを楽しむ、没頭する姿勢が重要であること。その目的意識には利他の精神が宿っていることが前提となること。 粘り強く行動し続けるためにはしなやかマインドセットが土台にあり、適切に成長していくためには外部からのフィードバックが必要となる。 ただ精神論で、気合と根性でやり抜けと喝破するのではなく、やり抜く力を構成する要素を分解している点が良いな、と読んでいて感じました。具体性があると自分の行動に落とし込みやすくなります。 GRITを
はじめにこれはEngineering Manager Advent Calendar 2023 25日目の記事です。 毎日良質な記事がアップされて、完全に俺得な一ヶ月でした。ご参加いただいたみなさんありがとうございます。 最終日の記事では、EM Advent Calendarを俯瞰しながら執筆している私のEMキャリアをふりかえり、結局のところEMとは何なのか、ということを考えてみます。 Advent CalendarにおけるEMの多様性と共通点LLM時代におけるEMという、実に2023年的な切り口から始まったこのAdvent Calendarには、実に多様なコンテンツが集まってきました。 新任EMの方の奮闘の記録、手を動かしてなんぼという考え方、スクラムとの接近、プロジェクトマネジメント的アプローチ、オブザーバビリティのEM業への援用、キャリア論・・・。 共通しているのは「マネジメント対象
はじめにこれはQiitaのEngineering Manager Advent Calendar 24日目の投稿です。 エンジニアリングマネージャー（EM）の役割EMというロールの定義は組織によって異なりますが、共通項としては「チームのパフォーマンスを最大化すること」があります。 チームのパフォーマンスを最大化するためには様々な打ち手が考えられます。 チームのイネーブルメント チームメンバーの採用、育成、評価の実施 キャリア形成支援 パフォーマンス・マネジメント ロードマップに沿ったスケジューリング、チーム内の体制最適化 技術的リーダーシップ 技術的意思決定への参加 技術的課題の解決への貢献 コミュニケーション コミュニケーションパスの設計 チームのAPIとしての機能 プロセス改善 予算管理 チームの規模や会社のフェーズ、そこにいる人々の特性によってとるべき打ち手は異なってきます。 私が今
1on1ミーティングの普及1on1ミーティングが多くの現場に浸透してずいぶん経ちます。1on1という仕組みの普及に大きく貢献したのは「ヤフーの１ｏｎ１―――部下を成長させるコミュニケーションの技法」でしょうか。 本書の帯に「部下のための時間」と書かれていることからわかるように、1on1はその普及段階においては「上司と部下の間で定期的に行われるミーティング」という意味合いでした。 ここ最近では1on1という言葉が指す範囲がもっと広がっていると感じます。同僚同士でのコミュニケーションだったり、定期的ではなく突発的に設けられた場だったり。 物事が普及していく過程でもともと持っていた意味合いが変化していくのはよくあることで、こういった意味の広がり自体が1on1が広く普及しているという事実を物語っています。 同僚同士の1on1上司ー部下という関係性ではなくフラットな関係性での1on1は、上下関係があ
本当に、人間関係に恵まれた人生を送っています。40年近く生きていると、新しく「友人」と呼べる人間に出会える機会は少なくなっていきます。それなのに、CTO Night & Day 2023で「ちゃんさん」という親友と出会ってしまった。 ちゃんさんは、ゲームエイトでCTOを担っているすごい人。ルックスもイケメンだ。そんなちゃんさんの「最も大切にする法則」のnoteを読んで、自分もマネジメントについて大切にしていることを書き留めておこうと思い立ちました。本稿はその成果物です。ちゃんさん無しには生まれなかった成果なので、本稿を読んで得るものがあった方は私ではなくちゃんさんに感謝してください。私とは一緒に飲んでください。 これを読む方は、きっとマネジメントをされていたり、マネジメントをしたいと思っている方だと思います。お忙しいですよね。なので、目次を追えばとりあえずは私が大切にしていることがわかるよ
日本CTO協会が掲げるバリューのひとつ、「Give First / あなたの当たり前は誰かの学び」をテーマに書きます。 なんでもやる課AWS主催のCTO Night and Dayに初めて参加したのが2018年、日本CTO協会にジョインしたのが2019年。自分の肩書はCTOではなくVP of Engineeringですが、それなりの期間CTO界隈に在籍していることもあり、様々なステージの様々なCTO/VPoE/ex-CTOと交流させてもらってます。みなさん本当に視座も志も高く、技術が大好きで、それでいて物腰が柔らか。とても居心地がいいコミュニティです。 皆さんと話しているとよくでてくるキーワードが、「CTOはなんでも屋だ」です。「CTOはTechnologyってついてるけど経営にコミットするし、特にアーリーステージなら本当になんでもやる」というのはよく聞きます。 自分自身はすでに組織がある
一方で、やはりチームに内在する課題、目をそむけたくなるような現実と向き合うことも、やはり大切だ。 ポジティブの渦の中のネガティブ チームがポジティブになっているとき、成果が出ているとき、つまり「いい状態」のとき。こういったポジティブの渦の中にいるというのは、良いことではある。成果が出ていてその上楽しい！という状態なのだから。 しかし、そういった状態の中にいるときだからこそ、感じた違和感を外に出しづらいという問題がある。群衆が熱狂しているときに、誰も自分が率先して「王様の耳はロバの耳だ！」と声を上げたくないのだ。 「心理的安全性のあるチームなら、不都合な真実だって声をあげられるはずだ！」そう、それはその通り。でも、チームがそこまでの状態になっているとは限らない。ではどうするかというと、「仕組み」でカバーするのだ。 いくつか「不都合と向き合う」仕組みを紹介する。 象、死んだ魚、嘔吐いきなりエグ
ストーリーポイントを使った見積もり 今回の話ではストーリーポイントでよ見積もりを是とすることを前提においています。な前提に置くかについては @ryuzee さんの以下の記事に詳しいので、「そもそもストーリーポイントの良さがわからない」という方はまずこちらをご覧ください。いってらっしゃい。 おかえりなさい。読みましたか？言わんとしてることはきっとわかってもらえたと思います。 私がストーリーポイントでの見積もりを提案する現場でもそうでした。だいたい、その意義については理解してもらえる。けれども「規模や大きさを表す相対的な数値」という概念がなかなかつかみどころがない。なんとか自分たちが理解しうるところに手繰り寄せようと工夫した結果、「ストーリーポイントなら1-2時間」のような時間への変換が行われてしまうのです。 それまで扱ったことがない概念だから理解しづらいのはわかる。理解しようと、今理解してい
はじめに2022年から2023年にかけては、各地のスクラムフェスを中心に多くのプロポーザルを提出し、そしてありがたいことに多くのプロポーザルがAcceptedとなり発表する機会に恵まれました。下記が2022年1月から2023年5月までの、プロポーザル提出を経て発表機会を得たものです。 ふりかえってみると月に一度に近いペースで登壇してますね。間にはプロポーザルドリブンではない登壇も何件か挟んでいることを考えると我ながらよく頑張ったな、という感想です。 2022.02 Developers Summit 2022 2022.05 スクラムフェス新潟2022 2022.06 スクラムフェス大阪2022(vivaさんとの共同プロポーザル) 2022.09 スクラムフェス三河2022 2022.10 XP祭り2022 2022.11 Agile Japan 2022 Social Impact 20
はじめにこれは子育てエンジニア Advent Calendar2021 3日目の記事だ。参加は今回で3回目。その分、子どもたちと私達夫婦の間のバランスも変わってきた。だからこそ見えてきたことから、今回の記事を書く。 この記事を読んでほしい人は、子育てが始まってからというものの「自分の時間がとれない」「自己研鑽できない」という悩みを持っている人、そしてその悩みから焦りを感じている人だ。 先に結論を言ってしまうと、子育てで忙しい時期に無理やり時間を作る必要はない。焦る必要はない。なぜなら、一度は消滅してしまった自分の時間はやがてやってくるからだ。 次項より、私の体験を通してその結論に至った理由を解説していく。 小二、年長、幼少クラスの三人子どもたちの年齢および学年は、当然のことながら昨年よりひとつインクリメントした。三人の子どもを育てるというのはそれなりに大変で、てんでばらばらに動き回る子ども
「目標設定、ニガテなんですよね」組織に属するメンバーを育成し、評価する。そのための材料として「目標設定」を活用している組織は多い。MBOか、それに類する形を採用しているところが多いのではないか。（観測範囲での判断なので今は違うかもしれない） そして、「目標設定」を行う組織は多いというのに、「私、目標設定得意なんですよ」というエンジニアの存在は寡聞にして存じ上げない。なぜなのだろう。 エンジニアの目標設定は難しい？組織のレベルでは、「売上○○円」「ユーザー数○○人」「平均DAU○○」といった目標が設定されることが多い。財務に直結するものだ。翻って、エンジニアたちは組織にどう貢献するのか。エンジニアリングだ。直接売上がどうこうではなく、「どうすればビジネスに貢献するか」から立脚された仮説に基づいて行動をしていくことになる。 こうすれば画面遷移数が減って使いやすくなる、その事により利用率が向上す
アンチアジャイル？そういうことじゃない「今どきのテック系ユニコーン企業のソフトウェア開発はこれまでとは別物だ。書籍に書かれているようなアジャイルなんてやってない。もちろんスクラムもだ。」 本文が始まる前、「お目にかかれて光栄です」の冒頭に記載されているこの文章はインパクト大だ。この言葉を見ただけで「いやいやそんなことはない、アジャイルというのはだな・・・」とアジャイルを擁護したくなったり、「ほらアジャイルなんてのは一過性のものだろ、だからうちは（アジャイルなんて）やらないんだ」とうそぶいたり、そういう空中戦が発生してしまいそうなくらい、インパクトがある。 しかし、本書「ユニコーン企業のひみつ」は決して「アジャイルは時代遅れのものですよ、その代わりにこの新しくて素敵な手法があります、さあ使いなさい」という類のものではない。本文を読めばわかる。 まず目次から読み解くでは、本書はいったいどのよう
はじめにこれはいちばんやさしいdora_e_mの Advent Calendar 2020、つまり一人アドベントカレンダーの25日目の記事です。 最終日となる今回は、頻繁に相談される「やりたいことがないんだけど、どうやってキャリアを築いていったらいいか」という問いに対する、私なりの回答を書き記していきます。 キャリアイメージ、ありますか?みなさん、キャリアイメージはお持ちでしょうか。自分がやりたいこと、なりたい像はハッキリしているでしょうか。ハッキリしているなら、この記事は不要かもしれません。 やりたいことがない、何を目指したらいいかわからない。自分もそうでした。今だって、「これをやらずにはおられない」という使命感で昼も夜も情熱を燃やしている、という状態ではありません。それでも、成し遂げたいことや貢献したいことはありますし、プライベートを差し置いてもやりたいようなことが今の自分にはあります
次のページ
このページを最初にブックマークしてみませんか？
『dora_e_m｜note』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
