アジャイルと通過点とベクトル - Mitsuyuki.Shiiba
昨日と比べて今日一歩前進してる？ もう10年以上前になるけど、計画とリソース効率を重視していた大きな組織の中で、より良いサービスづくりをしたいと、アジャイルなプラクティスやスクラムを取り入れてやり方を変えたことがある それは、うえから「アジャイルな開発をするように」とふってきたトップダウンな指示ではなくて、自分がそういうものづくりをしたいなと思ったというボトムアップな始まり（幸運なことに、少し進めていたところでトップダウンでも話が出てきたので、ボトムアップとトップダウンの両方から取り組むことになってとても良かった） そのボトムアップな改善のときに考えていたのは、その瞬間にやっていることが理想的かどうかというスナップショットじゃなくて、昨日と比べて今日一歩前進してるかというベクトルだったなと思う。まぁ、あんまり深く考えるタイプじゃないので、結果的にそうだったという側面が大きいかもしれない 計
頭の中のコードを形にするまで - Mitsuyuki.Shiiba
を書いてみる気分 今日の時点での自分のやり方なので、またしばらくすると変わってるかもしれない 僕には、最初に考えたとおりに実装できるようなスキルがないので コードを書きながら形にしていく感じ サイズ だいたい、チケット一枚が、5,6時間で実装できるくらいのサイズになってる 2,3日くらいでレビューまで終わって本番にデプロイすることが多いかな （基本的にはそれくらいってだけで、1,2週間くらいかかるような長いやつもある） 技術的なフィージビリティチェックとかはこの前に終わってる 実装を頭に思い浮かべる こんなふうにすれば良さそうかなぁ このあたりは何パターンか考えられるけどどっちがいいかなぁ とか頭の中に思い浮かべる とりあえず動くものを実装 まずは思い浮かべたものが全部つながって動くかをサクッと確認したいので雑に実装する そして、気づくことがいくつかある あれ？この場合どうなるんだろう？っ
開発中のコミュニケーションには色んなところで想像が入り込む - Mitsuyuki.Shiiba
例えば「会議が多い」という意見に、どう対応しよう？ 普通に考えたら「無駄な会議を減らそう！」かな だけど、できれば僕は「だからどうしたいと思ってるんですか？」というのをその意見をくれた人に確認したい 十中八九「会議を減らしたい」ってことなんだろうとは思いつつ、でも「会議が多いから、」のあとには色んなことが想像できる （順当→）会議を減らしたい それぞれの会議に自分が参加しないといけない理由を知りたい 会議が多くて他のことをやる時間がないから、自分の担当タスクを減らしたい 会議が多いのはいいんだけど、間に休憩が欲しい 「そっかぁ、それは大変だよね。ありがとう」って話を聞いて欲しいだけ もしかしたら「だから、充実してるんです」って可能性もなくはない さらに「会議を減らしたい」だったとして、その内容も 「無駄な会議が多いから減らしたい」かもしれないし 「開催頻度を減らしてもいい会議があるのではな
意識低めの成長 - Mitsuyuki.Shiiba
とても雑記 個人の成長は必須かなぁ？ よーはつのツイートを見て、古川さんのスライドを見て、「グループや会社は成長して欲しいなぁって思うけど、個人の成長はどうなんだろう？僕は『今、自分が持ってるチカラで会社の成長を支える』ぐらいがいいなぁ」みたいなことをぼやーっと考えた ここ数年、こういう組織の支援もやっているけど、ほんとに難しい… 開発組織の持続可能性について https://t.co/8HpulzqngQ pic.twitter.com/Jx9LFuH0p2— yoh nakamura (@yohhatu) July 12, 2022 意識低い 最近の自分は「成長しなきゃ！」「そして自分の成長で会社の成長を支えなきゃ！」みたいなのはあんまりなくて、意識は低い方かなぁと思う。「それはそれ、これはこれ」な気持ち 単純に、新しいことを学ぶのは楽しいし、昨日できなかったことが今日できるようになる
ペアプロが苦手でペアワーク - Mitsuyuki.Shiiba
ペアでやろうよー！ チーム内で知識を共有できるように、フルリモートでも一緒に仕事できるように、チームとしてプロジェクトに取り組めるように、「ペアでやろうよー！」ってなって「それいいねー」って思って、最近はペアで仕事をしてる そして、何年も前からうすうす感じてはいたんだけど、やっぱり、僕はペアプロが苦手だった！ので、ペアプロじゃなくてペアワークしてる ペアプロ？ペアワーク？ 「ペアプロ」は「ペアプログラミング」のこと。一緒にコードを書く。リモートワークなのでペアプロするときは、Zoom とかで画面をシェアしながらコーディングしてる 参照 → https://martinfowler.com/bliki/PairProgramming.html 一方「ペアワーク」って言葉は、正式な定義があるわけじゃなくて、自分がそう呼んでいるだけなんだけど「ひとつのタスクを二人で担当する」こと なんで苦手なん
毎日何度も本番環境にデプロイをしている話 - 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 次の挑戦をするのに、ちょうどいい時期かなぁ ここ数年は、色んなチームのサポートをするエンジニアをやってました。テ
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
