エンジニアからマネージャになったときにあるだろうなぁってことを想像して遊ぶ - Mitsuyuki.Shiiba
ソフトウェアエンジニアの話ね。想像して遊んでるだけね。 スキルは高い まず、マネージャになってほしいって言われる時点で「仕事を任せられる」というエンジニアなんだろうな。それは、つまりコードを書くことに加えて、プロダクトをなんとかしてリリースする力と責任感をもっていて、それが会社にとってプラスになっている。 だから、チームを任せて同じようなエンジニアを育てて欲しいと期待されている。自分自身も、自分のスキルをもっと会社の役に立てるぞー！とやる気になっている。 任せたい そういう人がマネージャになって、あるだろうなぁと思うのは「どう任せたらいいんだろう？」という悩み。 自分が手を動かせばプロジェクトがなんとかなるのは分かっている。でも、自分はマネージャの仕事があるし、そこは自分の役割ではないし、実際のところ手を動かす時間なんてない。それはメンバーにやってもらわないといけない。 ただ、だいたいの場
何年も前に書かれたソースコードを読むときの頭の中 - Mitsuyuki.Shiiba
コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。 コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に（そのときはこんな感じだったんだろうなぁ）って想像しながら読んで楽しい。 ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。 前提 今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき「だった」とかは考えない。今後の自分がどう書きたいかなぁ？くらい。 また、そのコードを書いた人が良いとか良くないとかでもない。
Gitのコミットメッセージは適当に書いてる - Mitsuyuki.Shiiba
「Gitのコミットメッセージをしっかり書こう」という記事を読んで、いい話だなーと思う一方で、うちのチームはちょっと前に「コミットメッセージは適当でいこう」って決めたなーって思った。 Gitのコミットメッセージをしっかり書こうという話【備忘録的共有】 | SIOS Tech. Lab しっかり書くのを否定するわけでは全然ない。しっかり書くのはしっかり書くのでいいなって思う。どっちがいいかはチームやプロダクトによるので、チームがいいと思う方を選べばいいかなと。 僕もしっかり書くほうがいいなって思うときもあるのだけど、今のチームでは適当のほうがいいなってだけ。 しっかり書きたいとき 僕が、コミットメッセージをしっかり書きたいときはどういうときだろう？って考えると、OSSにプルリクエストを出すときかなぁ。自分は特にOSSの何かを作ってるわけじゃないけど、自分で何かのOSSを作るならある程度ちゃんと
カケハシに入社して1ヶ月目：アジャイルやHRTが土台になっていて嬉しい - Mitsuyuki.Shiiba
ソフトウェアエンジニアとしてカケハシに入社して1ヶ月目が終わった。入ったら思ってたのと違ったらどうしよう？とドキドキしてたけど、思ってた以上に自分にとって、とてもいい場所で、よかった。 専任のスクラムマスター（社内ではディレクターという名前）がいることを大切にしていたり、何人か元々知ってる人たちがいることもあって、ふりかえりやスクラム、それから組織づくりの面白い話が聞こえてきたりして楽しい。ここはスクラムフェスか？って思った瞬間が何度かあった。 チームのみんなが優しい。ビジネスのメンバーも一緒の小さなチームで、みんなでわいわい毎日楽しく過ごしてる。それぞれが結構難しいことをやってると思うんだけど、それを感じさせないスキルの高さがあって、背中を預けられるなぁって気持ち。そして、僕が初歩的な質問をしても、みんな丁寧に教えてくれる。それと、ゆのんさんがチームのスクラムマスターなのは贅沢な気持ち。
アジャイルと通過点とベクトル - Mitsuyuki.Shiiba
昨日と比べて今日一歩前進してる？ もう10年以上前になるけど、計画とリソース効率を重視していた大きな組織の中で、より良いサービスづくりをしたいと、アジャイルなプラクティスやスクラムを取り入れてやり方を変えたことがある それは、うえから「アジャイルな開発をするように」とふってきたトップダウンな指示ではなくて、自分がそういうものづくりをしたいなと思ったというボトムアップな始まり（幸運なことに、少し進めていたところでトップダウンでも話が出てきたので、ボトムアップとトップダウンの両方から取り組むことになってとても良かった） そのボトムアップな改善のときに考えていたのは、その瞬間にやっていることが理想的かどうかというスナップショットじゃなくて、昨日と比べて今日一歩前進してるかというベクトルだったなと思う。まぁ、あんまり深く考えるタイプじゃないので、結果的にそうだったという側面が大きいかもしれない 計
ウェブアプリケーションエンジニアとして転職活動をしますー！ - Mitsuyuki.Shiiba
しばらくしたら次のことを考えたいなと思ってるので、よい仕事や空いてるポジションがあったら教えてください！— Mitz Shiiba@フルスタックエンジニア (@bufferings) December 8, 2022 突然ですが CircleCI を辞めることになりました。そのことについてあまり話すつもりはないのですが、今の気持ちだけ書いておくと、びっくりはしたけど特にネガティブな感情はなく、面白い経験だなぁという気持ちです。 この一年間、色々とあまりできない体験をしてきた締めくくりにピッタリです。この状況を受け入れて、流れに身をまかせて楽しもうと思います。 ということで、こんな機会はあまりないので、次をどうするか、折角だから色々な会社のお話を聞いてから考えたいなぁと思ってつぶやいたら、たくさんのご連絡をいただき、とても嬉しく思っています。ひとつひとつのお誘いや励ましが、とてもありがたいで
サイボウズさんのマネージャー話を読んで想像して遊んだ - Mitsuyuki.Shiiba
サイボウズさんの、この記事を読んだ blog.cybozu.io とても面白い。良いなと思う。ぼーっと想像して遊んでみる。全部想像だよ 職能横断チームへ 2019年の組織変更ではマネージャーをなくしたことに目がいくけど、職能ごとの組織から職能横断のプロダクトチームに変更したことがまず興味深い 職能横断のプロダクトチームだと良さそうなのは プロダクトのことを第一に考えることができる 職能間の壁をなくして全員で取り組むことができる 結果として、プロダクトをより良くするための開発サイクルが速く回るようになったんじゃないかな。それと、開発・テスト・リリース・運用など全てのフェーズからのフィードバックをチームが得られるので、そこからの改善も進んでそう。とても良さそう 職能別組織が持っていた良さ 一方で、以前の職能別組織の場合に良かったのは 自分の専門領域に集中して取り組むことができる 専門知識を持っ
フルスタックすきまエンジニア - Mitsuyuki.Shiiba
ぼーっと。最近は、フルスタックすきまエンジニアっぽい。と思ったので、とりあえずタイトルだけ書いて、深く考えずに書き始めてみる 僕は、好きなサービスの周りのことだと、何をやっても楽しいタイプなので、これをやったらチームにとって良さそうかな、って思うことをやってたら楽しい。ただ、そのままどっかに行ってしまうとあれなので、軸足はコーディングに置くように意識してる あと、自分は色んなことを同時に考えられるタイプではないので、たくさん面白そうなことがある中で、最大でも3個くらいしか選べないよなぁと思っている。それ以上手をだしてしまうと、混乱する。だから、今の自分がどのスキマを埋めるのがいちばんいいかなぁってのを雰囲気で考えながら動いてると思う。たぶん 具体的に何をやってるかなぁって考えてみる。色々あるけど、同時にやってるわけじゃなくて、どれかをやってるときは、別のことは横に置いてる コード周り 軸足
ペアプロが苦手でペアワーク - Mitsuyuki.Shiiba
ペアでやろうよー！ チーム内で知識を共有できるように、フルリモートでも一緒に仕事できるように、チームとしてプロジェクトに取り組めるように、「ペアでやろうよー！」ってなって「それいいねー」って思って、最近はペアで仕事をしてる そして、何年も前からうすうす感じてはいたんだけど、やっぱり、僕はペアプロが苦手だった！ので、ペアプロじゃなくてペアワークしてる ペアプロ？ペアワーク？ 「ペアプロ」は「ペアプログラミング」のこと。一緒にコードを書く。リモートワークなのでペアプロするときは、Zoom とかで画面をシェアしながらコーディングしてる 参照 → https://martinfowler.com/bliki/PairProgramming.html 一方「ペアワーク」って言葉は、正式な定義があるわけじゃなくて、自分がそう呼んでいるだけなんだけど「ひとつのタスクを二人で担当する」こと なんで苦手なん
トランクベース開発とデプロイ - Mitsuyuki.Shiiba
前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発？ 幹（trunk）となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター！というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする
毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
後輩が自走できるようにサポートするぞー - Mitsuyuki.Shiiba
この記事を読んで、自分が後輩をサポートするときはどうするっけなぁって考えてみた。例によってあんまり深く考えずに勢いで書く。誰にでもどこにでも当てはまるもんじゃないと思う。僕のいる環境の話ね。 note.com 信頼する まずは、信頼する。頑張ろうとしてるとか、良いものを作ろうとしてるとか、自走したいと思ってるとか。そういうの。例えばもし「頑張ろうとしてないように見える」場合、「頑張ろうとしている」という部分を信じてるから、その気持ちが行動につながるまでの間のどこかに妨げとなる何かがあるはずって考えて、それを見つけて取り除いていく。 対話 自分の期待を共有する 「自走できるようになってね？」ってだけ言って待ってるのってめんどくさい。僕はめんどくさいことが嫌い。楽をしたい。てか、言うだけでできるならもうなってる。それよりも、今何ができているか、次の一歩は何か、目指したいのはこういうところだよ、
「ユニコーン企業は書籍に書かれているようなアジャイルなんてやってない」 - Mitsuyuki.Shiiba
4/26 に発売されます！ 「ユニコーン企業のひみつ」をいただいて読みました。読みやすくて面白かったー。4/26 に発売されます！チームをリードしている人や組織づくりをしている人にはもちろんおすすめだし、メンバーの一員としてチームの中で仕事をしている人も「なるほどそんな風に仕事をしてるのかー！」って感じることができて面白いと思うー。あと、アジャイルな開発とかスクラムをやってる人ももう一度自分の大切にしているものを見直すことができるんじゃないかなぁ。ぜひどうぞ。 www.oreilly.co.jp ユニコーン企業はスクラムをやっていない この本の「ユニコーン企業」とか「テック企業」って「大きくなってもスタートアップみたいな働き方をしている企業」のことで、Google・Amazon・Facebook・Spotify のような企業を指してる。そういった企業が何を大切にしているか、どんな風に開発を
僕の頭の中にいる人たち - Mitsuyuki.Shiiba
ちょっと前に、みわさんとせきさんとお話をした。とても心地のいい空間を用意してくれて、幸せな時間を過ごすことができた。ありがとうございました。 その中で「僕の頭の中にはお二人がいるんですよ」という話をしたのだけど、今日は僕の頭の中にいる人たちを何人か紹介しようと思う。 せきさん 僕が何かに悩んでると「うまくいったらどうなるの？」って聞いてくれる。「あぁ、正しさみたいなものに、とらわれてるかも」って言うと「よし」って言ってくれる。常に、自分の行動を疑わせてくれる。 みわさん 僕が気のせいかな…って通り過ぎようとしたら「うん。そうなの。違和感があった」って言って「どうして彼はいつもと違う言い回しを選んだんだろう？何かここに隠れてる気がする」って言うので、いっしょに気をつけて見てみたりする。 そんな風にお二人が僕の頭の中にいてくれるおかげで、自分だけだと気づけない視点に気づけたり、通り過ぎそうなと
毎朝15分以上のデイリースクラムをしてる - Mitsuyuki.Shiiba
15分以上のデイリースクラム 今一緒に仕事をしているチームでは、毎朝みんなで集まって話をしてる。みんな家から仕事してるからZoomで。 デイリースクラムみたいなものではあるのだけど、15分以内におさめる、ということはあまり考えていない。 だいたい15分は超えていて、長いときは30分ぐらいかかる。でも、それでいいと思っている。それだけ話すことがあるというだけ。 どうして？ 理由は、開発チームだけじゃなくて、プロデューサーも含めて全員で「現状を確認する」「同じ方を向く」「不安を共有する」ということをやっているから。実際のところ、開発チームだけの話だと5分もかからない。 プロデューサーはチームの外側で起こった色んなことをフィルタリングして開発チームに必要な情報を届けてくれる。とても助かる。お互いに情報を共有して、現状の認識合わせをする。そのうえで、今日何をやるべきかを再確認している。 そんな感じ
知らない技術は怖い - Mitsuyuki.Shiiba
AよりB、CよりD 今後の方向性を決める判断の中で「Aという技術ではなくBを採用する方がが良さそうです」とか「既存システムのCは良くないからやめてDを使うようにしましょう」とか。最近、何人か全然別の人からそういう話を聞く機会があった。 AよりBが良さそう？ 「僕はAの方が良いと思うんですけど、Bの方が良さそうだと思う理由を知りたいです」って聞くと「Aはこういう部分に問題があると思います」って言われて話が噛み合わなくて、しばらく話をして気づいた。 この人、Aを触らずに想像だけで喋ってるんだ。ってことに。なので、実際に動かして見せてあげると「あぁ、それならAの方が良いですね」ってなった。 「興味があるだけなんですけど、僕も知らない技術だったので少しドキュメントを読んで実際に触ってみて機能を確認してからAの方が良いなと思ったのですが、どうして触らずに想像だけでAは問題があるって断言したんですか？
エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え？そこは問題ないと思いますよ？」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
雑用上司 - Mitsuyuki.Shiiba
僕はWebサービス開発会社のエンジニアなんだけども。 雑用は新人にお願いするんじゃなくて、上司がやると良さそう。だよなって思ってる。 会議の設定とか、飲み会の幹事とか、会議の資料作りとか、そういうの。 そうすると、良さそうのは。 上司は新人より組織に関して色んなことができるので、無駄なものをなくしたり、効率化したりできそう。 本当に必要なものだけが残って、で「それを自分がやるのは時間がもったいない！誰かを雇ったとしても結局その方が得だ！」ってなるとプログラムを書くために入社した人じゃなくて、誰かそういうことをやる人を雇うことができそう。 「出世したら雑用は部下にやらせよう！」じゃなくて「遂に雑用ができるまで偉くなったか！」ってなると雑用が尊いものになりそう。 雑用から学ぶ？ よく「雑用から学ぶのだ！」って話を聞くんだけど、そんな遠回しなことせずに「こういう場合はこうするんだよ」って仕事の中
信頼関係 開発チーム編 - Mitsuyuki.Shiiba
自分の中の考えをまとめるシリーズの続き。前回まではこんなの 開発するときに考えていること。信頼関係 マネージャ編。 - Mitsuyuki.Shiiba 信頼関係 ビジネス側の人編。 - Mitsuyuki.Shiiba 今日は開発チームの信頼を得るために僕が考えていること。これで信頼編は最後！ いつもどおり相手の立場で考えるところから。とはいっても僕はエンジニアなので。自分のことを考えればいいのかな。 エンジニアは良いものを作りたい。お金が儲かるってのはもちろん良いんだけど、もちょっと奥の方に、誰かに喜んでもらえたら嬉しいとかがあるかなーと思う。とにかく良いものを作りたい。 でも、実際の仕事でそんな気持ちをそのまま出せるかというと。そういうもんでもなくて。それは何故だろう？と考えてみたんだけど。理不尽なことが多いからかな。と思った。 開発チームって工程的には下流にいて、だから、理不尽なこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
