イチからつくり直したほうが速い、という幻想 | ダーシノ(@bc_rikko)
イチからつくり直したほうが速い、という幻想 岩田「いまあるものを活かしながら手直ししていく方法だと２年かかります。イチからつくり直していいのであれば、半年でやります。」 引用:『MOTHER2』ふっかつ記念対談 はじめてのひとも、もういちどのひとも。 - ほぼ日刊イトイ新聞 任天堂の元社長であり、天才プログラマーと呼ばれた岩田聡氏が、MOTHER2の開発が行き詰まっているときに糸井重里氏に放った言葉だ。 技術的負債が詰まったプロジェクトに参画したプログラマーなら誰もが「イチからつくり直したほうが速い」と考えるだろう。 しかし、「イチからつくり直す」という選択肢は理想に見えるが、現実は残酷だ。 我々は天才プログラマーではない つくり直している間はお金を生み出さない つくり直しても完成する保証はない 最適解を選択し続けたはずが、完成する頃には別の負債になっている 「イチからつくり直す」という選
2022年のプロダクトマネジメント方針を公開します - SmartHR Tech Blog
こんにちは、プロダクトマネージャー（以下、PM）のadachiです。 SmartHRでは、年始に各部署のリーダーがその年の方針を発表することになっています。今回は私がPMグループの方針として書いた文章を、丸ごとそのまま公開したいと思います。 本文に入る前に、少しだけ補足をさせてください。 現在PMグループには13名のPMが所属しており、それぞれ担当するプロダクトの性質もフェーズも異なります。そのようなチームに向けたメッセージということで、やや抽象的かつ焦点が絞りきれていない内容になっております。（言い訳その1） また、改めて読み返すとかなり基本的なことしか書いていないのですが、基本に立ち戻ってがんばろうぜ！という趣旨であることをご理解いただければと思います。（言い訳その2） そして、あふれる思いを詰め込んだ結果、かなりの長文になってしまいました。シンプルさを美徳とするPMとしては汗顔の至り
毎週やってる定例会のアジェンダに「これは月末の会で」としておくとスキップされがち - hitode909の日記
開発しているアプリケーションのフロントエンドの様子を見る会（フロントエンド草むしり会）を毎週30分ずつ開催している。 式次第の雰囲気を紹介するとこういう形で、毎週見るメトリクスやエラーに加えて、月に1回くらい様子を見たい項目もある。 アップデート関連は、Pull Requestが出たら都度対処するのだけど、それに加えて最近の様子はどうだろう、と眺める時間を取りたい。そういうものは月に1回くらい見ることにしている。 毎週 この会の大義を確認しよう 終わってない宿題を眺めよう エラーのメトリクスを見よう パフォーマンスのメトリクスを見よう 月の初めの会のみ Dependency Dashboardのアップデート候補を見よう Dependabot alertsを見よう ここで「月の初めの会のみ」としているのがポイントで、今回が月の初めかどうかは誰が見ても明らかで、間違いが起きにくい。 これを仮に
CTO15年やってみた (その1かも) | GREE Engineering
とても久しぶりのエントリになります、グリー株式会社でCTOをやっておりますふじもとです。Pixel Budsを買ったはいいものの、イヤフォンの位置なおすたびにジェスチャ認識されて通知読み上げられることに悩んでいます。たぶん耳にちゃんとフィットしてないのが原因です。 気がつけば、今年でCTOというタイトルでお仕事をしてはや15年が経ち16年目に突入しておりまして、よい機会なので今どんなことを思うか、何が変わったか、などなど勢いで書いてみようと思った次第です...というそれっぽい理由はほんの少しで、ほんとのところそんな立派な理由でもなく、来たる 2020/09/18 (fri) に GREE Tech Conference 2020 (online) が開催されるので、その宣伝をしたいなーと思ったのです。ということで...！ GREE Tech Conference 2020 2020/09/
スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
コミットメント言語で大事なのはそれが制御下にあるかどうか - snoozer05's blog
拙訳『エラスティックリーダーシップ ―自己組織化チームの育て方』にコミットメント言語 (Commitment Language) というものがでてきます。コミットメント言語とは、簡単にいうと「言質を与える言い方」のことで、本書では「仕事では自分が何を行うかを言質を与える言い方で約束すべきである」という話で、このコミットメント言語というものがでてきます。 具体的にいうと、希望的な物言い（「したいと思います」「しようと思ってます」「やれると思います」）やコミットメントを表明しない言い方（「はやったほうがいいとは思っています」「やらないといけないとは思ってます」）をせず、やることを約束する言葉遣い（「〜します」）をするようにしましょうという話です。 ですが、実はここだけを切り取って読んでしまうと勿体なくて、著者のロイがコミットメント言語の章で伝えたい主旨は、単に言い方だけを変えなさいという話では
とあるベンチャーのひどい真実とこれからのこと・その１ - IDEA and Players
ブログを数年ぶりに書くことにした。 前回書いたのが2年前の9月。今日までの間、何度か書こうとも思ったけど精神的に無理だった。 悪いことが現在進行形で起こっている最中にそれを文章にして再確認をするなんて、正直とても耐えられるものじゃない。 それでも今になって文章にしようと思ったのは、やはりここ数年で起こったことを自分なりに整理をつけたいと思った、というのが理由としてひとつある。理由はもうひとつあるが、それは後で書く。 なにも嵐が過ぎ去ったから、というわけではなくて、むしろまだど真ん中なわけだが、ひとまず現状を記録しておきたい、という欲求に駆られて久しぶりに自分の言葉をキーに打ち込んでいるというわけだ。 その前に前提条件。 知っている人は知っているが自分はあるベンチャー企業でエンジニアとして働いていて、入社して今年で4年目になる。 まあ、ぶっちゃけて言うと散々な4年間だった。 まず自分が入社し
LGTM画像は見た目はおもしろいけど遊んでいるわけではない - hitode909の日記
YAPCのスポンサーセッションで，DeNAの採用担当の方が話されていて，エンジニア文化への憧れから，コードの意味は分からないけど勝手にLGTMしたり，会場の発表スライドに載せるには不適切な画像を貼ったりしている，という発表をされていた． 単に迷惑そう，と思ったのと，それ以上に悲しくなって，自分たちが大切にしていることを軽んじられると悲しい気持ちになる． LGTMな画像を貼るのは，傍目から見ると，にぎやかな画像が出てきて楽しそうな雰囲気があるけど，画像を貼る前にはコードが正しいか検証しているのであって，ミスの許されないシリアスな場所でもある． 見た目がおもしろそうだからといって遊びに来られると迷惑だし，そういうライトな活動をするような，遊んでいるように思われていたのか，という悲しさがある． 逆に，そんなシリアスな活動をしているなら，そうと分かる真剣そうな雰囲気になっているべきという気もして，
「露出で払おう」とした起業家へのプログラマの返答
ワオ、いいアイデアですね。ええ、作れますよ。バックエンドにサーバ、フロントエンドにウェブアプリケーションをそれぞれ必要になりそうです。そうしておけば、将来モバイル対応したい時にも必要なものは既にそこにあることになります。 バックエンドの開発は$300(3万3000円) 請求するでしょう。あなたの指定のサーバに配置できます。ウェブアプリの方も、シンプルなデザインでよければ同じだけ掛かりそうです。もっとアートっぽくしたければフロント側は外注に出すので$700(7万7000円) ですかね。
今はコードがお偉いさんなんだからMOBは雁首揃えろって話 - アンカテ
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ Mob Programmingって初めて聞いたけど、とてもいい方法に思える。 コードを書く時に、今現在の仕様はわかっていたとしても、今後どうなるか、どういう方向に発展するのか気になって、ビジネス的にその分野に詳しい人の所に聞きに行ってから書きはじめることがあるし、性能的に大丈夫かDBに詳しい人の意見を聞いたり、何か迷った時に過去のプロジェクトで似たようなケースをどっちの方法で解決したか調べたりすることもある。 書き出すとすぐ終わる短いコードでも、書き出す前に、聞きにいったり議論したりする時間が随分かかっていることもある。この時間をかけないと、結局、後で変更になるので、先に聞きにいくのがベターなんだが、チーム全員集まってひとつのコードを書けば、そういう時間を省略できるような気はする。 だから、これが生産性が高いということは感覚的に
モブプログラミングという働き方 #DevLOVE
2017年6月18日（日）DevLOVE 200 Bridgeにて。
【追記あり】inside 売れないサービスの開発現場から
この二年間、ある一つの売れないサービスを開発し続けてきた。 GWに実家に帰ったときに地元の友達に話したら面白がってくれたのでちょっと書いてみようと思う。 今作っているアプリは、売れていない。 二年前に開発が始まって、リリースして一年半ほどになるが、一円も稼いでいない。 エンタメ系snsのはずなんだが、アクティブユーザーが増えるはずの大型連休で、起動したユーザーがたったの三人だった日があるほど、売れていない。 売れてないが故に常駐しているエンジニアは僕一人だ。外部のエンジニアにスポットでたまにタスクベースでお願いする程度。 ディレクターっぽい人が二人（マーケティング兼任）と、デザイナーが一人いて、 この3人と僕とのやりとりを地元の友人は面白がってくれた。 いわゆる「エンジニアあるある」ではあると思う。 例えば新機能の開発が始まったとき、 ーーーーーーーーーーーーーーー ディ「〇〇な機能が欲し
【追記あり】Re: inside 売れないサービスの開発現場から
http://anond.hatelabo.jp/20170509183828 を書いた増田です。 こんなにたくさん反応があると思っていませんでした。 開発に対してモチベーションが保てずに、愚痴まとめてスッキリしようとか、そういう気持ちで殴り書いたものだったので。 本当にありがとうございます。 「俺、こんなんドン・キホーテと一緒やん」みたいな気持ちでやってたことが、少し報われました。 自分発信のものに反応もらえるってこんなに嬉しいんですね。（何しろ二年くらいそういうのないもので。） はてブ、ツイッターでの反応は全部読んでます。ありがとうございます。（二年なかったので許してください。気持ち悪がらないでください。） どうせお前のスキル不足だろ！！！バカが！！！働け！！！死ね！！！みたいなの予想してたので、9割くらいの人に同調されてるのに少しびっくりしています。 と同時に、そんなんやっぱりどっか
オープンイノベーションと闇イノベーション
先日、とある人の Faccebook での投稿で「オープンイノベーションは都市伝説」という発言があって、私もそれに近い感覚を持っているので今の考えをまとめておきます。 オープンイノベーションの成功例国内外のオープンイノベーション事例や日本国内の現状については、300 ページを超えるNEDO のオープンノベーション白書 (2016) によくまとまっています。 こうした白書や本に掲載される事例を見ていると、オープンノベーションには確かに成功例はあるものの、向き不向きがあることに気付きます。 成功事例を見てみると、「課題が明確」でかつ「課題が衆目を引くぐらい面白い」ものであり、「課題を解決するための技術」をインバウンドで求めている、といった条件を満たすと成功しやすいように見えます。 たとえばよくオープンイノベーションの事例として挙げられる P&G のプリングルスのプリントチップスの事例を見てみる
なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
コードの半減期とテセウスの船 | POSTD
プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです（この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします）。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
グロースハックという言葉の違和感について｜グロースハック本の著者が考える本来の定義
アプリを最速でリリースした話 #pixiv Night 4
「ZOZOTOWN作り直しにつき「40名」のエンジニア求む！」について、尾野（しっぽ）tail_y さんのツイート
