ごきげんよう。ex-dwango (元ドワンゴ) のerukitiです。第2のドワンゴ Advent Calendar 2016の12/11です。去年はElectronを探す日常という何かごちうさっぽいものを書いたんですが、今年は異世界転生ラノベっぽい何かです (ラノベじゃないです)。 告知 冬コミ(C91) 2016/12/29 (1日目) 西め18b 東京ラビットハウス 第7開発セクションに居候 10年落ちのFITを高速燃費24km/Lに改善するハックとか、Yoshii9 を1000万円クラスと殴り合えるレベルに音質改善するハックと、プロジェクタの映像品質を改善するハックする本を出します。オカルト？怪しい？それは実際にブースに来てあなたの目で確かめてみてほしいです。 序文 ようこそここは転生部屋、いわゆる異世界転生ラノベで冒頭で描かれる謎の白い空間というヤツだ。かわいい系や美人系の女神

前置き 私のキャリアは少し変わっています。 この業界に新卒で入ってから十数年は、大手ゼネコン的SIerにて、ほぼ一貫してプロジェクトマネジメントをやってきました。最終的には100人月程度の案件を回していたので、中堅クラスではあったと思います。それなりに経験も積んだとは思いますが、あれ、そもそも私って人の管理をやるためにIT業界に入ったんだっけ。。というレーゾンテートル的な理由で、プログラマーに転身しました。 そんなわけで、おそらく日本のIT業界におけるプログラマーから管理職に至るという一般的なキャリアパスを逆行している形になります。 そういった事情もあり、プロジェクト管理からは距離を置くようにしていたのですが、最近またプロジェクトマネジメントについて考える機会が多くなったので、この辺で昔話をしてみようと思います。 他山の石としてワカモノの役に立てば。 前提として ガチガチのウォーターフォー

はじまり はぁ うぉ〜〜〜 アイディアがたくさん生まれるぞ！！！ 資料作成なんてたくさんかいてしまえば簡単だ！！！ 、、、（数時間後）、、、 プレゼン後 チーン なんで、どうして僕のアイディアが斬新なものばかりで一杯あるのに、、、 と資料作成で悩んでいる方！！聞いてください。 書けばいいってわけでも 何も考えずに行動していても意味がありません 説得力のある資料作りとして有名な「PREP（プレップ）法」を使う人もいると思います。 「Point」（要点） 「Reason」(理由) 「Example」(例) 「Point」(要点) まずは、要点を書き、次にその理由を説明して、さらに具体例を出した後、再び結論にまとめる方法です。 口頭で説明する時に頭の中がわかりやすいです。 文章で説明すると文字がダラダラと続いてしまい、長ければ長くなるほど理解しにくくなります。 しかも、最初の結論がズレていたらダ

はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機