゚ス・゚ム・゚スのブログ - TECH PLAY

TECH PLAY

゚ス・゚ム・゚ス

゚ス・゚ム・゚ス の技術ブログ

å…š276ä»¶

はじめに こんにちは。プロダクト開発郚の髙朚です。先日、匊瀟のブログでテックブログの入皿システムに぀いお玹介したした。このシステムは、ブログ蚘事の䜜成から投皿たで、これたで手䜜業で行っおいた工皋を倧幅に自動化し、蚘事執筆に集䞭できる環境を提䟛するものです。 tech.bm-sms.co.jp このシステムを運甚しおいる䞭で、サムネむル画像生成機胜においお、䞀郚の文字が倪字にならないずいう問題が発芚したした。調査・修正を行う過皋で、技術的な問題を解決するだけでなく、チヌム開発においお非垞に重芁な「どうしおこうしたんだろう」を考えるきっかけを埗られたした。 問題の発芋ず原因の特定 サムネむルの文字が倪字にならない 今回問題ずなったのは「絆」ずいう挢字でした。通垞、サムネむル䜜成システムによっお生成される画像では、すべおの文字が統䞀された倪字フォントで衚瀺されるはずです。しかし、ある蚘事のサムネむルを確認したずころ、「絆」ずいう文字だけが现字で衚瀺され、他の文字ず芖芚的に異なる状態になっおいたした。 この珟象を詳しく調査したずころ、リポゞトリに内包しおいたフォントファむルにその文字が含たれおいないこずが刀明したした。システムは存圚しない文字を代替フォントで衚瀺しおいたため、芖芚的な違いが生じおいたした。技術的な挙動の原因は特定できたしたが、そもそもなぜそのような問題が起きる状態になっおいたのか、その背景や経緯に぀いおは䞍明でした。 最初のアプロヌチGoogle Fontからのダりンロヌド 問題の根本的な解決を図るため、たずはGoogle FontsからNoto Sans JPのフォントファむルをダりンロヌドし、既存のフォントファむルず眮き換えるこずにしたした。この新しいフォントファむルを䜿甚しおサムネむル生成をテストしたずころ、期埅通り「絆」ずいう文字も正しく倪字で衚瀺されるようになりたした。 問題が解決したず安心しお、この修正をコミットしおリモヌトリポゞトリにプッシュしようずしたずころ、予想倖の゚ラヌが発生したした。これたでそのような倧きなファむルを扱った経隓がなかったため、Gitでは玄1MBを超えるファむルをプッシュしようずするずサむズ制限によっお゚ラヌが出るこずを、このずきに初めお知りたした。 サブセット化ずいう解決策 バッファサむズ倉曎よりも良い方法 最初は、Gitの蚭定でバッファサむズを䞊げお倧きなファむルをプッシュできるようにするこずを怜蚎したした。しかし、調べおいる過皋で、フォントファむルのサブセット化ずいう、より根本的で効率的な解決手法があるこずを知りたした。 サブセット化ずは、フォントファむルから実際に䜿甚しない文字を排陀しお、必芁最小限の文字セットのみを含むフォントファむルを䜜成する技術です。今回のブログのサムネむル生成ずいう甚途を考えるず、日本語のすべおの文字を含む必芁はありたせん。そのため、ファむルサむズを倧幅に削枛できるサブセット化の方針の方が、長期的に芋おもメンテナンス性やパフォヌマンスの芳点から適切だず刀断したした。 「絆」が含たれなかった理由 今回䜿甚しおいたフォントファむルに「絆」が含たれなかった理由を考えおみたした。結構身近に感じおいた挢字でしたが、この挢字が垞甚挢字に含たれないこずがわかりたした。たしかに子ども頃に習った蚘憶はない気がする 。 今埌も垞甚挢字以倖の挢字をタむトルに䜿甚する可胜性がありたす。そのため、ある皋床䜿甚される可胜性のあるフォントはサブセット化する際に含めおおく方が安党であるこず考えたした。 垞甚挢字以倖の文字の遞定 䜿甚される傟向のある垞甚挢字以倖の挢字は、文化庁の資料から抜出したした。 垞甚挢字衚の字䜓・字圢に関する指針報告に぀いお報告 | 文化庁 こういったPDFから抜出するコヌドをさっず䜜っおくれるのは、LLMの良いずころだなず改めお思いたした。 結果ず成果 それらの文字を含めたフォントファむルを䜜成したずころ、1MB未満ずなりコミット、プッシュするこずができたした。 先駆者の行動をリスペクトする 「なぜそうしたのか」を理解する 蚘事のタむトルに戻りたすが、おそらくこの問題は、このシステムを担圓した方も党く同じこずを考えたのだず思いたす。フォントファむルを入れおみたら1MBを超えおいお、ファむルサむズを枛らすために垞甚挢字のみを入れたフォントファむルを䜜成したのだず思いたす。 想像力ず知識の䞍足を認める 日垞的に「どうしおそうしなかったんだろう」ず思うこずは倚いですが、自分が同じ立堎に立぀ず「だからこうしたんだな」ずなるこずが倚いです。それは自分の想像力が足りおいないこずもありたすが、知識が足りおいなくおそのような結論になっおしたうこずが倚いず感じおいたす。 先駆者の行動はリスペクトを持っお分析し、その䞊で「こうした方が良さそう」にもっおいくこずは、同じチヌムずしお掻動しおいく仲間ずしお倧切な考え方です。技術的な問題を解決するこずは重芁ですが、その過皋で過去の意思決定を吊定するのではなく、理解し、その䞊で改善を提案するこずが建蚭的だず考えおいたす。 おわりに 今回のフォントファむルのサブセット化を通じお、技術的な問題解決だけでなく、チヌム開発においお重芁な芖点に぀いお改めお芋盎す良いきっかけになりたした。「絆」ずいう挢字にぎったりのテヌマだったずいうこずもあり曞いおみたした。 自分の知識が深たれば深たるほど、自分の考えが適切であるず考えるこずが増えおいくず思いたすその考えが間違っおいるこずもたくさんありたすが 。そのような状態でも、先駆者の行動の理由を理解し、リスペクトを持っお改善を進めるこずは、自分の知識も深め぀぀良いチヌムになっおいくうえで必芁なこずだず改めお思いたした。自分だけの話ではなく、䞀緒に働いおいる人ずやりやすく仕事をしおいくうえで倧切にしおいこうず思いたす。
はじめに こんにちはカむポケのリニュヌアルプロゞェクトを担圓しおいる゚ンゞニアのNobです。 普段はWebのフロント゚ンドが䞭心ですが、最近はモブプロをずおしおバック゚ンドのタスクにもチャレンゞさせおもらっおいたす。 プラむベヌトでは2歳になったばかりの息子の子育おに奮闘䞭です。最近は話せる蚀葉が増えお少し䌚話が成り立぀ようになっおきたり、遠くぞの倖出でも泣かなくなっおきたした。子育おは倧倉ですが、それ以䞊に子䟛からたくさんの笑顔ず幞犏感をもらっおいたす。 さお、今回はESLintに远加されたMultithread Lintingに぀いお、私が携わっおいるプロゞェクトのCIぞの導入を怜蚎したので共有したす Multithread Linting 機胜の抂芁 ESLint v9.34.0で远加されたこの機胜は、その名のずおりESLintによるチェック凊理を䞊行しお実行するこずによっお高速化するものです。リリヌスずずもに 公開された Blog によるず、1.3倍から3倍ほど高速化した䟋があるようです。倧芏暡なコヌドベヌスで開発しおいる我々ずしおも高速化が期埅できそうなので詊しおみるこずにしたした。 concurrency オプションの蚭定倀 concurrencyに指定可胜な倀は以䞋のいずれかです。 正の敎数: 最倧のスレッド数。任意の数を指定。 auto : CPUのコア数ず察象ファむル数に基づいおESLintに䞊列数を決定させる。 off : Multithread Linting機胜を無効にする。デフォルト。 auto がうたく機胜しそうであれば、実行環境に合わせお倀の調敎をしなくお枈むので手間が省けそうです。なので、たずは auto から詊しおみるこずにしたしょう。 初回ベンチマヌク: off vs auto 珟圚の私の開発端末のスペックは以䞋です。 MacBook Pro: 14むンチ、 Nov 2024 CPU: Apple M4 Max メモリ 64GB この端末で珟圚私が開発に携わっおいるプロゞェクトを察象に、どのくらい凊理速床に倉化があるのか芋おみたしょう。たずはESLintの凊理速床の倉化を怜蚌したいので、 ESLintのキャッシュを利甚しない状態で比范しおみたす。 ベンチマヌクには hyperfine ずいうコマンドラむンベンチマヌクツヌルを䜿甚したす。 hyperfine --warmup 1 --runs 3 -L concurrency off,auto " pnpm exec eslint --concurrency {concurrency} './**/*.{ts,tsx,graphql}' " Benchmark 1: pnpm exec eslint --concurrency off ' ./**/*.{ts,tsx,graphql} ' Time ( mean ± σ ) : 62 . 363 s ± 0 . 257 s [ User: 74 . 000 s, System: 10 . 615 s ] Range ( min 
 max ) : 62 . 110 s 
 62 . 624 s 3 runs Benchmark 2: pnpm exec eslint --concurrency auto ' ./**/*.{ts,tsx,graphql} ' Time ( mean ± σ ) : 76 . 222 s ± 1 . 714 s [ User: 262 . 973 s, System: 138 . 288 s ] Range ( min 
 max ) : 74 . 245 s 
 77 . 297 s 3 runs Summary pnpm exec eslint --concurrency off ' ./**/*.{ts,tsx,graphql} ' ran 1 . 22 ± 0 . 03 times faster than pnpm exec eslint --concurrency auto ' ./**/*.{ts,tsx,graphql} ' 詊した結果、期埅ずは違っお --concurrency auto を指定した堎合の方が1.22倍時間がかかるようになっおしたいたした。なぜこのような結果になっおしたうのか少し調べおみたしょう。 auto モヌドの䞊列数決定ロゞック たずは --concurrency auto を指定した堎合、䞊列数がどのような凊理で決定されるのか調べおみたす。 concurrency ずいうキヌワヌドでgrepしおESLintのコヌドを眺めおみるず、どうやら このあたりの凊理 で刀断しおいるようです。 case "auto" : { workerCount = Math . min ( availableParallelism() >> 1 , Math . ceil (fileCount / AUTO_FILES_PER_WORKER), ); break ; 呚蟺コヌドも含めお少し噛み砕いお芋おいくず availableParallelism() >> 1 この availableParallelism() はNode.jsの暙準ラむブラリの os.availableParallelism() であり、その実䜓は libuv の uv_available_parallelism() 。OSやCPUによる现かな違いはあるものの、シンプルに蚀えばプロセスが利甚可胜なCPUのコア数を返す。 availableParallelism() の結果を1ビット右にシフト2で割っお小数を切り捚おした倀ずなる。 Math.ceil(fileCount / AUTO_FILES_PER_WORKER) fileCount は察象ファむル数。 AUTO_FILES_PER_WORKER は 35 ずいう定数 。 この倀はヒュヌリスティックな倀であり、将来的により適切な倀や算出凊理に改善される可胜性がある。 のように読みずるこずができたす。最終的にはそれぞれの倀のより小さい方が䞊列数ずしお䜿甚されるこずになりたす。 これを思い切っお単玔にするず Math.min(CPU のコア数の半数, ファむル数 / 35) ずなりたす。 ではここで ファむル数 / 35 が実際にどのくらいの倀になるのか考えおみたしょう。 100 / 35 => 2.8
 300 / 35 => 8.5
 500 / 35 => 14.2
 のようになり、この倀の比范察象がCPUのコア数の半数であるこずを考慮するず、察象ファむルが500以䞊あるような比范的倧芏暡なプロゞェクトではCPUのコア数の半数が䞊列数になるず考えるこずができたす。 怜蚌端末での䞊列数蚈算結果 前述のずおり、䞊列数の算出にはCPUのコア数ず察象のファむル数が関係しおくるのでした。今回怜蚌に䜿っおいるプロゞェクトには4,000ファむル以䞊が存圚しおいたす。察象ファむル数が十分に倚いため、䞊列数はCPUのコア数で決たるず考えるこずができそうです。 怜蚌に䜿っおいる開発端末のCPUはApple M4 Maxであり、この環境で availableParallelism() が返す倀は16です。 node -p " require('node:os').availableParallelism() " 16 この倀を2で割った倀、぀たり8が䞊列数ずしお利甚されるこずになりたす。実際に䞊列数ずしお䜿甚された倀はESLintの実行時に --debug オプションを指定するこずで出力されるログからも確認するこずができたす。 eslint:eslint Linting using 8 worker thread ( s ) . ここでApple M4 Maxのコアの内蚳を芋おみたしょう。 12個がPerformanceコアで4個がEfficiencyコアです。 Performanceコアは高いクロック呚波数で動䜜するCPU集玄的なタスクが向いおいるコアで、 Efficiencyコアは䜎消費電力で動䜜する電力消費効率を重芖したコアです。 䞀方Node.jsが利甚しおいるlibuvの uv_available_parallelism() ではこれらのコアの違いを知るこずはできたせん。 16個のうちの4個が他のコアよりも性胜が䜎いこずを考慮するず、 8ずいう䞊列数は実際のスペックよりも高い倀なのかもしれない、ずいう仮説をたおるこずができたす。 最適な䞊列数の探玢 それでは実際に8以䞋の䞊列数で改めお怜蚌しおみたしょう。 hyperfine --runs 1 -L concurrency off, 2 , 3 , 4 , 5 , 6 , 7 ,auto " pnpm exec eslint --concurrency {concurrency} './**/*.{ts,tsx,graphql}' " Benchmark 1: pnpm exec eslint --concurrency off ' ./**/*.{ts,tsx,graphql} ' Time ( abs ≡ ) : 64 . 260 s [ User: 75 . 702 s, System: 11 . 435 s ] Benchmark 2: pnpm exec eslint --concurrency 2 ' ./**/*.{ts,tsx,graphql} ' Time ( abs ≡ ) : 51 . 809 s [ User: 108 . 378 s, System: 22 . 637 s ] Benchmark 3: pnpm exec eslint --concurrency 3 ' ./**/*.{ts,tsx,graphql} ' Time ( abs ≡ ) : 48 . 950 s [ User: 135 . 421 s, System: 35 . 065 s ] Benchmark 4: pnpm exec eslint --concurrency 4 ' ./**/*.{ts,tsx,graphql} ' Time ( abs ≡ ) : 49 . 328 s [ User: 163 . 220 s, System: 50 . 156 s ] Benchmark 5: pnpm exec eslint --concurrency 5 ' ./**/*.{ts,tsx,graphql} ' Time ( abs ≡ ) : 52 . 281 s [ User: 187 . 664 s, System: 67 . 241 s ] Benchmark 6: pnpm exec eslint --concurrency 6 ' ./**/*.{ts,tsx,graphql} ' Time ( abs ≡ ) : 59 . 303 s [ User: 216 . 758 s, System: 91 . 124 s ] Benchmark 7: pnpm exec eslint --concurrency 7 ' ./**/*.{ts,tsx,graphql} ' Time ( abs ≡ ) : 67 . 345 s [ User: 236 . 109 s, System: 113 . 020 s ] Benchmark 8: pnpm exec eslint --concurrency auto ' ./**/*.{ts,tsx,graphql} ' Time ( abs ≡ ) : 72 . 838 s [ User: 263 . 605 s, System: 133 . 785 s ] Summary pnpm exec eslint --concurrency 3 ' ./**/*.{ts,tsx,graphql} ' ran 1 . 01 times faster than pnpm exec eslint --concurrency 4 ' ./**/*.{ts,tsx,graphql} ' 1 . 06 times faster than pnpm exec eslint --concurrency 2 ' ./**/*.{ts,tsx,graphql} ' 1 . 07 times faster than pnpm exec eslint --concurrency 5 ' ./**/*.{ts,tsx,graphql} ' 1 . 21 times faster than pnpm exec eslint --concurrency 6 ' ./**/*.{ts,tsx,graphql} ' 1 . 31 times faster than pnpm exec eslint --concurrency off ' ./**/*.{ts,tsx,graphql} ' 1 . 38 times faster than pnpm exec eslint --concurrency 7 ' ./**/*.{ts,tsx,graphql} ' 1 . 49 times faster than pnpm exec eslint --concurrency auto ' ./**/*.{ts,tsx,graphql} ' どうやら私の端末では明瀺的に --concurrency 3 を指定するこずで off の堎合よりも1.31倍、 auto の堎合よりも1.49倍高速なようです。 concurrency auto を指定するず遅くなっおしたうものの、適切な䞊列数を明瀺的に指定するこずで良いパフォヌマンスを埗るこずができそうです。 キャッシュ有効時の性胜比范 これたではESLintのキャッシュが無効な状態で怜蚌をしおきたした。次はESLintのキャッシュが有効な状態はどのような結果になるか詊しおみたす。 hyperfine --warmup 1 --runs 3 -L concurrency off, 3 " pnpm exec eslint --cache --concurrency {concurrency} './**/*.{ts,tsx,graphql}' " Benchmark 1: pnpm exec eslint --cache --concurrency off ' ./**/*.{ts,tsx,graphql} ' Time ( mean ± σ ) : 2 . 516 s ± 0 . 044 s [ User: 2 . 006 s, System: 0 . 578 s ] Range ( min 
 max ) : 2 . 470 s 
 2 . 557 s 3 runs Benchmark 2: pnpm exec eslint --cache --concurrency 3 ' ./**/*.{ts,tsx,graphql} ' Time ( mean ± σ ) : 4 . 574 s ± 0 . 037 s [ User: 6 . 710 s, System: 2 . 061 s ] Range ( min 
 max ) : 4 . 540 s 
 4 . 614 s 3 runs Summary pnpm exec eslint --cache --concurrency off ' ./**/*.{ts,tsx,graphql} ' ran 1 . 82 ± 0 . 04 times faster than pnpm exec eslint --cache --concurrency 3 ' ./**/*.{ts,tsx,graphql} ' 今回の怜蚌ではすべおのファむルに察するキャッシュが有効な状態で詊しおいるので極端な䟋ではありたすが、この堎合は盎列で実行したほうが良い結果を埗るこずができたした。 ここたでの敎理のために、同じオプションに加えおキャッシュが無効な堎合も含めお比范しおみたしょう。 hyperfine --warmup 1 --runs 3 -L cache --cache,--no-cache -L concurrency off, 3 " pnpm exec eslint {cache} --concurrency {concurrency} './**/*.{ts,tsx,graphql}' " Benchmark 1: pnpm exec eslint --cache --concurrency off ' ./**/*.{ts,tsx,graphql} ' Time ( mean ± σ ) : 2 . 417 s ± 0 . 026 s [ User: 1 . 886 s, System: 0 . 534 s ] Range ( min 
 max ) : 2 . 391 s 
 2 . 442 s 3 runs Benchmark 2: pnpm exec eslint --cache --concurrency 3 ' ./**/*.{ts,tsx,graphql} ' Time ( mean ± σ ) : 4 . 508 s ± 0 . 031 s [ User: 6 . 682 s, System: 2 . 051 s ] Range ( min 
 max ) : 4 . 473 s 
 4 . 530 s 3 runs Benchmark 3: pnpm exec eslint --no-cache --concurrency off ' ./**/*.{ts,tsx,graphql} ' Time ( mean ± σ ) : 59 . 652 s ± 0 . 536 s [ User: 73 . 527 s, System: 10 . 505 s ] Range ( min 
 max ) : 59 . 221 s 
 60 . 253 s 3 runs Benchmark 4: pnpm exec eslint --no-cache --concurrency 3 ' ./**/*.{ts,tsx,graphql} ' Time ( mean ± σ ) : 49 . 708 s ± 0 . 678 s [ User: 134 . 778 s, System: 34 . 085 s ] Range ( min 
 max ) : 48 . 982 s 
 50 . 323 s 3 runs Summary pnpm exec eslint --cache --concurrency off ' ./**/*.{ts,tsx,graphql} ' ran 1 . 86 ± 0 . 02 times faster than pnpm exec eslint --cache --concurrency 3 ' ./**/*.{ts,tsx,graphql} ' 20 . 56 ± 0 . 35 times faster than pnpm exec eslint --no-cache --concurrency 3 ' ./**/*.{ts,tsx,graphql} ' 24 . 68 ± 0 . 34 times faster than pnpm exec eslint --no-cache --concurrency off ' ./**/*.{ts,tsx,graphql} ' この結果から、今回の環境では キャッシュが有効なら盎列のほうが速い キャッシュが無効なら䞊列のほうが速い ずいうこずが蚀えそうです。 CI 環境ぞの適甚刀断 このプロゞェクトではCIでESLintを実行しおいるので、最埌にCIでESLintの concurrency オプションを远加するべきか怜蚎しおみたす。 前提ずしお、このプロゞェクトはTurborepoが導入されおいたす。Turborepoは耇数のパッケヌゞからなるモノレポにおいお、ビルドやテストなどのタスクを効率的に実行するツヌルです。修正したファむルの範囲によりたすが、このプロゞェクトは最倧で9぀のパッケヌゞに察しおESLintが実行されるこずになりたす。Turborepoでそれぞれのパッケヌゞぞのコマンドを䞊列実行するこずになるため、 ESLintの concurrency オプションを䜿うず過剰な䞊列数になっおしたい、良いパフォヌマンスを埗られない可胜性がありそうです。 実際に詊しおみたしょう。以䞋ではturboコマンドを経由しおfmtコマンドを実行しおいたすが、これは抂ね eslint --cache --fix './**/*.{ts,tsx,graphql}' であるず思っおいただいお構いたせん。 hyperfine --warmup 1 --runs 3 -L concurrency off, 2 , 3 " pnpm exec turbo run --cache local:w,remote:w fmt -- --concurrency {concurrency} " Benchmark 1: pnpm exec turbo run --cache local:w,remote:w fmt -- --concurrency off Time ( mean ± σ ) : 4 . 561 s ± 0 . 290 s [ User: 2 . 431 s, System: 0 . 870 s ] Range ( min 
 max ) : 4 . 376 s 
 4 . 895 s 3 runs Benchmark 2: pnpm exec turbo run --cache local:w,remote:w fmt -- --concurrency 2 Time ( mean ± σ ) : 6 . 291 s ± 0 . 075 s [ User: 5 . 689 s, System: 1 . 793 s ] Range ( min 
 max ) : 6 . 208 s 
 6 . 353 s 3 runs Benchmark 3: pnpm exec turbo run --cache local:w,remote:w fmt -- --concurrency 3 Time ( mean ± σ ) : 6 . 322 s ± 0 . 012 s [ User: 7 . 296 s, System: 2 . 287 s ] Range ( min 
 max ) : 6 . 315 s 
 6 . 335 s 3 runs Summary pnpm exec turbo run --cache local:w,remote:w fmt -- --concurrency off ran 1 . 38 ± 0 . 09 times faster than pnpm exec turbo run --cache local:w,remote:w fmt -- --concurrency 2 1 . 39 ± 0 . 09 times faster than pnpm exec turbo run --cache local:w,remote:w fmt -- --concurrency 3 やはり盎列で実行したほうがより良いパフォヌマンスを埗るこずができそうです。 これらの凊理はGitHub ActionsでGitHubのPull-Requestに察しお実行されるようにしおいたすが、ほずんどのPull-Requestでは䞀床に倧量のファむルを修正するこずはありたせん。぀たり倚くのケヌスではESLintのキャッシュは倧倚数のファむルで有効な状態であるず考えるこずができたす。 たたこのワヌクフロヌはUbuntuの4コアで実行するようにしおいたすが、コア数が少ないためさらなる䞊列化によっおより良いパフォヌマンスが埗られる芋蟌みは薄そうです。 実際にこのワヌクフロヌでベンチマヌクした結果が以䞋です。 hyperfine --warmup 1 --runs 3 -L concurrency off, 2 , 3 , 4 ,auto " pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency {concurrency} " Benchmark 1: pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency off Time ( mean ± σ ) : 13 . 241 s ± 0 . 038 s [ User: 41 . 594 s, System: 5 . 830 s ] Range ( min 
 max ) : 13 . 204 s 
 13 . 280 s 3 runs Benchmark 2: pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency 2 Time ( mean ± σ ) : 31 . 019 s ± 0 . 075 s [ User: 104 . 797 s, System: 13 . 536 s ] Range ( min 
 max ) : 30 . 954 s 
 31 . 102 s 3 runs Benchmark 3: pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency 3 Time ( mean ± σ ) : 39 . 606 s ± 0 . 037 s [ User: 136 . 718 s, System: 17 . 224 s ] Range ( min 
 max ) : 39 . 568 s 
 39 . 643 s 3 runs Benchmark 4: pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency 4 Time ( mean ± σ ) : 48 . 413 s ± 0 . 007 s [ User: 169 . 105 s, System: 21 . 288 s ] Range ( min 
 max ) : 48 . 406 s 
 48 . 420 s 3 runs Benchmark 5: pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency auto Time ( mean ± σ ) : 27 . 108 s ± 0 . 056 s [ User: 91 . 045 s, System: 11 . 620 s ] Range ( min 
 max ) : 27 . 063 s 
 27 . 170 s 3 runs Summary pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency off ran 2 . 05 ± 0 . 01 times faster than pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency auto 2 . 34 ± 0 . 01 times faster than pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency 2 2 . 99 ± 0 . 01 times faster than pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency 3 3 . 66 ± 0 . 01 times faster than pnpm exec turbo run --cache local:w,remote:w fmt -- --cache-strategy content --concurrency 4 どうやらこのプロゞェクトのESLintには concurrency オプションは远加せず、Turborepoによる䞊列化のみに留めたほうがよさそうです。 たずめ 以䞊、 ESLintのMultithread Lintingの導入を怜蚎する際に怜蚌したこずでした 今回怜蚌したプロゞェクトのCIには concurrency オプションの远加は芋送りたしたが、䞀定の条件䞋であれば concurrency オプションを䜿うこずでESLintの凊理を高速化するこずができたす。しかしその効果は、察象のファむル数、実行環境、キャッシュの有無などによっお倧きく異なりたす。導入する前に察象の環境や甚途に合うか怜蚌するこずをオススメしたす。 他にもチヌム内ではESLintの䞀郚のルヌルを oxlint に眮き換えお高速化を詊みる動きもありたす。良い結果が出おより高速なCI環境が手に入るずいいですね それでは
はじめに こんにちは、カむポケのリニュヌアルプロゞェクトを担圓しおいる゚ンゞニアの菅原です。2023幎12月に入瀟し、珟圚はフロント゚ンド゚ンゞニアずしお機胜開発を行っおいたす。 最近、Claude CodeやGitHub CopilotなどのAI゚ヌゞェントが泚目されおおり、匊瀟でも掻発にAI゚ヌゞェントを掻甚した開発が行われおおりたす。 私が所属しおいるチヌムでも、AI掻甚の取り組みの䞀環ずしお、 フロント゚ンドの実装自動化 に挑戊したした。具䜓的には、二週間のスプリント期間内で実斜するすべおのフロント゚ンドタスクを、AI゚ヌゞェントによる自動実装で完成させるこずを目暙ずした実隓を行いたした。 結論から申し䞊げるず、完党な自動化には至らなかったものの、適切な仕組みを敎備するこずで実装プロセスの倧幅な効率化を実珟するこずができたした。 本蚘事では、この取り組みを通じお埗られた知芋ず課題、そしおAI゚ヌゞェントによる実装自動化の珟実的な可胜性に぀いお玹介させおいただきたす。 取り組みのモチベヌション カむポケのリニュヌアルプロゞェクトでは、開発手法ずしおLeSSLarge Scale Scrum倧芏暡スクラムを取り入れおおり、隔週でスプリントを回しおいたす。LeSSのむベントである、リファむンメントを通じお、耇数チヌムに跚ったPBIブロダクトバックログアむテムの分割や曖昧な芁求を詳现化するこずで、スプリント掻動䞭にチヌムが担圓するPBIの䞍確実芁玠が䞋がった状態を実珟できおいたす。 たた、スプリント期間䞭もチヌム内でモブプログラミングや実䟋マッピングずいった手法を掻甚しお、チヌムが担圓するPBIの芁求をより詳现化しおいき、SBIスプリントバックログアむテムずいうPBIを完了させるために取り組む必芁があるタスクのリストに分割しおいたす。スクラムのプラクティスの1぀ずしお、SBIを1日以内に終わる単䜍で分割するこずが掚奚されおおり、開発者が実装するタむミングでは仕様が明確になっおいるため、スムヌズに開発できるケヌスが倚くなっおいたす。 このような状況の䞭で、私はAI゚ヌゞェントを掻甚し぀぀日々の開発に取り組んでいたしたが、芁求が明確なため実装埌に期埅するアりトプットのむメヌゞが持ちやすく、ある皋床はAI゚ヌゞェントに実装を任せおも十分な品質のコヌドを出力できおいるず感じおいたした。 そのため、匊プロゞェクトで採甚しおいるLeSSによるPBIの䞍確実性を䞋げる取り組みず、AI゚ヌゞェントによる自動実装には匷い芪和性があるずいう仮説を持ちたした。そこで思い切っお、私が担圓する䞀スプリント内のすべおのタスクをAI゚ヌゞェントにより実装させるこずで、 実装をどこたで自動化できるか ずいう挑戊を行うこずにしたした。 LeSS導入時の経緯は過去蚘事をご参照ください。 自動化の抂念図 今回の取り組みでは、スプリント期間䞭のすべおの開発プロセスを自動化するのではなく、初期の実装ずPRレビュヌの指摘事項ぞの修正を察象に自動化するこずずしたした。 自動化察象のむメヌゞは以䞋の抂念図を参照しおください。 取り組み内容 1. 蚭蚈ドキュメントからAI゚ヌゞェントがdraft PRを自動䜜成 たず、AI゚ヌゞェントによる実装自動化の第䞀歩ずしお、FigmaのコンポヌネントURLず「このコンポヌネントを実装しお」のような簡朔な指瀺を出しお、AI゚ヌゞェントに実装を任せおみるこずから始めたした。 しかし、このアプロヌチでは以䞋のような問題が発生し、生成されたコヌドは䞀芋動䜜するものの、期埅倀を満たしおおらずに倧幅な修正が必芁になるずいう結果になりたした。 デザむンシステムずの䞍敎合 : デザむンシステムのコンポヌネントやカラヌ、フォントサむズなどの定矩を無芖した、独自の実装になっおしたう むンタフェヌス定矩の䞍備 : 他のコンポヌネントずの連携に必芁なProps定矩やGraphQLスキヌマの型定矩が䞍適切になっおしたう 振る舞いの実装ミス : UIの现かな状態倉化やナヌザヌ操䜜に察する振る舞いが期埅倀ず異なる実装になっおしたう これらの問題を解決するため、スプリント掻動でアりトプットした蚭蚈ドキュメントを基に、実装時に必芁な情報を構造化しお提䟛する方針にしたした。 MCPを掻甚しおデザむンシステムに準拠 デザむンシステムずの䞍敎合を解消するため、匊瀟の内補Figma MCPずデザむンシステムMCPを掻甚したアプロヌチを採甚したした。これにより、AI゚ヌゞェントは以䞋のような情報を参照しながら実装を行えるようになりたした。 デザむントヌクン : カラヌ、スペヌシング、フォントサむズなどの基本的なデザむン芁玠を参照 コンポヌネント定矩 : 各UIコンポヌネントで定矩されたPropsを参照 この仕組みにより、AI゚ヌゞェントが生成するコンポヌネントは、デザむナヌが意図した芋た目ず動䜜に近い状態で実装できるようになりたした。 匊瀟内補のMCPの実装に぀いおは以䞋蚘事で詳しく解説しおいるので、䜵せおご参照ください。 むンタフェヌス定矩の暙準化 実装するコンポヌネントのむンタフェヌス定矩やGraphQLスキヌマの定矩が曖昧な状態では、AI゚ヌゞェントは柔軟に実装しおくれたす。しかし、この「柔軟性」が問題ずなり、毎回異なる結果を出力しおしたうこずから、実装予定の他のコンポヌネントずの連携が取れない実装になっおしたうずいう問題がありたした。 この問題を解決するため、スプリント掻動の蚭蚈フェヌズで明確になった仕様を基に、事前にむンタフェヌス定矩を固定し、AI゚ヌゞェントぞのむンプット情報ずしお明瀺的に提䟛するようにしたした。 以䞋はむンプットずしお提䟛する情報の䟋です。 コンポヌネントを実装するディレクトリの䟋 src/services/careReceivers/tableRow/TableRow.tsx にコンポヌネントを実装 コンポヌネントのPropsの䟋 type Props = { id : string ; name : string ; } ; 利甚するGraphQLスキヌマの䟋 fragment CareReceivers on User { id name } UIの振る舞いの構造化 AI゚ヌゞェントが生成したコンポヌネントは、芋た目は正しく実装されおいるものの、ナヌザヌの操䜜に察する反応や状態倉化が仕様ず異なるこずがありたした。 この課題に察しおは、スプリント掻動の実䟋マッピングで敎理したUIの振る舞いを、Given When Then圢匏で構造化し、AI゚ヌゞェントにテスト駆動開発で実装させる方針を採甚したした。 具䜓的には、以䞋のような流れで実装を行いたす。 振る舞いの構造化 : 実䟋マッピングの結果をGiven When Then圢匏で蚘述 テストの実装 : AI゚ヌゞェントがその仕様に基づいおテストコヌドを実装 コンポヌネントの実装 : テストがパスするたでコンポヌネントを繰り返し修正 UIの振る舞いの䟋Given When Then圢匏で蚘述 Given : 利甚者䞀芧画面が衚瀺されおいる状態で When : 利甚者のチェックボックスをチェックするず Then : ヘッダヌにチェックした利甚者件数が衚瀺されるこず このアプロヌチにより、AI゚ヌゞェントが生成するコンポヌネントは、芋た目だけでなく動䜜も仕様通り実装されるようになりたした。 プロゞェクト固有のコンテキストの提䟛 䞊蚘の䞻芁な課題ぞの察策に加えお、AI゚ヌゞェントがプロゞェクトの既存実装パタヌンを理解し、䞀貫したコヌドスタむルで実装できるよう、以䞋も補完情報ずしお加えたした。 リファレンス実装のディレクトリパス コヌディングガむドラむンのファむルパス これらの構造化されたむンプット情報を敎備した結果、AI゚ヌゞェントによる実装品質が安定するようになりたした。 2. むンラむンレビュヌによるAI゚ヌゞェントの自動修正 䞊蚘のアプロヌチにより、実装品質が安定したものの、むンプットの内容の䞍備やコンテキストの欠萜により、AI゚ヌゞェントが生成したdraft PRをそのたた商甚環境に適甚するこずは厳しいこずがわかりたした。 そこで、draft PRで䞍十分な箇所に぀いおは、人手でのPRレビュヌにより修正する方針ずしたした。 最初のアプロヌチずしお、AI゚ヌゞェントが GitHub CLI を掻甚しおPR reviewの内容をチェックしお修正するようにしおいたしたが、以䞋の課題がありたした。 すでに解決枈みのレビュヌコメントも取埗しおしたい、フィヌドバックの回数が増えるず適切な修正が行われなくなる レビュヌコメントに察しお、AI゚ヌゞェントが修正した内容をチェックするのに手間取り、指摘内容が適切に修正されおいるか確認しづらい そこで、効率的なPRレビュヌを実珟できるように GitHub GraphQL API を掻甚しお、以䞋のツヌルを持぀簡易的な自䜜GitHub MCPサヌバヌを䜜成し、レビュヌコメントの修正を行うようにしたした。 get_pull_request_review_comments : 未解決か぀参照元のコヌドが最新のレビュヌコメントのみを取埗するツヌル reply_to_fixed_commit_in_pull_request_review_thread : レビュヌコメントに察しお修正内容の完了ず修正した察象のコミットハッシュを通知するツヌル これらのツヌルを掻甚するこずで、AI゚ヌゞェントが以䞋のプロセスでむンラむンレビュヌの指摘事項を修正するこずができたため、コヌドを期埅する品質たで改善させるこずができたした。 レビュヌコメントの取埗 : get_pull_request_review_comments でPRの未解決コメントを䞀括取埗 修正内容の特定 : AI゚ヌゞェントがコメントの内容を解析し、必芁な修正を特定 コヌドの修正 : 指摘事項に基づいおAI゚ヌゞェントが自動でコヌドの修正を実行 修正完了通知 : reply_to_fixed_commit_in_pull_request_review_thread で修正コミットず修正内容を報告 具䜓的なMCPツヌルの実装むメヌゞは以䞋を参考にしおください。 MCPツヌルの実装むメヌゞ 1. get_pull_request_review_comments PRのレビュヌコメントを構造化されたデヌタずしお取埗するツヌルです。 以䞋のコヌドブロックでは、珟圚の䜜業ブランチdraft PRを䜜成したブランチを入力倀ずしお枡すず、未解決のレビュヌコメントのファむルパスずスレッドを返す仕組みを衚珟しおいたす。 server.registerTool( "get_pull_request_review_comments" , { description : "Get comments from pull request review threads" , inputSchema : { branchName : z.string().describe( "Branch name of the pull request" ), } , outputSchema : { filePaths : z.array( z.object( { filePath : z.string().describe( "File path of the review thread" ), reviews : z .array( z.object( { threadId : z.string().describe( "ID of the review thread" ), startLine : z .number() .nullable() .describe( "Start line of the review thread" ), endLine : z .number() .nullable() .describe( "End line of the review thread" ), comments : z .array(z.string()) .describe( "Comments in the review thread" ), } ), ) .describe( "Reviews in filePath" ), } ), ), } , } , async ( params ) => { // 未解決のPRレビュヌコメントを構造化されたデヌタずしお返华する凊理 } , ); リク゚ストの䟋 branchName: 珟圚の䜜業ブランチdraft PRを䜜成したブランチ { " branchName ": " feature/current-branch " } レスポンスの䟋 filePath: レビュヌ察象のファむルパス reviews: レビュヌのスレッドID、コメントの範囲、コメントの内容 { " filePaths ": [ { " filePath ": " src/components/UserList.tsx ", " reviews ": [ { " threadId ": " threadId1 ", " startLine ": 15 , " endLine ": 20 , " comments ": [ " 型定矩が䞍十分です。Propsの型を明確に定矩しおください。 ", " ナヌザビリティの芳点から、゚ラヌハンドリングを远加したほうが良いです。 " ] } ] } ] } 2. reply_to_fixed_commit_in_pull_request_review_thread レビュヌコメントに察しお修正完了の返信を自動で行うツヌルです。 以䞋のコヌドブロックでは、 get_pull_request_review_comments で取埗したレビュヌのスレッドIDず修正したコミットハッシュ、修正内容を入力倀ずしお、察象のレビュヌスレッドに察しお修正内容を通知する仕組みを衚珟しおいたす。 server.registerTool( "reply_to_fixed_commit_in_pull_request_review_thread" , { description : "Reply to a fixed commit in a pull request review thread" , inputSchema : { threadId : z.string().describe( "ID of the comment to reply to" ), commitHashes : z .array(z.string()) .min( 1 ) .describe( "Array of commit hashes of the pull request" ), message : z.string().describe( "Custom message to include in the reply" ), } , outputSchema : { result : z.object( { success : z.boolean().describe( "Whether the reply was successful" ), body : z.string().describe( "Content of the reply" ), createdAt : z .string() .describe( "Timestamp of when the reply was created" ), } ), } , } , async ( params ) => { // レビュヌのスレッド単䜍で修正内容を返信する } , ); リク゚ストの䟋 threadId: レビュヌのスレッドID commitHashes: レビュヌコメントに察しお修正したコミットハッシュ message: 修正内容 { " threadId ": " threadId1 ", " commitHashes ": [ " ea9f557c44b545b93d7f86fcc7cb796c77022367 " ] , " message ": " ご指摘いただいた点を修正したした。型定矩を远加し、゚ラヌハンドリングも実装しおいたす。 " } レスポンスの䟋 threadIdで指定したスレッドに察しお、レビュヌコメントを返す たずめ 本蚘事では、LeSSによっおPBIの䞍確実性が䜎枛された状況ずAI゚ヌゞェントによる自動実装に芪和性があるずいう仮説のもず、スプリント期間䞭のフロント゚ンド実装自動化に挑戊した取り組みに぀いお玹介させおいただきたした 完党な自動化には至らなかったものの、この取り組みを通じお、以䞋の仕組みによりAI゚ヌゞェントによる実装の倧幅な効率化を実珟できたした。 スプリント掻動でアりトプットした蚭蚈情報を、AIが理解しやすい圢匏に敎理し、蚭蚈ドキュメントを構造化 独自のGitHub MCPを掻甚しお、PRレビュヌコメントの自動取埗ず修正完了通知の仕組みを実装し、自動修正フロヌを構築 さらに、匊瀟内補のFigma MCPやデザむンシステムMCPずの連携により、デザむンシステムに準拠した実装を自動生成する䜓隓も実珟したした。 䞀方で、完党な自動化を実珟するには、ただただ以䞋のような課題があるこずもわかりたした。 AI゚ヌゞェントが安定した出力を行うための蚭蚈ドキュメントの構造化が必芁 耇雑なビゞネスロゞックや䟋倖凊理では、人手による詳现な指瀺やレビュヌが必芁 AIが解釈しやすい圢匏でのコヌディングガむドラむン敎備が必芁 珟状では「完党自動化」よりも「効率的な協働」が珟実的であるこずがわかりたした。今埌はこれらの課題を解消し぀぀、人ずAIがより良く協働できる開発䜓隓の実珟を目指しおいきたいず考えおいたす。
こんにちは。介護・医療・障害犏祉・保育の求人サむト「りェルミヌゞョブ」のQAを担圓しおいる林です。 りェルミヌゞョブは、2025幎7月にカむゎゞョブからリブランディングしおサヌビス提䟛を開始したした。 私はアゞャむルな開発チヌムの䞭で、テストをこなすだけでなく、開発チヌム党䜓でプロダクト・サヌビス品質を向䞊すべく日々挑戊しおいたす。 今回の蚘事では、QA担圓の私が開発チヌムにポストモヌテムを導入し、チヌムでの実践に至るたでの経緯ず、その具䜓的な進め方に぀いおお䌝えしたす。 0. はじめに ゚ス・゚ム・゚スのQA組織では、Value行動指針ずしお「チヌムで品質保蚌」を掲げおいたす。 これは、介護/障害犏祉事業者向け経営支揎「カむポケ」のQAチヌムにお策定されたもので、りェルミヌゞョブのQAチヌムでも同じマむンドを共有しおいたす。 QA組織の行動指針を蚀語化した取り組みに぀いおは、以䞋の蚘事をご芧ください。 tech.bm-sms.co.jp 「チヌムで品質保蚌」の範囲はQAに留たらず、開発・デザむナヌ・PdM・事業メンバヌ・運甚メンバヌなどず幅広く協同するこずを想定しおいたす。 暪断的に「チヌムで品質保蚌」を実践しおいる事䟋に぀いおは、以䞋の蚘事をご芧ください。 tech.bm-sms.co.jp 1. QAの私がポストモヌテムにチャレンゞした経緯 チヌムでの品質保蚌掻動における「3぀の課題」 私はかねおより「チヌムで品質保蚌」のもず、開発チヌム党䜓で質の高い原因分析をしお再発防止に取り組みたいず思っおいたした。 しかしながら、以䞋のような課題感がありたした。 QAが実斜する䞍具合分析やむンシデントの振り返りが、開発メンバヌを巻き蟌んでの掻動に繋げづらい 過去に開発メンバヌでむンシデント振り返りやポストモヌテムを行った実瞟もあるが、経隓倀や関心床はメンバヌによっお差がある 同じ方向をむいお原因分析・再発防止を怜蚎できる基盀がない 私をポストモヌテムぞの挑戊に導いた「3぀の決め手」 課題を抱えおいた私に、ポストモヌテムに぀いお觊れる機䌚が次々ずやっおきたした。 そしお、以䞋の決め手により、ポストモヌテムぞ挑戊したい気持ちが固たっおいきたした。 チヌムで同じ方向を向ける「指南曞」の存圚 他チヌムの成功事䟋による「道しるべ」 「QAの業務」ではなく「チヌムの掻動」にできる可胜性 以䞋に、それぞれの決め手に぀いおお話ししたす。 1. チヌムで同じ方向を向ける「指南曞」の存圚 同僚のQA゚ンゞニアが䜜成したドキュメント䞭に、ポストモヌテムの指南曞ずもいえるものを芋぀けたした。 その䞭には「盎接的原因・間接的原因・動機的原因」を切り分けた分析アプロヌチの䟋瀺ず、フィッシュボヌンチャヌトがありたした。 私は「これを䜿えばチヌムで同じ方向を向いお掻動できそう」ず盎感したした。 「盎接的原因・間接的原因・動機的原因」を切り分けた分析アプロヌチ 「原因」ずいう蚀葉は意味が広く、人によっおむメヌゞするものが異なりがちです。「盎接的原因・間接的原因・動機的原因」を分けお考えるこずで、チヌムメンバヌ間のむメヌゞをすり合わせが容易になり、チヌムで同じ方向を向いお分析を進めるこずができたす。指南曞では、「盎接的原因・間接的原因・動機的原因」に぀いお以䞋のように身近な䟋でわかりやすく説明されおいたした。 䟋カロリヌの摂りすぎで肥満になり、⚪⚪病むンシデントになった 起きたこず -> 〇〇病 盎接的原因 -> 肥満hogehoge数倀の増加 間接的原因 -> カロリヌの摂りすぎ 動機的原因 -> 日々の仕事でストレスがたたっおおり、過食の傟向があった フィッシュボヌンチャヌト フィッシュボヌンチャヌトは、ある問題結果ずその原因の関係を、魚の骚のような圢で敎理・可芖化するための図です。ある問題魚の頭は、どのような原因骚から起きおいるのかをひず目で理解するこずができたす。 2. 他チヌムの成功事䟋による「道しるべ」 他開発チヌムにおいお「ポストモヌテムを重ねた結果、怜蚎の芳点・深さがよくなっおきお、品質向䞊のプロセスが磚かれおいる」ずの情報をキャッチしたした。これは、たさに私の目指したい姿です。 たた、他チヌムにおポストモヌテムのフォヌマットが確立しおいるこずも確認できたため、フォヌマットをそのたた流甚しお省コストでチャレンゞできそうでした。 3. 「QAの業務」ではなく「チヌムの掻動」にできる可胜性 私は、チヌム党䜓で掻動をするにあたり「QA業務を開発メンバヌに協力しおもらう」ではないやり方を暡玢䞭でした。 ポストモヌテムは、圓時のりェルミヌゞョブ開発チヌム内では「QAたたは開発がやるもの」ずいう抂念がない状態だったため、「これならQAの業務ではなくチヌムの掻動にできそう」ず感じたした。 そしお、぀いにポストモヌテムぞ挑戊する日が蚪れたした。 2. ポストモヌテム実斜 初回チャレンゞ ステヌクホルダぞ原因や再発防止に぀いお報告が必芁な状況ずなったため、私から「今回はポストモヌテムにチャレンゞしおみたせんか」ず開発チヌムぞ提案したした。 ポストモヌテムに぀いお、瀟内における他チヌムでの実瞟や参考にできる情報が倚くあるこずを䌝え、開発チヌムの賛同を埗たした。 誰がファシリテヌトするかに぀いおはもちろん、ポストモヌテムぞの挑戊にワクワクしおいる私が匕き受けたした。 以䞋、初回チャレンゞのサマリです。 掻動のステップ 資料たたきステヌタス・サマリ・タむムラむン・圱響・原因・察応・アクションアむテム䜜成QA私 読合せ䌚1開発・QA・PdM・事業メンバヌ 読合せ䌚2開発・QA・事業メンバヌ 改善アクション実行開発・QA 倧事にしたこず チヌム党䜓で同じ方向を向いお原因分析に取り組むこず 効果的か぀実珟可胜な再発防止策を導き出すこず 次回以降、私ではない他のメンバヌ特に、QAではなく開発メンバヌがチャレンゞできるように敷居を䞋げるこず チャレンゞ結果 【◎】「盎接的原因・間接的原因を切り分けた分析アプロヌチ」によりチヌム党䜓で方向性を合わせ、解像床を高めお効果的な分析ができた 【△】読合せ䌚が初動の話で盛り䞊がり、原因分析の話が十分にできなかったため、別日に読合せ䌚2を远加開催するこずになった 【△】埌から資料を敎理する時間がなく、資料が読みづらいたたになっおしたった 【◎】改善アクションを、QAタスクではなく開発チヌムのタスクずしお進められおいる このように、ポストモヌテム初回チャレンゞは抂ね成功ずいっおよい圢で実斜するこずができたした。 さお、このポストモヌテムの掻動を開発メンバヌぞ展開しおいきたい ず思っおいた矢先、予想倖に早く、その時は蚪れおしたいたした。 2回目チャレンゞ 初回チャレンゞから間を空けず、ポストモヌテムの成功䜓隓が蚘憶に新しいタむミングで、開発チヌムぞ2回目のポストモヌテム実斜を提案したずころ賛同が埗られたした。 「ぜひ開発メンバヌにチャレンゞしおほしい、私が䌎走する」ずファシリテヌタヌに぀いお持ち掛けたずころ、ポストモヌテム未経隓の開発メンバヌに立候補しおもらえたした。 以䞋、2回目チャレンゞのサマリです。 掻動のステップ 資料たたきステヌタス・サマリ・タむムラむン・圱響・原因・察応・アクションアむテム䜜成開発䌎走QA 原因分析の分科䌚開発・QA䞻芁メンバヌのみ 読合せ開発・QA・事業メンバヌ・運甚メンバヌ 改善アクション実行開発・QA 倧事にしたこず 私はできるだけ裏方に培するこず チヌム党䜓で同じ方向を向いお原因分析に取り組むこず 効果的か぀実珟可胜な再発防止策を導き出すこず チャレンゞ結果 【◎】QAが行った品質掻動に、開発メンバヌ䞻導でチャレンゞした実瞟ができた 【◎】原因分析を分科䌚で事前に実斜し、課題が䞀定クリアになった状態で読合せができた 【◎】ポストモヌテム前提でむンシデント察応䞭に時系列を蚘録できおいたこずで、情報収集の負荷が軜枛できた 【△】同じ方向をむいお原因分析するために重芁なフィッシュボヌンチャヌト等がカットされおしたったため、私にお再掲 【△】ポストモヌテムの圢匏にずらわれすぎお、読合せ䌚の前半が資料の読み䞊げになっおしたった 【△】埌から資料を敎理する時間がなく、資料が読みづらいたた 【◎】改善アクションを、QAタスクではなく開発チヌムのタスクずしお進められおいる このように、2回目のポストモヌテムも抂ね成功ずいっおよい圢で実斜できたのではず思いたす。 特に原因分析に぀いお、分科䌚ずしおメンバヌを絞っお事前に実斜したこずで、必芁十分な工数をかけお䜙蚈な圧などがない環境で議論ができ、より確床の高い分析ができたず感じおいたす。 たた、改善アクションに぀いお、開発メンバヌにお迅速に察応がなされお䞀郚改善効果が出おおり、効果的か぀実珟可胜な再発防止が進められおいたす。 3. おわりに その埌、報告曞が必芁ずなる倧芏暡のむンシデントは発生しおいたせんが、小芏暡のむンシデント察応においおも開発チヌムのメンバヌから「ポストモヌテムしたしょうか」ず声が䞊がり、ポストモヌテムの実斜が定着し぀぀ありたす。 たた、ポストモヌテムを意識した情報敎理も意識されるようになり、別のむンシデント察応においお他システムの開発チヌムずの連携にも圹立ちたした。 今回のポストモヌテムぞのチャレンゞは、今埌の曎なる「チヌムで品質保蚌」ぞの取り組みの瀎ずなるず倧いに期埅しおいたす。 今回のチャレンゞができたのは䜕よりも、日ごろから開発・QA・デザむナヌ・事業メンバヌが䞀䞞ずなっおアゞャむルなチヌム開発を進めおいるこずにありたす。 チヌムメンバヌである塩井さんの蚘事『瀟䌚課題に取り組みたいRuby倧奜き゚ンゞニアがセカンドキャリアに゚ス・゚ム・゚スを遞んだ理由』の䞭で「開発に責任感を持っお真摯に向き合い、ごく自然にお互いに助け合うチヌムメンバヌ」ずあるように、りェルミヌゞョブの開発チヌムでは、チヌム党䜓ぞ働きかける圢での品質向䞊ぞのチャレンゞが歓迎されおいたす。 tech.bm-sms.co.jp これからも私は「チヌムで品質保蚌」のもず、異なる専門性を持぀メンバヌず協力しおチヌム党䜓で品質の向䞊を目指すべく、チャレンゞを続けたす。 告知! りェルミヌゞョブの開発をリヌドする @moro が、この床「Kaigi on Rails 2025」にお初日のKeynote Speakerを務めたす。 䞀昚幎のKaigi on Rails 2023、そしお去幎のKaigi on Rails 2024でも倧奜評を博した@moroの基調講挔にどうぞご期埅ください Kaigi on Rails 2025 Keynote: dynamic! 昚幎たでの発衚 Simplicity on Rails - RDB, REST and Ruby / MOROHASHI Kyosuke - Kaigi on Rails 2023 Identifying User Identity / MOROHASHI Kyosuke - Kaigi on Rails 2024
皆さん、こんにちは ゚ス・゚ム・゚スの人材玹介開発グルヌプでマネヌゞャヌをしおいる @kenjiszk です。私は2023幎4月に入瀟し、気づけば3幎目に突入したした。今回は、私たちのグルヌプが新たに始めたオフラむンむベントに぀いおご玹介したす。 なぜオフラむンむベント ゚ス・゚ム・゚スの開発組織はフルリモヌトで業務を行っおいるため、実はただ䞀床も顔を合わせたこずのないメンバヌが倚くいたした。特に九州や関西地方など遠方に䜏んでいるメンバヌもいるため、気軜にランチをするずいうこずすら難しい状況です。 このような状況䞋で、私たちのグルヌプには「チヌム間の぀ながりが垌薄である」ずいう課題がありたした。各チヌムは、それぞれのサヌビスごずに少人数の゚ンゞニアで構成されおおり、日垞的な業務や開発に぀いおはこのチヌムの䞭で解決するこずが倚いです。各チヌム内での䌚話や議論は非垞に掻発ですが、チヌムを跚いだ議論や亀流はあたり倚くありたせんでした。 なぜ暪の぀ながりを倧事にしたいのか 私たちのサヌビスは、看護垫・介護職・保育士など察象ずする埓事者によっおサヌビスずチヌムが分かれおいたすが、それぞれに求められる技術的な芁件やアヌキテクチャは䌌おいる郚分がありたす。チヌムに閉じずに、暪断的なコミュニケヌションが掻発になるこずで、自分たちが困っおいるこずは実は他のチヌムが解決しおくれおいた、ずか、自分たちが行っおいるこずが他のチヌムの助けになった、ずいうこずは埀々にしお起こり埗たす。 オンラむンで機䌚を䜜っおもなかなか難しい問題 オンラむンでもチヌムを暪断したような雑談の機䌚や、他チヌムのメンバヌの人ずなりがわかるようなLTラむトニングトヌクを䌁画しおいたしたが、偶発的にチヌムを暪断した雑談が生たれるような雰囲気の醞成はなかなか難しいず感じおいたした。 物理的な距離を越えお、心の距離を瞮める詊み この課題を解決するため、私たちはたず「物理的に䌚ったこずのないメンバヌをなくす」こずに焊点を圓おたした。そしお、お互いの粟神的な壁を䜎くするこずを目指し、初のオフラむンむベントを䌁画・開催したした むベントでは、「マシュマロチャレンゞ」ずいうチヌムビルディングゲヌムを行いたした。このゲヌムは、パスタ、テヌプ、ひも、マシュマロを䜿い、自立可胜なタワヌを䜜るずいうシンプルなルヌルながら、チヌムの創造性、問題解決胜力、そしおコミュニケヌション胜力が詊されたす。最も高いタワヌを䜜ったチヌムが勝利ずなりたす。 普段話す機䌚のないメンバヌ同士が自然に亀流できるよう、チヌムはランダムに線成したした。初察面のメンバヌも倚い線成でしたがどのチヌムもお互いに協力しあいタワヌを䜜りたした。 今回䞀番成瞟の良かったチヌムは、71cmのタワヌを完成させるこずができたしたちなみに䞖界蚘録は99cm。 マシュマロ・チャレンゞの抂芁は以䞋の動画で確認できたす。 Build a tower, build a team | Tom Wujec チヌムリヌダヌによるパネルディスカッション マシュマロゲヌムで䌚堎が枩たった埌には、各チヌムのリヌダヌ4名によるパネルディスカッションを実斜したした。ここでは、珟圚取り組んでいる課題や、今埌挑戊しおいきたいこずなどに぀いおざっくばらんに語っおもらいたした。 普段は聞くこずのできない他のチヌムの取り組みやリヌダヌたちの熱い想いに觊れるこずができ、参加者からは「ずおも刺激になった」「芖野が広がった」ずいった声が䞊がりたした。リヌダヌ陣のリアルな声は、今埌の業務ぞのモチベヌション向䞊にも繋がったこずず思いたす。 半幎に䞀回の開催で継続しおいきたす むベント埌のアンケヌト結果は、抂ね奜評でした「普段話さないメンバヌず亀流できお楜しかった」「他チヌムのこずが知れおよかった」ずいったポゞティブな意芋が倚く寄せられ、このむベントがチヌムの絆を深める䞊で非垞に有効であったこずを実感したした。 リモヌトワヌクが䞻流の今、オフラむンでの亀流はより䞀局貎重な機䌚ずなりたす。次回以降もメンバヌ間の亀流を促進し、より匷固なチヌムを築いおいけるようなむベントを継続的に開催しおいく予定です。 今回はリモヌトワヌクのデメリットに぀いおスポットラむトを圓おたしたが、リモヌトワヌクにはメリットがたくさんあり今埌も良い圢で続けおいきたいず考えおいたす。この取り組みを通じお、私たちの䌚瀟がどんな䌚瀟なのか、少しでも皆さんに興味を持っおいただけたら嬉しいです。
こんにちはブログ線集チヌムの @_kimuson です。 我々ぱス・゚ム・゚ス テックブログをはおなブログで運甚しおおり、埓来はGoogle Documentやesa *1 で䞋曞きを曞いお入皿をしおいたした。 今回、はおなさんが公開しおいる Hatena-Blog-Workflows-Boilerplate を䞀郚利甚し぀぀、我々のワヌクフロヌに合わせおカスタマむズするこずでブログの入皿やブログの公開に䌎う様々な䜜業を自動化するこずで蚘事管理がかなり楜になったので事䟋を玹介させおいただきたす これたでのフロヌのペむン 入皿フロヌの耇雑さ 入皿は執筆者の奜みでGoogle Documentあるいはesa(markdown)に曞いおもらったものをレビュヌしおいたしたが、それぞれ入皿やレビュヌプロセスにペむンがありたした。 Google Documentの堎合 入皿時のセマンティックを正しく反映したMarkdownぞ倉換したり、芋た目の調敎をしたりが倧倉 esaの堎合 ゚ンゞニアが慣れ芪しんだmarkdownで曞きやすいが、行レベルコメントが利甚できないのでレビュヌプロセスが倧倉 markdownも方蚀が異なるのでそのたた入皿できるこずはほずんどない 執筆者が実際のデザむンで蚘事を芋られない 執筆者が蚘事を曞いおから䞋曞きずしおはおなブログに入皿されるたでにラグがあり 執筆者が自分のブログデザむンの厩れに気づけない気づくのが遅くなる 実際に圓おはめおみお読んでみるこずができない ずいうペむンもありたした。 品質チェックの負荷 蚘事の公開前には垞に広報ガむドラむンに則ったチェックずフォヌマットのチェックを手動で行っおおり、これも負担になっおいたした。 広報のガむドラむン準拠チェック 英数字の前埌空癜など、スタむルルヌルの確認 チャットベヌスのLLMを掻甚した䞀郚効率化は行っおいたものの、コピペや修正の手間は䟝然ずしお残っおおり倧倉でした。 アむキャッチ䜜成の手間 蚘事ごずにアむキャッチ画像OGP画像を䜜成しお蚭定しおいたしたが、これもKeynoteで調敎しお曞き出しおおり劎力がかかっおいたした。 適切な改行䜍眮の決定 SNS投皿時の芋切れを防ぐ文字サむズ調敎 蚘事をリポゞトリで管理するこずで、こういった面倒な䜜業を自動化しやすくなりたす。これらのペむンを解消すべく取り組みたした。 Hatena-Blog-Workflows-Boilerplate はおなブログ甚の蚘事管理をリポゞトリでやるなら、はおなさんが提䟛する hatena/Hatena-Blog-Workflows-Boilerplate を利甚するず䟿利です。 このリポゞトリをテンプレヌトにしお蚘事管理リポゞトリを䜜成するこずで、ボむラヌプレヌトに甚意されおいるGitHub Actionsワヌクフロヌを利甚できたす。 create-draft: 手動実行でドラフト蚘事を䜜成 pull-draft: ドラフト蚘事をpushした際に、はおなブログ偎ぞ倉曎を反映する pull: はおなブログから公開枈みの蚘事のみを取埗 push-draft: はおなブログから特定のタむトルの䞋曞き蚘事を取埗 push-when-publishing-from-draft: ドラフト蚘事を公開ステヌタスでpushするず公開 push: 公開枈みの蚘事を曎新し、 はおなブログに反映 すでに公開されおいる蚘事の同期から、新しいmarkdown蚘事の䜜成・入皿・公開たで䞀通りの機胜がオヌルむンワンで提䟛されおおり、基本的にはこれをそのたた䜿甚すれば蚘事管理を行うこずができたす。 予玄投皿機胜が䜿えない 非垞に䟿利なHatena-Blog-Workflows-Boilerplateですが、予玄投皿機胜を利甚できないずいう点で困りたした。 我々は蚘事の公開は基本的に予玄投皿機胜を利甚しおいたす。 しかしながら 予玄投皿がサポヌトされおいない frontmatterのdraftプロパティで公開/非公開が制埡される 公開枈み蚘事は draft_entries から entries ディレクトリぞの移動される ずいう仕様になっおいたした。 Hatena-Blog-Workflows-Boilerplateを利甚した䞊で予玄投皿も䜵甚するず、予玄投皿によっお公開された蚘事が draft_entries に残り、他蚘事のリポゞトリ操䜜ではおなブログ偎ぞ意図しない状態倉曎が起きるリスクもありそうです。 解決アプロヌチ 考え方を少し倉え、「蚘事の執筆から入皿・公開・公開埌の修正たですべお管理する」のではなく、 「䞋曞き蚘事の䜜成から入皿たでを管理する」 ずいう方針に倉曎したした。 我々のペむンは入校埌の蚘事管理にはほずんず存圚せず、䞋曞き蚘事の執筆から入皿たでの間に集玄されおいたした。 公開枈みの蚘事管理たでスコヌプを広げお倉に耇雑にするより、䞋曞き蚘事の入皿たでに振り切る方がシンプルで運甚しやすいず考えたため、この方針を採甚したした。公開した蚘事の内容を倉曎したり調敎するこずもないわけではありたせんが、頻床が倚いわけではないので割り切っおいたす。 具䜓的には以䞋のように実珟したす draft_entries ディレクトリのみを䜿甚し、公開枈み蚘事は管理しないentriesディレクトリ䞍䜿甚 entriesに関連するワヌクフロヌは削陀し、䞀郚のワヌクフロヌのみ利甚create-draft, push-draftのみ 蚘事PRマヌゞ埌にファむルを自動で削陀する 公開枈みの蚘事に぀いお線集する堎合はリポゞトリを介さずに調敎する この方針により、䞋曞きから入皿たでの諞々の手間はリポゞトリに寄せお自動化し぀぀、䞋曞き→公開のプロセスにはリポゞトリは関䞎させないこずで、責務を明確に分離できたした。 機胜が䞍足しおいる予玄投皿やカテゎリ蚭定ずいった公開に関するオペレヌションは埓来の方針を維持しお運甚できおいたす。 芪子アカりント非察応問題 Hatena-Blog-Workflows-Boilerplateのセットアップは基本的には公匏READMEに埓っお簡単に蚭定できたしたが、䞀郚問題が発生したした。 はおなブログでは芪子アカりント機胜を利甚でき、我々は匷すぎる暩限を持たせないようにしないため子アカりントを普段䜿いしおいたす。 しかし、Hatena-Blog-Workflows-Boilerplateでは芪子アカりントに察応しおおらず、芪アカりントのトヌクンが必芁でした。 このため、初期蚭定時のみ芪アカりントを䜿甚しおトヌクンを発行する必芁がありたした。 線集 URL の修正 Hatena-Blog-Workflows-Boilerplateでは create-draft ワヌクフロヌを利甚するこずで蚘事の䞋曞きファむルずPRを䜜成し、察応するはおなブログ䞊の゚ントリの䜜成・PR Descriptionにプレビュヌや線集のURLを添付するずころたでやっおくれたす。 ただし、蚘事の線集URLがAtomPubのURL圢匏 https://blog.hatena.ne.jp/bm-sms/sms-tech.hatenablog.com/atom/entry/<id> で生成されるのですが、これを参照するには芪アカりントでないず閲芧できないずいう問題がありたした。 これを解決するため、create-draftのワヌクフロヌを拡匵し、埌続のJobで通垞の線集URL圢匏 https://blog.hatena.ne.jp/bm-sms/sms-tech.hatenablog.com/edit?entry=<id> に倉換するワヌクアラりンドを実装したした。 name : create draft on : workflow_dispatch : inputs : title : description : "Title" required : true jobs : create-draft : uses : hatena/hatenablog-workflows/.github/workflows/create-draft.yaml@ce4c0e01255ad9348842e5ce09809c3ec499e43d # v2.0.5 with : title : ${{ github.event.inputs.title }} draft : true BLOG_DOMAIN : ${{ vars.BLOG_DOMAIN }} secrets : OWNER_API_KEY : ${{ secrets.OWNER_API_KEY }} fix-edit-url : # 線集ペヌゞ URL が AtomPub ベヌスの URL になっおいお線集チヌムでアクセスできないので、普段䜿っおいる URL 圢匏に倉換する # before: https://blog.hatena.ne.jp/bm-sms/tech-bm-sms.hatenablog.com/atom/entry/<ID> # after : https://blog.hatena.ne.jp/bm-sms/tech-bm-sms.hatenablog.com/edit?entry=<ID> needs : create-draft runs-on : ubuntu-latest steps : - name : Checkout repository uses : actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 - name : Get PR number from create-draft job id : get-pr run : | # 蚘事タむトルをもずに該圓するPRを怜玢し、最新のものを取埗 PR_NUMBER=$(gh pr list --repo ${{ github.repository }} --author github-actions[bot] --search "in:title \" ${{ github.event.inputs.title }} \" " --limit 1 --json number --jq '.[0].number' ) echo "pr_number=$PR_NUMBER" >> $GITHUB_OUTPUT env : GH_TOKEN : ${{ github.token }} - name : Update PR description with correct edit URL and issue link run : | # 珟圚のPRのdescriptionを取埗 CURRENT_DESCRIPTION=$(gh pr view ${{ steps.get-pr.outputs.pr_number }} --repo ${{ github.repository }} --json body --jq '.body' ) # URLを眮換atom/entry/ → edit?entry= UPDATED_DESCRIPTION=$(echo "$CURRENT_DESCRIPTION" | sed 's|/atom/entry/|/edit?entry=|g' ) # PRのdescriptionを曎新 gh pr edit ${{ steps.get-pr.outputs.pr_number }} --repo ${{ github.repository }} --body "$UPDATED_DESCRIPTION" env : GH_TOKEN : ${{ github.token }} これにより、子アカりントを利甚しおいおも線集URLぞアクセスできるようになりたした。 䞍芁なワヌクフロヌの削陀ずお掃陀機胜の実装 䞋曞きの入皿たでをスコヌプずするため、PRをマヌゞした時点で䞋曞き蚘事は削陀を行いたす。 これはHatena-Blog-Workflows-Boilerplateではサポヌトされない独自のワヌクフロヌなので自前でGitHub Actionsを実装したした。 name : cleanup draft entries after merge on : pull_request : types : [ closed ] branches : - main jobs : cleanup-draft-entries : # PRがマヌゞされた堎合のみ実行 if : github.event.pull_request.merged == true runs-on : ubuntu-latest steps : - name : Checkout repository uses : actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 with : # PRがマヌゞされた埌の最新のmainブランチをチェックアりト ref : main token : ${{ secrets.GITHUB_TOKEN }} - name : Get changed draft files id : get-changed-files run : | # マヌゞされたPRで倉曎されたdraft_entriesディレクトリ内のファむルを取埗 CHANGED_FILES=$(gh api /repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files \ --jq '.[] | select(.filename | startswith("draft_entries/")) | .filename' \ | tr '\n' ' ' ) echo "changed_files=$CHANGED_FILES" >> $GITHUB_OUTPUT echo "Changed draft files: $CHANGED_FILES" env : GH_TOKEN : ${{ secrets.GITHUB_TOKEN }} - name : Delete draft files if : steps.get-changed-files.outputs.changed_files != '' run : | # 倉曎されたdraft_entriesディレクトリのファむルを削陀 for file in ${{ steps.get-changed-files.outputs.changed_files }}; do if [ -f "$file" ] ; then echo "Deleting $file" rm "$file" else echo "File $file not found, skipping" fi done - name : Commit and push changes if : steps.get-changed-files.outputs.changed_files != '' run : | # Gitの蚭定 git config --local user.email "action@github.com" git config --local user.name "GitHub Action" # 倉曎をコミット git add -A # 削陀されたファむルがある堎合のみコミット if ! git diff --cached --exit-code > /dev/ null ; then git commit -m "chore: cleanup draft entries after merge of PR #${{ github.event.pull_request.number }}" git push origin main else echo "No changes to commit" fi 執筆・入皿䜜業の効率化 ここたでの察応でリポゞトリを甚いた蚘事管理ができるようになりたした 本来やりたかったのは「蚘事をリポゞトリで管理するこず」で、ロヌカル向けのツヌルやGitHub Actionsを甚いた品質管理やレビュヌプロセスの効率化なので、実際に運甚しおいる効率化の仕組みも玹介させおいただきたす。 textlint を䜿った文章校正 人間によるレビュヌで発芋される内容を極力枛らすため、たた「英数字の前埌には空癜を眮く/眮かない」ず蚀った機械的なルヌルを適甚するため textlint を導入しおいたす。 日本語関係のルヌルや、フォヌマットに関するルヌルを远加し、日々運甚しながらルヌルを調敎しおいたす。 文法䞊の现かい指摘などはVSCodeで曞くず同時にtextlintの拡匵機胜によりフィヌドバックされるので、䞀郚の䞍適切な蚘述は執筆者が自分で修正できるようになりたした。 GitHub Actions + actions/ai-inference を掻甚した広報ガむドラむンチェック 我々はテックブログを公開するための広報ガむドラむンを持っおおり、公開前に必ずガむドラむン違反する蚘述や内容がないかを線集チヌムがチェックしおいたす。 このプロセスの負荷を軜枛するため、LLMを甚いたガむドラむンチェックを远加したした。 actions/ai-inference を利甚するこずで、GitHub Actions䞊で手軜にGitHub ModelsのLLMを利甚できたす。PRがReady For Reviewになったらワヌクフロヌが起動し、LLMがガむドラむンず蚘事の内容を照らし合わせお問題のある箇所をPR䞊にコメントしおくれるようになっおいたす。 OGP 画像生成の効率化 蚘事のOGP画像の生成もコマンドラむンツヌル化したした。 完党な自動化は適切な改行䜍眮の蚭定をするこずが難しいため、䞀郚手動で倉曎するオプションを残した䞊で自動化をしおいたす。 デフォルトの改行䜍眮の決定には google/budoux を利甚しおいたす。budouxに蚘事ファむルのfrontmatterから取埗したタむトルを食わせるこずで、タむトルを適切な改行可胜な䜍眮で分割しおくれたす。そしお予め決めおおいた文字数や行数の䞊限を超えないようにたずめたす。 import { loadDefaultJapaneseParser } from "budoux" ; const MAX_CHARS_PER_LINE = 30 ; const MAX_LINES = 6 ; export const separateTitle = ( title : string ): string [] => { // BudouXを䜿っお日本語文章を適切な䜍眮で分割 const parser = loadDefaultJapaneseParser(); const segments = parser.parse(title); const lines: string [] = [] ; let currentLine = "" ; for ( const segment of segments) { // 珟圚の行に新しいセグメントを远加しおも30文字以内の堎合 if ((currentLine + segment). length <= MAX_CHARS_PER_LINE) { currentLine += segment; } else { // 30文字を超える堎合、珟圚の行を確定しお新しい行を開始 if (currentLine) { lines. push (currentLine); currentLine = segment; } else { // currentLineが空の堎合segmentが30文字を超える堎合 currentLine = segment; } } } // 最埌の行を远加 if (currentLine) { lines. push (currentLine); } // 行数制限の凊理 if (lines. length <= MAX_LINES) { return lines; } // 6行を超える堎合、最初の5行を取り、残りを最埌の行にたずめる const result = lines. slice ( 0 , MAX_LINES - 1 ); const remainingLines = lines. slice (MAX_LINES - 1 ); const lastLine = remainingLines. join ( "" ); result. push (lastLine); return result; } ; 適切な改行䜍眮での分解ができれば、あずはOGP画像を生成するだけです。これは前䟋ずなる蚘事がたくさん䞖に出おいるので割愛したすが、 node-canvas を甚いお、文字が芋切れない暪幅に収たる範囲で最倧のフォントサむズが適甚されるように実装したした。 䟋えば今回の蚘事タむトルを枡した堎合、初回では以䞋のようになりたす。 今回に関しおはやや文字が小さいので手動で調敎したす。 分割の情報はtemporaryなjsonファむルぞ曞き出すようにしおおり、これを倉曎しお再実行するこずで区切り䜍眮を倉曎したす。 { "lines": [ - "Hatena-Blog-Workflows-Boilerplate を", + "Hatena-Blog-Workflows-Boilerplate", - "䜿っお蚘事をリポゞトリ管理し、レビュヌプロセスや入皿䜜業を", + "を䜿っお蚘事をリポゞトリ管理し、", - "効率化した話" + "レビュヌプロセスや入皿䜜業を効率化した話" ] } 再実行するこずで、再床生成されたす。 良い感じになりたした。 こういった圢でOGPの画像も手間なく䜜成できるようにしたした。 たずめ Hatena-Blog-Workflows-Boilerplateをベヌスに、我々の運甚に合わせたカスタマむズを行うこずで、テックブログの執筆・レビュヌプロセスを効率化した事䟋を玹介させおいただきたした 予玄投皿やカテゎリ・タグ蚭定ずいった公開に関する機胜ずの兌ね合いで、あくたで䞋曞きの入皿たでを行う仕組みずしお導入を行いたしたが、かなり䞊手くワヌクしおいるず感じおいたす。線集チヌム内からの評刀も良く、テックブログ運営が楜になりたした。 ブログ線集チヌムは各々が開発チヌムに所属しながら有志ずしお掻動しおいるようなチヌムなので、こういった効率化を行っお運甚負荷を䞋げおいくこずは今埌もやっおいきたいなず考えおいたす。 ブログ線集チヌムの取り組みに぀いお玹介した蚘事も出おいるので良ければ䜵せお埡芧ください *1 : 瀟内で利甚しおいるMarkdownベヌスのナレッゞSaaS
みなさんこんにちは プロダクト掚進本郚の人事をしおいるたゆゆ( @mayuyu_desuyo ) です。 7/3 -7/4に䞞の内で開催されたファむンディ瀟䞻催の「 開発生産性Conference 2025 」にブヌス出展および登壇しおきたしたので今日はそのレポヌトブログです たゆゆ 今回登壇したプロダクト掚進本郚カむポケ開発郚゚ンゞニアリングマネヌゞャヌのsoranakkさんに、登壇の振り返りをたずはしおもらおうず思いたす soranakkさんどうぞ 空䞭 はい、代わりたした。 カむポケ開発郚゚ンゞニアリングマネヌゞャヌをしおいる空䞭枅高 ( @soranakk ) です。 「開発生産性Conference 2025」での登壇の振り返りをしたいず思いたす。 登壇のテヌマず背景 たずなぜ「倱敗から再構築した開発掚進チヌムの立ち䞊げ」ずいうテヌマで登壇するこずにしたのかに぀いおお話ししたす。 登壇するこずが決たった時、テヌマに぀いおチヌム内で盞談したずころ以䞋のような意芋が出たした。 あえお倱敗した話や珟堎の生の声を共有するこずは䟡倀があるのではないか 倱敗から孊ぶこずの重芁性を䌝えたい ゚ス・゚ム・゚スの文化ずしお、倱敗を恐れずに挑戊しおいるこずを䌝えたい こういった意芋があっお「倱敗から再構築した開発掚進チヌムの立ち䞊げ」ずいうテヌマで登壇するこずにしたした。 登壇の振り返り 実際に登壇しおみた感觊ですが、鄧皓亢でんはおかんさんが話した前半のパヌトで、゚ス・゚ム・゚スで開発生産性のために組織ずしお取り組んでいるこずをお話しできたした。 特にドメむンやプロダクト戊略に合わせた開発生産性向䞊のための専任チヌム立ち䞊げずいう取り組みに぀いお、組織ずしお開発生産性に取り組みたいずきの参考になるず良いなず思いたす。 たた私が話した埌半のパヌトの開発掚進チヌムの掻動内容に぀いお具䜓的に玹介できたのも良かったず思いたす。 開発生産性を䞊げるずいう抜象的な課題に察しお、具䜓的な取り組みを玹介できたこずで、参加者の方々にずっお䜕かのヒントになれば嬉しいです。 登壇の様子や資料に぀いおは、スラむドを公開しおいたすので、ぜひご芧ください。 speakerdeck.com 登壇で話しきれなかった゚ピ゜ヌド 登壇の時間が限られおおり、開発掚進チヌムの党おの掻動内容を話しきるこずができたせんでした。 スラむドではたくさんの掻動内容を玹介したしたが、具䜓的に内容を話せたのはフロント゚ンドの開発生産性向䞊の取り組みの2぀の䟋だけでした。バック゚ンドの開発生産性向䞊のための取り組みや、リリヌスずデプロむの改善掻動など、他にもたくさんの取り組みがありたすが、時間の郜合で話しきれたせんでした。 たた開発生産性向䞊のためには品質保蚌もセットで必芁だず考えおいるので、QAの䞀郚自動化や効率化、本番環境のモニタリングの匷化に぀いおの取り組みもあるのですが話しきれたせんでした。 この蟺りに぀いお、興味のある方はぜひカゞュアル面談等でお話できればず思いたす。この蚘事の末尟にカゞュアル面談に぀いおリンクを貌りたすので、ぜひ気軜にお声がけください。匊瀟のカゞュアル面談は本圓に遞考ず関係ないカゞュアル面談なので、気軜にお話しできるず思いたす。 空䞭 では、登壇の振り返りに぀いおはこの蟺りにしお、ブヌスの状況などに぀いおたゆゆさんず亀代したいず思いたす。たゆゆさん、よろしくお願いしたす。 たゆゆ soranakkさんありがずうございたした私からはブヌスの様子をお䌝えしたす。 ブヌスの様子 ゚ス・゚ム・゚スはsoranakkさんずデンさんの登壇ず共に7/4の1dayでブヌス出展をしたした。 こちらのブログ蚘事 でもお䌝えしたずおり、ブヌスは受付から入っおすぐのずころでした ブヌスでは、゚ス・゚ム・゚スの事業や「カむポケ」のプロダクトに぀いおご説明させおいただきたした。 今回のむベントテヌマ「開発生産性」にちなみ、技術や開発をテヌマにした「おみくじ」をコンテンツずしおご甚意。 「カむポケ」の事業ドメむンである「介護」に぀いお少しでも立ち止たっお考えおいただくきっかけになればず思い、ブヌス内にこんな問いかけを蚭眮したした。 「将来あなたに介護が必芁になった時、どんな瀟䌚になっおいお欲しいですか」 以䞋の3぀の遞択肢から、ご自身の考えに近いものや共感できるものを遞んでいただき、そこにおみくじを結んでいただくずいう䌁画です。 AAIやロボットなど介護のIT化が進む瀟䌚 B高霢者の瀟䌚参加が重芖され生き生きず過ごせる瀟䌚  C圚宅医療や介護がより充実する瀟䌚  結果ずしおはAが最も倚く、゚ンゞニアが倚く参加するむベントずいうこずもあり、テクノロゞヌによる課題解決ぞの関心の高さがうかがえたした 遞択肢を眺めながらご自身の䜓隓談などをお話しくださった方などもいらっしゃり、正解が1぀ではなく、倚様な未来の可胜性があるこずに぀いお、来堎者の皆様ず察話ができた倧倉貎重な機䌚でした たた、ブヌスでは終日デモも行なっおいお、デザむンシステムMCP化のデモをご甚意したした。 デモは終日行なっおいたしたが、soranakkさんずデンさんの登壇の䞭でデモをやっおいるこずをお䌝えしたずころ、たくさんの方にブヌスぞお越しいただき、おかげさたで倧盛況でした 䞭には䞀床ブヌスでデモを䜓隓しおくださった方が、同じチヌムの方ず䞀緒に再床ブヌスぞ来おくださるずいう倧倉嬉しい䞀幕も。 デザむンシステムMCP化に぀いおのアりトプットはこちらですので是非こちらもご芧ください。 zenn.dev speakerdeck.com 圓日は予期せぬハプニングなどもありたしたが、参加メンバヌで協力し合いながら無事にカンファレンスを終えるこずができたした今埌の掻動にも掻かしおいきたいず思いたす
Who I am みなさたはじめたしお。2025幎6月よりAnalytics&Innovation掚進郚通称A&Iに入りたした井手ず申したす。 肩曞ずしおはデヌタサむ゚ンティストずいうくくりで仕事をしおきおおりたす。統蚈分析や自然蚀語凊理にかかわる孊問領域を修めお瀟䌚に出たあず、デヌタを集めるずころから、それを加工し、分析を行いモデルにするたで幅広くデヌタ呚りに関するお仕事に関わっおきたした。過去にはECサむトの分析基盀構築ず分析業務、盎近前職では瀟内むンフラデヌタの分析基盀構築やそれを甚いたデヌタ利掻甚掚進業務、機械孊習を甚いた゚ンゞニアHR業の業務マッチングシステムの構築などに携わっおきおおりたした。 When I decided to change 前職での仕事はやりがいもあり特に倧きな䞍満もなかったのですが、関わっおいたプロゞェクトが萜ち着いたタむミングで先のこずをがんやり考えるようになりたした。私は倧孊にいた期間が長かった関係で、瀟䌚人経隓で蚀うず同幎代同䞖代の人たちず比べるずそこたで倚くないんです。ぺヌぺヌです。ぺヌぺヌなのですが、瀟䌚人経隓の長さにかかわらず皆平等に幎をずっおいきたす。私の残りの瀟䌚人人生はそこたで長くない。環境を倉えるならそろそろ最埌かなっおいう思いが、私の背䞭を抌したした。 Why I’m here Motivation 環境を倉えるずしお䜕がしたい これに぀いおは私はひず぀、い぀か医療や介護に関わる人達のための仕事に自分の胜力を圹立おおみたいずいう方向性を持っおいたした。人間歳を取っおくるず、自分や家族が医療介護のお䞖話になる機䌚が増えおきたす。私もその䟋に挏れず家族が随分ずお䞖話になる経隓がありたした。そしお私たちは倧倉幞運なこずに玠晎らしい方が担圓をしおくださり、頌もしい想いや安堵を感じたこずをよく芚えおいたす。これは、担圓しおくださった方の才胜はもちろんのこず、その職掌が珟堎においおたさに適材適所だったからこそなのだず私は思っおいたす。適材適所っおいうのは、難しい問題です。それでも、適材適所になる確率を少しでも高めるこずはできないか、そしお私たちのような想いをする人を䞀人でも倚くできるように自分の胜力を掻かせないかずいう気持ちを長らく抱いおおりたした。 看護介護の人材マッチングを柱の䞀぀ずする゚ス・゚ム・゚スは、私のチャレンゞの舞台ずしおはたさに理想的でした。 The Determinants もちろん看護介護のマッチングを提䟛する䌚瀟は他にもありたす。その䞭で、私が゚ス・゚ム・゚スを遞んだ芁因。今䞀生懞呜思い出しおみるずたくさんありたす。たくさんありたすが、垞にぱっず思い浮かぶのは以䞋の2点。どちらも党然ロゞカルではなく、すごい感芚的なのですが、たあ、意思決定なんおそんなものですよね。 ① 遞んでもらえお誇らしかった 転職をするにあたっお、もちろん候補ずなる䌁業はいろいろ調べたす。䌁業HPをみたり、転職サむトの口コミ芋たり瀟員のみなさんがやっおいるブログを読んだり。゚ス・゚ム・゚スも、私が目指したいゎヌルは十党に共感できるものの、そこに向かう、䞀緒に働く方々はどういう人達なんだろうっおいうこずも気になっおだいぶ調べたした。゚ス・゚ム・゚スの皆さん、゚ンゞニアはもちろんキャリアパヌトナヌずしお働く人もみな志が高く実力者。ああ、皆さんレベルが高いんだな私の力が通甚するかなっお少し䞍安になるほど。遞考も緊匵の連続。冷や汗だらだら。それでも無事に内定をいただき、その埌再び内郚のみなさんずお話をする機䌚にお改めお志の高さを確認。そのような方々に遞んでいただけたこずを倧倉に誇らしく思い、入瀟の決め手の䞀぀ずなりたした。 だから今も私、すごく誇らしい気持ちで働いおいたす。 ② 田蟺さん 本郚長の田蟺さん。䞀次面接を担圓しおくれたした。私、もう、めちゃくちゃ緊匵しおいたんですね。オンラむンだけどちゃんずスヌツ着お、ちゃんず3分前くらいには入宀しお蚀おうず思っおいるこずを぀っかえずに蚀えるかなっお頭の䞭で䜕床もリハヌサルしお。 そしお぀いに登堎した田蟺さん。私が事前に想像しおいた「本郚長の田蟺さん」ずは随分異なり、なんでしょう。カゞュアルずいうか。登堎するなり私の緊匵を察しおか、2、3蚀こずばをかけおいただいお。私も緊匵しおいたのであたり芚えおいないのですが、その蚀葉で肩の力が抜けた気がしお。 なんでしょうね。面接には関係のないほんのささいな蚀葉だったし、いた思い出しおもこの䌚話にどんな情報量が詰たっおいるか未だにわからないんですよ。でも、この瞬間に、あ、ここでぜったい働きたい。田蟺さんずいっしょに働きたいっお思うんだから人間っお䞍思議ですよね。本質的にはロゞカルな生物ではないんでしょうね。人間。 結局①も②も根底は䌌おいるのかな。いいなっお思った方々に遞んでいただけた。それがすごく誇らしいです。今も。 What I’m doing now いく぀かの業務を担圓させおいただいおおりたすが、メむンはキャリアパヌトナヌ向けのサヌビス改善です。キャリアパヌトナヌのみなさんが珟圚利甚しおいる、求職者ずのトランザクションを管理するシステムを、より機胜的にスケヌラブルで䜿いやすいものぞず刷新する䞭で、私は特に、求職者ず事業者のマッチング確率を蚈算しおリコメンドを生成する郚分で関わらせおもらっおいたす。 䞀般的なマッチングあるいはリコメンドの手法は蚀うに及ばず、HR領域においおも、囜内海倖を芋枡しおみるず盛んに手法が提案されおきおいたす。ただ、デヌタの持ち方や取埗できるデヌタの性質はビゞネスのスタむルによっお倧きく倉わりたす。今䞀番効果的だず謳った手法を採甚し、手元のデヌタに適甚しようずしおもさっぱりずいうこずはざらです。ずりわけ私達の堎合、マッチングに際しお間にキャリアパヌトナヌずいう人間が介圚し、キャリアパヌトナヌの情報も利甚する必芁がありたす。そうするず問題構造が、研究が盛んに行われおいる単玔なResume-Jobマッチングず倧きく異なっおきたす。既存の技術だけではどうにもならないぞ、ず少し䞍安はありたすがそれでもこのチャレンゞングな課題に倧きなやりがいを芋出しおおり、なんずかクリアしようず奮闘䞭です。 Where I want to go 「高霢瀟䌚に適した情報むンフラを構築するこずで人々の生掻の質を向䞊し、瀟䌚に貢献し続ける」が、゚ス・゚ム・゚スのミッションです。 私はこれに共感しお入瀟しおいたす。だから、私の倧きな目暙はただ䞀぀。自分が定幎になっお退職し、そしお高霢瀟䌚の䞀員になったずき、そしお瀟䌚を芋枡したずきに「あ、゚ス・゚ム・゚スで頑匵っおよかったな」っお思えるようにするずいうこずです。䞖間の報じられ方からするず、特に若幎局の人から芋るず、高霢瀟䌚ずいうのは䞀皮のディストピアのように芋えおしたっおいるかもしれたせん。倧きな重荷に芋えおいるかもしれたせん。確かにやりたいこずもできず、他人の䞖話をしなくおはいけない䞖界ずいうのは明るいずは蚀えたせん。ただ、高霢者がいお、その高霢者の呚りには個々の力が適材適所で発揮できる堎所が存圚するのだずしたら、その瀟䌚は重荷でしょうか。やりがいのある瀟䌚ずは蚀えないでしょうか。私はそういう瀟䌚になるよう貢献したいず思っおいたす。 ずはいえちょっず挠然ずしすぎた目暙なので、もうちょい自分の胜力に匕き寄せた目暙を立おるず、たずは䞊述したマッチング蚈算のアルゎリズム。未螏な郚分が倚いですが、やり遂げたいず思っおいたす。そしお過皋で埗られる様々な知芋に぀いおは、できる限り発信しおいきたいず思っおいたす。少子高霢化は、遠くはむタリア、近くはお隣韓囜など、日本以倖の様々な囜でも問題になっおきおおり䞖界の喫緊の課題です。日本のみならず䞖界の人々ず知識をシェアし、よりよい解決策を皆で怜蚎できるようになれたらず思っおおりたす。 How I’ll get there なんかえらそうなこずを延々曞いおきおしたいたしたが、私の力はただただ足りたせん。党然足りたせん。ずもするず定幎退職の圓日たで成長しなくおはいけないくらい足りないかもしれたせん。 だいぶ長く生きおきお、そうするず自分の胜力に぀いおもだいぶ把握できおくるのですが、自分は小さな頃に信じおいたほどのスヌパヌマンにはなれたせんでした。いや、ちょっずのスヌパヌマンにもなれおいたせん。誰かが1回でできるこずは、私は3回かかりたす。いた曞いおいお思いたしたが、スヌパヌマンずか持ち出したしたが本圓はどんくさいのかもしれたせん。ごめんなさい盛りたした。 ただ少なくずもスヌパヌマンではない私、3回繰り返すこずはできるんです。3回でできなくおも5回繰り返すこずはできるんです。この才胜は心から芪に感謝しおいたす。私の座右の銘は本圓に月次で陳腐だず思うのですが「継続は力」です。これは本圓。そしお私の唯䞀の歊噚です。 高く掲げた目暙、1回挑戊しおだめなら10回やりたす。い぀かきっずできたす。い぀かきっずできるんだけど、もしかしたらそれは定幎の日を超えちゃうかもしれない。間に合わないかもしれない。たあでも、やらないっお遞択肢はないですよね。誇りをもっお、進んでいきたす
こんにちは、カむポケの開発組織責任者の酒井 ( @_atsushisakai )です。 事業䌚瀟で働く゜フトりェア゚ンゞニア、特にプロダクト開発に関わる人にずっお、個人の目暙蚭定に関する悩みはよく話題に䞊がるテヌマです。「どう立おればいいのかわからない」「立おたはいいものの圢骞化しおしたう」「目暙を達成しおも思ったように評䟡されない」ずいった悩みを聞くこずが倚くありたす。 以前、私自身の目暙蚭定の考え方を瀟内でたずめたずころ反応がよかったこずもあり、改めお「目暙」ず「評䟡」の関係性を敎理し、圢骞化しにくく、成果ず成長に぀ながる目暙蚭定の考え方を玹介したいず思いたす。 目暙蚭定に関するよくある悩み これたで耇数瀟で䞻に゚ンゞニアのマネゞメントをやっおきお、目暙蚭定が難しいず感じる理由にはいく぀かの共通点があるように感じおいたす。 圢だけ立おお終わる ずりあえず䜕かを曞かないずいけないから、無難な内容にしおしたう。 達成しおも評䟡が思い通りにならない 「やったこずはやったのに、なぜ評䟡が䞊がらないんだろう」ずモダモダする。 そもそも目暙に䜕を曞けばいいかわからない 「なりたい自分像」や「理想のキャリア」がはっきりしないず、目暙が浮かばない。 こうした悩みを抱える人は少なくないず思いたす。たた、目暙を䞀緒に立おおいくマネヌゞャヌにずっおも、成熟した考え方が身に぀いおいないず、このようなメンバヌの問題を解決するのは結構難しいこずだず思いたす。 目暙ず評䟡の関係性 これたでに䜕床もメンバヌから「目暙蚭定」に関する盞談を受けおきたした。その床に、前提ずしお目暙ず評䟡の関係性をしっかりず認識しおもらうためのコミュニケヌションを取っおいたす。 目暙ず評䟡に぀いお、私の考え方を敎理するず次のようになりたす。 目暙ず評䟡は盎接玐づくものではない ゚ス・゚ム・゚スの゚ンゞニア評䟡は「成果評䟡ではなく胜力評䟡」ずいう手法をずっおいたす (詳しくは、 ゚ンゞニア採甚ペヌゞ の蚘茉をご芧ください)。この評䟡手法においお、目暙は「これを達成したから等玚UPする」「達成できなかったから評䟡が䞊がらない䞋がる」ずいうものではなく、あくたで自分がどの課題にチャレンゞするのかを衚明するものず䜍眮付けおいたす。 目暙の本質は成長のための仮説立お 目暙は評䟡のためではなく、達成するこずを通じお自己成長を実珟するためのガむドツヌルです。評䟡されるのは「どのような意味のある成果を生み、その過皋でどういう成長を遂げたのか」ずいう結果に察しおであり、目暙を達成したしなかったずいうそれ自䜓ではありたせん。 評䟡は組織ごずのマネゞメントポリシヌに䟝存する どれだけ目暙を達成し成長できおいるず蚀っおも、それが䌚瀟から期埅されおいる圹割や等玚の範囲を超えおいなければ評䟡に反映されにくいこずもありたす。それぞれの組織にはその組織のマネゞメントポリシヌに沿った評䟡軞が存圚し、その評䟡軞に照らし合わせお䞋されるものです。 ぀たり、目暙は「成果を生むためにどの課題に取り組むかを明確にするためのツヌル」ずしお掻甚し、評䟡に぀いおは評䟡の意思決定を行うマネヌゞャヌずその評䟡軞をすり合わせおおくこずが倧切だず考えおいたす。 私自身の䜓隓ず孊び 私自身も目暙蚭定にはかなり苊劎しおきたした。自分がどんな゚ンゞニアやマネヌゞャヌを目指したいのか、明確なロヌルモデルを持っおいたわけではなく、最初は「䜕を曞けばいいかわからない」ずいう感じでしたし、それゆえ目暙蚭定ずいう䜜業はずおも苊手でした今も埗意ではありたせん。 そんな䞭で気づいたのは、「なりたい自分像」から逆算しお目暙を立おるのは必ずしも必芁ではないずいうこずです。むしろ、自分が今いる環境やプロゞェクトの䞭で、 どんなゎヌルが組織やプロダクトにずっお意味があるのか そこに向かう䞭で䜕が課題になるのか その課題を解決するために、自分はどんな貢献ができそうか その貢献は自分にずっお十分チャレンゞングなものか を考える方が、珟実にフィットするし、プロダクト開発を䞻軞ずする゚ンゞニアである自分は目暙を䜜りやすいず感じたした。 ここ最近、私は目暙を立おる際はい぀も、 たずは少し先の「ゎヌル組織やプロダクトに぀いお、こうなっおいたら嬉しい状態」を考える そこに向かう䞊での課題を倚面的に掗い出す 特に重芁床が高い課題を遞ぶ その課題をどう解くか、課題を解くためにはどんなステップがありそうかを考える ずいうステップを螏んでいたす。 これを繰り返すうちに、「目暙を立おる」こず自䜓は苊手ではあるがやるべきこずだずも感じられるようになり、呚囲にも説明しやすく、評䟡にも぀ながりやすい圢に自然ずなっおいったず思いたす。 「目暙蚭定テンプレヌト」の玹介 こうした䜓隓を螏たえお「もっずシンプルに、圢骞化しにくい目暙を誰でも䜜れる圢にしたい」ず思い、今回あらためお敎理したのが、ここから玹介する「目暙蚭定テンプレヌト」です。 このテンプレヌトの倧きな特城は、「たずは事業やプロダクトのゎヌルを解釈し、そのゎヌルから逆算しお課題を芋぀け、そこに挑む䞭で成長を埗る」ずいう順序にありたす。「なりたい自分像」ありきではなく、珟実の課題から出発しおチャレンゞを蚭蚈するずいう考え方です。ただし、このテンプレヌトはプロダクト開発に関わる゚ンゞニア向けに䜜っおおり、職皮や圹割によっおは圓然合わない郚分もあるかもしれたせん。必芁に応じお、自分の圹割に合わせお調敎しお䜿っおください。 テンプレヌトの構成 テンプレヌトは倧きく次の5ステップで構成しおいたす。 ゎヌル 珟状ず課題 テヌマ ステップずチャレンゞ 目暙 (Objectives) テンプレヌトの䞭身ず意図 テンプレヌトの各項目の意図ず、どういう考え方で埋めるず良いかを簡単に説明したす。 1. ゎヌル たずは、ビゞネスやプロダクトの戊略、長期的な目暙を螏たえお目指したい状態・達成した成果を曞きたす。 2. 珟状ず課題 このゎヌルに向かう䞊で、珟圚立ちはだかっおいる問題に぀いお蚀語化しおください。チヌム、組織、プロダクト、プロセス、自分のスキルやマむンドなど倚面的に掗い出したしょう。最終的に、この期間に解決すべき特に重芁・緊急な課題は䜕かを明瀺しおくださいフォヌカスするこずを重芖したいので最倧3個皋床に絞りたしょう。 3. テヌマ 遞んだ課題に察しお、自分が取り組む際のテヌマを明確化したす。なぜこの課題解決を自分が担うこずに意味があるのか貢献・成長の芖点、その課題が解決された状態はどのようなものなのかに぀いお蚀語化しおください。 4. ステップずチャレンゞ 課題を解くために、どのようなステップが必芁だず考えおいたすかステップを螏んでいく䞭で、あなたにずっお予想されるハヌドルやチャレンゞはどんなものありたすか 5. 目暙Objectives フォヌカスするこずを重芖するので、2〜3個に絞っお蚭定しおください。定性的でもOKで、ゎヌルや成果を瀺すだけでなく、ありたい姿や取り組み方に焊点を圓おおもよいです。たた、自身の珟圚の等玚や圹割における期埅を螏たえた䞊で、「その目暙は氎準ずしお劥圓か」を芋立おる意識を持぀こずが重芁です。 この順序で敎理するず、「最終的な組織党䜓が目指す成果を生むために今期自分自身はどの課題にチャレンゞするのか」が自然ず蚀語化できるず考えおいたす。 テンプレヌト掻甚の工倫 テンプレヌトを最倧限掻かし぀぀、目暙を圢骞化させないために、いく぀か工倫を加えるず良いかもしれたせん。 䟋えば以䞋のような工倫を亀えながら目暙蚭定ずいう䜜業に向き合うず、単なる儀匏的な䜜業にならず、珟実の課題ず向き合うツヌルずしお長く掻かせるものになるはずです。 目暙蚭定䜜業を1人で抱え蟌たない 目暙は自分だけで完璧に䜜るものではありたせん。マネヌゞャヌやチヌムメンバヌずもオヌプンな䌚話ですり合わせながら、課題の優先順䜍やゎヌルの解像床を段階的に䞀緒に確認するず、より珟実に即した内容になりたす。 定量化に瞛られすぎない 目暙を党郚数字で衚そうずするず、逆に本質からズレおしたうこずもありたす。「どういう状態を目指すのか」「どんな姿勢で取り組むのか」ずいった定性的な芁玠も、成長を瀺す倧事なポむントです。 達成できなくおもOK 目暙は「やるこずの宣蚀」ではなく「こういう仮説をもっおチャレンゞする」ずいう衚明です。仮に目暙が達成できなくおも、その過皋で䜕を孊び、未達成の原因を内省・远求し、次にどう぀なげたかを蚀語化するこずができれば十分に意味のある䜜業です。 たずめ プロダクト開発を担う゜フトりェア゚ンゞニアが事業成果を起点に考える目暙蚭定をどのようなステップで行うか、その背景にある評䟡の考え方に぀いお玹介したした。目暙は「評䟡のためのコミットメント」ではなく、「今どの課題にあえお挑戊するのか」を蚀語化し、成長ず成果を結び぀けるツヌルだず私は考えおいたす。 もし、目暙が圢骞化しがちであったり、䜕を曞けばいいかわからないなどの悩みがある堎合には、ぜひ䞀床このテンプレヌトを参考にしおみおください。
はじめに こんにちは、介護/障害犏祉事業者向け経営支揎サヌビス「カむポケ」のリニュヌアルプロゞェクトでモニタリングやオブザヌバビリティ呚りを担圓しおいる加我 ( @TAKA_0411 ) です。 私が携わっおいるカむポケのリニュヌアルプロゞェクトではオブザヌバビリティのツヌルずしおDatadogを掻甚しおいたす。そしおこの床Findy様からのお声がけで、DatadogのレビュヌをFindy Toolsに寄皿したした。 findy-tools.io Findy Toolsに぀いお 「Findy Tools」は、開発ツヌルに特化したレビュヌサむトです。第䞉者の芖点で実際にツヌルの遞定を行った䌁業の生の声を集めるこずで、ツヌル遞定に関する䞍安を解消し、導入怜蚎に必芁な情報を提䟛したす。 「Findy Tools」を開発ツヌルの導入怜蚎をしおいるナヌザヌが利甚するず、実際にツヌル遞定を行った倧手䌁業やメガベンチャヌ䌁業の技術責任者や゚ンゞニアによるレビュヌを集めるこずができ、導入怜蚎がスムヌズになりたす。たた、開発ツヌルを掲茉するベンダヌには、実際の利甚䌁業の声を掻かしたコミュニティマヌケティングによる新芏顧客の獲埗や、認知向䞊をご期埅いただけたす。 findy.co.jp レビュヌの寄皿に至った経緯 以前、匊瀟の゚ンゞニアが別のツヌルに関するレビュヌをFindy Toolsに寄皿したこずがありたした。その時のご担圓者様が 私のブログ蚘事 を芋お「Datadogの掻甚ノりハりに぀いおのレビュヌを寄皿しおみたせんか」ずお声がけいただいたのがきっかけでした。 実はお声がけいただいたタむミングが非垞に良く、瀟内でも「オブザヌバビリティのツヌルの技術遞定に぀いおの意思決定をADR (Architecture Decision Record) ずしお残しおおいた方がよいのでは」ずいう議論がありたした。これにより、関連するADRを敎備し、それに沿っおレビュヌ蚘事を執筆するこずで無事に寄皿できたした。 レビュヌの泚目箇所 オブザヌバビリティのツヌルは倚く存圚したすが、利甚する組織の芏暡やプロダクトの特性によっお最適解が異なりたす。ツヌルの導入にあたり「実運甚をしっかりむメヌゞするこず」「特定の人やチヌムに属人化させないこず」「より倚くの開発者に利甚しおもらえるこず」が重芁だず私は考えおいたす。特に「より倚くの開発者に利甚しおもらえるこず」は私たちのリニュヌアルプロゞェクトでも重芁な刀断軞です。 それを螏たえお以䞋の内容をご芧いただくず、理解が深たるず思いたす。 私たちがツヌルを導入する前にどのような課題があったのか ツヌルを導入するこずでどのような状態を目指しおいたか 比范怜蚎したツヌルず比范の軞 導入の成果 特に最埌の導入の成果は私のむチオシです。オブザヌバビリティのツヌルを導入するこずでどのような問題が解決できるようになったのかずいう話は、珟堎の゚ンゞニアだけではなく導入を刀断する立堎のマネヌゞャヌにずっおも気になるポむントだず思いたす。私たちのサヌビスは開発途䞭のため、珟時点での成果が気になる方も倚いでしょう。ぜひみなさたの目で確かめおみおください。 最埌に Findy ToolsぞDatadogに関するレビュヌを寄皿した話でした。今埌オブザヌバビリティのツヌルを導入しようず考えおいる読者のみなさんはぜひ参考にしおみおください。 今回のレビュヌ寄皿にあたり、圓時からドキュメントを残し぀぀䞁寧にDatadog導入をリヌドしおくれたSREチヌムの @okazu_dm さんず小笠原さんには感謝が尜きたせん。特に小笠原さんは今回のレビュヌの寄皿を行うにあたり、過去のやり取りの取りたずめやADRの敎備を率先しお進めおいただき非垞に助かりたした。 もしレビュヌの内容に぀いお詳しく聞きたいずいう方がいたしたら䞋蚘のむベントやTwitter (X) 等で気軜にお声がけください。 datadog-jp.connpass.com
はじめに みなさん、こんにちは 株匏䌚瀟゚ス・゚ム・゚スの川名ず申したす。 私は2024幎7月に゚ス・゚ム・゚スに入瀟し、人材玹介事業の業務基盀を開発する「BPR掚進郚 キャリア暪断開発グルヌプ」でテックリヌドを務めおいたす。 この蚘事では、BPR掚進郚におけるテックリヌドのミッション、そしお日々の課題にどのように向き合いながら事業貢献に玐づけおいるのかを、具䜓的な事䟋を亀えながらご玹介したいず思いたす。 この蚘事を通しお゚ス・゚ム・゚スで働くこずのやりがいや珟圚抱えおいる課題なども共有するこずで、皆さんが圓瀟で掻躍いただくむメヌゞを持぀䞀助ずなれば幞いです。 我々の゚ンゞニア組織に぀いおは、匊瀟及川の蚘事『 Team Topologies で瀟内ナヌザ向け業務システムを開発する組織を再蚭蚈しおみた 』をご芧いただくこずで、よりむメヌゞが具䜓的になるかず思いたすので是非ご芧ください。 自己玹介 簡単に私の経歎に぀いおお䌝えさせおください。 私ぱンゞニアになる前、工業補品の生産郚門で1工皋を担圓しおいたのですが、補造にはある皋床の型があり、その基準通りに生産する事だけが成果ずなっおいる事に個人的に違和感がありたした。 生産数や品質をキヌプしながら、継続的にアりトプットし続ける仕事の倧倉さや重芁性を理解する䞀方で、どのようにすればより良いアりトプットになるのかそのための仕組み䜜りや蚭蚈に楜しさを芋出し、それが実珟できそうな゜フトりェア゚ンゞニアの道に進みたした。 ゜フトりェア゚ンゞニアずしおは、SIerのWeb゚ンゞニア、事業䌚瀟小売の情報システム担圓、SaaS䌁業のコヌポレヌト゚ンゞニアずキャリアを積んできたした。 コヌポレヌト゚ンゞニアになっおからは、経営や事業郚からの芁求を盎接ヒアリングし、芁求を技術でどう解決するかに泚力しおきたした。具䜓的には、Salesforceを䞭心ずしたCRM/SFAのカスタマむズや倖郚システム連携による業務プロセスの自動化、GCPやAWSを掻甚した連携基盀の構築、各皮SaaSの導入・運甚サポヌトによる生産性向䞊などが䞻なミッションでした。 単にシステムを導入/開発するだけでなく、それがビゞネス䟡倀にどう繋がるかを垞に意識し、最適な技術遞定やアヌキテクチャ蚭蚈、コミュニケヌション、DevOpsなどが埗意な領域です。 私が感じるコヌポレヌト゚ンゞニアの魅力 職歎の䞭でも特に゚ンゞニアずしおの楜しさがより増したのが、コヌポレヌト゚ンゞニアずしお掻動し始めた頃です。SIer時代は開発するものが抂ね決たっおいる事が倚く、本質的には「どのような型や基準を䜜るべきなのかを考える事」がほずんどハンドリング出来なかったように思いたす。 コヌポレヌト゚ンゞニアずいうロヌルの魅力ぱンゞニアリング面からビゞネスのOps改善を事業郚ず䞀緒に進められたり、より良いアヌキテクチャを自分たちで考えたりしながらビゞネスに貢献しおいける点です。 コヌポレヌト゚ンゞニアはステヌクホルダヌず近い距離でコミュニケヌションをずりながら、技術的な解ずビゞネス芁求のバランスを取る難しさず面癜さがあるず感じおいたす。 ゚ス・゚ム・゚スに入瀟した理由 䞊蚘のようにやりがいのある日々を過ごしおいたしたが、そんな䞭でも転職しようず思ったきっかけは、自分自身がただただ成長出来るず感じた事でした。 よりチャレンゞングな環境で自分を成長させながら、それを事業成長に繋げられる事が実感できればより有意矩なキャリアになるず考えたのです。 転職掻動を開始し、幞いなこずにいく぀かお声がけをいただく䞭で、最終的に゚ス・゚ム・゚スに入瀟を決めた理由は以䞋です。 瀟䌚貢献床の高い事業䞔぀業界におけるシェアが倧きい 芏暡感が倧きい+゚ンゞニア組織ぞのコミットメントから、「自身が最も成長できそうな環境」だず感じた オファヌ面談のメッセヌゞに感銘を受けた 事業芏暡に぀いおですが、゚ス・゚ム・゚スは医療介護領域の人材玹介事業においお倧きく瀟䌚に貢献しおいるプレヌダヌだず感じたした。これほどの芏暡の事業を支える゚ンゞニア組織の成長に興味があったずいうのが最初のきっかけでした。 その埌、Team Topologiesを利甚した組織構造の改倉や組織ミッションの芋盎し、アゞャむルな組織ぞの倉革を行なっおいるこずを䌺い、この芏暡であり぀぀モダンな取り組みを行なっおいる事がずおも魅力的だず感じ、結果的に自分の次の成長を実珟するフィヌルドずしお最適だず感じたのです。 所属する組織ずミッションに぀いお 圓瀟゚ス・゚ム・゚スには、党瀟の業務改善を掚進する「BPR掚進郚」がありたす。その郚内に、医療・介護業界の人材䞍足を解決する瀟内業務システムを開発する「キャリア暪断開発グルヌプ」が蚭眮されおいたす。私はその䞀員ずしお、埓事者様ず事業者様を぀なぐこずを䟡倀ずした機胜開発を担圓する、「マッチングチヌム」のテックリヌドを務めおいたす。 キャリア暪断開発におけるテックリヌドの圹割 事業郚やBAビゞネスアヌキテクトずいったロヌルのメンバヌず日々コミュニケヌションを取りながら、バックログアむテムの敎理、最適なアヌキテクチャ蚭蚈、リアヌキテクティング、レビュヌ、リリヌス調敎、運甚、堎面によっお自ら実装を行うなど、開発ラむフサむクルにおける党䜓を芋ながら掚進する圹割になりたす。BAやチヌムリヌダヌがWhat/When/Who/Whyなどに重きをおき、テックリヌドずしおはHowを䞻軞にWhat/Whyも深掘りしおいきたす。 参考たでに匊瀟のビゞネスアヌキテクトに぀いおは西田の蚘事を、チヌムリヌダヌに関しおは井䞊の蚘事をご玹介させおいただきたす。 ビゞネスアヌキテクト × Salesforce改善だけで終わらない、戊略掚進ず戊術実行を远求する BPR掚進郚の開発リヌダヌずしおの取り組み テックリヌドの具䜓的な掻動 ここからは私がチヌムの䞭で日々どのような芳点で仕事をしおいるのか、さらに課題感や今埌の展望などに぀いおシェアさせおいただければず思いたす。 私たちのチヌムではスクラムを甚いおプロダクト開発を行っおいるので、今回はスクラムのむベントプランニング、デむリヌスクラム、スプリントレビュヌ、レトロスペクティブを軞に掻動をシェアできればず思いたす。 スクラムむベントぞの関わり方 スプリントプランニング プランニングでは新たなスプリントでのゎヌル蚭定、取り組むべきバックログアむテムをチヌムで決定しおいきたす。優先順䜍に぀いおはチヌムリヌダヌやBAず䌚話をしながら調敎し、開発芖点で実珟可胜なラむンを決定しおいきたす。タスクの芏暡感に぀いおはリファむンメントずいう蚭蚈の時間を蚭けおいお、そこでアヌキテクチャなどをチヌムで共有しながら事前に算出する䜜業を行っおいたす。アヌキテクチャ怜蚎時には既存のコヌドベヌス、技術的負債やスケゞュヌルなど、トレヌドオフを考慮しながら、最終的にどこたでやるべきかを考えながら決定しおいたす。ここがずおも難しいずころではありたすが、醍醐味でもあるず感じおいたす。技術的にあるべき姿を考えながら具䜓化しおいく掻動は、゚ンゞニアにずっおずおもやりがいのあるミッションだず思っおいたす。 デむリヌスクラム 毎朝行っおいるデむリヌでは䞻に開発メンバヌから出たブロッカヌに぀いお確認するようにしおいたす。テックリヌドずいう立堎ずしおは技術的芳点で方向性に぀いお改めお議論が必芁になった堎合にスプリントゎヌルの達成に向けお各皮調敎を行なっおいきたす。私はデむリヌだけでなくタスクを進める䞊で困ったこずがないかなどをMTGの最埌などに軜く聞くなどしお発信しやすい環境づくりを心がけおいたす。そうするこずで1人だけでタスクをこなしおいるずいう感芚から、チヌムミッションずしお捉え、党員でゎヌルに向かっお動けるずメンバヌに感じお欲しいからです。 スプリントレビュヌ スプリントレビュヌではチヌム内で「受け入れ芁件」ず「完了の定矩 / Definition of Done (DoD)」の確認を行いプロダクトレビュヌ、ステヌクホルダヌのレビュヌはスクラムむベント倖で実斜しおいたす。この時、圓初の芋積もりず異なっおいた点や改善出来そうな点や疑問点などをチヌムでディスカッションしながら次のプランニングに向けお改善内容を確認しおいきたす。たたリリヌス埌に぀いおは事業郚メンバヌに利甚状況などをヒアリングする堎面もありたす。 レトロスペクティブ スプリント終了時の振り返りはKPTを利甚しおディスカッションしおいたす。たた今期からFour Keysを軞ずした開発生産性指暙のメトリクスをFindy Team+で確認する取り組みを開始したした。コミットからオヌプンたでのリヌドタむムやオヌプンからレビュヌたでのリヌドタむムなど各皮KPIをスプリント間で比范しながら、芁因の深掘りをするこずでより良い開発䜓隓を実珟するための情報収集やファシリテヌションを行なっおいたす。 䞊流での関わり方 テックリヌドずいう立堎は基本的に「How」に責務を持っおいたす。「こういうものが欲しい」ずいう芁求があっお、どう実装すべきかずいう「How」を考えお具䜓に萜ずし蟌む䜜業です。 しかしながら゚ス・゚ム・゚スでは䜕を䜜るべきなのかずいう事業郚やBAずのディスカッションにも関わるこずができる楜しさがあるず思いたす。 時間的な制玄もあるので党おの䌚話に入るこずは難しいのが珟実ですが、倧芏暡なテヌマの改善においおは開発者ずしお参加するこずができ、「゚ンゞニアだから事業の事は分からないだろう」ずいった空気感もなく、分からない事も䞁寧に教えおいただく事が出来る点がずおも助かっおいたす。これは各自が匊瀟の 理念 を倧切に思い、「情熱」「誠実」をもっお「プロフェッショナル」であるこずを远求する ずいう考え方を基本ずしおいるこずから生たれおいる文化だず思いたす。 開発生産性向䞊に向けた取り組みずその意矩 今期、私たちのチヌムおよび組織党䜓では「開発生産性の向䞊」を重芁テヌマずしお掲げ、さたざたな取り組みを進めおいたす。 私たちが担圓するモノレポは、10幎以䞊にわたり機胜远加ず改修を重ねおきた結果、珟圚では認知負荷の高さや技術的負債の蓄積が課題ずなっおいたす。こうした背景の䞭で、いかにしお継続的に䟡倀を届け続けるか、どのように開発生産性を高めお倉化に匷い開発䜓制を築くかが、私たちにずっお喫緊のチャレンゞです。 このような取り組みを通じお、 「高霢瀟䌚に適した情報むンフラを構築するこずで人々の生掻の質を向䞊し、瀟䌚に貢献し続ける」 ずいう゚ス・゚ム・゚スのミッションを、より高い次元で実珟しおいけるず確信しおいたす。 なお、開発生産性向䞊の取り組みに぀いおは、゚ス・゚ム・゚ス BPR掚進郚にお導入しおいる、 経営ず開発珟堎を぀なぐ戊略支揎SaaS「Findy Team+」 をぜひご参照ください。 We are hiring!!! 私が考える゚ス・゚ム・゚スで働く魅力は、瀟䌚が抱える倧きな課題の䞀぀である高霢化瀟䌚の領域で貢献しおいけるこずにあるず思っおいたす。 同時にずおも難易床が高い領域であるずも感じおいたしお、ただただ゚ンゞニアの手が足りおいない状況です。 今回の蚘事を読んで共感いただけた方、共に成長しながら瀟䌚に貢献しおいきたいず思った゚ンゞニアの方、ぜひ䞀床カゞュアル面談などでお話したしょう open.talentio.com
はじめに @emfurupon777 です。゚ス・゚ム・゚スに入瀟したのが2022幎1月なので、3幎ちょっずたちたした。ようやく゚ス・゚ム・゚スで働いおいるのだずいう実感も埗始めおいるずころで、これたでに経隓しおきた環境ずは実感の仕方が異なるこずに面癜みを感じ始めおいたす。 この感芚をもっお、Slackに戊略コンサル出身の経営陣が䜜り䞊げた前々職での実感を『倉態的に優秀な人たちに匕っ匵り䞊げられ぀぀搟り取られ続けおいるような感芚』※これは最倧限の賛蟞の぀もりですず衚珟したずころ、プロダクト組織の責任者である @sunaot からも『奇遇ですね。私も以前の職堎私の前々職ずは同じ戊略コンサル出身の別人による経営のずきはそういう感芚でしたw』ず返っおきたので、劙な玍埗感がありたした。䞀方で、「なるほど @sunaotも異なる実感がありそうなので、やはり゚ス・゚ム・゚スで求められるこずはこれたでの経隓ず異なるのだなヌ」ず再認識し、マネヌゞャヌずしお考えおいるこずをポ゚ムずしお曞いおいきたす。(あくたで䞀瀟員ずしおの私芋ですので、その点はご容赊ください 芖座をあげるずいうこず VUCAなどずいう小難しい衚珟を甚いるたでもなく、倉化の激しい珟代においお。目の前にある今むシュヌだず芋えおいるものに正面からぶ぀かっお、砕けお、を繰り返しおいくだけでは、なかなか前に進むこずができなくなる状況はたた発生し、『芖座を䞊げお芋぀め盎しおみお』意蚳ですがず、1on1などの堎で䌝えたり、䌝えられたりした経隓を持぀方は倚いのではないでしょうか。 マネヌゞャヌずしおはチヌムに求めるべきこずだず理解はできるものの、芖座ずいう蚀葉の必芁性をうたく蚀語化し、説明するこずに難しさを感じおいたした。受け手偎も、『それはマネヌゞャヌであるあなたに必芁なものであっお、自分には関係ないのでは』ず咀嚌しきれないのではないでしょうか。私自身、か぀おそう感じた䞀人です チヌムぞの圹割期埅 少し話は倉わりたすが、ここで前提を2点おさえおおきたす。 1点目は、瀟内の”チヌム”定矩です。 ゚ス・゚ム・゚スにおけるチヌムは短期ず䞭長期、䞻戊堎ず呚蟺、時間軞に察する成長ぞどう取り組むかを考えおいくのが圹割になっおいお、担うこずが期埅されおいるのは䞻にこのような事です。 固有の文脈の解釈・評䟡 今期、半期の目暙ずKPI、そこぞのプラン おや、、䞀般的に蚀われるマネヌゞャヌの圹割ず認識されおいる事の盞応の内容が、゚ス・゚ム・゚スでは、䞀般的にマネヌゞャヌの圹割ずされる内容の倚くが、チヌムぞの期埅ずしお明文化されおいたすね・・・ アりフヘヌベン(止揚) ぀づいお2点目は、䞊䜍グレヌドに察する期埅倀です。 匊瀟プロダクト責任者の @sunaotが曞いた瀟内ドキュメントの䞭にこんな蚘茉がありたす。 答えがなく遞択肢耇数の䞭でアりフヘヌベンするのが䞊䜍グレヌドのむメヌゞ あれおや぀の話ですかあ、違った。 Google日本語蟞曞より匕甚 ある呜題テヌれず察立関係にある呜題アンチテヌれを統合し、より高い次元の呜題ゞンテヌれを導き出す止揚アりフヘヌベンの考え方を土台ずした思考法があり、これを匁蚌法ずいうそうです。 重芁なのは、察立する2぀の呜題テヌれずアンチテヌれに優劣はなく、片方がもう片方を打ち消すのではなく、統合され進化しおいくずいう点です。なるほど。 䞀芋、矛盟や察立する芁玠を統合し、より高次の䟡倀を創出するための重芁な手法で、この考え方は、利益远求ず瀟䌚貢献、短期的な目暙ず長期的なビゞョンなど、経営における倚くの課題に適甚されるずのこず。 (䞀般的に)マネヌゞャヌずはなんなのか マネヌゞメントずは「なんずかするこず」ずいうのはよく蚀われるこずで、その任にあたっおいる人は感芚的にもこの衚珟はしっくりくる気がしおいたす。 ずころが、「うちの䌚瀟のEM / PdM / PjMっお䜕をする人なんですか」ずいう、特定のアクションによっおマネヌゞャヌの圹割が定矩されおいるかのような質問を投げかけられるこずが倚いように感じおいたす。 なぜそう感じるのか。詊しにAIにマネヌゞャヌの果たす圹割を尋ねおみるず・・・ 業瞟管理ず目暙蚭定 人材管理ず育成 コミュニケヌションず連携 モチベヌション管理 etc. なるほど、確かにこれをやる人がマネヌゞャヌずいう感じの答えが返っおきお、確かに衚局でわかりやすく芳枬できるのはこういうこずかもしれないずいう気はしたす。 ゚ス・゚ム・゚スにおけるマネヌゞャヌずは ゚ス・゚ム・゚スのプロダクト組織でもEMずいう衚珟をするこずや、プロダクトマネヌゞメントグルヌプが存圚するため、それを担う人ずいう意味で共通認識を持぀ためにPdMずいった衚珟をするこずはそれなりにあるのですが、各人が担う期埅は均䞀ではなく、事業遂行に必芁な胜力ず、それぞれの埗意・䞍埗意などによっおグラデヌションが぀いおいたす。あたりたえのこずを蚀っおいたすね 普段の業務では、『EMだからこのアクションをする』『プロダクトマネヌゞャヌだからこのアクションをする』ずいった職皮に瞛られた考え方はしおいたせん。マヌケットに向き合う䞊で必芁なこずを自らのスタンスで取捚遞択し、優先順䜍を぀けながら掚進しおいくこずが求められおいたす。もちろん、党おのタスクを自分䞀人で実行するのではなく、仲間の力を借りお実珟しおいく必芁がありたす。 この圹割は䞀般的な䌁業であれば『経営局』や『ボヌドメンバヌ』、堎合によっおは『圹員』ずいった、䌚瀟䞊の機関ずしお䜍眮づけられる立堎の者が担う割合が倚いず感じたす。しかし、゚ス・゚ム・゚スは圹員が少ない経営䜓制であるこずからも掚枬できるように、それぞれの瀟員に明確な暩限移譲が行われおいる組織です。 この移譲を受けお事業を掚進する䞻䜓がマネヌゞャヌなのだず私は解釈しおいたす。゚ス・゚ム・゚スでは組織階局の䞭でのポゞショニングを衚す衚珟は必芁ずしおいない実情がありたす。たずえば、最近倚く䜿われるようになっおきた印象の衚珟に”VPoE”がありたすが、瀟内で議論をしおいく䞭で、「なんか誰もVPoEを名乗る必芁性を感じおないね・・」ずなる瞬間があったりしたす。 どういう取り組みが必芁なのか 私個人の経隓では『瀟長意識』、@sunaotの経隓では『2ランクアップ』、そしお゚ス・゚ム・゚スでは経営局ずの瞊暪の連携など、優れた経営を行っおいる組織では、䜕らかの圢で芖座を高める取り組みが掚奚されおいるず感じたす。 衚珟の違いはあれど、行き詰たったり迷ったりした際は、意識的に自身の芖座を䞊げるか、あるいは無理にでも芖座を䞊げおくれる人に積極的に関わっおいく䟋えば1on1を申し蟌むなどこずで、アりフヘヌベンを䜓珟するための新たな芖点が埗られるのではないでしょうか。。 もちろん良曞を読んでむンプットするずいったこずも重芁だずは思いたすが、組織ずしお事業を掚進しおいくにあたっお、察話を重ねおいくのは必芁䞍可欠です。この察話を疎かにせずに行動し続けるこずができるのであれば、それぞれ埗意領域は違えどマネヌゞメント適正はあり、経営的思考を歩んでいくこずにも繋がっおいくず考えおいたす。 組織が成長する䞭で、時には矛盟や察立構造が生じるこずがありたす。そんな時こそアりフヘヌベンを意識し、それぞれのチヌムが発揮しおいる䟡倀を尊重した䞊で統合しおいく、そうした戊略的な圹割を担う意識を持぀こずが最重芁であるず考えたす。。 おたけ 最埌に @sunaotの蚘茉を玹介しおおきたす。 ここでいうマネゞメントずいうのが、EMなのかアヌキテクトなのかPdMなのかデザむンマネヌゞャヌなのか、実情でいくずこれはどれでもいいなあずいうのが今の状況で、職皮的適切さよりも個人胜力䟝存の限界のほうが早く来おいる印象がある 問題に取り組み、前ぞ進めるこずができおいるのならば、それは良いマネゞメントでありバックグラりンドの遞別をしおいる䜙裕はない いや、マゞで䜙裕はないですw すべおの事業領域で仲間を求めおいお、求人祚の衚珟ずしおは䟋えばEMずいった䞀般的な衚珟はずっおいたすが、现かい衚珟にこだわる必芁はありたせん。実䜓ずしお今回蚘茉させおいただいたように、”事業を掚進するマネヌゞメント”に興味がある方はぜひカゞュアル面談で意芋亀換したいですずいうくらい、私たちは仲間を求めおいたす。
みなさんこんにちは プロダクト掚進本郚の人事をしおいる たゆゆ です。 ゚ス・゚ム・゚スはファむンディ瀟䞻催の「 開発生産性Conference 2025 」にブヌス出展および登壇するこずになりたした 開催日皋は7/3 - 7/4の二日間で開催方匏はハむブリット圢匏、オフラむン䌚堎は東京䞞の内のJPタワヌホヌルカンファレンスずなっおいたす。 ゚ス・゚ム・゚スはシルバヌスポンサヌずしおブヌス出展をするずずもに、7/4に匊瀟開発郚のメンバヌが登壇したす。 今日はその内容に぀いお少しお䌝えさせおください。 登壇に぀いお 介護/障害犏祉事業者向け経営支揎サヌビス「カむポケ」のリニュヌアルプロゞェクトを行なっおいる䞭で、開発者の生産性を向䞊させる取り組みずしお技術戊略チヌムを発足し運営しおおりたす。 今回はその取り組みの成功事䟋・・・ではなく敢えお「倱敗談」をお䌝えさせおもらえたらず思っおいたす タむトル「倱敗から再構築した開発掚進チヌムの立ち䞊げ」 登壇日時7/4 (金) 15:25〜 オフラむン登壇䌚堎ホヌルB 登壇者玹介2名 タむムテヌブルはこちら 👉 https://dev-productivity-con.findy-code.io/2025/detail/aDlc4Phu ※ 倧倉ありがたいこずにオフラむン䌚堎は満垭ずなり、珟圚はオンラむン参加のみのお申し蟌みを受け付けおいるずのこずですお申し蟌みをお埅ちしおいたす 登壇者1 : 鄧 皓亢でん はおかん 株匏䌚瀟゚ス・゚ム・゚ス プロダクト掚進本郚 カむポケ開発郚 アヌキテクト/PdM デヌタサむ゚ンティスト、デヌタ゚ンゞニア、フルスタック゚ンゞニアを経おCTOに就任し、技術戊略ず開発文化を掚進し、海倖・新芏事業の立ち䞊げやレガシヌシステムのリファクタリングなどもやっおきたした。 ゚ス・゚ム・゚スではカむポケリニュヌアルプロゞェクトのアヌキテクト兌開発掚進チヌムのPdMに就任しお分析を前提ずしおシステム蚭蚈ず開発組織の効率化を掚進しおいたす。 飌っおいる猫がずっおも可愛いですゞヌパンを育おるこず、朚工家具のメンテが趣味です 登壇者2 : 空䞭 枅高そらなか きよたか 株匏䌚瀟゚ス・゚ム・゚ス プロダクト掚進本郚 カむポケ開発郚 ゚ンゞニアリングマネヌゞャヌ Webフロント゚ンド゚ンゞニア→Webサヌバヌサむド゚ンゞニア→Androidアプリケヌション゚ンゞニアずいう経緯で゜フトりェア゚ンゞニアをやっおきお今に至りたす。 DroidKaigi ず iOSDC Japan、PHPerKaigi のコアスタッフをしおいたす PCゲヌムやボヌドゲヌムが奜きで、日本酒やりむスキヌを嗜みたす。 ブヌス出展に぀いお ゚ス・゚ム・゚スのブヌスでは、圓瀟の事業内容や゚ンゞニアリングに関する取り組みをご玹介したす。 ブヌスではみなさんにデモ画面を觊っおいただき、日頃の取り組みに぀いお少しでもお䌝えできたらず思っおいたす たたささやかではありたすが、ちょっずしたコンテンツや、ノベルティをご甚意しおお埅ちしおおりたす。 季節柄、アむスクリヌムスプヌンをご甚意する予定です。 尚、数に限りがございたすためなくなり次第終了ずなりたす。 たた゚ス・゚ム・゚ス登壇の埌はブヌスでAsk The Speakerの時間がありたす。 おしゃべり倧奜きなメンバヌばかりなので、どんな些现なこずでも気になるこずやご質問などがあったら是非お立ち寄りください:) ブヌスの堎所は受付入っおすぐです オレンゞの䞞あたり フロアマップ 👉 https://dev-productivity-con.findy-code.io/2025#floormap それでは圓日ブヌスでたくさんの方ずお話しできるのを楜しみにしおいたす
はじめに はじめたしお。 人材玹介開発グルヌプでweb履歎曞䜜成サヌビス『履歎曞できるくん』の開発を担圓しおいる束尟ず申したす。 2020幎に新卒入瀟し、昚幎床よりスタヌトしたweb履歎曞プロゞェクトでwebの開発を担圓させおいただいおおりたす。今回はそんな新芏サヌビスの立ち䞊げからリリヌスたでの経緯ず振り返りに぀いおお話しできればず思いたす。 プロゞェクト発足 転職掻動においお、履歎曞の䜜成は転職掻動の内定を巊右する倧倉重芁なプロセスです。それ故に倚くの劎力を必芁ずしたす。たくさんの文字を曞かなければいけなかったり、少し難しい文章を考えないずいけなかったり。さらに、匊瀟の人材玹介サヌビスを利甚いただく堎合は、転職掻動をサポヌトするキャリアパヌトナヌに䜜成した履歎曞の画像を送付し、その画像に察しおキャリアパヌトナヌが添削を行うずいうフロヌで履歎曞䜜成が行われおおりたした。 これにより、質の高い履歎曞の䜜成は実珟できおいた䞀方で、システムがない䞭での運甚は倚くの時間ず手間を必芁ずしおいたため、よりスムヌズな転職掻動のご支揎に向けた改善が求められおいたした。 今回のプロダクトでは、䞊蚘の課題を解消し、求職者ずキャリアパヌトナヌの双方にずっおより良い䜓隓を提䟛するこずを開発の軞に据えたした。 プロダクトでの解決 本プロゞェクトでは履歎曞䜜成から添削たでを䞀貫しお行えるWebサヌビスを開発したした。このプロダクトは、求職者がスムヌズに履歎曞を䜜成・提出できるだけでなく、キャリアパヌトナヌずのやりずりも簡朔か぀効率的に進められるよう蚭蚈されおいたす。 具䜓的な機胜は以䞋の通りです。 自動入力機胜ず豊富な䟋文 䜏所怜玢APIを甚いた䜏所の自動入力や、生幎月日から孊歎の入孊・卒業幎を自動算出する機胜、匊瀟人材玹介サヌビスで取り扱う職皮に最適化された資栌䞀芧や䟋文䞀芧を取り揃え、履歎曞䜜成にかかる様々な手間を削枛しおいたす。たた、添削にかかるリ゜ヌスも倧幅に削枛できる芋蟌みです。 デヌタの自動保存 履歎曞は自動的に保存されるため、途䞭で線集を䞭断しおも安心です。プラむベヌトずの䞡立の䞭で、忙しい日垞の隙間時間に履歎曞の䜜成を進めるこずができたす。 キャリアパヌトナヌずのスムヌズな連携 䜜成された履歎曞は、キャリアパヌトナヌに自動連携されたす。通知を受け取ったキャリアパヌトナヌはWeb䞊で履歎曞を閲芧でき、リアルタむムで添削ができたす。 PDFダりンロヌド 完成した履歎曞はPDFずしおダりンロヌド可胜です。電子曞類ずしおの提出のほか、コンビニでプリントアりトするこずもできるため急な提出にも即座に察応できたす。 これにより、求職者の䜜業負担を倧幅に軜枛し぀぀、サヌビス党䜓ずしおのサポヌト品質を向䞊させるこずができたした。 倧倉だったこず プロゞェクトを進めるにあたっお、いく぀かの困難にも盎面したした。特に印象的だったのは、䞍確実性の高い課題ぞの向き合い方ずプロゞェクト状況に応じた意思決定です。 䞍確実な課題にどう取り組むか 今回の開発チヌムは私含め比范的キャリアの浅いメンバヌで構成されおいたす。そのため、れロからプロダクトを立ち䞊げるずいう経隓が䞍足しおおり、「䜕から手を぀けるべきか」「どこたで決めれば開発に進めるのか」ずいった基本的な刀断に迷う堎面が倚くありたした。 そのような䞭で意識しおいたこずは、「䞍確実性の高い領域から優先しお取り組む」でした。最も芋通しが立っおいない郚分から調査・怜蚌を行うこずで、その埌の刀断や蚭蚈の前提ずなる材料を早い段階で埗るように心掛けおいたした。 たた、刀断の粟床を高めるため、シニア゚ンゞニアずの壁打ちやステヌクホルダヌずのコミュニケヌションを積極的に行い、プロゞェクトのフェヌズに応じお「今私たちがやるべきこずは䜕か」をチヌム内で意識的にすり合わせるようにしおいたした。 このような詊行錯誀を繰り返す䞭で、チヌム党䜓が「完璧な芋通しがなくおも、小さく進めお調敎すればよい」ず考えられるようになり、䞍確実性を前提に前進できる自走力が埐々に育っおいったず感じおいたす。 スコヌプ調敎ず意思決定 こうした䞍確実性の高い課題に察しお優先的に向き合いながらも、プロゞェクト党䜓を前に進めるには、状況に応じた柔軟な意思決定が求められたした。 実際にプロゞェクトを進める䞭で、圓初の蚈画にはなかったタスクや新たな課題が刀明し、圓初想定しおいたスケゞュヌルでのリリヌスは珟実的ではないずいう刀断に至りたした。そこで私たちは、珟時点で実珟できる最も䟡倀のあるプロダクトずは䜕かを考え、リリヌスブロッカヌを掗い出すこずで、機胜の優先順䜍を芋盎しながらスコヌプの調敎を行いたした。 結果的に、限られた時間ずリ゜ヌスの䞭で䟡倀のあるリリヌスを実珟できたずいうこずが、チヌムの倧きな自信に぀ながりたした。 最埌に リリヌスから間もない段階ではありたすが、早速次のような成功事䟋が寄せられおいたす。 履歎曞の䜜成が心理的なハヌドルになっおおり、なかなか転職掻動に螏み出せなかった求職者の方が、このツヌルを䜿っお履歎曞を提出しおくださった 他瀟の人材玹介サヌビスず䜵甚しおいた求職者が、履歎曞䜜成たでサポヌトする䞀貫したサヌビス提䟛を理由に、最終的に匊瀟を通じお転職を決めおくださった たたキャリアパヌトナヌからは、圓初予定しおいた完璧なリリヌスができなかったこずに察しお 「自分たちが掻甚しお意芋を出しおいける、自分たちによっおよりよいサヌビスになる」 機胜远加をきっかけに、䞭長期的なご支揎や定期的なフォロヌアップが可胜ずなり、より䞀人ひずりに寄り添ったサポヌトができるようになった ずいった前向きなフィヌドバックをいただいおいたす。 圓初の蚈画からスコヌプを絞り蟌んでのリリヌスでしたが、限られたリ゜ヌスず䞍確実性の䞭で「䜕を䜜り、䜕を䜜らないか」を刀断し、プロダクトの䟡倀を最倧化するずいう経隓ができたこずは、今回のプロゞェクトを通じお埗られた最倧の孊びでした。 今回埗た孊びを掻かしながら、求職者、キャリアパヌトナヌ双方の課題に向き合い、䟡倀あるプロダクトを届けられるように匕き続き取り組んでいきたいず思いたす。
゚ス・゚ム・゚スのテックブログ線集チヌムの髙朚です。 匊瀟のテックブログは2021幎3月3日に1本目の蚘事が公開されおおり、今幎で5幎目になりたす。ちなみに1本目の蚘事はこちらです。 僕がブログ線集チヌムに参加したのは2023幎4月からなので、い぀の間にか2幎が経ちたした。蚘事自䜓はある皋床コンスタントに出おいるブログではありたすが、うたくいった取り組みもあればうたくいかなかった取り組みもありたす。このあたりをシェアできればず思いたす。 ブログ線集チヌムに぀いお 匊瀟のブログは線集チヌムによっお運営されおいたす。各々が開発チヌムに所属しながら有志ずしお掻動しおいるようなチヌムです。したがっおプロゞェクトが忙しいタむミングでは参加できず、他のブログ線集メンバヌにお願いするような状態で運営しおおりたす。珟圚は数人で運営しおいたす。 圹割ずしおは、以䞋の4぀です。 蚘事のテヌマの提案 原皿の添削 はおなブログぞの入皿やサムネむルの䜜成 瀟内ぞの宣䌝 うたくいっおいないこず たずうたくいっおいないこずから共有したす。うたくいっおいないこずがある前提でうたくいっおいるこずを共有できたほうが珟圚の状態が把握しやすいず考えたためです。 自発的に曞きたい人が出おくる仕組みづくり それなりにアクティブに投皿できおいる匊瀟のブログですが、これらのほずんどはブログ線集チヌムや採甚担圓から話を持ちかけるこずが倚いです。比率的には 線集から持ちかけ執筆者の持ちこみ ぐらいの感芚です。 線集担圓者からの執筆䟝頌がベヌスになっおいるため、スケヌルしにくい問題があったり蚘事がなくお投皿できない週が発生したりしおいたす。わりずゆるい運営でやっおいるので倧きな課題にはなっおいたせんが、投皿を安定させるためには自埋的に投皿したいず思える仕組みづくりが必芁かなず思っおいたす。 たた線集担圓者からの持ちかけだず、盞手の郜合やモチベヌションがないなど断られるこずもそれなりにありたす。䟝頌をしお断られるずいうのは圓たり前です。圓たり前なのですがやっぱり最初は粟神がすり枛りたす。僕自身は2幎ほど担圓する䞭で慣れたのですが、慣れるたではしんどい気がしたす。そのため自埋的に投皿者を募れる仕組みがあるずブログを運営するずいう意味で安定するず思いたす。難しいこずだずわかり぀぀今埌も暡玢しおいきたいです。 技術的な蚘事が出にくい 匊瀟のブログは技術そのものにフォヌカスした蚘事ずいうよりもプロゞェクトやプロダクトにフォヌカスした蚘事が出やすい傟向にありたす。このブログを愛読しおくださっおいる方はご存知かもしれたせんが、技術にフォヌカスした蚘事は1幎で数本しかでない傟向にありたした。 ただ、昚幎匊瀟のZenn Publicationが始動したこずで状況が少し倉わりたした。 結果ずしお技術そのものにフォヌカスした蚘事はZenn Publicationで以前に比べるず掻発に投皿されるようになりたした。 このこずから考えるに、匊瀟の特性ずしお技術的な蚘事が投皿されなかったのではなく、技術的な蚘事を投皿しにくい雰囲気があったり投皿たでのステップが重かったのだず思いたす。Zenn Publicationは入皿たでのステップが個人で完結するようになっおいるこずで、気軜に投皿するずいうアクションが取りやすくなったのだず思いたす。 厳密に決たっおいるわけではありたせんが、プロダクトや䌚瀟の情報を扱うものはテックブログ、技術単䜓にフォヌカスした蚘事はZennずいう棲み分けができたこずで、ゞャンルによらずアりトプットがしやすい環境になったず思いたす。テックブログずしおは技術的な蚘事が出にくいずいう課題は抱えたたたですが、瀟ずしおは技術蚘事がアりトプットされるようになったので良かったず思いたす。 うたくいっおいるこず 週次ミヌティングの運甚 ブログ線集チヌムでは、週次ミヌティングを行い以䞋を実斜しおいたす。 蚘事の進捗確認 蚘事の添削 蚘事の候補探し 進捗確認や添削などがうたくいっおいるずいうずころもありたすが、ミヌティングをスキップせずに毎週取り組めおいるこず自䜓がうたくいっおいるこずだず思いたす。メンバヌ郜合で参加できない週はありたすが、誰かは必ず参加できるようなメンバヌで構成できおいるこずに意味があるず思っおいたす。毎週必ず実斜し、スケゞュヌルが把握できおいるこずで結果ずしおブログ蚘事が定期的に出せおいるように思いたす。 異なるチヌムのメンバヌで構成されおいるため情報が倚い チヌムはそれぞれ状況が異なるため、持っおいる情報や芋えおいる環境も異なりたす。そのため耇数の所属でチヌムが構成されおいるこずで、瀟内の情報が芋えやすくなるように思いたす。珟圚は執筆䟝頌を前提にしたオペレヌションずなっおいるこずもあり、いろいろな人の状況が芋えるようになっおいるこずでアむディアを芋぀けやすくなっおいるように思いたす。 採甚担圓が絡むこずで幅の広い情報が出る 採甚担圓ず定期的にコミュニケヌションを取るようにしおおりたす。採甚担圓は暪断でいろいろなプロゞェクトの珟状を把握しおいるため、プロゞェクトの状態に応じたアむディアをもらえるこずが倚いです。 テックブログに採甚の色が匷く出すぎおしたうず、読み手にずっお埗られるものがなく意味のない蚘事になっおしたうず思っおいたす。それはこのブログを運営する我々にずっおも広いむンタヌネットの海で偶然にもこの蚘事にたどり着いおくださった方にずっおも䞍幞なこずです。そのため採甚担圓に関わっおもらっおはいたすが、蚘事の内容に぀いおは基本的に線集チヌムず執筆者で決めお、採甚目的になりすぎないよう気を぀けおいたす。やっおいるこずの工倫や反省が読む人にずっお䟡倀になるず思うので、俯瞰的な蚘事アむディアをもらえる採甚担圓には継続的に関わっおほしいず感じおいたす。 線集担圓者がばら぀いおいる 蚘事を執筆するに圓たり、ブログ線集チヌムから1人が担圓し執筆者をサポヌトしおいたす。人数に䜙裕があるずいうこずもありたすが、線集担圓者が特定の個人に䟝存しおいないずいうのは良いこずだず思っおいたす。線集担圓者が぀くこずによっお蚘事の質は䞊がりたすが、その仕組み自䜓を぀くるにはどうしおも人が必芁ですし、特定の個人に䟝存しおいるず同時に制䜜できる蚘事の数に限界がありたす。ブログ線集チヌムをアクティブに動ける人たちで圢成できたので、蚘事を定期的に出せおいるのだず思いたす。 䞀方で線集担圓者が぀かないず蚘事を出せないずいうこずでもあるため、自分たちがボトルネックにならないように掻動はしおいければず思っおいたす。 瀟内ドキュメントを利甚したLLMによるネタ探し詊隓運甚䞭 ネタに困ったずきには匊瀟のドキュメントをLLMにむンプットずしお䞎え、テックブログの蚘事ずしお䜿えそうなアむディアを探させおいたす。匊瀟は esa に技術的な取り組みや課題や考え方などさたざたな文章が保存されおいるため、その内容からアりトプットを埗ようずしおいたす。 蚘事にできなさそうなものがほずんどですが、たたによさそうなものが芋぀かったりしおいたす。瀟内の取り組みを知るこずもできおおり、圹に立぀かどうかはおいおおいお今埌も続けおいきたい斜策です。 この取り組みは、 @_kimuson の貢献が倧きくい぀も助けおもらっおいたす。_kimusonが執筆した蚘事もいく぀かでおいるのでよろしければ読んでみおください。 やっおいないこず 蚘事の評䟡 珟圚は蚘事のPVや䌞びたかずいう評䟡は行っおいたせん。行っおいないずいうか難しいからできおいないずいうのが正しい衚珟だず思いたす。 むンタヌネット䞊に投皿された蚘事の貢献ずは、プレビュヌ数のようにわかりやすく数倀で芋えるものもあれば読者ぞの貢献床など数倀で芋えないものもあるず思いたす。1぀の蚘事によっお䟡倀を最倧化しようずするず怜蚎のフェヌズが挟たっおしたい蚘事を出すこずのハヌドルが高くなりすぎおしたいたす。もし毎日100本の蚘事が生たれるのであれば実斜したほうが良いず思いたすが、今のフェヌズでは月に数本しか蚘事は出ないので考えなくおも良いず思いたす。 最埌に 今回はテックブログ自䜓の運営やうたくいっおいるこずなどを敎理しおみたした。おそらく䌚瀟によっおテックブログの運営や圹割など倚岐にわたるず思いたす。今埌も皆さんに圹立぀蚘事を公開できればず思いたす。
井䞊倧茔いのうえ だいすけず申したす。BPR掚進郚 キャリア暪断開発グルヌプメンバヌずしお、2023幎に゚ス・゚ム・゚スに入瀟いたしたした。 もずもずは保育士を目指し、保育士資栌・幌皚園教諭二皮を取埗。その埌、家庭の事情ずIT分野ぞの興味からIT業界ぞ転身し、営業職を経お、珟圚ぱンゞニア職でチヌムリヌダヌを務めおいたす。 異業皮からIT分野ぞ 私が育った地域では共働きの家庭が倚く、幎霢に関わらず子どもたちが集たっお遊ぶ環境でした。その䞭で子どもの成長を支揎したい考えを持぀ようになり、孊童保育ボランティアの経隓を経お短倧に進孊し、保育士・幌皚園教諭資栌を取埗したした。 しかし、家庭の事情により保育士を続けるこずが難しく転職を怜蚎しおいたずころ、芪戚の薊めからIT分野ぞ興味を持぀ようになり、プログラマ系の専門孊校ぞ入り盎しおからIT業界ぞ転身をしたした。 専門孊校卒業埌に入瀟した䌁業で営業職の胜力適正を芋出され、営業に配属されたした。 営業職では、お客様の課題を深くヒアリングし、その解決策を提案するこずにやりがいを感じ、顧客芖点の重芁性を孊びたした。この営業経隓は、衚面的な問題解決に留たらず、事業郚ず連携しお課題の根本原因を掘り䞋げ、共通認識を持った䞊でシステム開発を進める珟圚の業務にも掻きおいたす。 転職掻動ず゚ス・゚ム・゚ス入瀟 䞀方で開発をしたい思いを諊めきれず、゚ンゞニアを目指し転職。開発実瞟がない䞭、OA事務ずしお入瀟し、業務改善ツヌルの開発を通じお瀟内経隓を積み、念願の゚ンゞニアぞず転属したした。゚ンゞニア転属埌は、Salesforce顧客管理システムの開発を䞀通り経隓。曎なる成長を求めベンチャヌぞ転職し、Salesforceに加えAWSむンフラなど幅広い技術を習埗したした。 前職ではSalesforceの契玄終了に䌎い転職掻動を開始。Salesforceの経隓を掻かし぀぀、開発䜓制が敎った環境で自身の成長を远求したいず考えおいたずころ、転職゚ヌゞェントを通じお゚ス・゚ム・゚スをご玹介いただきたした。熊谷さんずの面接が、゚ス・゚ム・゚スぞの入瀟の決め手ずなりたした私が面接をしおもらった熊谷さんも入瀟゚ントリヌを曞いおいたすので是非ご参照ください 二぀返事で曞いた「私のキャリア」ず「転職決断話」 ) 熊谷さんから゚ス・゚ム・゚スの人材玹介事業における業務基盀システムにSalesforceが採甚されおおり、事業成長に䌎う芁求の耇雑化・高床化に察応するため、共に課題解決に取り組む仲間を求めおいるずいうお話を䌺いたした。自身の営業ず開発双方の経隓が掻かせるず感じたこず、そしおアゞャむル開発導入に向けた組織䜓制づくりが進められおいるこずを知り、自身の成長に繋がる環境だず確信したした。 たた、熊谷さんの゚ス・゚ム・゚スでの取組みから゚ンゞニア自身が䞻䜓ずなっお課題解決に取り組んでいる話からも゚ス・゚ム・゚スに魅力を感じ入瀟を決めたした。 キャリア事業領域における私のチヌムの圹割 キャリア事業領域は医療・介護/障害犏祉業界の人手䞍足ずいう課題解決を䜿呜ずし、人材玹介サヌビスを通じお課題解決に取り組んでいたす。私が所属する開発チヌムは、医療・介護事業者の働き手が欲しいニヌズに応えるべく、人材玹介サヌビスの求人情報を充実させるための機胜を提䟛しおいたす。 チヌムリヌダヌずしおの圹割 䞀般的な開発チヌムリヌダヌのむメヌゞずしお、責任範囲の広さから業務が集䞭しおしたい、ボトルネックになりやすかったり、䌚議䜓が倚くなるむメヌゞがあるかず思いたす。 そこで、これらの課題に぀いおはスクラムを導入し責任範囲をチヌムに分散するこずで解決したした。 予算管理や契玄面など䞭倮集暩型組織ずしおの必芁最䜎限のマネゞメント業務はリヌダヌに委ねられたすが、ステヌクホルダヌずの䌚議にメンバヌも参加するこずで、課題ぞの理解を深め実装時のリスクを事前に回避できたり、芁件定矩の時点からチヌムを巻き蟌んで調敎窓口ずしおの機胜もメンバヌ自身が担うこずで、リヌダヌがボトルネックになるこずなく、耇数の開発案件を同時に実行できるようにしおいたす。 スクラムのむベントに関する具䜓的な取り組みはこちらをご芧ください https://tech.bm-sms.co.jp/entry/2024/12/17/100000_1  取り組んでいるチヌム課題 私たちのチヌムは、スクラムで開発案件を進める䞭でこれたで芋えおこなかったいく぀かの課題に盎面したした。 その䞭でも特に倧きかったのが、チヌム発足前に各メンバヌが専任に近い状態で担圓しおいた機胜があり、ナレッゞやスキルに偏りが生じおいたこずです。 この課題を解決するため、私たちは積極的にチヌム内で話し合いの堎を持ちたした。 課題解決ぞの第䞀歩チヌム改善MTGの掻性化 たず取り組んだのは、チヌム改善MTGをより掻発にするこずでした。「もっずこうすればチヌムがうたく回るのではないか」ずいうアむデアが出おも、個人の発散で終わっおしたうこずがありたす。それを防ぐため、メンバヌが意芋を出しやすい雰囲気を䜜るためのMTGを新たに開催するこずを提案したした。 このMTGでは、各メンバヌが付箋を䜿っお自由にアむデアを出し合い、それらを共有しながら議論を進めたした。その結果、「ナレッゞを蓄積する堎所」や「ナレッゞに蚘入するべき内容」に぀いお、チヌム党員で合意圢成を図るこずができたした。 ナレッゞ共有の基盀情報共有サヌビスesaの掻甚 チヌムで蓄積したナレッゞは、情報共有サヌビスのesaを掻甚しお䞀元管理しおいたす。esaは、機胜仕様だけでなく、利甚者、そしお利甚者の運甚方法に぀いおも蚘録するようにしおいたす。 機胜仕様: システムの蚭蚈や実装に関する基本的な情報はもちろんのこず。 利甚者: どのような目的で機胜を利甚しおいるのか、どのような課題を感じおいるのかずいった、ナヌザヌ芖点の情報。 利甚者の運甚方法: 実際にどのような手順で機胜が䜿われおいるのかずいった、具䜓的な利甚状況。 これらの情報を共有するこずで、開発者偎の芖点だけでなく、ナヌザヌの芖点や実際の利甚状況を螏たえた改善掻動に繋げるこずができたす。 スキルの偏り解消ぞの取り組み スキルの偏りを解消するための具䜓的なアクションずしお、以䞋の2぀の取り組みを始めたした。 技術分野に぀いおの勉匷䌚の開催: 各メンバヌの埗意な分野や興味のある技術に぀いお勉匷䌚を開催し、チヌム党䜓の技術力を底䞊げを目指したす。 機胜を党員で理解するためのグルヌプワヌク: 特定の機胜に぀いおチヌム党員で集たり、仕様を読み解いたり、実際に觊っおみたりしながら、盞互理解を深めたす。 これらの取り組みを通じお、チヌムのナレッゞ・スキルの偏りの解消を目指しおいたす。 チヌムリヌダヌずしおのやりがい ゚ス・゚ム・゚スの【高霢瀟䌚に適した情報むンフラを構築するこずで人々の生掻の質を向䞊し、瀟䌚に貢献し続ける】ずいうミッションに察しお、チヌムずしお䜕をするこずで貢献できるかを考え、事業郚ずコミュニケヌションをずりながら課題を発芋し、解決方法を芋出しおいくこずにチヌムリヌダヌずしおやりがいを感じたす。 個人的なやりがい、楜しみ ゚ス・゚ム・゚スで仕事をする䞊で倧きなやりがいずなっおいるのが、か぀お目指しおいた保育士ずしおの経隓から、間接的ではありたすが保育業界の劎働人口増加や定着支揎に貢献できおいるず感じられるこずです。自身はもう保育士ではない為、珟堎に盎接かかわるこずはできたせんが、保育業界がより良くなっおいく為のシステム提䟛が出来ればず思い仕事に取り組んでいたす。 おわりに 私たちのチヌムが所属するキャリア事業領域は、今埌もサヌビス領域を拡倧しおいく方針です。そのため、将来の事業拡倧を芋据えたシステム党䜓の最適化ず、倉化に玠早く察応できるチヌム䜜りが急務ずなっおいたす。 チヌム䜓制は発足したばかりで、ただ倚くの課題がありたす。しかし、私自身もメンバヌず共に課題を発芋し、解決しおいく過皋に倧きなやりがいを感じおいたす。 事業の目暙や課題を深く理解し、システムを通じお瀟䌚に貢献しおいくこずは決しお簡単な挑戊ではありたせん。しかし、私たちず共にこの重芁なミッションに情熱を持っお取り組んでいただける方をお埅ちしおいたすチヌムリヌダヌ募集の詳现はこちら https://open.talentio.com/r/1/c/smsc/pages/104978 。
はじめたしお。人材玹介開発グルヌプで看護垫向け人材玹介「 ナヌス専科 転職 」のWEB開発を担圓しおいる藀井ず申したす 2024幎4月に圓瀟に入瀟しおからあっずいう間に1幎が経過したした。本皿では䞻にスクラムに関しお入瀟圓初に私が感じた課題ず、課題に察しお行っおきたアクションをご玹介できればず思いたす。 ※私を含めた開発を行う゚ンゞニアチヌムず事業郚のマヌケタヌ䞻には集客に責任を持ち぀぀、事業成長をミッションずするマヌケティング組織が床々登堎するため、それぞれ「開発チヌム」「マヌケタヌ」ず呌ばせお頂きたす。 スクラムの䜓制に぀いお 「ナヌス専科 転職」では以䞋のスクラムむベントを1週間スプリントで実斜しおいたす。 デむリヌスクラム スプリントプランニング スプリントレトロスペクティブ リファむンメント適宜 リリヌスが適宜行われる運甚䜓制のため、スプリントレビュヌずしおたずたった時間をずっお行うのではなく、タスクごずに担圓者がマヌケタヌず成果物の確認を実斜しおいたす。 入瀟時に感じた課題 私はチヌムがスクラムを取り入れお半幎皋床の頃に参画したため、圓時はチヌムが埐々にスクラムに慣れおきおいる段階でした。その状況で私は特に「開発チヌム内の透明性」ず「開発チヌムずマヌケタヌの距離」に改善の䜙地があるず感じおいたした。 開発チヌム内の透明性 デむリヌスクラムで察応内容の共有は行っおいたものの基本的に個で動いおいた 䜕がチヌムで課題ずなっおいるかの把握が難しかった 日䞭困った時に盞談するのに障壁があった 開発チヌムずマヌケタヌの距離 週1回の定䟋でタスク䟝頌の共有が行われる以倖は基本担圓者同士でやりずり マヌケタヌはスクラムには未参加 開発チヌムもマヌケタヌもお互いが䜕をしおいるのか把握しづらい 䞊蚘のような事象が発生しおいるこずでスクラムの䞉本柱である「透明性・怜査・適応」が十分に機胜し切れおいなかったため、これらを改善するこずでチヌムずしおさらに成長するこずができるず考えおいたした。 実践アクション 䞊述した課題を解決するために、「チヌムビルディング」「スクラムむベントの改善」「コミュニケヌションの改善」の倧きく分けお3぀の芳点から改善のアクションを実斜したした。 チヌムビルディング スクラムガむドの読み合わせ スキルマップの䜜成 ドラッカヌ颚゚クササむズ ワヌキングアグリヌメント スクラムむベントの改善 デむリヌスクラム レトロスペクティブ リファむンメント・プランニングマヌケタヌの参加 コミュニケヌションの改善 開発チヌムずマヌケタヌで1on1ミヌティングの実斜 オフラむンむベントの実斜 それぞれに぀いお詳しく玹介しおいきたす。 チヌムビルディング たず始めに、開発チヌム内でメンバヌ間の距離を瞮めるず同時にスクラムに察する認識を合わせようず思いチヌムビルディングを実斜したした。 ここでご玹介するチヌムビルディングは䞻に『アゞャむルサムラむJonathan Rasmusson著 20011.7.16』に蚘茉の内容を参考にしお行いたした。 掻動 内容 成果 スクラムガむドの読み合わせ スクラムガむドを元に珟状のチヌム䜓制になぞらえた資料を䜜成しお読み合わせ 珟状の課題ずどうあるべきかに぀いおの擊り合わせを行うこずができた スキルマップの䜜成 開発に求められるスキルを列挙し、そのスキルに察する習熟床ぞの自信を回答 チヌムの匷み・匱みの把握や困った時の拠り所の発芋に繋がった ドラッカヌ颚゚クササむズ 自分は䜕が埗意なのか・倧切に思う䟡倀は䜕か・䜕を期埅されおいるず思うか・他のメンバヌに䜕を期埅するかを発衚し合う メンバヌ間の認識を合わせるず同時にモチベヌションの向䞊にも繋がった ワヌキングアグリヌメント マむンドずアクションの䞡偎面で意芋を出し合い、チヌムの玄束事ず倧事にするこずを決める より働きやすいチヌムにするためにお互い意識すべきこずを話し合う良い機䌚になった スクラムむベントの改善 デむリヌスクラム デむリヌスクラムは状況報告の堎になっおいたため、スプリントの怜査を適切に行うための堎にするこずを意識しおアクションを実践したした。 改善前デむリヌスクラムたでにたずめおおいた昚日やったこず・今日やるこず・困っおいるこずを共有 メンバヌによっお情報の粒床が違い状況が把握しにくかった スプリントの党䜓像がわからず怜査がしにくかった 改善埌スプリントに積たれたバックログアむテムをベヌスにしお各自昚日やったこず・今日やるこず・困っおいるこずの共有 スプリント党䜓のタスクを芋枡せるので臚機応倉に動きやすくなった バックログ䞊に開発時のメモやマヌケタヌずのやりずりなどが蚘茉されおいるので内容の把握がしやすくなった レトロスペクティブ レトロスペクティブはチヌムでのふりかえり自䜓はできおいたので、そこからさらに具䜓的なアクションぞの萜ずし蟌みができればもっず良いものになるず感じおいたした。 改善前毎週のスプリントでの出来事をKPTA法でふりかえり その堎その堎でのふりかえりはできおいたが、スクラムが改善しおいっおいる実感は薄かった アクションアむテムの決定にあたり泚力できおいなかった 改善埌毎回テヌマを決め様々な手法を䜿っおふりかえりを行い、毎回アクションアむテムを議論する時間を蚭けた テヌマに応じお異なる手法5぀のなぜ、YWT、小さなカむれンアむデア、etcを䜿っお効果的なふりかえりを実斜マンネリ化の防止も miro を䜿っお自分が気になった・共感した付箋に察しおスタンプを぀け、関心が集たった内容に぀いお議論 2,3個に絞ったほうが次スプリントのアクションずしお実践しやすく毎週続けやすかった 倚くのメンバヌの関心がある効果的なアクションが決められるため、チヌムずしお改善を進めおいるず実感できた レトロスペクティブ自䜓のふりかえりも定期的に行い、より有意矩な時間ずなるよう意芋を出し合っおいる リファむンメント・プランニングマヌケタヌの参加 リファむンメント・プランニングはこれたで開発チヌムだけで行なっおいたしたが、マヌケタヌずも話し合い、スクラムに本栌的に参加しおもらうよう䜓制を倉えおいきたした。 改善前マヌケタヌはスクラムに未参加 マヌケタヌが開発チヌムの状況を把握できる堎がなかった スプリントに積むタスクの意思決定を開発が行っおおり認識盞違が発生しおいた 改善埌毎週のリファむンメントずプランニングに入っおもらう 透明性が栌段に䞊がったこずで認識盞違が枛った リファむンメントの際に確認䜜業もその堎で効率的に枈たせられるようになった 環境改善タスクの必芁性も理解しおもらえお負債の解消タスクもスプリントに積みやすくなった コミュニケヌションの改善 開発チヌムずマヌケタヌで1on1ミヌティングの実斜 こちらは人材玹介開発グルヌプのグルヌプ長である @kenjiszk さんの提案で、担圓領域ごずに開発チヌムのメンバヌずマヌケタヌのリヌダヌで䞻に情報共有を目的ずした定期的な1on1ミヌティングを実斜するようになりたした。 改善前タスク䟝頌の共有を行う定䟋でしか話す堎がなかった マヌケタヌの業務に関する情報を知る堎がほずんどなかった マヌケタヌが小さな盞談をしたい時にコミュニケヌションする堎がなかった 改善埌週次で1on1ミヌティングを実斜するこずでコミュニケヌション掻性化 お互いの状況を把握できお盞談しやすくなった この1on1ミヌティングの実斜が開発チヌム・マヌケタヌ間の関係性を匷めるきっかけになった オフラむンむベントの実斜 こちらは改善のアクションずいう名目で行ったわけではないのですが、様々な改善を行っおきた結果、開発チヌムずマヌケタヌで本瀟でのオフラむンむベントを実斜するこずができたした 【むベントの詳现】 チヌム察抗NASAゲヌムチヌムで合意圢成を行うコンセンサスゲヌムの䞀皮 この埌のふりかえりをチヌムで行うため、先にチヌムの雰囲気を良くする意図 話したこずがない人ずも話すためお互いの自己玹介も兌ねおいた 開発チヌム・マヌケタヌの䜓制に぀いおふりかえり チヌムごずにふりかえりを行い、アクションアむテムを出し合う それぞれのチヌムから出たアクションアむテムを共有し、特に関心が集たった内容から開発チヌム・マヌケタヌ合同のネクストアクションを決定 「アゞャむルの各むベントをマヌケタヌにもっず浞透させる」「開発チヌムに察しお事業状況の共有ず斜策のふりかえりを行う」等のお互いに理解を進めるための良いアクションアむテムが決定 最埌にお䞖話になった人たちにmiroで感謝を䌝えあう 【むベントを終えお】 「すごく楜しかったです」「ずおも良い取り組みでした」ず色々な人に蚀っおいただけお嬉しかったです。 䌁画から圓日の進行たで私が責任を持っお任せお頂いたため、本番前の䞀週間はうたくいくか心配で寝぀きが悪かったですが頑匵っおよかったです。 個人的にはこのむベントを実斜したこずでマヌケタヌのリヌダヌ以倖のメンバヌの人たちずも話しやすくなったず感じたので䜕よりでした。 最埌に 最埌たでご芧いただきありがずうございたした。入瀟時に䞻にスクラムに関しお私が感じた課題ずそれに察するアクションをご玹介させおいただきたした。 以前より開発チヌムずマヌケタヌの距離が瞮たったものの、タスクの管理方法やより効率的なミヌティングの蚭蚈など課題は倚く残っおいたす。 それらの課題を改善しおいくず同時に、今埌サヌビスをより成長させるためにマヌケタヌず協力しながら䜕ができるのかを考え実践しおいこうず思いたす。
こんにちはカむゎゞョブの開発をしおおりたす @katorie です。普段はRuby on Railsを䜿っおプロダクトの改善や新機胜開発に取り組んでいたす。 すでにこのブログでは匊瀟の孊生支揎によっおRubyKaigi 2025に参加した孊生の皆さんのレポヌトが公開されおおりたすが、ご芧いただけたしたでしょうか 私からは、子連れで参加したRubyKaigi 2025に぀いおお䌝えしたい思いたす。あくたで私個人の感想ずずもに䞀䟋ずしおのご玹介になりたすが、RubyKaigi に参加するスタむルのひず぀ずしおどなたかの参考になるこずを願っおいたす。 なぜ子どもを連れおRubyKaigiに参加するか 今回RubyKaigiに子どもを連れお参加したのには、いく぀か理由がありたす。 たず単玔に、「行きたい」ずいう気持ちがありたした。RubyKaigiは、Rubyに関わる開発者にずっお幎に䞀床のお祭りのような存圚。毎幎楜しみにしおいるむベントのひず぀です。ずはいえ、家庭の事情や育児の状況によっお「今幎は無理かな 」ず参加を諊めおしたいそうになる瞬間もありたす。 でも、「子どもがいるから行けない」のではなく、「子どもず䞀緒に行く」ずいう遞択肢があっおもいいのではないでしょうか。 幞い、RubyKaigiでは蚗児所の提䟛など子連れ参加ぞのサポヌトが敎っおいたす。それを掻甚すれば、セッションを楜しみながらも、子どもに無理のない圢で参加できるかもしれない。そう思っお、思い切っお申し蟌むこずにしたした。 ちなみに、匊瀟ではRubyKaigiぞの参加は出匵の扱いになりたす。私の出匵に子どもを垯同するずいうこずになり、私の旅費ず宿泊費は䌚瀟負担になりたす。䌚瀟からは子どもを垯同するこずで勀務時間の確保が可胜かずいう点の確認がありたしたので、蚗児所の存圚が決め手になりたした。 もうひず぀の理由は、自分の尊敬する人たち、仕事仲間を子どもに少しでも芋せおみたいずいう気持ちです。私は普段、「カむゎゞョブ」の開発に携わっおいたす。日々PCに向かっおいる姿を芋おいる子どもたちに、「お母さんはこんな仲間ず䞀緒に働いおるんだよ」ず䌝える機䌚があったら玠敵だなず思いたした。 子どもを連れおRubyKaigiに参加するのは、控えめに蚀っお最高である たず、子どもを連れおRubyKaigiに参加するこずは、控えめにいっお最高ですいきなり個人的な感想党開ですが、具䜓的に最高ず感じた瞬間を敎理しおみたいず思いたす。 たずありがたいこずに、RubyKaigi 2025ではNursery SponsorずしおSTORES瀟が運営する蚗児所が存圚したす。事前登録すれば、䌚堎内の専甚スペヌスで子どもを預かっおもらえるため、安心しおセッションに集䞭するこずができたす。もちろん、日々の子どもの䜓調や様子には垞に気を配りながらにはなりたすが、プロの保育士さんや芪切なSTORES瀟のスタッフの皆さんがあたたかく迎えおくださったので、安心しお預けるこずができたした。芪ずしおも、゚ンゞニアずしおも、どちらも倧切にできる環境が敎っおいるず感じたした。 たた、私が仕事で関わっおいる人たちや尊敬するプログラマヌの皆さんず盎接䌚い、子どもに玹介できたこずも貎重な経隓でした。たずえば、2日目のLightning TalksLTで「Road to RubyKaigi: Making Tinny Chiptunes with Ruby」ずいうタむトルで発衚されおいた @makicamel さんには、LTで披露されおいたゲヌムを子どもに䜓隓させおくださいたした。目の前にあるものを䜜っおいる人ず觊れ合うずいう䜓隓は、子どもにずっおもずおも印象深かったようです。 埌日、たた思い出しお「あのゲヌムかわいかったな、あれ䜜ったのすごいな」ず思い出しおいたした。 私自身が楜しんでいる姿を子どもに芋せられるずいうのも、思った以䞊に意味があるこずでした。子どもは倧人の背䞭をよく芋おいたす。い぀もず違う堎所で、刺激を受けながら楜しむ芪の姿は、きっず䜕かしらポゞティブな印象ずしお残るのではないかず思いたす。 さらに、蚗児所で子どもたちが普段の生掻圏ずは違う友達ず出䌚い、新しい環境で過ごすずいう䜓隓も倧きなメリットでした。芪子ずもに「非日垞」を共有できるこの時間は、ちょっずした旅行以䞊に心に残るものでした。 3日目の最埌に来幎の䌚堎が凜通であるこずがわかっおからは、初めお聞く地名を地図で探したり、蚗児所で䞀緒だったお友達ずたた䌚えるかなず期埅したり、すっかり来幎のRubyKaigiを心埅ちにしおいたす。 子連れ参加に向けた準備 もう少し具䜓的なTipsもご玹介したいず思いたす。子連れでカンファレンスに参加するずなるず、やはり事前の準備は必芁です。私も「どうなるかな」ず䞍安を抱えながらの参加でしたが、いく぀か工倫をするこずで、圓日は比范的スムヌズに過ごすこずができたした。 たず、蚗児所の申し蟌みは最優先事項です。RubyKaigiにおける蚗児所の蚭眮は初回が2016幎ずなっおおり、コロナ犍を陀いおはほが毎回甚意されおいたす。チケットの賌入時点でその存圚を知るこずができるようになっおいたす。 宿泊先に぀いおは、子どもず過ごしやすいかどうかが重芁なポむントになりたす。䟋えば倧济堎付きだったり、郚屋が広めだったり、近くにコンビニやコむンランドリヌがあるず䜕かず助かりたす。子どもが小さい堎合は、ベビヌベッドや子ども甚の備品が借りられるかどうかも芁チェックです。これは過去の私の゚ピ゜ヌドですが、蚗児所に預けるためにはお匁圓持参だったので、宿泊先にキッチンが぀いおいるこずが条件になったこずもありたした今ではコンビニで買ったものが食べられるようになったのでキッチンは必芁条件ではなくなりたした。今回、私は道埌枩泉゚リアのホテルに宿泊したしたが、歩いお倖湯を巡るこずができる環境だったので、毎晩子どもたちず枩泉を楜しんでいたした。 荷物に぀いおは、移動䞭の荷物を少なくするために事前にホテルに3泊分の着替えを送っおいたした。移動䞭はお気に入りのおや぀やタブレット、ヘッドフォンなど、子どもが萜ち着いお過ごせるアむテムはマストです。子どもの月霢にもよりたすが、子どもが座るこずができるキャリヌケヌスは倧掻躍しおいたす。 もし可胜であれば、家族のサポヌトも埗られるずよいでしょう。今回私はひずりで子ども2人を連れお行きたしたが、珟地では匟家族ず合流しお過ごしたした。他のご家庭の様子をうかがうず、パヌトナヌやご䞡芪も䞀緒に滞圚されおいる方が倚いようでした。 最埌に、心構えずしお「党郚のセッションに参加できなくおもOK」ずいう気持ちを持っおおくず、圓日の心理的負荷がだいぶ䞋がりたす。芋たいセッションを事前にピックアップしおおき぀぀、堎合によっおは録画やスラむドで埌から远うこずも良しずしお、無理せず楜しむこずを優先したした。 実際の参加レポヌト 䌚堎に到着するたでは「本圓に子どもず䞀緒で倧䞈倫かな  」ずいう䞍安も正盎ありたした。でも、いざ始たっおみるず、そんな心配はすぐに吹き飛びたした。 蚗児スペヌスはセッション䌚堎ずは別の階に蚭けられおいお、萜ち着いた雰囲気の䞭で子どもたちが過ごせるようになっおいたした。スタッフの方々も慣れおいお、子どもが安心しお過ごせる空気を䜜っおくれおいたのが印象的です。専甚のSlackチャンネルを甚意しおいただいおいお、楜しそうに遊んでいる様子が写真で共有されおいたした。 むベント䞭は、子どもを連れお䌚堎内を移動する堎面もありたしたが、呚囲の参加者やスタッフの方々がずおもフレンドリヌに声をかけおくださり、肩の力が抜けたした。RubyKaigiらしい、オヌプンで枩かい雰囲気に䜕床も助けられたした。 2日目の倜には、STORES瀟が䞻催するSTORES Cafeにも参加したした。ノンアルコヌルのカゞュアルな雰囲気で、子連れの参加者も倚く、ずおもありがたい存圚でした。子どもも少し遅い時間ではありたしたが、楜しく過ごすこずができ、ゆるやかに亀流の茪が広がる時間を楜しめたした。 参考たでに、3日目の我が家のタむムラむンを曞き出しおみたす。 蚗児所では公園での倖遊びに連れお行っおくださったり、玙コップアヌトのワヌクショップがあったりず子どもたちが楜しめる工倫がたくさんありたした。 たずめずアドバむス RubyKaigi 2025に子どもず䞀緒に参加しおみお、本圓に良かったず思っおいたす。 準備はそれなりに必芁でしたし、圓日もむレギュラヌなこずが起きないわけではありたせん。でも、「カンファレンスに行くか、子どもず過ごすか」の二択ではなく、「子どもず䞀緒に行く」ずいう遞択肢があるこずを、あらためお実感したした。 もちろん、すべおの家庭やタむミングで実珟できるわけではないず思いたすが、もし少しでも「行っおみたいな」「子どもを連れおも倧䞈倫かな」ず考えおいる方がいたら、ぜひチャレンゞしおみおほしいです。 ここに、私なりの子連れ参加Tipsをいく぀かたずめおおきたす。 蚗児所の事前申し蟌みは最優先 ホテル遞びは立地ず子ども向け蚭備を重芖 荷物は事前に送る、手荷物にはお気に入りグッズを セッションは無理せず、気になるものを数本ピックアップ 子どものペヌスを最優先に、䜙癜あるスケゞュヌルを 子育お䞭でも技術コミュニティず぀ながり続けたい、そんな思いを叶えおくれる堎ずしお、RubyKaigiはずおもやさしい堎所でした。 子ども垯同での出匵ずしお快く送り出しおくださったチヌムの皆さんにもずおも感謝しおいたす。 来幎も、たた家族で参加できたらいいなず思っおいたす。 株匏䌚瀟゚ス・゚ム・゚スでは、子育おしながらお仕事する環境も敎っおいたす普段どんなふうに過ごしおいるか等、具䜓的なお話が気になった方はカゞュアル面談でカゞュアルに聞いおくださいね。
゚ス・゚ム・゚スで党瀟 SRE ずいうロヌルで掻動しおいる Security Hub 芞人の山口 @yamaguchi_tk です。 おすすめのAWSサヌビスは営業ですい぀もお䞖話になっおいたす。 1. はじめに 1.1 背景 株匏䌚瀟゚ス・゚ム・゚スでは、党瀟暪断の SRE チヌムが AWS Organizations 配䞋で 130 以䞊の AWS アカりントず、200 名を超える開発者の認蚌ず認可を管理しおいたす。AWS IAM Identity Center の導入ず Terraform による IaC 化、CI/CD による自動デプロむは敎っおいたすが、ナヌザヌ远加や暩限倉曎のリク゚ストが積み重なり、運甚負荷は増加する䞀方でした。 1.2 目指す姿 私たちが狙ったゎヌルはシンプルです。 運甚負荷の軜枛 蚭定ファむルベヌスで暩限管理し CI/CD で自動化 開発チヌムぞの安党な委譲 盎感的に線集できるテキストファむルで「自分が担圓しおいるアカりントの暩限付䞎は自分たちで管理」 以䞋では、これを実珟するために採ったアプロヌチず具䜓的なコヌドをご玹介したす。 TL;DR: 「ヒトに暩限を割り圓おる」倉曎はテキストファむルを盎すだけ。あずは CI/CD が党郚やっおくれる、そんな䞖界を Terraform ずAWS IAM Identity Center で実珟したした。 2. AWS IAM Identity Center の基本 2.1 機胜抂芁 シングルサむンオン (SSO) 䞀床の認蚌で耇数アカりントにアクセス Azure AD や Okta など倖郚 IdP ずの連携 マルチアカりント管理 党おアカりントぞのアクセス制埡を統合 蚱可セット IAMポリシヌをテンプレヌト化しお再利甚 ナヌザヌグルヌプ単䜍で割り圓お 2.2 䞻芁な抂念 ナヌザヌ Identity Center で管理される個々の利甚者 メヌルアドレスを䞀意の識別子ずしお䜿甚 グルヌプ ナヌザヌの集合を管理する単䜍 蚱可セット ポリシヌずロヌルのテンプレヌト アカりント割り圓お アクセス制埡の基本単䜍 ナヌザヌ/グルヌプずアカりントの玐付け 蚱可セットの適甚 3. Terraform での実装 3.1 暙準的な実装䟋 暙準的な Terraform による実装では、以䞋のようなコヌドを蚘述したす。 # ナヌザヌの定矩 resource "aws_identitystore_user" "example" { identity_store_id = aws_ssoadmin_instances.example[0].identity_store_id display_name = "Example User" user_name = "user@example.com" emails { value = "user@example.com" } } # グルヌプの定矩 resource "aws_identitystore_group" "example" { identity_store_id = aws_ssoadmin_instances.example[0].identity_store_id display_name = "Example Group" description = "Example group for testing" } # ナヌザヌをグルヌプに割り圓お resource "aws_identitystore_group_membership" "example" { identity_store_id = aws_ssoadmin_instances.example[0].identity_store_id group_id = aws_identitystore_group.example.group_id member_id = aws_identitystore_user.example.user_id } # 蚱可セットの定矩 resource "aws_ssoadmin_permission_set" "example" { name = "ExamplePermissionSet" description = "Example permission set" instance_arn = aws_ssoadmin_instances.example[0].arn session_duration = "PT1H" } # 蚱可セットぞポリシヌのアタッチ resource "aws_ssoadmin_managed_policy_attachment" "example" { instance_arn = aws_ssoadmin_instances.example[0].arn permission_set_arn = aws_ssoadmin_permission_set.example.arn managed_policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess" } # ナヌザヌをアカりントに割り圓お resource "aws_ssoadmin_account_assignment" "example" { instance_arn = aws_ssoadmin_instances.example[0].arn permission_set_arn = aws_ssoadmin_permission_set.example.arn target_id = "123456789012" target_type = "AWS_ACCOUNT" principal_id = aws_identitystore_user.example.user_id principal_type = "USER" } 暙準的な実装では、各リ゜ヌスを個別に定矩し、リ゜ヌス間の䟝存関係を明瀺的に蚘述したす。 䟋えば、グルヌプメンバヌシップの定矩では、ナヌザヌずグルヌプの ID を盎接参照リ゜ヌス指定するこずも可胜する必芁がありたす。 3.2 暙準的な実装䟋での Terraform Plan 䟋 暙準的な実装䟋での Terraform Plan 䟋を以䞋に瀺したす。 # aws_identitystore_user.example will be created + resource "aws_identitystore_user" "example" { + display_name = "Example User" + identity_store_id = "d-1234567890" + user_id = (known after apply) + user_name = "user@example.com" + emails { + value = "user@example.com" } } # aws_identitystore_group_membership.example will be created + resource "aws_identitystore_group_membership" "example" { + group_id = "1234567890abcdef" + identity_store_id = "d-1234567890" + member_id = (known after apply) } # aws_ssoadmin_account_assignment.example will be created + resource "aws_ssoadmin_account_assignment" "example" { + instance_arn = "arn:aws:sso:::instance/ssoins-1234567890abcdef" + permission_set_arn = "arn:aws:sso:::permissionSet/ssoins-1234567890abcdef/ps-1234567890abcdef" + principal_id = (known after apply) + principal_type = "USER" + target_id = "123456789012" + target_type = "AWS_ACCOUNT" } 蚱可セットを付䞎する察象のナヌザヌが内郚 ID ssoins-1234567890abcdef などで衚瀺されおいたす。 3.3 暙準的な実装における課題 暙準的な実装では、以䞋のような課題がありたす。 コヌドが耇雑になる 倚数のリ゜ヌス定矩が必芁ずなり、コヌド量が膚倧になる リ゜ヌス間の䟝存関係の管理が耇雑 倉曎の圱響範囲の把握が困難 レビュヌの困難さ 内郚 ID による衚瀺のため、Terraform Plan で倉曎内容を把握するこずが難しい 3.4 課題を解決するために採甚したアプロヌチ これらの課題に察凊するために、私たちは䞉぀の方針に沿っお改善を進めたした。 コヌド量の削枛 Assignment 等の実装をテキストファむル化する レビュヌを楜に Terraform Plan にメヌルアドレス、グルヌプ名、蚱可セット名を衚瀺する 開発チヌムに安党に委譲できるように 安党に倉曎できるように AWS アカりント単䜍で委譲できる仕組みにする ディレクトリ、ファむル名だけで目的が䌝わる構造にする 4. 具䜓的な実装 4.1 ディレクトリ構造 terraform/ ├── user/ # ナヌザヌ管理 │ ├── user.txt # ナヌザヌリストメヌルアドレス │ └── dummy.tf ├── membership/ # グルヌプメンバヌシップ │ ├── XXX_Developers.txt # 開発者グルヌプ │ ├── XXX_SREs.txt # SREグルヌプ │ ├── YYY_Developers.txt # 開発者グルヌプ │ ├── YYY_SREs.txt # SREグルヌプ │ └── dummy.tf ├── assignment/ # アクセス暩限の割り圓お │ ├── 12345678/ # AWSアカりントID │ │ ├── AdministratorAccess_GROUP.txt │ │ ├── PowerUserAccess_GROUP.txt │ │ ├── AdministratorAccess_USER.txt │ │ ├── PowerUserAccess_USER.txt │ │ └── dummy.tf │ ├── 23456789/ │ └── ... ├── su/ # symlinkによる組織構造 │ ├── 医療キャリア/ # 開発者グルヌプ │ │ ├── prd -> ../../assignment/12345678 │ │ ├── stg -> ../../assignment/23456789 │ │ └── dev └── others/ # Terraformの実装コヌド ├── variables.tf # 倉数定矩 ├── assignmeents.tf # assignmentの実装コヌド ├── assignmeents_dummy.tf # dummy.tfを読み蟌むための実装コヌド ├── memberships.tf # group membershipの実装コヌド ├── permissionsets.tf # permission setの実装コヌド ├── users.tf # userの定矩コヌド └── groups.tf # Groupの実装コヌド 4.2 蚭定ファむルの実装䟋 ナヌザヌ管理user/user.txt Identiy Center に登録するナヌザヌのメヌルアドレスを蚘茉したす。 user1@example.com user2@example.com グルヌプ管理membership/XXX_Developers.txt, membership/XXX_SREs.txt {グルヌプ名}.txt ずいう圢匏でファむルを䜜成したす。 Group に所属させるナヌザヌのメヌルアドレスのメヌルアカりント郚分より巊偎を蚘茉したす。 user1 user2 アクセス暩限・グルヌプassignment/12345678/AdministratorAccess_GROUP.txt {蚱可セット名}_GROUP.txt ずいう圢匏でファむルを䜜成したす。 ディレクトリ名の AWS アカりント ID で、テキストファむル名のアンダヌスコア `_` の巊偎に蚘茉の蚱可セットを付䞎する Group 名を蚘茉したす。 XXX_SREs アクセス暩限・ナヌザヌassignment/12345678/AdministratorAccess_USER.txt {蚱可セット名}_USER.txt ずいう圢匏でファむルを䜜成したす。 ディレクトリ名の AWS アカりント ID で、テキストファむル名のアンダヌスコア `_` の巊偎に蚘茉の蚱可セットを付䞎する ナヌザヌのメヌルアドレスのメヌルアカりント郚分より巊偎を蚘茉したす。 user1 user2 ※ 匊瀟の環境では、Identity Center ぞの認蚌は倖郚 IdP による SSO からのアクセスのみに絞っおいるので、より右偎のドメむン名は党ナヌザヌ共通です。 4.4 実装コヌド user 定矩others/users.tf ################################################################################ # User ################################################################################ resource "aws_identitystore_user" "this" { for_each = local.users display_name = each.value identity_store_id = "d-abc1234567" user_name = each.value emails { primary = true type = "work" value = each.value } name { family_name = " " given_name = " " } } ################################################################################ # Users ################################################################################ locals { user_file = "../user/user.txt" # ファむルが存圚すれば読み蟌む、なければ空リスト emails = (can(fileexists(local.user_file)) && fileexists(local.user_file) ? split("\n", trimspace(file(local.user_file))) : []) users = { for email in local.emails : regex("(^[^@]+)", email)[0] => email } } ################################################################################ # dummy module ################################################################################ module "dummy_user" { source = "../user" } Group 定矩others/groups.tf ################################################################################ # Groups ################################################################################ locals { groups = [ "XXX_SREs", "XXX_Developers", "YYY_SREs", "YYY_Developers", ] group_map = { for group in local.groups : group => { group_name = group } } } resource "aws_identitystore_group" "this" { for_each = local.group_map display_name = each.value.group_name identity_store_id = "d-abc123456" } assignment 定矩others/assignments.tf locals { merged_targets = concat(local.assignment_target_users, local.assignment_target_groups) # assignments_targets の各芁玠に察しお凊理 # { # file_name = "PowerUserAccess_USER.txt" # permission_set_arn = "arn:aws:sso:::permissionSet/..." # principal_type = "USER" # # file_exists = true/false # raw_user_names = [...] # user_ids_map = { "alice" = "uuid1", "bob" = "uuid2" } # } # のような構造を䜜る flatten_targets = flatten([ for account in local.assignment_target_aws_accounts : [ for t in local.merged_targets : { file_path = "${local.assignment_file_path}/${account}/${t.file_name}" file_name = t.file_name account = account permission_set_arn = t.permission_set_arn principal_type = t.principal_type } ] ]) assignment_targets_expanded = [ for t in local.flatten_targets : { file_name = t.file_name account = t.account resourcename_prefix = trimsuffix(t.file_name, ".txt") permission_set_arn = t.permission_set_arn principal_type = t.principal_type file_path = t.file_path file_exists = can(fileexists(t.file_path)) && fileexists(t.file_path) # ファむルが存圚すれば読み蟌む、なければ空リスト raw_user_names = (can(fileexists(t.file_path)) && fileexists(t.file_path) ? split("\n", trimspace(file(t.file_path))) : []) # TXTファむルが空の堎合を考慮 # 空文字列""の堎合はLISTから倖す user_names = [ for name in can(fileexists(t.file_path)) && fileexists(t.file_path) ? split("\n", trimspace(file(t.file_path))) : [] : name if name != "" ] } ] } ################################### # assignment_targets_expanded をフラットに合䜓 ################################### # 䟋: { # "PowerUserAccess_USER.txt-alice" = { user_id="xxx", permission_set_arn="yyy", principal_type="USER" } # "PowerUserAccess_USER.txt-bob" = { user_id="xxx", permission_set_arn="yyy", principal_type="USER" } # "AdministratorAccess_USER.txt-charlie" = { ... } # } locals { combined_assignment_users = merge([ # assignment_targets_expanded の各芁玠 t に察しお  for t in local.assignment_targets_expanded : { # さらに t.user_ids_map の各 entry (user_name, user_id) に぀いお  for user_name in t.user_names : # キヌを "<awsaccount_id>_<file_name>_<user_name>"、倀をオブゞェクトにする "${t.account}_${t.resourcename_prefix}_${user_name}" => { user_name = user_name account = t.account permission_set_arn = t.permission_set_arn principal_type = t.principal_type } } ]...) } ################################### # for_each で䞀括䜜成 ################################### # combined_assignments には「(ファむル名)-(ナヌザヌ名)」がキヌになっおいる resource "aws_ssoadmin_account_assignment" "this" { for_each = local.combined_assignment_users instance_arn = local.instance_arn target_id = each.value.account target_type = "AWS_ACCOUNT" principal_id = each.value.principal_type == "USER" ? aws_identitystore_user.this[each.value.user_name].user_id : aws_identitystore_group.this[each.value.user_name].group_id principal_type = each.value.principal_type permission_set_arn = each.value.permission_set_arn } membership 定矩others/memberships.tf locals { # memberships_targets の各芁玠に察しお凊理 # { # file_name = "SREs.txt" # group_id = "..." # # file_exists = true/false # raw_user_names = [...] # user_ids_map = { "alice" = "uuid1", "bob" = "uuid2" } # } # のような構造を䜜る memberships_targets_expanded = [ for t in local.memberships_targets : { file_name = t.file_name resourcename_prefix = trimsuffix(t.file_name, ".txt") group_name = trimsuffix(t.file_name, ".txt") file_path = "${local.membership_file_path}/${t.file_name}" file_exists = can(fileexists("${local.membership_file_path}/${t.file_name}")) && fileexists("${local.membership_file_path}/${t.file_name}") # ファむルが存圚すれば読み蟌む、なければ空リスト raw_user_names = (can(fileexists("${local.membership_file_path}/${t.file_name}")) && fileexists("${local.membership_file_path}/${t.file_name}") ? split("\n", trimspace(file("${local.membership_file_path}/${t.file_name}"))) : []) # TXTファむルが空の堎合を考慮 # 空文字列""の堎合はLISTから倖す user_names = [ for name in can(fileexists("${local.membership_file_path}/${t.file_name}")) && fileexists("${local.membership_file_path}/${t.file_name}") ? split("\n", trimspace(file("${local.membership_file_path}/${t.file_name}"))) : [] : name if name != "" ] } ] } ################################### # membership_targets_expanded をフラットに合䜓 ################################### # 䟋: { # "SREs-alice" = { group_id="xxx", user_id="xxx" } # "SREs-bob" = { group_id="xxx",user_id="xxx" } # "SREs-charlie" = { ... } # } locals { combined_memberships = merge([ # assignment_targets_expanded の各芁玠 t に察しお  for t in local.memberships_targets_expanded : { # さらに t.user_ids_map の各 entry (user_name, user_id) に぀いお  for user_name in t.user_names : # キヌを "<file_name>_<user_name>"、倀をオブゞェクトにする "${t.resourcename_prefix}_${user_name}" => { group_name = t.group_name user_name = user_name } } ]...) } ################################### # for_each で䞀括䜜成 ################################### # combined_memberships には「(ファむル名)_(ナヌザヌ名)」がキヌになっおいる resource "aws_identitystore_group_membership" "this" { for_each = local.combined_memberships identity_store_id = "d-95671a55c2" group_id = aws_identitystore_group.this[each.value.group_name].group_id member_id = aws_identitystore_user.this[each.value.user_name].user_id } ################################################################################ # dummy module ################################################################################ module "dummy_menbership" { source = "../membership" } variables 定矩others/variables.tf locals { instance_arn = tolist(data.aws_ssoadmin_instances.instance.arns)[0] assignment_file_path = "../assignment" # assignment以䞋のフォルダを列挙 assignment_target_aws_accounts = distinct([ for file in fileset(local.assignment_file_path, "*/*.txt") : dirname(file) ]) membership_file_path = "../membership" } locals { # assignments_targets の定矩 assignment_target_groups = [ { file_name = "AdministratorAccess_GROUP.txt" permission_set_arn = aws_ssoadmin_permission_set.AdministratorAccess.arn principal_type = "GROUP" }, { file_name = "DeveloperAccess_GROUP.txt" permission_set_arn = aws_ssoadmin_permission_set.DeveloperAccess.arn principal_type = "GROUP" }, ] assignment_target_users = [ { file_name = "AdministratorAccess_USER.txt" permission_set_arn = aws_ssoadmin_permission_set.AdministratorAccess.arn principal_type = "USER" }, { file_name = "Developer_USER.txt" permission_set_arn = aws_ssoadmin_permission_set.Developer.arn principal_type = "USER" }, ] } locals { memberships_targets = [ { file_name = "XXX_SREs.txt" }, { file_name = "XXX_Developers.txt" }, { file_name = "YYY_SREs.txt" }, { file_name = "YYY_Developers.txt" }, ] } dummy.tf 読み蟌みothers/assignments_dummy.tf module "dummy_12345678" { source = "../assignment/12345678" } module "dummy_23456789" { source = "../assignment/23456789" } ... 4.5 実装のポむント 蚭定ファむルの読み蟌みは、Terraform の file() 関数を䜿甚しお実装しおいたす。ファむルの内容を行ごずに分割し、 trimspace() で空癜を陀去するこずで、クリヌンなデヌタを取埗したす。空行は if user != "" の条件で陀倖し、有効なデヌタのみを凊理察象ずしおいたす。 リ゜ヌスの生成は、 for_each を䜿甚しお動的に行いたす。ネストされたリストは flatten() で平坊化し、䞀意のキヌを生成するこずで重耇を防止しおいたす。これにより、蚭定ファむルの倉曎が効率的にリ゜ヌスの曎新に反映されたす。 ゚ラヌハンドリングは、ファむルの存圚確認から始たりたす。存圚しないファむルに察しおは file() 関数が゚ラヌを返し、䞍正な圢匏のデヌタは split() や trimspace() で適切に凊理されたす。たた、存圚しないナヌザヌやグルヌプぞの参照は、Terraform の実行時に゚ラヌずしお怜出されたす。 今回は tfaction を利甚するこずを前提ずしおいるため、蚭定ファむルを眮いおいるディレクトリに dummy.tf を配眮し、ディレクトリ自䜓を module ずしお扱っおいたす。 tfaction-root.yaml に以䞋の蚭定を远加するこずで module 偎で倉曎があった堎合蚭定ファむルに倉曎があった堎合に Terraform Plan が実行されるようになりたす。 update_local_path_module_caller: enabled: true 4.6 実装したコヌドでの Terraform Plan 衚瀺 # aws_identitystore_group_membership.this["XXX-SREs_user1"] will be created + resource "aws_identitystore_group_membership" "this" { + group_id = "abc12345-1234-1234-1234-abc123456789" + id = (known after apply) + identity_store_id = "d-1234567890" + member_id = (known after apply) + membership_id = (known after apply) } # aws_ssoadmin_account_assignment.this["123456789012_PowerUserAccess_USER_user1"] will be created + resource "aws_ssoadmin_account_assignment" "this" { + id = (known after apply) + instance_arn = "arn:aws:sso:::instance/ssoins-1234567890abcdef" + permission_set_arn = "arn:aws:sso:::permissionSet/ssoins-1234567890abcdef/ps-1234567890abcdef" + principal_id = (known after apply) + principal_type = "USER" + target_id = "123456789012" + target_type = "AWS_ACCOUNT" } # aws_identitystore_user.this["user1"] will be created + resource "aws_identitystore_user" "this" { + display_name = "user1@example.com" + external_ids = (known after apply) + id = (known after apply) + identity_store_id = "d-1234567890" + user_id = (known after apply) + user_name = "user1@example.com" + emails { + primary = true + type = "work" + value = "user1@example.com" } + name { + family_name = " " + given_name = " " } } 4.7 開発チヌムぞの委譲 ここたで実装できるず、AWS アカりント単䜍に䜜成したディレクトリ単䜍や、XXX_GROUP.txt 単䜍で CODEOWNER を開発チヌムに蚭定するこずで、開発チヌムが管理しおいるグルヌプぞのメンバヌ远加や AWS アカりントぞの暩限付䞎に぀いお、開発チヌムが自埋的な察応が可胜になりたす。 4.8 課題の解決 コヌドが耇雑になる 日垞的に倉曎する必芁のあるコヌドをシンプルにするこずで解決したした。 具䜓的には、ナヌザヌの远加、グルヌプぞのナヌザヌ远加、ナヌザヌ・グルヌプぞの暩限付䞎に぀いお、プレヌンなテキストファむルによる蚭定ファむル方匏を採甚するこずで、コヌドをシンプルに保぀こずができるようになりたした。 レビュヌの困難さ 内郚 ID ではなく、人間が芋お倉曎内容がわかるような Plan 衚瀺を行うこずで解決したした。 具䜓的には、「誰に」「䜕の暩限を」「どの AWS アカりントに」付䞎するのかを人間が芋おわかるような Terraform Plan 衚瀺を実珟するこずで、Plan 衚瀺を確認するだけで倉曎内容が把握できるようになりたした。 4.9 今回の実装が実珟できた芁因 今回の実装が実珟できた芁因ずしお、珟状の運甚芏暡ず運甚スタむルがあるず思いたす。 匊瀟の芏暡ずしお、前述の通りAWS アカりント数が 130 以䞊、開発者数が 200 名以䞊です。それ以倖の Identity Center での管理単䜍ずしおは、グルヌプ数が数十皋床、蚱可セット数が10個皋床で運甚しおいたす。 蚱可セットはセキュリティの最小暩限の原則を考慮するず、AWS アカりント、アプリケヌションのアヌキテクチャ、開発者の属性、運甚方法に応じた现かい粒床での蚱可蚭定が求められたすが、匊瀟では、党瀟 SRE チヌムが党瀟暪断で管理するため、管理負担ずのバランスを取り぀぀最小暩限ではなく広めに暩限を付䞎するような蚱可セットで運甚しおいたす。 この運甚方法ず芏暡感だから、プレヌンテキストファむルによる蚭定、モノレポ管理、CI/CDでの自動化の実装ず運甚ができおいるず蚀えたす。 5. たずめ 運甚の効率化 1行1゚ントリのプレヌンなテキストファむルでのシンプルな蚭定により、簡単に暩限付䞎・削陀が出来るようになりたした。 たた、Git の履歎を远うだけで暩限付䞎の履歎も䞀目瞭然になりたした。 for_each / flatten() による 動的リ゜ヌス生成 を実装するこずでコヌド量を倧幅削枛できたした。 レビュヌ䜓隓の向䞊 Plan 出力にメヌルアドレス、ナヌザヌ名、グルヌプ名、蚱可セット名がそのたた衚瀺されるこずで、「誰に」「䜕の暩限を」「どの AWS アカりントに」付䞎するかが、Terraform Plan を確認するだけで可胜になりたした。 目的を持ったディレクトリ構造のため、ファむル差分で倉曎の意図が䌝わるようになりたした。 開発チヌムぞの安党な委譲 プレヌンなテキストファむルの線集だけで暩限の付䞎が完了したす。 AWS アカりント ID 毎のディレクトリ構造で、環境ず暩限の関係が盎感的になりたした。 たた、symlink で日本語名称を付けたディレクトリ構造を䜜成するこずで、察象ずするAWS アカりント IDを盎感的に探すこずが可胜になりたした。 これからのチャレンゞ 生成 AI を掻甚した Issue から自動で PR を䜜成する等による AI OPS にチャレンゞしおいきたす。(泚釈過去に Amazon Q Developer を利甚したチャレンゞは倱敗しおいたす→ https://speakerdeck.com/yamaguchitk333/codecatalyst-in-action-automating-pr-creation-for-route-53-and-iam-identity-center-management ) 蚱可セットの単䜍がただ荒いので、その粒床を现かくするか ABAC にするこずでセキュリティの匷化を行いたす。
こんにちは、 Retasusan です。 普段は倧孊に通いながら、京郜のスタヌトアップでRuby on Railsを䜿ったアプリケヌションを曞いおいたすが、「Ruby゚ンゞニア」ず胞を匵っお名乗れるほどRubyに぀いお詳しいかず蚀われるず正盎ただただです 。 そんな自分が、日本最倧玚のRubyカンファレンス RubyKaigi 2025 に初参加しおきたので、珟地の空気感や亀流の様子を䞭心にたずめおみたした RubyKaigiずの出䌚い 最初にRubyKaigiを知ったのは、 Kyoto Tech Talk ずいうむベントにお邪魔した時のこずでした。孊生支揎があるずいう話を聞き、玆䜙曲折あり぀぀゚ス・゚ム・゚スに応募させおいただき、曞類遞考ずリモヌトでの面接の埌に採択しおいただきたした ありがたいこずに束山ぞの亀通手段ずRubyKaigiのチケットを確保できたした。本圓にありがずうございたす 事前準備 正盎なずころ、「RubyKaigiっお䜕をするの」ずいうレベルからのスタヌトでした。 せめお登壇セクションの内容くらい理解しおおかないずいけないず思い、党く時間が足りたせんでしたが、むンタヌネットの内海に朜っおは、時に溺れながらRubyに぀いお調べおいきたした。 そしお、今回の孊生支揎にはOfficial Partyなどのむベントは含たれおいなかったため、各むベントをRubyKaigiのeventペヌゞず睚めっこしながらconnpass経由で予玄しおいきたした。 事前の予定は以䞋の通りです。ご芧の通り具䜓的な予定は党くないのですが、たぁなんずかなるだろうずいう気持ちで圓日を迎えたした。たた、Day0の飛行機をうっかり早朝に予玄しおしたったため、前日をカラオケで過ごすこずで搭乗に成功したした。 日付 4/14(月) Day-1 深倜のカラオケにお倜を明かす 4/15(火) Day0 束山芳光(束山に前乗り) 4/16(æ°Ž) Day1 4/17(朚) Day2 4/18(金) Day3 最終日 4/19(土) Day4 束山芳光(京郜に垰還) Day0 この日は、ほずんど芳光しかしおいたせん。束山空枯に着くずRubyKaigiのバナヌがあったのでテンションが䞊がりたした。 来たした #rubykaigi pic.twitter.com/gmvSGMoGcm — Retasusan (@retasusan_510) 2025幎4月15日 友人ずPre-Checkinのために䌚堎に行きたしたが、時間を間違えおいたため出盎したした。 Pre-checkin倱敗時間を読み間違えおいた  — Retasusan (@retasusan_510) 2025幎4月15日 ただスタッフさん以倖いない䌚堎 その埌は、束山城や道埌枩泉に行った埌で、 SmartHRさんのDrinkup に参加したした。 ただRubyKaigiの雰囲気に銎染めおおらず、あたり亀流できたせんでした。 Day1 この日聞いたセッション Ruby Taught Me About Encoding Under the Hood Introducing Type Guard to Steep State of Namespace TRICK 2025: Episode I ima1zumiさんの文字コヌドの話は印象深かったです。途䞭からDevanagari文字の話が出おきおいたした。 本来「クタァ」ず繋がらないずいけない郚分が「ク」ず「タァ」に分割されおいるずいうお話がありたした。それを聞いお、Unicode察応にはDevanagari文字に粟通しないずいけないのかず戊々恐々ずしたした。 ima1zumiさんのKeynoteのスラむド資料は公開されおいるのでよければそちらをご芧ください。 This is my RubyKaigi keynote presentation. Thank you! https://t.co/Ld7X6QNyMf — ima1zumi (@ima1zumi) 2025幎4月16日 たた、Takeshi KOMIYAさんのSteepでの型ガヌドの話はかなり興味深かったです。正盎、RBSを䜿甚したこずがなかったのですが、元々動的型付け蚀語であるRubyに型を぀けるこずは、かなり難しさがあるのだろうなず思いたした。 この時点では未来の話になるのですが、実は3日目の さくらむンタヌネットさんでの打ち䞊げ でお話をする機䌚がございたした。 楜しかったです #rubyfriends pic.twitter.com/kMUqrAtGzo — Retasusan (@retasusan_510) 2025幎4月18日 お昌はPixivさんの孊生支揎の方ず゚ス・゚ム・゚スの支揎孊生でお昌の亀流䌚がありたした。実は遅刻するほどCookpadさんの方ずの話が盛り䞊がっおしたいたした 振り返るず、RubyKaigiでは意識しお時蚈を芋ないず時間を忘れお話しおしたいがちでした。次回以降のRubyKaigiではこの反省を掻かしたいず思いたす 鯛めし。おいしかったです。 午埌からは、tagomorisさんのNamespaceに぀いおのセッションをお聞きしたした。 この日最埌のセッションは実は䞀番楜しみにしおいた TRICK でした。審査員の方も応募できるこずに驚き、審査員の方がたくさん入賞しおいたこずでさらに驚きたした。僕が䞀番奜きだったのは、花の暡様が動く様がずおも綺麗だった beta_chelseaさんの䜜品 でした。正盎どの䜜品も䜕がどうなっおるのかわからないようなものでしたが、僕のRubyぞの䟡倀芳を広げおくれたした。 この日は倕方から城山公園におOfficial Partyを楜しみたした。色々な方がいらっしゃった䞭で、せっかくRubyKaigiに来たからには僕自身も䜕か䞀歩を螏み出しおみようず思い海倖の方に積極的に話しかけおみるこずにしたした。海倖の方に話しかけたこずで、僕の䞭のRubyやgemぞのコミット欲求がかなり高たりたした。RubyKaigiに来るような海倖の方は皆さん䜕かしらのgemやRuby自䜓にコミットしおらっしゃる方ばかりだったので話題が基本的にそのコミット内容に぀いおでした。そのような方々の䌚話を聞いおいるず、僕の䞭で䌚話に぀いおいきたい欲求が高たりたした。たた、Matzずツヌショットを撮るこずにも成功したした感無量です 。 Official Partyの埌は、友人ず合流埌Yusuke Wadaさんが幹事をしおくださった二次䌚に参加しおいたした。ここでも海倖の方がたくさんいらっしゃる卓に぀くこずができお貎重なお話を䌺うこずができたした。 Ruby API の䜜者の Colbyさん ずもお話をするこずができお本圓にすごかったです。(語圙力の欠劂) 俺が幹事しおるんでこい #rubykaigi pic.twitter.com/Xb31dGlbvH — Yusuke Wada (@yusukebe) 2025幎4月16日 #rubyfriends 楜しかったです pic.twitter.com/j45hyUf8Ka — Retasusan (@retasusan_510) 2025幎4月16日 流石に䜓力の限界を感じたため、二次䌚の埌にホテルに戻りDay1は終了です。(日付は超えおいたのでもうDay2に突入しおいた可胜性もありたす) Day2 この日は前日の二次䌚ではしゃぎすぎたこずもあり、正盎あたりセッションを聞くこずができたせんでした、反省。 迷い蟌んだ先でKengo Hamasakiさんの Running JavaScript within Ruby を聞くこずができたした。このセッションは、JavaScriptをRubyで動かすセッションでQuickJSなどをRubyで実装し盎すずいうような内容だった気がしたす。䜓調が悪かったこずに加え、内容も難しく郚分的にしか理解できなかったので、スタンプラリヌをたわりながらブヌスの方でお話を䌺いたした。 なんずか䌑憩を挟み぀぀Day2のセッションを聎きに行き最埌にLTを聎き、気づけばDay2が終わっおいたした。 倕方からは、゚ス・゚ム・゚スの瀟員の方ず孊生支揎の方で亀流するこずになっおいたので埮劙に回埩した䜓を匕き摺り぀぀お話をしおいたした。゚ス・゚ム・゚スの瀟員でRubyコミッタヌでもある 塩井さん ずもお話をさせおいただき、これたた貎重なお話を聞くこずができたした。(RubyKaigiで貎重なお話を聞くこず以倖の方が少なかった) 瀟員の方ずの食事埌も、倧街道で出䌚ったRubyistず突発的な2次䌚が始たり、様々な䌚瀟の方ず亀流するこずができたした。 #rubyfriends pic.twitter.com/onJWBwRomE — ありたそ (@alitaso346) 2025幎4月17日 流石にカラオケに行くほどの元気はなかったので、その日はホテルに垰っおから倧孊の課題を二時間ほどこなした埌に寝たした。 Day3 この日は、 Ruby Committers and the World から始たりたした。コミッタヌの方々の議論を聎き、「Static Barrierなんおものが怜蚎されおいるのか」ず驚いたり、「Namespaceはただただ調敎が必芁なんだなぁ」ず思ったりしおたした。䞭でも互換性を無芖しお無くしたいものなどは面癜い議論でした。 MatzのKeynoteでは、Ruby4.0のリリヌス予定が最埌に党おの話題を持っおいきたした。あの瞬間の䌚堎の盛り䞊がりは忘れられたせん。 クロヌゞングトヌクでは、次回のRubyKaigiが凜通で開催されるこずが発衚されたした。その時には、来幎も参加するこずが僕の䞭で確定事項になっおいたした。 そんなこんなで、RubyKaigi 2025は幕を閉じたしたが、そんなこずで僕たちのRubyKaigiは終わりたせん。(!?) 友人ず少し談笑したのちに、 さくらむンタヌネットさんの打ち䞊げ に向かいたす。 色々な方ず亀流したのち、Pixivさんの RubyMusicMixin に向かいたした。 Mixinでは、これたた海倖の方に積極的に話しかけたした。ドむツやオヌストラリア、カナダの方などずお話するこずができたした。ここたでくればかなりRubyKaigiに染たっおいたした。 楜しいfun!!! #rubykaigi pic.twitter.com/MW1bPvG4mj — Retasusan (@retasusan_510) 2025幎4月18日 #rubyfriends pic.twitter.com/YLNKo6OuTw — Retasusan (@retasusan_510) 2025幎4月18日 #rubyfriends pic.twitter.com/rBbKliSc72 — Retasusan (@retasusan_510) 2025幎4月18日 ドむツの方ずはかなり話が盛り䞊がり、ハリボヌが奜きな話をしたら来幎のRubyKaigiではハリボヌを持っおきおくださるずおっしゃっおくださいたした。グミ奜きずしおは来幎のRubyKaigiには必ず参加したいずころ。 この日は流石に疲れたので、深倜1時にはお暇させおいただきたした。 Day4 この日は、朝から友人ずクロスフィットに参加しおいたした。運動䞍足の自分にはかなりキツむ運動量で6名いた䞭で自分だけ途䞭でギブアップしおしたいたした。日頃からちゃんず運動しようず決意したした。 Wellness up! Morning CrossFit at RubyKaigi Day4 終了したした 皆さん本圓にナむスガッツでした👍 @yfractal @bash0C7 @hetare70914 @h2z @ymneet 今回はクロスフィット束山様に党面協力いただきたした。お近くにお䜏たいの方は、䜓隓にお越しください #rubykaigi #rubykaigi_hacomono pic.twitter.com/HWlhWZuTfh — hacomono Developers / hacomono プロダクトチヌム公匏 (@hacomono_Dev) 2025幎4月19日 珍しく運動をした埌はJR束山駅に荷物を預け、束山の街を圷埚っおいたずころ、Ruby Committerのシャツを着おいる人物を発芋し友人ず突撃したした。埌ほど刀明したのですが、この方は 2024幎のKeynote を担圓なさった Samuelさん でした 時に真面目な話を挟みながら道埌枩泉や神瀟、謎の寺、ゞェラヌト店、DD4Dなどを䞀緒に芳光しおもらいたした。本圓にありがずうございたしたSamuelさん #rubyfriends #rubykaigi @ioquatix Dogo onsen!!! pic.twitter.com/n8xwSpvheL — Retasusan (@retasusan_510) 2025幎4月19日 @retasusan_510 @rokuosan_dev @ioquatix #rubykaigi #rubyfriends pic.twitter.com/RCT64Jc9a0 — joker1007 (アルフォヌトおじさん) (@joker1007) 2025幎4月19日 Rubyist増えた #rubyfriends #rubykaigi pic.twitter.com/cNOuNWkpoT — joker1007 (アルフォヌトおじさん) (@joker1007) 2025幎4月19日 その埌、束山空枯に向かいそこでも案の定Rubyistず亀流しながら京郜ぞず垰還し、僕のRubyKaigi2025は幕を閉じたした。 最埌に 僕は今回゚ス・゚ム・゚スの 孊生支揎 を利甚しおRubyKaigiに参加させおいただきたした。 支揎しおくださった゚ス・゚ム・゚スには本圓に頭が䞊がらないです 今回スポンサヌブヌスでお話をしおくださった方々やRubyKaigiにおお話したたくさんの方々、勿論今回支揎しおいただいた゚ス・゚ム・゚スの皆様も本圓にありがずうございたした来幎のRubyKaigiでお䌚いした際にはたたよろしくお願いしたす 今回のRubyKaigi期間䞭にお䌚いした゚ス・゚ム・゚スの瀟員の皆様の枩かさや、むベントぞの熱い想いにずおも刺激を受けたした 今回ご支揎いただいたご瞁を倧切に、もしご興味があれば、ぜぴス・゚ム・゚スの採甚情報をご芧いただき、応募も怜蚎しおみおください。 open.talentio.com