これからの時代に求められるアジャイルな組織づくりとリーダーシップ - Mitsuyuki.Shiiba
アジャイルリーダーシップ を翻訳者の一人であるヒロオカさんにいただいて読みました。ありがとうございます！今の自分にグサッとくる内容でとてもとても良かった。今後の自分の行動も変わりそうです。今日から数日後の11月22日に発売されます www.kyoritsu-pub.co.jp 読みやすかった 著者は SCRUMMASTER THE BOOK を書かれたズージーさん ズージーさんの本自体が読みやすいのと、あと、ユーザベースさんの翻訳が読みやすいのとで、とても読みやすかった。英語の言い回しって日本語にすると分かりにくかったりするけど、そういうのがなくて、自然に読むことができた アジャイルリーダーシップ？ 「アジャイルリーダーシップ」ってタイトルを見たときは、アジャイルなチームのリーダーの話なのかな？スクラムマスターはこうあるべきだよとかって話？と思ったのだけど、読み始めてみるとそうじゃなくて、
クソコードと思わない - Mitsuyuki.Shiiba
なんか、あんまりいい感じじゃないなぁって思うコードに出会ったとして、それをクソコードと呼ばないようにはしてたんだけど、いつからか、そもそもクソコードだと思わなくなってる そのときの、そのコードが書かれた環境があって、それは、その人が持っているスキル以上のことをなんとかしないといけなかったのかもしれないし、めちゃくちゃなスケジュールの中でやらないといけなかったのかもしれないし、お試しで作ったものをそのまま使われちゃったのかもしれない あんまりいい感じじゃない構造だったとしても、そのコードによってシステムは動いて価値をもたらしていて、そのおかげで僕がそのコードに出会ってるんだから、それはとてもスゴイことだなぁって思う コードを悪者にして文句を言っても何も変わらないし、僕はエンジニアなのだから、そのコードをより良いコードにすればそれでいい 自分がコードを書くときには少し気をつけたり、あんまりいい
頭の中のコードを形にするまで - Mitsuyuki.Shiiba
を書いてみる気分 今日の時点での自分のやり方なので、またしばらくすると変わってるかもしれない 僕には、最初に考えたとおりに実装できるようなスキルがないので コードを書きながら形にしていく感じ サイズ だいたい、チケット一枚が、5,6時間で実装できるくらいのサイズになってる 2,3日くらいでレビューまで終わって本番にデプロイすることが多いかな （基本的にはそれくらいってだけで、1,2週間くらいかかるような長いやつもある） 技術的なフィージビリティチェックとかはこの前に終わってる 実装を頭に思い浮かべる こんなふうにすれば良さそうかなぁ このあたりは何パターンか考えられるけどどっちがいいかなぁ とか頭の中に思い浮かべる とりあえず動くものを実装 まずは思い浮かべたものが全部つながって動くかをサクッと確認したいので雑に実装する そして、気づくことがいくつかある あれ？この場合どうなるんだろう？っ
#fukabori をきいて Value Object と Value Object パターンについて頭の中を整理 - Mitsuyuki.Shiiba
連休の余韻も楽しんだので今日から散歩を再開した。ちょっと前までは「陽の光を浴びなきゃ！」と思って3時過ぎにウロウロしてたけど、これからはもうちょっと涼しい時間帯がいいなと思って、夕暮れ時に散歩しながら fukabori.fm を聴いてた。Value Object のお話。面白いなぁ 73. Value Object w/ kumagi | fukabori.fm kumagi さんの記事はこちら Value Objectについて整理しよう - Software Transactional Memo お絵描き PoEAA や DDD はだいぶ前に読んだことがあるけど、Value Object を雰囲気で捉えてるからちゃんと見直しておこうと思って、調べたりしながら絵を描いた。こういうことなのかな？ （絵をかくほどでもなかった・・・ Value Object とは？ kumagi さんも書いてる
毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
僕も41歳だー。CircleCI に入社しました。 - Mitsuyuki.Shiiba
そんむーさんのこの記事を読んで、すごいなぁかっこいいなぁって思って、そういえば僕も41歳だーって思ったので、書くことにした。軽い気持ちで書き始めたら思っていたよりもとても考え込んでしまった。 songmu.jp CircleCI に入社しました 11年勤めた楽天を離れて CircleCI に入社しました。先週の月曜日の10月18日から Senior Full Stack Engineer として仕事をしてます。大阪の自宅からフルリモートです。 寒くなってきたからちょうど良かったー！ https://t.co/td9lks2qVS pic.twitter.com/9AW6X8CPgH— Mitsuyuki Shiiba (@bufferings) October 20, 2021 次の挑戦をするのに、ちょうどいい時期かなぁ ここ数年は、色んなチームのサポートをするエンジニアをやってました。テ
スクラムマスターの次のステップって何だろう？ - Mitsuyuki.Shiiba
SCRUMMASTER THE BOOK を読んだ。 books.rakuten.co.jp もっと大きな物語 最初は（ほうほう。。。）って読んでて途中で（んー？？？）ってなってその後（あぁそういうことか・・・まじかwww）ってなった。面白い。スクラムの中のスクラムマスターという話よりも、もっと大きな物語だった。だけど、ページ数も多くなくて読みやすくて楽しかった。 わー！いただきました。よむー！ https://t.co/T8dEP6bUay pic.twitter.com/lC0t1SRCMN— Mitsuyuki Shiiba (@bufferings) September 4, 2020 悩むだろうなぁ スクラムマスターとして動いてる人であるかなぁと思うのが、雑用係みたいになってるとか、自分がいらなくなることを目指すけどその後どうしよう？とか。 特に後者の、チームとしてある程度うまく
アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
毎朝15分以上のデイリースクラムをしてる - Mitsuyuki.Shiiba
15分以上のデイリースクラム 今一緒に仕事をしているチームでは、毎朝みんなで集まって話をしてる。みんな家から仕事してるからZoomで。 デイリースクラムみたいなものではあるのだけど、15分以内におさめる、ということはあまり考えていない。 だいたい15分は超えていて、長いときは30分ぐらいかかる。でも、それでいいと思っている。それだけ話すことがあるというだけ。 どうして？ 理由は、開発チームだけじゃなくて、プロデューサーも含めて全員で「現状を確認する」「同じ方を向く」「不安を共有する」ということをやっているから。実際のところ、開発チームだけの話だと5分もかからない。 プロデューサーはチームの外側で起こった色んなことをフィルタリングして開発チームに必要な情報を届けてくれる。とても助かる。お互いに情報を共有して、現状の認識合わせをする。そのうえで、今日何をやるべきかを再確認している。 そんな感じ
トラブル対応中にエンジニアリーダーとして考えていること - Mitsuyuki.Shiiba
を言葉にしてみようと思った。僕のいる場所での話。ステークホルダーに対する窓口としてプロデューサーがいて、僕が開発チームのリーダーをしてるようなとき。 ## 状況を把握する システムトラブルが発生すると場が混乱してることが多い。色んな情報が混ざるし、色んな人から問い合わせが来たりするし、窓口になってくれているプロデューサーからの説明も省略されていることが多い。このときに一番避けたいのは、ミスコミュニケーションによって本当の問題を見失って無駄な作業をしてしまうこと。 なので、まずは落ち着いて状況を正確に把握する。ちょっとでもはやく解決したいから、その断片的な情報を元に調査に入りたい気持ちになるけど、ぐっとこらえて全体像を把握する。 コミュニケーションで特に気をつけるのは、相手や自分の中にある思い込み。思い込みがあると喋るときには（当然分かってることだよね）と言葉を省略してしまうし、聞くときには
Javaのコンテナのメモリ割り当ての考え方をまきさんに教えていただいたので記録 - Mitsuyuki.Shiiba
何度か教えていただいているので、今度こそしっかり覚えておきたくて、まきさんからのコメントを記録。 ## メモリサイズの考え方 SpringBootのアプリをコンテナとして動かす場合には768MB以上必要で、1GBくらいは割り当てる必要があるのではないかという僕のコメントに対していただいたコメント。 それは不正確..Tomcatを使う場合は最大コネクション(スレッド)がデフォルト200で+50スレッドくらい余裕を見ると250M (-Xss1M）でデフォルトのReservervedCodeCacheSize 240MとDirectMemorySize 10M加えた上にMaxMetaSpaceSizeがざっくり50Mくらい足すと550Mくらい使ってこれHeapを足すとコンテナサイズ— Toshiaki Maki (@making) November 16, 2019 その前提であればHeap 2
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
そのふりかえりの改善策って実現可能なのかな？ - Mitsuyuki.Shiiba
大変だったプロジェクトの反省会みたいな振り返りとかで、うまくいかなかったことだけを並べて「反省しています！次からはそうならないように、これこれといった対応をしていきたいと思います。」みたいなのをたまに見る。 そういうときに感じるのは「良かったところを知りたいなー」ってのと「そもそもその改善策って、実現可能なのかな？」ってこと。 ## 信頼していること そもそも僕は、全員が全力でプロジェクトを成功させようとしていたこと、良いものを作ろうとしていたことを信頼している。誰も手を抜いていたわけじゃない。 だから、たくさんの良かったことをまず知りたい。この判断は良かったよね。とか、ここは大変だったけどなんとかなったね。とか。 ## 課題 そのうえで、思った通りに進まなかったということなので、課題を出していく。例えば、Bが思っていた以上に難しかった。とか。 ## それって改善になる？ さて。その課題に
サービスエンジニアとサービス開発と3年後 - Mitsuyuki.Shiiba
最近何人かからキャリアパスの相談を受けてて、話をしているうちに自分の考えが少し整理できた気がするので忘れる前にメモ。雑記。 ## サービスエンジニア 僕の今いる部署に求められてるエンジニアは、技術をコアにしたエンジニアじゃなくて、サービスをコアにしたエンジニアだと思ってる。図の左側。技術を突き詰めて「この技術で何ができるか」というよりも、サービスのことを考えて「このサービスのためにあの技術が使えないか」という感じ。 ## アプリ開発とサービス開発 Webアプリの開発経験が10年以上あります、って人よりも、新卒の2,3年目の人の方が頼りになったりして、どういうところなんだろうなぁ？って思ってたんだけど。アプリ開発スキル、と、サービス開発スキル、が別のスキルってことなのかもしれない。 サービスを開発するときは、アプリの機能を実装するだけじゃなくて、全体のアーキテクチャ、インフラ、ビジネス側の運
たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba
「プロダクトオーナーとしてやることはしっかりやってるんです」 「もちろんバックログがあります。そして、ストーリーが優先順にならべられています」 「MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています」 「そしてこのMVPをこの日までにリリースしたいと考えているんです」 いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 「そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか？」 そうですね・・・。まずは、実現できないということを受け止めましょう。 「え？」 そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 「もう自分のできることは全てやっていますよ
実践DDDのサンプルプロジェクトが学びしかない - Mitsuyuki.Shiiba
IDDDを読んで、それなりに書いてあることは分かり始めたかな。と思ってたけど。 いざサンプルプロジェクトを読んでみたら、全然そんなことなかった。(ﾉД`)ｼｸｼｸ github.com いつものように、自分メモ。 プロジェクトの構成 全部で3プロジェクトと1ライブラリがある。 iddd_agilepm データストアとしてKVS(LevelDB)を使用。 DIコンテナは使ってない。 iddd_collaboration Event Sourcing と CQRS。ORM使わずにやってみた。 例をシンプルにするために、Event Sourcedな書き込みモデルと、CQRSの読み込みモデルを1スレッドで実行してる。イベントジャーナルとしてLevelDBを、リードモデル用にMySQLを使ってるのでほんのちょっとだけ一貫性がない状態が発生する可能性がある。別々のデータストアを使って、でも、できるだけ
読みやすいコード（僕にとって） - Mitsuyuki.Shiiba
最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
#jjug_ccc DDDとMicroservicesについて喋ってきましたー(∩´∀｀)∩ - Mitsuyuki.Shiiba
楽しかった！ DDD & Microservices with Spring Cloud 前半がこれまで僕が経験してきたDDD 後半がこれからのために素振りしておきたいこと これまで僕が経験してきたDDD 最近、組織について考えるようになってきたのもあって「境界づけられたコンテキスト」が一番大切だなって実感してる。全てを一度に相手にするのではなく、切り取られた世界を作って、その中で適用していく。その切り取られた世界の間の関係性もデザインしていく。そうすることで複雑さを手に負える大きさでコントロールできる。 DDDを知った当初は、エンジニアとしてEntityやValueObjectのところが面白いなーって思ってゴニョゴニョコード書いてたりしてたんだけど、しばらくして「もっと良いコード書くためにはその土台となるチームづくりをしなきゃ！」と思ってスクラムを導入してたんだけど、しばらくして「チーム
マイクロサービスで必要になるかなぁって思って僕がOAuth2とOpenID Connectをなんとなく分かるようになるまでの物語 - Mitsuyuki.Shiiba
プライベートの勉強は気が向くままにふらふらと。梅田の地下街を歩いてる感じで！（←つまり迷ってる） 元々は、Pivotal Japanさんの、この「今日から君もヒーローだ！」的なタイトルに惹かれてJava(Spring Cloud)でマイクロサービス作るぞーって進めてみたのであった。が、早速その2の「認可サーバーを立ち上げよう！」で「あー、これ知らない。分かんない。もう寝たい。」となってしまったのだった。 そんな僕が「なんとなく分かった！」になるまでの物語。・・・になるはず（ここを書いてる今はまだ分かってない）。 たぶん1ヶ月したら何を読んだか忘れてると思うので記録しとくことにした。 github.com ゴール OAuth 2.0って聞いたことあるけど、よく知らない。この辺、マイクロサービスの認証・認可部分で必要そうだなーって思うので、OpenID 2.0とOpenID Connectも含
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
