Runner in the High

技術のことをかくこころみ

組織

ソフトウェア開発におけるクリエイティビティの最小化、認知負荷

前提としてクリエイティブな仕事は再現性が低い。しかし逆に言えば再現性があってはいけないものがクリエイティブであり、再現性がないからこそクリエイティブであると言える。アートのように非再現的なものはクリエイティブであり、再現性が低く刹那的な成…

野良社内ツールと開発生産性、プラットフォーム・エンジニアリング

よくある野良の社内ツールは、開発生産性を向上させるための手段としてスポットで生まれることが多い。 たとえば、定期的に依頼されて手作業でキックしているバッチ処理を誰かがAPI化したり、それがCLIで実行できるようになったり、あるいは不特定多数の人々…

技術力のボトムライン、技術的負債

実際の現場に現れる負債とかクソコードとか呼ばれるものは、簡単にできるはずのものが何十にも不必要な複雑性でラップされた成果物(標準ライブラリ相当の実装を自前で全部書いていて、かつエッジケースでバグだらけ、とか)であることが多い。しかし一方で…

プラットフォーム・エンジニアリングと過去の経験

Publickeyで公開されていたPlatform Engineering Meetup #1のまとめがとてもよかった。 www.publickey1.jp スライド中でも書かれているように、共通のプラットフォームを作るのがめちゃくちゃ難しいというのは同意。 自分が今年の1月ごろに書いた記事とも若…

転職活動でいろんな会社のマイクロサービスと組織を見聞きして思ったこと

転職活動でいろんな会社のエンジニアの人と話して思ったことをマイクロサービスの観点で備忘録がてらメモしておく。 よくあるマイクロサービスの分割軸として、業務機能、ユースケース(動詞)、リソース(名詞)あたりが一般的だが、これらどれもがドメイン…

コードレビューとオーナーシップ、できる限りコードレビューをしない

前職でフロントエンドチームのスペシャリストとして開発プロセスを考えるポジションにいた。そのときに試してみて良かったなと思えたのはAutoApproveという仕組みで、これは任意のPRにAutoApproveというラベルが付くとGithub Actions経由でPRがGithub BotにA…

ITベンチャーのミドルマネージャ初心者として参考になった3冊

izumisy.work マネージャという役職として働くようになってそろそろ2年目が見えてきた。 自分の所属するUniposでは、複数チームが開発組織に並存するようになってから日が浅く(とは言っても1年以上は経っているが)それにともなって各チームをマネジメント…

ビジネス・アーキテクチャとシステム・アーキテクチャ

うちのコンサルが「システムアーキテクチャを決めるためには、ビジネスアーキテクチャを先に固めることが必要」と言ったら、お客様が「事業構造の変化が激しすぎてビジネスアーキテクチャを固めることが難しい」と仰った。そうだよなぁ。システムの寿命より…

メルカリShopsの開発組織に関する記事を読んで

engineering.mercari.com メルカリShopsの開発組織に関する記事が興味深かった。ソフトウェアエンジニアがフロントエンド/バックエンド関係なく開発をするというのは、たしかに開発組織の理想形だと思う。 2020年にオークランドで開催されたDeveloperWeek 2…

朝会と夕会を両方やっている

自分のチームでは朝会と夕会を両方実施しているので、その話を書きます。 (アジャイルとかスクラムとかは分からないです、念のため) 自分のチームにおける朝会の課題 もともと自分のチームでは「朝会」のみをデイリーのmtgとして実施しており、そこで「今…

官僚制とマイクロサービス

現代では官僚制というとなんだか政治的でネガティブな面ばかりが取り沙汰されている面があるが、実際には業務の効率化という観点では、近代的な合理性を追求する優れたモデルである。 官僚制にはネガティブな面はあるものの、組織としてスケーラビリティを維…

マネジメントする立場になって思うこと

今年の夏頃から会社で4-5人チームのリーダーをやっている。 新卒で入社したころはまさか自分がリーダー的存在になるなんて思っても見なかったが、やってみるとこれはこれでおもしろい。来年になる頃には自分がなんでこの選択をしたのか忘れてしまいそうな気…

開発チームの振り返りタイミングのパターン

考えることがあったので雑にメモ。 1. 毎週末(木曜日or金曜日) 最も一般的なパターン。木曜日ないし金曜日にその1週間を振り返る。 1スプリントを1weekと置いていれば毎週何らかの成果物があるはずなので、それに対する振り返りがこの時間にあたる。 毎週3…

大きなリリースをするべきではない4つの理由

自戒を込めてメモ 大きなリリースはバグを増やす 大きなリリースになればなるほど、コードベースに潜むバグが増える。充分なテストがないチームでは、コードレビューにテスト相当のタスクが求められるようになり、本質的な設計の優先度は低くなる。結果とし…