Ohkuraのブログ

趣味
- DDD
- CleanArchitecture

やりたいことはAWSを使ってアプリケーションを動かすこと。しかしAWSが高い。

どのくらい高いかというと、 ECS on fargate + RDSで月20000円

個人開発のアプリを作って提供する時に、ユーザー数と収益が増加していくとして、どのようにアーキテクチャをスケーリングしていくかという提案

激安サーバー＆Firebae無料枠 -> 1600円/month~
激安サーバー＆有料DBaaS -> 4000円/month~
ECS on fargate + RDS -> 20000円/month~

1, 2 の激安サーバー1台でやるには、SPAとBackendのコンテナを両方とも443のポートで動かす必要があるので、リバプロを挟むなどの工夫が必要

DBの切り替えという、だいぶ心理的コストの高い構成なので、これをするにはクリーンアーキテクチャを意識してDBを交換可能にすることが大切だよねという話をされていた。

感想

無料枠がとても大きかったplanetScaleも最近有料になったので無料DBaaSの選択肢がないの大変ですよね。。
KVSからRDBへの移行、全然やったことないので、実際にやってみたときのpros/consを知りたい！
個人開発でAWS使いたいのめっちゃわかる。個人開発で使うべき安い構成について知ることができて嬉しかった

「友達にコード送ったら１行にされた」

ひなさん　@mi111025

自分の作ったポートフォリオサイトについて友人と話していたら、とても長く書いていたコードを１行にしてもらっちゃった話だった。

HSL色空間知らなかった。

感想

HSL色空間全然知らなかった
知識によって冗長だったコードを短くできるという体験すごい。
友人とコードレビューし合える関係がとても素敵だと感じた。

Let's Learn Code Review

RioFujimonさん　@RioFujimon

コードの書き方を学ぶことはあるけど、コードレビューについて学ぶ機会はあまりないよねという話

Googleがコードレビューの指南書を持っている。コードレビューをどのような観点でするといいかなどについてなど、説明がいろいろある。

感想

Googleからコードレビューのドキュメントが出ているなんて知らなかった
コードレビューのドキュメントがあるというのをチームに共有しようと思った
できる部分から少しずつ実践していこう！という最後のメッセージがとても素敵

「Result型の次のエラーハンドリング」

そうさん。さん @moso_midnight

jsでtry-catchがしんどくなってくるので、Result型を導入することでエラーハンドリングもType safeにできるという話

感想

関数型言語について全く明るくなかったので、ちゃんと勉強したいと思った。
かねてから関数型言語のエッセンスを取り入れることで、全てをType Safeにできるとは聞いたことあったけど、その実例を見ることができてとても良かった。
React, TSちょっとできるって言えるように僕も頑張りたい

「記事の一歩目は業務内容から」

yamatai12 さん (taiyama1212)https://twitter.com/taiyama1212

技術記事を1年で100本ほど書いている超人の方。

技術記事書きたいけど何書けばいいかわからない。という方へのアドバイスというような内容だった。

感想

月10本ペースで技術記事書くのとんでもない。
「どういう時が記事を書くきっかけになるよ」というのをまとめてくださっていてとても参考になると思いました。
技術記事としてのアウトプットまだあまりできていないと感じていたので燃えました🔥

Laravelのサービスコンテナを知ろう

Takumi@男子新体操をしてるエンジニア　さん　(@Ota_Rg_Blog)https://twitter.com/Ota_Rg_Blog

DIの目的から始まり、サービスコンテナ（≒DIコンテナ）はいいぞ！という話につながるお話。

感想

テスタビリティが上がるよねという話に共感した
個人的にDI好きなのでとても面白かった

Bloom FilterをJSで実装してみた

kii310 さん (@kii310_nyan)https://twitter.com/kii310_nyan

Bloom Filterという空間効率の良い確率的データ構造をjs(ts)で実装した話。

Bloom Filterについて初めて知ったのですが、簡単に説明してくださった。

イメージとしては、配列に入っているかどうかの判定とかを確率的に行えるというもの？

感想

ユースケースとして、キャッシュヒットなど、処理に時間をかけたくないが、最悪偽陰性でも問題ない場合に有効なのなな
初めてBloom Filterという言葉を聞いたのでとても興味深かった

正しいプロファイリング

saitos さん

「推測するな、計測せよ」

というのは物事を推測で語るなという意味ではなく、計測した値に基づいて議論せよという話

なぜプロファイリングするのかという話から、ビジネスに対してどのように利益になるのかなど、網羅的に説明されていた。

感想

とても勉強になる内容だった
最近特に、仕事でもパフォーマンスに取り組んでいたので、タイムリーな情報でとても嬉しかった。

ライブづくりの話

こばさん　さん　(@ynstg)https://twitter.com/ynstg

Mikuのライブをするために、どのように許可を取って人を集めて、会場をセッティングするのかという話。

個人で煙を炊く機械をヤフオクで落札しているのがすごかった。

感想

発表の時にスライド上にコメントを流せるツールを使っていた。僕も何かのLTの時には使ってみたいと思った！
何かイベントを企画して遂行しきるその実行力が凄まじい。見習いたいと思った。

2024-04-20

【雑記】社内の読書会の運営って難しいと思った話

雑記

今、僕は途中から引き継いだ社内の読書会を運営している。

読書会を始めるにの当たって以下のルールがあった

週に一回業務時間内で1時間行う
強制参加ではない
初回に集まったメンバーで本を決める
あらかじめ読んできて、読んできた内容を元に集まったメンバーで議論をする
対象はエンジニアチーム全体

このルールを元に今まで4冊の本を読書会で扱ってきている

最初に読み始めたのはチームについての本。次にアジャイルについての本。ここは結構盛り上がった

三冊目に選んだ本は、クラウドサービス関連の本。目的としては社内のスクラムチームのメンバーのみならず、幅広い人に来て欲しかったからだった。当初の狙いを完全に満たすものになったわけではなかったが、まずまずの参加者が来てくれて、盛り上がった。

三冊目を読んでいるあたりから主体的に運営を任せてもらっていた。

四冊目は、ソフトウエアのアーキテクチャなどについての本。今では3~4人の参加者まで減ってしまっていた。

ここで、私は、だんだんと参加者がいなくなってしまうことに焦っていた。

それは1冊目、2冊目に読んだ本の内容をチームで共通言語として得たことにより、それを土台として議論を行うことができるようになった体験を持っていたからだった。

参加者が多ければ多いほど、同じ書籍を読んだ人同士で共通言語を作ることができる。このことによって、チームのレベルがボトムアップしたような体験が、私の中に良い体験として残っていた。

そんな私の理想像とは裏腹に、読書会の参加メンバーは減っていった。

しかし、人数が少ないと読書会の価値はないのか。

よく考えれば、断じてそんなことはない。

毎週興味持って参加してくれるメンバーがいて、本の内容について議論できる状態が作れているのはそれだけで価値があるはず。

そもそも自分が読みたかった本を強制的に読み進められるだけで価値があるじゃないか。

私は暗黙的に目的を「共通言語の醸成」と位置付けていてしまっていて、そうならなかったからだめ！と考えてしまっている節があったことに気づいた。

そもそも、多くの人に来てもらえる施策をしていただろうか。参加のハードルを下げるだけでは、「参加したい」、「参加しなきゃ」と思えるような読書会にすることはできないだろう。

目指すかどうかは別として、もし、本当に多くの人に参加してもらう必要があるなら、今の進め方はあまり得策ではないと感じた。本の選定プロセスや、募集の仕方など、多くの人に来てもらう方法をちゃんと考える必要があると感じた。

まとめ

私はゆるく読書会を運営していたが、人が減ってきたことに焦りを覚えていた。

しかし、そのことに対して何も策を講じていなければ人が去っていくのは自然なことであるし、それは良くないことであるという前提も正しくはないと感じた。

多くの人で読書会をすることに価値はあるが、多くの人に集まってもらうには、そのための施策は別途行う必要があると感じた。

ただ、ひとまず今の読書会に集まってくれている人たちと、楽しく読書会ができればそれでいいと思った。

おしまい

2024-04-17

1on1で理想的なチームってなんだろうという話をした

雑記

1on1にて、

自分の理想とするチーム像と、EMが理想とするチーム像にギャップがあった。

私の思い浮かべる理想的なチームとは

部活のような、文化祭前日のクラスのような、熱を帯びて一つの目的に対して立ち向かっていて
チーム内のコミュニケーションが活発で
お互いを信頼しあっている

そんなものを想像していた。

私はこの状態を目指すべきだと思っていたし、現状のチームと理想のギャップを感じてた。

しかし、EMさんと僕とでチームの理想像に関する考えは異なっていた。

EMさんの考えとしては「団結！！って感じのチームではなくとも、異なる価値観を持つメンバーが、最大限能力を発揮できるようにする。その中で理想のチーム像を作っていくのでは？」という考えだった。

私がトップダウン的に理想を体現しようとしているのに対して、EMはボトムアップ的に個の力を最大化しようとしている。

チームというのはチームの数だけ性質がある。それぞれのチームの理想的な姿は異なるもの。

どのチームも目指すべき絶対的な理想があるのではなく、チームの数だけ目指す場所があるのかもしれない。

自分はEMさんのような考えを今までしてこなかったので、目から鱗だった。

何が正しいかわからないけれど、もっと考えていこう。

おしまい

ふりかえりカンファレンス「LT」を聞きました

参加ブログ

スクラムガイドのスプリントレトロスペクティブを改めて読みかえしてみた

内容メモ

品質と効果を高める方法の計画→これは反省会にしないための目的

過程を検査する→仮説を持った真因の探求→努力・根性で終わらせない。 Good Problem Result→結果の代償や良し悪しには問わない

これを対話する→報告会ではない。

いろいろ話し合った中で、最も役立つ変更を特定する。

スピードも重要。できるだけ早く対応する。

感想

スクラムガイド、もう一度ちゃんと読んでみようと思いました。報告会ではない、だったり、最も役立つ変更を特定するだったり、ハッとしました。

2プロダクトをコネクト！同時開発のしんどさと楽しさと心強さと

内容メモ

2プロダクトをコネクト！同時開発のしんどさ

2プロダクトを同時に見るチームをやってきた。

ここで起こったこと。

ドメイン言語知識がバラバラで、フロントとバックに分かれちゃった
プロダクト切り替える認知負荷が厳しい

→まずプランニングを変革：必ず終わるようにするスクラムの「確約」から

1スプリントで1プロダクトにすることにした。

プロダクト間の優先順位は PdMに喧嘩してもらって決める

感想

僕も今、2プロダクトを見ているのに近い状況だけれども、1スプリント1プロダクトにするなどのテクニックは応用できそうだと感じました。確かに、2プロダクト見ざるを得ない状態になっていた時はインクリメントが終わっていました。

しくじり先生〜ふりかえり手法はチームのイマとコネクトして〜

内容メモ

振り返り手法の選択はチームの今とコネクトするのが吉！

チームの状況、スプリントの状況、振り返りの雰囲気を踏まえた上で、どのような振り返り手法を試すのかを考える必要がある

感想

他のセッションでも話されていたけれども、やはり戦略的にチームの状況を考えて振り返りの手法を考えることが大切だなと感じました。

多職種で実施したふりかえりで基本的なことに気付かされた

内容メモ

6人で全員違う職種
手法はKPTA

-> 2回目らへんに異変が発生。振り返る対象、着眼点

しかし最後には、観点などが揃ってきた。

5回目には振り返りの理解度が上がったと回答。

感想

ふりかえる目的の共通認識化が大切。参加者同士の目的がコネクトしたことが、最後のふりかえりの改善した感の原因だった

ふりかえりカンファレンス「「もやもや」を開きあうふり返りによって、組織に生まれる変化とは」を聞きました

参加ブログ

KMT（ケモティ）　KMQT（ケモキュート）

いかに人の内面（価値観）まで共有し合う振り返りができるかについて探求する。

KPTのもやもや

Pが出てきた時に、それは分かってるんだけどなぁ。というモヤモヤがある。

Pが全て今解決するべき課題とは限らないのでは？
Pが全てのチームの課題ではないのでは？

と感じる。

（確かにそう感じることあるかも）

KPT→KMT

KMTのMはモヤモヤ

モヤモヤもいろんな種類がある

これ効果感じられていないかも。。。みたいな悩みモヤモヤ
これをやるのがいい！という実感はあるけど、成果が具体的に何かもう少し探究したい！という探究的モヤモヤ

そもそもモヤモヤとは？ → 心に蟠りがあってスッキリしないさま →何が課題なのかよくわからないけど、なんとなく気になることを口に出してみよう！

どうやるか

チームでモヤモヤを一人ひとり出し合い、語り合う→モヤモヤを開き合う場づくり

日常業務ではあまり話す機会がないモヤモヤを話していい場を作る。

（確かに普段の業務でモヤモやについて話せないという状況で、場づくりとして機能しそう）

なぜモヤモヤを開き合うのか

モヤモヤ耐性が身に付く

もやもやを開き合うことを習慣としてやることで、悩みを一人抱え込みすぎないことが習慣化する。

チームメンバーの相互理解が深まる

モヤモヤの中にその人の大切にしていることがあらわれる。

KMQT

KMTにQ（Question）を追加する。

出したモヤモヤを問いに変える。

出したモヤモヤから、自分たちが探索していきたいことを問いにしてみる。

例えば「部門のミッションをチームの具体的な活動に落とすのがむずいな」→「他チームと連携してより効果的な活動を出せるだろうか？」みたいな

KMQTのいいところ

一緒に探求する関係性が生まれてくる

一人で抱えていたモヤモヤがチームのもやもやに！

チームのアイスブレイクにもいいかもしれない。

miro.com

テンプレも公開いただいているみたいです。

モヤモヤを出すのは勇気がいる。チームに合わせたモヤモヤの出し方をアレンジする！

質問

Q.どのくらい時間がかかりますか

A.3人で1時間でちょうどいいくらい

感想

Problemを出すことに対して、あまり効果的でないと感じる時があるのわかる。
Problemまで行かないような、さまざまな悩みや感情をモヤモヤとして出すことで、メンバー同士の価値観の共有などの効能がある
Moyamoyaに対して問いをすることで、仮説が生まれTryに「なることがある」。自分は無理やりTryにしてしまいがちだなと思っていたので、意識してみようと思った。

ふりかえりカンファレンス「「ふりかえりのふりかえり」をふりかえり、実のあるふりかえりにする」を聞きました

参加ブログ

はじめに

「振り返りのファシリってどうやったら上手くなるんですか？」

ふりかえりファシリ熟達への道問題。特にスクラムガイドなどにも明記されていない。

ファシリにとっては、「理想　主観」メンバーにとっては「現実　客観」。この二つを繋げるのが振り返りの振り返り（＝FoF）

FoFから実のあるFBを増やすためには？というお話。

どのようにファシリテーターに対するFBを増やすか

事前に準備する

ファシリの本番は振り返りなので、不可説を持って振り返りファシリに挑むことが大切。

漫然とファシリをするのではなく、チームにとって何を解決したいかの仮説を立ててファシリをすることが大切。→フィードバックの感度が上がる

場の熱の流れ

振り返りのファシリはオーケストラの指揮者のよう。

メンバーが議論に集中でき、かつ、議論に従分な熱を込められるようにする。焚き火に薪をくべる作業。なるほど

炎、場の熱は生き物

その場で褒める

人間は五感と感情をセットで記憶している。発言の言い換えがハマる。褒め感＋キーワード化

誠意を見せる

感謝と尊敬。フィードバックをくれるまでに多大な労力をかけてくれている。

FBしてよかったと思わせないといけない。

FBが欲しいとちゃんと伝える

情けは己のためならず、巡り巡って人が為。学びを循環しようという意思を伝える。

実例

「〇〇を意識してファシリしました」をちゃんとメンバーに表明する。その上で、メンバーからフィードバックをもらう。

感想

ふりかえりのファシリ。まだまだ改善できるところはあるな、、、ということに気づいた。
どのようなフレームワークを選ぶかばかり考えていたが、今回のふりかえりの目的や達成したいことなどの準備をしてからふりかえりのファシリをすることが大切だと感じた。やってみよう。

ふりかえりカンファレンス「Connect with Psychotherapy 〜サイコセラピーから学ぶ、行動変容のための準備〜」を聞きました

参加ブログ

「Connect with Psychotherapy 〜サイコセラピーから学ぶ、行動変容のための準備〜」を聞きました