サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
WWDC25
note.com/dora_e_m
エンジニアリング統括責任者の手引き「エレガントパズル」「スタッフエンジニア」のWill Larsonによる「エンジニアリング統括責任者の手引き」。ありがたいことに訳者の島田さんよりご恵贈いただき、一通り読み終えたので感想をしたためます。 一言でいうと「技術統括責任者だったことがある人、今まさに技術統括責任者の人、これから技術統括責任者を目指す人」なら必読の一冊です。 全25章、エンジニアリング統括責任者のライフサイクルが網羅本を読み始めるときは、だいたい目次を眺めることからスタートします。 本書の目次を眺めると、エンジニアリング統括責任者のポジションに就くところから離れるところまでが網羅されていることがわかります。 エンジニアリング統括責任者のポジションに就く 最初の90日間 エンジニアリング戦略を立てる 計画の仕方 効果的なバリューを作る エンジニアリング組織の測定 M&Aへの参加 リー
燃え尽き症候群燃え尽き症候群、という言葉を聞いたことはあるでしょうか。聞いたことがない、または言葉は聞いたことがあるけれどよく知らない、という方は、以下が燃え尽き症候群の傾向だよ、というポイントをおさえていただければ。 消耗感（Exhaustion）：エネルギーの枯渇、疲れ切った感覚 シニシズム（Cynicism）：仕事に対する距離感や否定的な態度 効力感の低下（Inefficacy）：業務上の達成感や能力に対する自信の低下 なぜ燃え尽きてしまうのか燃え尽きたい…。矢吹丈のように全力を出し、後には真っ白な灰だけが残る、そういう生き方を望む人もいるでしょう。個人の考えですが、そういった自ら燃やし尽くすことを選ぶ人がそうなることは決して否定はしません。命は燃やし尽くすためのもの、かもしれませんから。 でも、それを望まず、意図せずして燃え尽きてしまうことは、できれば避けたいですね。じゃあ、なんで
はじめに最近、Cursorを使って文章を書いてみよう！という記事をよくみかけるようになりました。これは面白そうだなー、自分が普段書いてるnoteとかにも役に立ちそうだなーと思って試してみたんですが、これがすごく効率的で面白かったので、noteにしたためます。 従来の文章作成の悩みブログを書いている方なら共感していただけると思うんですが、文章を書くときっていざ書き始めると大変なことがいくつか出てくるんです。 自分の文体を一貫させるのが難しい 過去に読んだ本からの引用を探すのに時間がかかる 書きたいことはあるけど、うまく構成できない 書き始めるまでの「腰の重さ」をなんとかしたい なんなら過去に書いた記事と重複した内容を書いちゃうこともあるので、「何を書いたか」に神経を張るのも大変だったりします。助けてくれ、AI。 Cursorを活用した新しいワークフローCursorとは？まず、Cursorとい
EMConf JP 2025が終わった2025年2月27日、実行委員として関わったEMConf JP 2025が大盛況・大好評のうちに幕を閉じました。 参加者、スタッフ、スポンサー、もろもろのサポーターの皆さん、そして実行委員会、様々な角度で関わった方々で作り上げた場はテーマである「増幅と触媒」を体現するような、見たいと願っていたし、見たことのない景色でした。 実行委員会にとってはまだイベントは終わりではなく、ふりかえりなども実施していくのですが、いったんの区切りということで、ごく個人的なふりかえりと僕の視点からの景色をつらつら書いていきます。 初めての実行委員自分にとって、カンファレンスの実行委員というものを経験するのは初めてでした。いや、それどころか、カンファレンスのスタッフもほとんど経験していません。オンラインのふりかえりカンファレンススタッフは一回だけやったけど、オフラインで大規模
はじめにある程度成熟してきたコミュニティにとって、「内輪ノリ」というものは不可避的に発生するものです。長い歴史を重ねるRegional Scrum Gathering Tokyoにもそれは存在しており、ことに先日開催されたRSGT2025ではDay3のOSTやその後の参加者たちによる対話の場で話題として挙がっていました。 自分が内輪に入っていない状態で「内輪ノリ」を感じるとき、そこに居心地の悪さを感じることは大なり小なりあるでしょう。私自身、初めてRSGTに参加した際には独特の空気感に戸惑うことはありました。そしてそれはRSGTに限ったことではなく、新しく飛び込んだコミュニティ、友人に誘われて参加した集まり、様々なところで感じるものでした。 では内輪ノリは、新参者を遠ざける排外的なものでしかないのか？そんなことはありません。コンテキストが共有され前提が形作られたからこそ生まれるノリからは、
発売から半年近くが経ち、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時間」のような時間への変換が行われてしまうのです。 それまで扱ったことがない概念だから理解しづらいのはわかる。理解しようと、今理解してい
次のページ
このページを最初にブックマークしてみませんか？
『dora_e_m｜note』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
