サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ブラックフライデー
daiksy.hatenablog.jp
これは「あらたま・いくおのAdvent Calendar 2025」5日目のエントリです。 昨日はyuya moriさんの『「マネジメントやるのもその育成も無理ゲー」を整理する』でした。 ぼくがこのアドベントカレンダーに登録しようと思ったのは、「あらたま・いくおのマネジメントRadio」がとても好きだからです。 ぼくは言語優位・視覚優位なタイプで、耳からの情報処理があまり得意ではなく、Audibleやポッドキャストを聴く習慣はほとんどありません。ですが、お二人のポッドキャストは、仕事柄共感することも多く、自分にとって身近な話題が多いのですんなり聴くことができ、いつも楽しませてもらっています。 お二人のお話を聴いていると、「いつも楽しそうだな〜」と微笑ましい気持ちになります。マネジメントにまつわる話題なので、時にはシビアな話もあるわけですが、そういうときにもあまり深刻さは感じません。きっと日
あらたま・いくおのマネジメントRadioの最新回（本稿執筆時点）が「マネージャーの横のつながり」だった。 listen.style あらたまさんや、いくおさんと一緒に仕事をしたことはないが、なぜか出てくるエピソードすべてに身に覚えがある。 社内のつながりを深めたいな、とマネージャー同士が集まるお茶会をやってみたけど、思ったより盛り上がらないとか……。 マネージャーは扱う仕事の性質上、どうしても孤独になる。たとえば5人のチームのマネージャーをやっていれば、同じチームの5人は仲間であるが、とはいえその人たちの人事評価に関することは自分の胸の内にしまっておくしかない。人事評価に関することは、同列のマネージャーが相談相手になるが、その人たちと担当プロダクトについて、チームメンバーと同等の熱量で議論するのは難しい。つまり、自分が所属するどの場に対しても、緊密に相談できることと、できないことがあり、常
自分は登山が趣味である。 やりはじめてもう4年ほどになるが、体力が伴っていない悩みがある。リモートワーク生活で普段体を動かすことがなく、体力不足が深刻だ。 先日、積雪期の武奈ヶ岳に行ってきたのだが、途中でどうにも足が動かず、同行者に相談して途中で引き返してもらうことになった（快くリタイアに付き合ってくれた同行者には感謝）。 yamap.com 雪山はこれがはじめてではないのだが、以前登頂できた赤坂山も、自分としてはかなりきついコースだったなぁとふりかえった。 yamap.com 昨年の秋に、友人とはじめて北アルプスに登った。 13時間で標高差1,400mを往復するコース（途中山小屋で1泊する）だったが、これもかなり自分にとってはきつかった。 yamap.com もう少し、普段の地元の六甲山を歩くときのように「疲れたけど楽しかったねー」という感覚でこれらの本格的な山行を終えられないだろうか。
新型コロナウィルスの影響を受けて、広く導入されたリモートワークが、最近になって縮小傾向にある。 ビッグテックをはじめ、それに倣う形で出社回帰の方針を打ち出す企業も少なくない。 これらの企業の発信を見ていると、多くが生産性やコミュニケーションのしづらさを理由にあげているケースが多い。実際、感覚的にはこれは理解できなくもない。 仮に、生産性を理由とした出社回帰を狙うのであれば、リモートワークによって生産性がどの程度低下し、出社回帰によってどのような機序があってどの程度向上することを見込んでいるかの仮説や、その後の検証結果まで知りたいところであるが、今のところ自分はそのような情報を見つけられていない（多分に社内事情を含んだデータになるはずなので、そう気軽に出てくることも期待できない）。 本当にリモートワークで生産性は下がるのか。業務遂行上、出社回帰したほうが事業はやりやすいのか。 AIに手伝って
今年の5月にマネージャーとして転職をした。 daiksy.hatenablog.jp いわゆる出戻りであるのだが、以前の在籍時とはポジションが変わっていたり、3年のブランクがあったりするため、ほぼゼロスタートの気持ちで仕事に取り組んでいる。 マネージャーとして新しく仕事をはじめる場合は、最初の100日は観察に徹するべきだと考えた。それは、宮坂さんのこのエントリを参考にしているためだ。 note.com 最初の100日でもっともしてはいけないことで共通するのが「華麗にビジョンを語り戦略を策定して期待値をあげること」はしてはいけない。逆に最初にすべきことはなにか？「勉強マシーンになること。具体的には資料を読み人に会って話を聞きまくる」こと。つまり最初の100日は「口はほどほどにして耳と目と足を動かせ」ということだ。 なので、試用期間中はエンジニア全員と話そうと、100人との1on1をやるなど、
最近、「計画的偶発性理論」に言及されている記事や登壇がたくさん目に入る。 自分のキャリアをふりかえっても、たしかにそういうところがあるなー、という気分になるので、言及したくなる気持ちもわかる。自分の人生は偶発性のオンパレードだ。ただ、いうほど計画的にその偶然をうまく使えているかなー、所詮ただの生存バイアスじゃないかなーという気持ちにもなる。 そこで、年の瀬ということもあるので自分のキャリアをちょっとふりかえってみる。 ぼくは2001年に社会人になった。就職氷河期真っ只中ではあったが、たまたま大学の就職課で実家近くの会社の求人が掲載されており、ここなら徒歩通勤ができるな、というよこしまな動機で申し込んでみたら内定が出た。選り好みできる状況でも無かったのでそのまま入社した。それがたまたまITの会社だった。当時は求人が本当に無い時代だったが、ITに限ってはまぁまぁ人が足りない状況だったのだ。 キ
id:konifar さんのこの記事を読んで、なんかわかるなー、と思った。 konifar-zatsu.hatenadiary.jp "忘れてた"の例に限らず、人からの指摘に対して過度に敏感になって自分を守るための言葉を紡ぐようになる。 この「自分を守るための言葉」というのがとてもやっかいで、特にマネージャーがこれを多用するとメンバーからの信頼を一瞬で失う。このような言葉を使う人間に対して、なにを相談しようと思うだろうか。 マネージャーという仕事をしていると、メンバーに対して時に厳しいフィードバックを行う場面がある。このような場面では、言いづらいことを言う必要があるわけだが、ここでも「自分を守るための言葉」が頭をもたげてくる。本来率直に伝えるべきことを過剰なオブラートで包んだり、伝えるべきことを伝えずに自分が良い人であるための修辞を重ねてしまったりしてしまうのだ。 「1on1はマネージャー
フルリモートから出社回帰する企業が増えている。 この流れの中で、次のようなケースを時々目にする。 もともと都心部で働いていたが、フルリモートとして就業するのを契機に地方に移住し、家を購入する、というケースだ。 このような人たちが、勤め先の出社回帰によってキャリアの転換に悩む様子を指して、「会社に依存している身でよくそういう判断ができるな」という意見をいくつか見た。 おそらくだが、地方に移住した人たちも、別に会社に強く依存している、というわけではないと思う。いざとなれば、他のフルリモートの就業先、あるいは地元の就業先を探す、くらいの心持ちでは常にいるのではないだろうか。 一方自分はといえば、やはり会社に依存しすぎるということを良しとせず、いざとなれば身軽に首都圏に引っ越すことも視野に入れて賃貸で暮らしている。 考え方の違いにすぎないのではないか。 いろいろな事情があって、新卒で入社した会社を
ある会社が、フルリモートから定期的な出社へと方針を変更するとのことで、インターネットがざわざわしている。 ネット上でいろいろな意見が交わされているが、どうも首都圏に在住している人と、地方在住の人とで温度感が異なるように思い、嗚呼、またか...と憂鬱な気分になる。 東京一極集中という状況は今にはじまったことではなく、そもそも人口の規模が大きく異なるのであるから仕方がないこととはいえ、ソフトウェアエンジニアとして20年とすこし生きている自分のキャリア選択は、常に「このまま地方に住み続けるか、東京に行くか」という天秤の上に乗せられ続けている。 東京に引っ越したほうが、どう考えてもパイは大きいというのは分かっていつつも、生まれてから今まで生活し続けている地元の愛着も捨てがたく、そうそう割り切れるものではない。 しかし、これまで地元にこだわって住み続けている自分も、自宅を賃貸にし続けているのは「いざ
仕事をする机の周囲に本がうず高く積まれている。積読もたくさんある。 今日は自分の蔵書の中からEMっぽい本を並べてみようと思う。 次のような基準でピックアップしてみた。 自分の蔵書(物理本, Kindleライブラリ, Kindle以外の電子書籍ライブラリ)を全部舐めて以下の条件に合致するもの EMとして仕事をしていて、よく読み返したり、引用したりするもの EMの仕事に役立ちそうだなという観点で内容をよく覚えているもの なんとなく分類をしているが、あんまりきっちり時間をかけて精査したわけではない。 タイトルの"75冊"というのは、上記の観点で並べていったらこの数になった、というだけで、なにかの文脈を伴う数字ではない。 (あと2冊無理やり足して77にしようかなと一瞬思ったがそういう余計な小技はやらないことにした) みんなの読んでる本も知りたいな〜〜〜 ぼくが書いた本 (オススメ！) スクラムの拡
ぼくは人見知りだ。 コンビニで「いつもありがとうございます」と顔を覚えられるコミュニケーションをされると、そこに通うのは気まずくなる。（行きつけの居酒屋とか料理屋で覚えてもらえると嬉しいと感じるのでたちが悪い） 飲食店で店員さんが忙しそうにしていると、申し訳なくて注文ができない。特にカウンターの店などは店員さんとの距離感が近いのでもう無理...。なにも頼まなくても勝手に出てくるコースのお店が最高。最近はタッチパッドで自分のペースで注文できる店が増えたのでそれも最高。配膳ロボットいつもありがとう。 この世で最も苦手なものの一つが立食パーティだ。着席形式の会であれば、まだ固定化されたメンツとそれなりの時間を過ごすことになるので、だんだん慣れてくるわけだが、立食パーティとなるともう無理...。会話メンバーは常に入れ替わるし（むしろそうしたいから立食形式を主催は選ぶのであるが）、いったん食事を取り
部門横断的なマネージャーとして仕事をしていると、なにかを決めようと思っても自分だけで自由に決められること、というのはそんなに多くなくて、合意形成がとても重要である。 特に自分のような就任半年の新任マネージャーは、まだまだ過去の経緯やカルチャーなどを充分に理解しているわけではなく、自分がよかれと思って考えていることが、結果として過去の経緯を無視してしまっている、というようなこともある。 つまり、自分の意思決定に対するレビューや、叩き台を叩いてもらって合意形成を図る、というプロセスがとても重要だ。 もちろん、どうしても自分の考える理想に由来する施策、などもあるわけで、そういう場合は反対意見があっても押し切って意思決定する場合もある。とはいえ、そのような場合でも、合意形成のプロセスをやったうえで、「ここは自分がやりたいことだからやらせてほしい」と伝達するうえでやるべきだ。そうでないと、周囲から暴
@941 さんが最近、折にふれて「LTは5分」というのを強調されている。 まさか10分のセッションをLTと呼称していませんよね？ https://t.co/iLigKowObb— 941 / kushii (@941) 2024年12月5日 ぼくもLTといえば5分派閥の人間なので、共感できる。 最近、登壇のご依頼をいただく際に「15分程度のLT形式でお願いします」のようなお誘いを時々見かけるが、その度に、15分も喋るのならそれはLTではなくて普通のトーク（あえて呼び分けるならショートトークとか）なのでは？？ と思いながら口には出さずに過ごしている。 wikipediaの「ライトニングトーク」のページを見てみると。 ja.wikipedia.org 様々な形式があるが、持ち時間が5分という制約が広く共有されている とある。 ライトニングトークの歴史についてまとめられているページがある。 gi
これは、以前別のエントリに掲載した当時の自分のカレンダーの様子である。 マネージャーは油断するとカレンダーがこうなる（今はまだだいぶ余裕を保てているが）。 この図を掲載したときは、定例会を整理したという記事を書いた。 daiksy.hatenablog.jp この記事で書いた当時の自分の文章は、今読んでもおもしろい（おもしろくない）。 このように、10時から16時までのコアタイムは定例ミーティングで埋め尽くされている。これに、採用面接であるとか、突発的な相談ごと、四半期ごとのミーティングなどが数少ない隙間をさらに埋めていく。 ミーティングによって生じるコンテキストスイッチに脳は破壊され、ミーティングの合間の30分間はお手洗いや次のミーティングの準備、あるいは脳を休めるためのTwitterによって無為に消費される。マネージャーとして、組織を改善する施策やアイデアを時間をかけて練ったり、メンバ
技術組織全体を管掌するマネージャーの仕事をしていると、油断すると自分のやっている仕事が誰からも見えていないまま数週間が経つ、ということがある。 自分の仕事の透明性はなるべく保ちたいし、そうでなければメンバーからの信頼は得られないと思っている。 なので、なるべく自分の仕事は以下のように見える化している。 自分のもっているタスクの一覧や進捗状況は、社内のグループウェアの誰でも閲覧可能なページで管理している タスク一覧の更新内容は、Slackの自分の分報チャンネルに流れるようにしている このようにしているのだが、EMの仕事はたとえば人事に関することであったり、評価に関することであったりもするので、そういうのは公開できない。 入社直後は比較的、みんなに見えているタスク一覧の更新は活発だったが、だんだん時間が経つにつれて公開しづらい仕事が増えてきた。 結果、みんなに見えているタスク一覧と、みんなに見
ある日ふと、「最近の自分はアウトプットに臆病になっているなー」と感じ、こういうエントリを書いた。 daiksy.hatenablog.jp 内容は、雑なアウトプットで「だいくしーさん考えが浅いな」みたいな「化けの皮が剥がれる」ことを恐れているが、自分が過剰に意識するほど他人は自分には興味が無いだろうから、気にせずに雑なアウトプットをしたらいいんじゃないか、というものだ。 もう少しこまめにブログを書こうと思ったもう一つの理由は、こにふぁーさん (@konifar)が毎日のようにはてなブックマークのホッテントリ入りをしていて、すごいなーと思ったからだ。 なんでそんなに毎日書けるんだろう、と思っていたら、こういうエントリを書かれていたので、自分も真似しようと思った。 konifar-zatsu.hatenadiary.jp ネタ的なものを思いついたら、iPhoneのメモに書いておく。毎日それを「
若い頃と比べて自分に勢いが無いと感じることがある。 たとえば、ブログを書こうとエディタを開いて書き始めたはいいが、手が止まってしまう。 おもしろそうなカンファレンスにプロポーザルを提出しようと検討するが、結局提出せずに終わってしまう。 昔はこういうときには深く考えずにブログを書いたり、プロポーザルを提出したりしていた気がする。 年齢を重ねて、それなりの社会的なポジションを得ることにより、自分は臆病になってしまったのだと思う。 要するに、化けの皮が剥がれるのが怖いのだ。 「だいくしーさん、普段偉そうなことを言っているわりに、考えが浅いな」とか、「つまらない登壇内容だな」と思われることが怖いのだ。 若い頃はそういうことはあまり気にしなかった。失うものがあまり無かったからだ。考えの浅いブログエントリを書いたところで、誰にも読まれずに埋もれるだけだし、登壇に失敗したところで1週間もすれば誰もそのこ
先日、DevLOVE関西の200回目を記念するイベントで登壇してきました。 登壇内容を考えるにあたって、大きく2案あったので、没にしたほうのネタを簡単にブログに書いて供養しておきます。 ロックバンドの成功の証は、日本武道館でのライブである、みたいなイメージがなんとなくあります。 地元の小さなライブハウスで、客席に友人しかいない状態で演奏するところからはじまって、そこそこ有名になり、対バンに呼ばれるようになって、ソロでライブハウスが埋まり、Zeppなどの大きなハコでやるようになって、そういうステップアップを繰り返した先に、ついに武道館を満員にする。 そのときの彼らの気持ちは、どんなものなんだろうか。 自分にとって、かつて武道館のような舞台がありました。 今は会場が変わりましたが、かつては毎年目黒の雅叙園で開催されていたデブサミ。ここは自分にとっての武道館のようなものでした。 2010年ごろに
仕事のひとつとして、技術組織におけるタレントマネジメントに取り組んでおり、勉強したことを簡単にまとめておく。 タレントマネジメントと一口に言っても、その類型にはいろいろとあり、マッキンゼーの"War for Talent"が書籍も出版されていてよく知られている。これは、簡単に説明すると、社員を成果の発揮度でA, B, Cに位置づけ、組織をAの人材で充足し、Cはなるべく数を減らす、という戦略をとる。選別の要素の強いマネジメント手法であり、あまり日本型の人事管理には馴染まない。そもそも、組織のすべてをA人材で満たす必要はあるのか、A人材のみで充足するためのコストに見合うのか、といった議論もある。 マッキンゼーの"War for Talent"は選別的なアプローチであり、逆に人材すべてをタレントとみなすマネジメントは、包摂アプローチと分類される。 他にもタレントマネジメントの類型はいろいろとある
はてなにエンジニアリングマネージャとして入社して2ヶ月と少し経ちました。 マネージャとしての「最初の100日」もいよいよ終盤です。 note.com 入社して最初の取り組みとして、およそ100人のエンジニア全員との1on1を実施しました。 なぜ全員とやろうと思ったか イギリスの人類学者であるロビン・ダンバーによって提唱された「ダンバー数」というものがあります。 これは、人間が安定的な社会関係を維持することができる人数の認知的な上限について提案された数字です。大雑把に説明すると、人間が相互に認識しあって社会関係を築ける人数はおよそ150人程度、というものです。 要するに1つの組織でお互いに顔見知りの状態で活動ができる集団の人数上限が150人前後であるということです。 このエントリを書いている時点で、はてなのエンジニアはおよそ100人ほどいます。つまり、はてなのエンジニア組織は、まだダンバー数
出戻りとして入社して1ヶ月が経ち、試用期間の1/3が終わろうとしています。 前回のエントリにも書きましたが、「技術グループ」というチームを横断した横串のエンジニア組織の専任エンジニアリングマネージャとして仕事を開始しました。 入社前に最初の1ヶ月でここまではやりたい、と思っていたことがおおよそできたような、少し届いていないような、そういう感覚です。 具体的になにをやったのかを、簡単に書いておこうと思います。 観察と情報収集 daiksy.hatenablog.jp ↑上記エントリでも書いたように、基本的には情報収集に最も時間を使いました。 毎朝30分CTOと1on1をし、目についた端からドキュメントを読みあさり、疑問があればまたCTOとの1on1で掘り下げる。主だったMTGを見学し、ひたすら観察する。こんな感じです。 エンジニア全員1on1 エンジニア組織専任のエンジニアリングマネージャと
今の会社に入社してから10営業日目を迎えました。 前回の転職のときにも書きましたが、マネージャーとしての転職は、他の職種とは違った難しさがあるのを実感する日々です。 マネージャーの仕事は、社内の人々からさまざまな期待をされる役割ですが、リモートワークということもあっていまいち何をしているのかみんなには伝わりづらい仕事です。そこで、毎日日報を書いたり、社内チャットの分報チャンネルにこまめに雑談も含めて吐き出したり、グループウェアに文章を書いたりしています。 このような入社直後のマネージャーの様子を、社内向けにグループウェアに投稿した文章をアレンジして書いておこうと思います。世の中の新任マネージャーの参考に少しでもなりますように。 どういう役割として入社したか はてなでは、組織・基盤開発本部エンジニアリングマネージャーという役割をもって入社しました。 はてなは、はてなブログやMackerelな
2024年5月1日から、株式会社はてなで組織・基盤開発本部のエンジニアリングマネージャとして働き始めました。 2014年から、2021年まで社員だった時代があるため、いわゆる出戻りという形になります。 一度退職した会社に再び入社する、というのは、通常の転職活動と違った悩みなどもあり、自分も今回の転職に際して「アルムナイ採用」などのキーワードでいくつか参考にした記事がありました。 最近は身近な事例も耳にするとはいえ、まだまだ通常の転職と比べてアルムナイ採用は例が少ない気がするので、せっかくなので体験記を書いておこうと思います。 基本的には自分の個別の事例ですので、世間一般のアルムナイ採用の実態とは異なる箇所もあることをご承知おきください。 戻ろうと思ったきっかけ もともと最初にはてなを辞めた理由が、自分の新しいキャリアを志したチャレンジという側面が強かったため、辞めた直後からなんとなく「機会
自分がまさに中間管理職ど真ん中なので、中間管理職の仕事を可能な限り自分なりに言語化してみようと思い、ざっくばらんに思ったことを書いていく。 今回は、情報伝達について。 組織がコンパクトであれば、中間管理職など必要はない。トップの意思がダイレクトに末端までスムーズに伝わるからだ。 組織が大きくなるにつれ、情報の伝達はスムーズにいかなくなる。 帝人の元会長である安居祥策氏が、日本経済新聞に寄稿した記事で記した「√の法則」というものがある。 100人の社員に物事を理解してもらおうと思えば、√100=10 として10回同じ説明をする必要がある。 10,000人の社員が相手になれば、100回になる。 多くの人に自分の考えを理解してもらうためには、このくらい同じ説明を何度も繰り返す必要があるということだ。全社員が集まる集会で、1回説明すれば明日からすべての社員がそのように動く、ということはない。 これ
実は密かな長年の夢だったのですが、この度、技術評論社さんから単著を出版することになりました。 Scrum@Scaleの解説書で、全編書き下ろしです。 紆余曲折があり編集者さんに本を書きませんか、と打診いただいてから2年半ほどの大仕事でした。 Scrum@Scaleについてまとまった日本語の書籍は他にはなく、複数のスクラムチームで仕事をされている現場の大きな手がかりとなるはずであると自負しています。ぜひお手にとってみてください。 スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する 作者:粕谷 大輔技術評論社Amazon 書籍の内容について 本書はぼくが現職でScrum@Scaleを導入した際の知見を惜しみなく注ぎました。全7章の構成です。 第1章 スクラムのスケーリングと大規模の難しさ アジャイルコーチになんの前提もなく「スクラムをスケールするにはどうす
コーチズクリニックとは？ こちらのスライドが詳しい。 speakerdeck.com Regional Scrum Gatheringや、スクラムフェスなどのカンファレンスで設けられる相談の場 カンファレンス参加者が、同じくカンファレンスに参加しているアジャイルコーチに個別相談ができる アジャイルコーチは、自分の得意分野と、カンファレンスのセッションなどに参加していない時間を表明しておく 相談者はそれを見て、自分の相談内容に答えてくれそうなコーチを指名して相談する これを社内でもはじめてみた ぼくの勤める会社にスクラムマスターギルドという集まりがある。毎週1回、30分程度集まって、各チームのスクラムマスターやアジャイルコーチが知見を交換したり、悩みを相談したりする場がある。気軽に相談ができて良い場なのだが、もう少し踏み込んだがっつりした相談をしたいときがある、と意見があった。 そこで、社内
リモートワークは会議室という物理的な制約がないので、ミーティングし放題だ。加えて、オフィスでその人の席まで歩いていってちょっと声をかける、ということができないので、そういうことをしたい場合は30分のテレビ会議を設定する、というようなことになる。 マネージャーという仕事をしていると、前述のような状況とあいまって1日の大半がミーティングで埋め尽くされてしまう。 たとえば、自分の勤務時間範囲のカレンダーから、「定例ミーティング」だけを抽出してみても以下のような有様だ。 このように、10時から16時までのコアタイムは定例ミーティングで埋め尽くされている。これに、採用面接であるとか、突発的な相談ごと、四半期ごとのミーティングなどが数少ない隙間をさらに埋めていく。 ミーティングによって生じるコンテキストスイッチに脳は破壊され、ミーティングの合間の30分間はお手洗いや次のミーティングの準備、あるいは脳を
いよいよ RSGT2022が迫ってきましたね！ これはRSGT2022を待ちわびるアドベントカレンダーの記事です。 qiita.com RSGT 2022では、1月5日の14時からRoomCにて「Scrum@Scaleの理論と実装 - 組織をリファクタリングしながらスケールする」というお話をさせていただきます。 Scrum@Scaleを採用して運用しているチームに今年になって参画し、そこでの取り組みや「Scrum@Scaleってどういうものなの？」といったお話をさせてもらう予定です。 スクラムマスターとしての7ヶ月 さて、ぼくは2021年5月に今の会社にエンジニアリングマネージャーとして入社しました。現在のミッションは、Scrum@Scaleで運用されている部門全体を統括して、その開発プロセスを整えていくのが仕事です。他にも、社内にスクラムを横展開したり、採用・育成などエンジニアリングマネ
これは Chatwork Advent Calendar 2日目のエントリです。 また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。 chatwork.connpass.com スクラムマスターって何をする人なの？ 本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。 スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。 そ
次のページ
このページを最初にブックマークしてみませんか？
『だいくしー(@daiksy)のはてなブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
