はてなブックマーク

有名な開発フレームワーク”スクラム”が、現代のアジャイル開発にもたらした貢献は多くの人が認めるところだと思います。 私自身も、スクラムの思想である「経験主義」「リーン思考」に強く影響を受けた人間の一人です。 私はスクラムの考え方自体はかなり好きですが、唯一賛成できない点があります。 それは『スクラムの一部を変えたものはスクラムと呼ばない』というルールです。 スクラムガイドには以下のように記載されています。 最後に スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。 ~スクラムガイド2020より抜粋~ おそらくスクラムガイドの著者は「正確な”スクラム”の

プロダクトや機能をゼロから最初に作るエンジニアは、その作ったものを改善するフェーズにおいてまるで魔法がかかったように凄まじいパフォーマンスを発揮できます。 今回はその話について書きます。 10xという名のバフ魔法 プロダクトを立ち上げた凄腕エンジニアが開発において凄まじいパフォーマンスを発揮しているのを見たことがある人もいるかもしれません。 その凄腕エンジニアは他の人が1時間かかって直すバグをわずか5分程度で直します。 機能改修も他の人が1週間かかるものをわずか半日で実装してしまいます。 その人に開発を任せると、他の人の10倍の速さで開発が完了する。まさに10xです。 プログラマの格言でも『チーム内の良いプログラマと悪いプログラマの差の差は10倍ある（100倍と言う人もいます）』というものがあるので、実際にそういう状況は様々な現場で起きているのでしょう。 その10倍の差は本当にすべて実力差

CTOアドベントカレンダー2021の12日目の記事です。 今の時代、様々な組織の情報透明性が上がっています。 有名スタートアップが自社のエンジニア組織についてメディアで発信している情報を見たり、流行りの本でGAFA・米国ユニコーン企業のエンジニア組織で採用されている最新の概念を勉強したりできます。 しかし成功している素晴らしい会社の話を聞いていると、どうしてもそれが唯一の正解だと思ってしまいがちなので、注意が必要です。 それらは成功して大きくなった後の組織の話であり、またブランディングとして良い側面だけをクローズアップして拡散しています。 そしてタイトルの通り、事業内容により必要なエンジニア組織は大きく異なります。 成長途上のスタートアップでは名もなき戦略を自分達でゼロベースで考えながら、それを泥臭く改善していく必要があります。 具体的に、事業内容によって必要なエンジニア組織が変わるとはど

プログラミングにおいて、お気に入りのよく使っている小技として「プルリクにセルフコメントしまくる」という小技があります。 良いプルリクの作り方については検索すれば色々ネット上に情報が転がっているのですが（説明文の書き方、PR分割の方針…etc）、セルフコメントについてはあまり見たことがないのでTipsとして取り上げてみました。 ※ 前提：各用語は以下の意味で使っています。 「プルリク」はGithubのプルリクスト（＝マージリクエスト）のことを指します 「セルフコメント」は自分で作ったプルリクエストのコード差分行やあるいはプルリク全体に対しコメントをつけることを指します。 セルフコメントにおいては、「レビュアーへの質問」「レビュアーへの説明（修正背景の意図など）」「やり残したTODOの備忘メモ（例：マージ後XXXしないといけない）」などを書きます。 これをすると以下のメリットが得られます。 メ