Developers Summit 2024にて『良いプロダクト作りのための組織育成』について話してきました #devsumi

2024/02/16にベルサール羽田でデブサミに登壇してきました!

とても緊張しましたが、登壇もカンファレンス自体もとても楽しかったです。

この記事では、今回のこの登壇について掘り下げて書きます。(登壇セッションは「良いプロダクト作りのための組織育成(理論&実践編) 健全なコードは健全な組織、健全なチームから」)

登壇してるzoe

Developers Summit とは

翔泳社さんが主催する国内でも最大級のカンファレンスで、幅広いエンジニアが集まるイベントになっています。

Developers Summitデブサミ)は、2003年から続くデベロッパーのための祭典です。この度、COVID-19による長い間のオンライン開催を経て、4年ぶりに対面での再会を迎えます。「Developers Summit 2024」は、新たな旅立ちの舞台となります。

event.shoeisha.jp

登壇の経緯

去年の年末に、会社の同僚達といっしょにカンファレンスの公募セッションにプロポーザルを出す会をやってました。 ちょうどその際にデブサミのセッション公募も始まっていたので、せっかくなので去年PHPCON福岡とPHPCON沖縄で話した組織育成のテーマの内容を整理したものを応募してみました。

fortee.jp

fortee.jp

実は、私はカンファレンスでの登壇経験は浅く、このPHPCON沖縄福岡での登壇が初めてだったこともあり、正直今回のプロポーザルが採択されるとは思っておらず、採択メールが届いたときはとてもびっくりしました。(11枠しか公募セッション無いなかで100以上応募あったらしいのに採択されたらしい、やばくない??)

登壇内容について

登壇資料はSpeakerDeckにあげているので、興味ある方はぜひ見てください。

speakerdeck.com

今回は、時間が30分でしたが、この30分で福岡と沖縄で話した理論編と実践編の両方を余さず話したかったので、内容の構成や何を話して何を話さないかだったり、せっかくなので新しい内容を詰め込みたいという気持ちがあったので、タイムマネジメントに苦労しました。

また、セッションの冒頭にも入れましたが、教育やピープルマネジメントについて悩んでる人は多いが、なかなか「人」に関わるものなので話しにくかったり、どのように誰に相談すればいいかわからないという問題があり、これに対して少しでも力になれればと想い発表させてもらいました。

セッションの目的。組織育成で悩んでる人は多い。ピープルマネジメントや教育について話せる人を増やしたい。
セッションの目的

ちなみに、資料のヘッダー部分の飛行機のマークをシークバーのようになってるのに気づいた方はいましたか?地味にこだわったポイントなので気づいてくれてる人がいたら嬉しいです。

登壇後や懇親会

登壇後のask the speakerや懇親会では、いろんな方たちに話しかけてもらうことができ、とても良かったです。またこういうコミュニケーションの場を用意して頂き運営の方にはとても感謝しています。

特に私はこういう場で、自分から話しかけに行くのが得意な方ではないため、スピーカーとして懇親会で10秒だけ自己紹介できるという仕組みはとても助かりました。

私は「赤髪の人はこの会場で3人くらいしかいないのでぜひこの髪を目印に話しかけてください、登壇内容は〜」と自己紹介したおかげで、実際に髪色を目印に話しかけに来てくれた人がいて、自己紹介と髪を目立ちやすい色にしてて良かったなと思いましたw(自分から話しかけにくい人は登壇と派手髪おすすめですw)

10秒自己紹介してるzoe
10秒自己紹介してるzoe

また、話しかけに来てくれた人は色々な人がいて、実際現場で教育に悩んでる人や、エンジニアの教育を専門にやってる方など様々いましたが、皆さんそろって独学で教育や組織についてこんなに体系的に整理してるのはすごいと褒めて頂きとても嬉しかったです。

登壇後の振り返り

登壇後の振り返りとして、雑に思ったことをXに投稿してました。

苦手なものでも、継続していっぱい練習することである程度うまくなることはできるし、何より私の登壇でも「意思を持ち実践して、感じたことを継続して振り返ることの重要性」を説いているので、自身が実践することは大事だと考えています。

私自身の登壇における次の課題は下記の通りで、今後これをできるように頑張っていきたいです。

もともと私は相手の反応を見ながらアレンジして話すやり方が得意なので対多になってしまう登壇だとそれがしにくいということが起因していると考えていた。 でも、本当の問題はそこではなく、練習時に相手を想像して出来ない、あるいは想像している相手の解像度が低いということが原因なのではないかと思った。

練習時の相手の解像度が低いまま練習をし、その練習通りに話す結果、聴講者に伝わりにくい発表になる。 こういうサイクルになっていたのでは無いかと想像した。

 

そう考えると、次の段階としては発表練習時にも、聴講者を解像度高く想像して練習を出来るようになり、安定して質の高い発表が出来るようになりたい。

おわりに

デブサミの参加も登壇もほぼ初でしたが、総じてレベルの高いイベントでとても楽しかったです。そんな中私もその場を作る一員として登壇できたこととても誇りに想います。

また、来年も登壇できるかはわかりませんが、参加したいと思いました。もちろん他のイベントでも積極的に登壇できるよう頑張っていきますので、もし見かけたときは声をかけてくれると嬉しいです。

SREチームを立ち上げて2年経過して今

こんにちは!今回は自社の株式会社ウィルゲートで2021年にSREチームの立ち上げをしてから2年経ったので立ち上げの背景から何をしてきたか、今のSREチームはどうなのかを振り返りたいと思います。

この記事は SRE Advent Calendar 2023 の 12日目の記事です。

なお、この記事はPHPカンファレンス北海道2024に出したプロポーザルのネタの供養でもあります。

fortee.jp

また、このプロポーザルをきっかけにツナギメエフエムというpodcastにゲストとして招待されて話したりもしましたので、もしよければ聞いてください。

tsunagi.me

SREチームの立ち上げの背景

まず立ち上げの背景からですが、株式会社ウィルゲートでは2021年当時は開発チーム約15人程度で4~5程度の大小ある自社プロダクトの開発を行っていました。 普段の開発においては、プロダクトごとに機能開発や保守開発や運用を担う開発チームとインフラ全般の保守運用をまるっと担うインフラチームで構成されていました。 そんな中で、いくつかの問題が上がってきました。

  • リリースサイクルが長い
  • トイルの撲滅する動きが優先できていない
  • SLI/SLOを経済的合理性に沿って定められていない
  • 定期的に開発していくための土台がメンテナンスされていない
  • インフラとアプリケーション開発の両方ができる人材がいない結果、領域の間にある問題が解消できない

こういった問題を改善するために、インフラチーム、開発チームとは別にSREチームを2021年に立ち上げました。

立ち上げ当初の活動

SREチームを組成するに当たって最初に行ったのはSREチームの役割を決めるところと人員を選抜するところからでした。

まず役割ですが、各プロダクトのユーザのニーズやビジネスモデルを一緒に理解するところからはじめ、それに合わせてSLI/SLOを事業部一緒になって考えるところからはじめました。

また、人員についてですがSREチームでは領域の垣根を超えてサービスの信頼性を向上するために幅広くやれる高いスキルとマインドが求められるところから、開発チームの中でもインフラを積極的に学び意欲があるメンバーがいたので、そのメンバーを中心にSREチームを立ち上げました。 定めたSLI/SLOを元に各プロダクトごとに開発チームと一緒にどういった改善をしていくかを考え、SREチームはそれを実現するためのサポートを行うという形で活動をしていきました。

実際に行ってきた活動

SREチームが立ち上がってから実際にどういった活動・施策をしてきたかを簡単に紹介したいと思います。 実質1.3人月くらいのリソースで各プロダクト開発チームとインフラチームに働きかけながら地道に各プロダクトごとにスケジュールや体制を決めながら下記施策を行ってきました。

  • 未使用テーブルや計算ロジックの修正によるRDSのコスト削減
  • Datadogの導入
  • バッチ処理のFargate並列化
  • Fargateのコスト最適化
  • 外部サービスの使用箇所と料金の可視化
  • 依存ライブラリのメンテナンス
  • MySQL on EC2からRDS、RDSからAmazon Auroraへの移行
  • 不要なAPIや画面、ライブラリの削除
  • Dockerイメージのメンテナンス及びホスティングサービスのECRへの移行
  • BitbucketからGitHubへの移行
  • MySQL5.7からMySQL8.0への移行
  • フロントエンドビルド環境をWebpackからViteへの移行
  • E2Eテストの導入
  • Larastan/PHPStanの導入と出ている警告の修正
  • 重いエンドポイントの修正
  • CI/CDの整備
  • 頻出エラーやワーニングの修正及び出力条件の調整

本質的にはSRE活動というよりは地道な改善活動という感じですが、これらの活動を実施することによってよりよい開発環境を実感してもらうことができました。

このおかげで、ただサービスに必要な機能を開発するだけではなく、サービスの改善をしやすくするための活動(いわゆる木こりのジレンマにおける斧を研ぐという活動)も大事だということを開発チームに理解してもらうことができました。

現在のSREチーム

2023年12月 現在SREチームは技術的負債として残っているPHPのEOL対応として各プロダクトのバージョンアップを並行して主導しています。 (もともと細かい技術負債の返済やライブラリのメンテナンス、GitHub移行などしてきたのもこのPHPバージョンアップの対応のための布石でもありました。) これが実施できるのもSREとしての動きがSREチームだけでなく、各プロダクトの開発チームにおいても積極的にされるようになり、SREチームに余力が生まれてきている証拠でもあります。

そして、PHPのEOL対応が終われば、いよいよより本格的にSREとしてプロダクト横断でのサービスの信頼性を向上させるための活動に専念できるようになります。 また、その際には社内事例やノウハウをSRE系のカンファレンスなどで発表できればと思いますので、その際にはよろしくお願いします。

それでは、残りの SRE Advent Calendar 2023 の記事もお楽しみに

PHPカンファレンス福岡2023に登壇・参加しました!

PHPカンファレンス福岡は今回4年ぶりの開催でした。

fortee.jp

今回、私もプロポーザルが採択されたので登壇してきました。 i will blogということなので簡単な感想ブログを書きます。

登壇するzoe

ちなみに聞いたセッションの内容は、いくつかあるのですが自分の登壇で緊張してたので、あまり頭に入ってないので後日スライドや動画が公開されたら見直そうと思います。

登壇しました

今回、私は14:35〜15:05の30分枠で「良いプロダクト作りのための組織育成 健全なコードは健全な組織、健全なチームから」というタイトルで登壇しました。 こういったカンファレンスでの登壇は初めてでしたが、想像してたよりも緊張することなくちゃんと発表できとても楽しかったです。

fortee.jp

この発表内容は私が社内でここ数年、新人教育や組織育成についてやってきたことを都度社内のMiroにまとめてきたことを、一度社のテックブログにまとめたものを発表用に整理し直したものです。 ずっと教育のために独学で学んできたことですが、かなり色々勉強してきたものだったので、どこかで整理してアウトプットしたい欲があったので、ここでちゃんと整理してアウトプットできてよかったです。

tech.willgate.co.jp

speakerdeck.com

また、思っていたよりも発表内容に興味・関心を持ってくれた人が多く、登壇後のAsk the speakerで質問もたくさんいただきました。

Ask the speakerでは登壇内容に対する質問というよりは、私の登壇を聞いたうえで自分たちの組織に対してどう考えて適用していけばいいかという観点での相談が多く、みんな組織や教育といったところで悩んでいるんだなということがわかりました。

教育に対する考え方のまとめを話すzoe
教育に対する考え方のまとめを話すzoe

実際、登壇の中では説明のために体系的な理論などを紹介しましたが、実際の現場では理論をそのまま実践、活用できることは多くなく、あるいは知っていてもそれを適用して活用することは至難ですので、質問者のリアルな悩みを聞いてとても共感することが多かったです。そこに対して私の経験と理論を踏まえて、私なりの対処法や考えを話せたことは私自身の知識の整理としても、とても良かったなと思います。 また私自身、色々悩んでずっとやってきていたことなのでわかるのですが、今回登壇をすることで、同じ悩みを抱えてる人同士で色々話していける場を作れたこともとても良かったです。

感想

初めてのカンファレンスでの登壇でしたが、皆さんが真剣に聞いてくれてたおかげか、思ってたよりちゃんと発表できたことと、話したかったことがちゃんと話せたこと、いろんな方に「こんなに教育について体系的に考えててすごい」などたくさんのFBをもらえて嬉しかったです。聞いてくださった皆様、Ask the speakerで話してくれた皆様ありがとうございました。

また、初めての登壇ということで練習にいっぱい付き合ってくれたり、資料の添削をしてくれた会社の仲間には感謝してもしきれません。おかげさまで話したかった内容をちゃんと整理して話すことができました。ちなみにウィルゲートから登壇した3人で会社のイメージカラーであるオレンジに揃えてたのに気づいてた方はこっそり教えてください。

また、今回は初の会社の同僚と一緒での地方カンファレンスへの参加でもあり、様々なカンファレンス周辺でのイベントにもいっぱい参加させていただきました。 おかげで多くの方と交流させていただくことができ、普段の仕事だけでは話せない内容や刺激を受けることができとても楽しかったです。

イベントの企画運営、スポンサーしてくださった皆様、交流してくださった皆様本当にありがとうございました。 また、近いうちにどこかのイベントでお会いできることを楽しみにしてます!

一緒に来た会社のみんな
一緒に来た会社のみんな

食べたもの

以下は、食べたものの雑記です。

ウェストのごぼ天うどんと明太丼
ウェストのごぼ天うどんと明太丼

全然野菜で飲んだお酒
全然野菜で飲んだお酒
全然野菜ではマクドナルドの差し入れがありました。テリヤキバーガー美味しかったです。ご馳走様でした!

shin shinのラーメン
shin shinのラーメン

前夜祭はLINEさんのオフィスでピザを頂きました。美味しかったです!ごちそうさまです!

カンファレンス当日のお昼
カンファレンス当日のお昼

カンファレンス後の2次会
カンファレンス後の2次会

締めのやまちゃんラーメン
締めのやまちゃんラーメン

カンファレンス翌日のお昼の一風堂
カンファレンス翌日のお昼の一風堂

AfterHack後の華味鳥の水炊き
AfterHack後の華味鳥の水炊き

カンファレンス翌々日の朝ごはん おしゃれなカフェでのバインミー
カンファレンス翌々日の朝ごはん おしゃれなカフェでのバインミー

BOSS E・ZO FUKUOKAのフードコートで食べた肉まぶし
BOSS E・ZO FUKUOKAのフードコートで食べた肉まぶし

帰宅前に福岡空港で食べたラーメン
帰宅前に福岡空港で食べたラーメン

らーめんばっかり食べてるな

PHPerKaigi2022に参加しました

f:id:zoe302:20220412005126p:plain
PHPerKaigiでの写真

PHPerKaigiとは

PHPerによるPHPerのためのお祭り、「ペチパーカイギ」今年も開催!

とあり、PHPer好きのためのイベントです。今年2022年は前夜祭も含め全3日での構成となっておりなかなかのボリュームがありました。

phperkaigi.jp

また、私の所属している株式会社ウィルゲートはゴールドスポンサーとしてスポンサーもしていました。

tech.willgate.co.jp

おすすめセッション

全体を通してどの発表もクォリティ高く全部オススメなのですが、やはりずば抜けて参考になる、すごいなと感じたのは t_wada さんの「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」がとても勉強になりました。 毎年PHP Conferenceなどでセッションは聞いていますが、今回PHP8.1の内容にアップデートした上で新しい内容をたくさん盛り込まれててとても参考になりました。

fortee.jp

もう一つは ヒエイカザト さんの「エラー監視とテスト体制への改善作戦」がとても良かったです。 エラー監視について泥臭く向き合いつつ、細かい工夫が参考になりました。最終的にはやはり組織の問題と一緒に解決しいこうという考え方も今の環境とも重なって見えとても参考になりました。

fortee.jp

その他

PHPerKaigiではPHPerチャレンジという#から始まる特定の文字列を探すというCTFのようなイベントがあったのですが、私は残念ながら6位という成績でした。

f:id:zoe302:20220412010925j:plain
PHPerチャレンジの結果発表

また、会全体を通しての動向やログはツイッターでつぶやいてるので気になった方は覗いてみてください。

twitter.com

参加しての感想

今回、オフラインのこういった大規模なイベントへの参加は久しぶりでした。 久しぶりにオフラインで参加できたので、ギークトークや現地での新たなつながりなどを得られてとても楽しかったです。 また、いろんな発表を聞いてとてもモチベーションが上がったので今度は自分もなにかセッションに応募して話してみたいなと思いました!

改めて、運営スタッフさん、スポンサーの皆さんに感謝です。ありがとうございました。

正しい鍵(キーペア)なのにSSHできない!? 〜 原因は鍵のOpenSSH新旧の形式の違いだった

先日サーバ上でキーペアを使用したssh接続で作業しようとしていたところ、OpenSSHで作った鍵の形式が違うことにより、ハマってしまったポイントが有ったので記事にまとめようと思います。 ※この記事ではPuTTy形式とOpenSSH形式の違いによる話は取り扱いません。

f:id:zoe302:20210307212058p:plain

起きた事象

  • OpenSSH形式の公開鍵、秘密鍵のキーペアが正しい状態である
  • 公開鍵がサーバにauthoried_keysとして登録されていて、authorized_keysの場所権限ともに正しい状態
  • サーバにsshでログインしようとすると認証ができない(厳密にはWordPressプラグインインストールをsshでできない)
    • 画面上のエラーメッセージ: 「{WPのユーザ}の公開鍵と秘密鍵が正しくありません」
    • /var/log/secure.log のエラーメッセージには怪しいものは特に出ておらずクライアント側で接続を切ったとしか出ていない
sshd[6058]: Received disconnect from 127.0.0.1 port 47070:11: PECL/ssh2 (http://pecl.php.net/packages/ssh2) [preauth]
sshd[6058]: Disconnected from 127.0.0.1 port 47070 [preauth]
  • 他のサーバで同じキーペアを用いるとsshログインできることを確認
  • 同じサーバで新しく生成し直したキーペアではsshログインできることを確認

結論

  • OpenSSH7.8以降で生成した鍵は後方互換がなくクライアントによってはエラーが発生する
    • パスフレーズが有る際のフォーマットが変わっているため対応していないクライアントではうまくパースできず接続できない状態になっている模様
  • OpenSSH7.8以前で生成した秘密鍵の特徴
    • -----BEGIN RSA PRIVATE KEY----- で始まる
    • パスフレーズで保護してると暗号化についての情報が表示される
  • OpenSSH7.8以降で生成した秘密鍵の特徴
    • -----BEGIN OPENSSH PRIVATE KEY----- で始まる
    • パスフレーズで保護しても暗号化についての情報が表示されなくなった

解決までの経緯

問題発見

起きてた事象としては、WordPressプラグインインストールをsshで行おうとしていたときに発生しました。 サーバ上に登録していた鍵を指定してsshメソッドを使いプラグインをインストールしようとするも公開鍵と秘密鍵が正しくありませんと言われインストールできない。

仮説→検証

そこで、そもそも鍵が誤っているのかを確認するため、サーバ上でlocalhostsshできるかを試してみるが、これは成功する。 つまりキーペア自体は正しく設定されておりssh認証できる状態であることがわかる。

ここでこの鍵は他のサーバでも使っているものの使いまわし(本当はあまり良くないが)であることを思い出し、新たに別の鍵を生成してそれで同様にWordpPressのプラグインインストールができるかを試してみた。 すると、この新しい鍵ではスムーズにプラグインのインストールができた。

根本原因調査

ということで鍵の何らかの違いによってうまくsshできない状態になっていると仮定して鍵の違いを調査した。

もともとあった秘密鍵は鍵の冒頭が -----BEGIN OPENSSH PRIVATE KEY----- で始まっており、新しく作った秘密鍵-----BEGIN RSA PRIVATE KEY----- で始まっていた。

ということで2つの鍵の違いを調べたところクラスメソッドさんの記事が出てきて、OpenSSH7.8で鍵のフォーマットが変わっていることを知りました。

dev.classmethod.jp

どうやらパスフレーズがあるときのフォーマットが変わっており、その変更のためにsshクライアント側でうまく考慮できていないとssh接続する前にエラーとなってしまい接続できないようになっているようでした。*1

解決

本来パスフレーズがあるときに暗号方式などが出ていたものを消すようにしたのはセキュリティ上の問題を少しでも低減する目的かと思いますが、今回はそもそもパスフレーズは設定していなかったので、もともとの形式に変換する方法を選択しました。 すでにある鍵ファイルを変換するために下記コマンドを使用しました。

ssh-keygen -p -m PEM -f id_rsa

これで変換した鍵ファイルを用いて再度WordPressプラグインを試したところ無事成功しました。

めでたしめでたし。

*1:詳細は追っていないため、最新のWordPressなどでは対応されている可能性はある。

ISUCONに向けてpprof導入手順まとめた

pprofとは

Go用プロファイリングツール
実行時間を計測して処理の重い箇所を調べることができるとても便利なツール

pprofの画像

導入手順

ライブラリの取得

$ go get -u runtime/pprof
$ go get -u net/http/pprof

※go modを利用していれば不要だった気がする

コードの修正

インポート部分に下記追加

import (
        ...
        ...
+   _ "net/http/pprof"
)

main関数に以下を追加

func main() {
+   runtime.SetBlockProfileRate(1)
+   runtime.SetMutexProfileFraction(1)
+   go func() {
+       log.Println(http.ListenAndServe("0.0.0.0:6060", nil))
+   }()
        ...
        ...
}

ここまでできたらほぼ完了。

依存パッケージのインストール

WebUIでグラフを見れるようにするために下記をインストール

$ apt install graphviz
or
$ yum install graphviz

ポート開放

WebUIを外から見れる用にするために 1080 ポートを開ける

分析データ収集

アプリケーションが動いてる状態(ISUCONならベンチマーク中)で以下のコマンドを実行しデータを収集&WebUIを起動する

$ go tool pprof -http=0.0.0.0:1080 {アプリケーションのディレクトリ}  http://localhost:6060/debug/pprof/profile

プロファイルできてから再度見る場合

$ go tool pprof -http=0.0.0.0:1080 {アプリケーションのディレクトリ} {収集したファイルパス}

実行が終了したら以下のURLで見ることができる。

http://xxx.xxx.xxx.xxx:1080/

※ポートの説明

  • 1080:pprofを結果を外部から見るためのポート
  • 6060:pprof自体がアクセスするためのポート(外部からアクセスしないので、開けなくてよい)

参考サイト

medium.com

docs.google.com

HHKB厨が corne cherry を自作してみた

1年前くらいに自作したcorneキーボードの記事の下書きが眠ってたので消化です。

作って一時期使ってたのですが、HHKB type-s Hybrid が出て衝動買いしてからそっちを使ってしまってますw(これで家にHHKBが3代目ですよ、、) corneも無線対応してまた使いたいですね。

背景

今まで HHKB BTモデル無刻印 を使っていたが友達に左右分離がいいぞと言われたので、買ってみた。

自分のキーボードに求めるもの

ということで自分がほしいと思うキーボードの条件を洗い出してみた。

  • US配列であること(記号が入力しやすい)
  • コンパクトであること
  • 静かであること
  • 配線が少ないこと(できれば無線であること)
  • 2〜3万円で揃うこと

上記に加えて自作のきっかけでもあるので左右分離キーボードを試してみたいと思っていました。

購入したもの

自作キーボードキット

Corne Cherry

『cherry 茶軸』(42個)

キーキャップ

適当な黒い無刻印のやつ(40個)

f:id:zoe302:20190926203551j:plain

以下自作工程写真

※写真はろうと思ったら画質良すぎて変換めんどくさくなったのでgoogleフォトでw

photos.app.goo.gl

firmware の設定

自作しただけではまだ使えません。キー配置の設定をマイクロチップに設定する必要があります。 今回は QMK Firmware を使って設定しました。

私の設定は下記レポジトリに入ってます。参考にしてみてください。 github.com

キー配置以外にも設定できるのですが、最初なのであまりいじってません。

キー配置は全部で4レイヤ設定しています。 設定次第ではもっとレイヤを増やすこともできますが、レイヤを増やしすぎると切り替えに使うキーが増えるのでその分corneだとそもそもキー数が少ないので配置がつらくなりますw

  1. デフォルトレイヤ=アルファベット
  2. RAISEレイヤ=Fnキー+移動系キー
  3. LOWERレイヤ=数字キー+記号キー
  4. SWITCH(RAISE+LOWER同時押し)レイヤ=予備(なにか欲しくなったら追加予定)

完成

完成したcorne cherry