栞/#devprocess
「パートナーがいる人は少しの間、頭にその人を思い浮かべて、自分はなぜその人と一緒にやろうとしているのか考えてみよう。なぜその人はあなたについてきているのか。きっとその人は命令されたいのではなくて、自分たちで何かを成し遂げたいと思っているはずだ。スタートアップにはそうした人たちが集まっている。指示型リーダーではこうした人達の自発的な活動を潰してしまう可能性がある。 自己組織型リーダーの仕事は人に命令せずに、何か揉め事が起きたときに、まるで裁判官のように仲裁にはいる。それでうまくいく。」
「普通の人が最先端Web開発に関わって成長してエリートになっていける仕組みが必要」
「Working-Backwards法の商品開発では、お客様の視点をスタート地点にするため、開発前にプレスリリースを作成する。プレス内容は、既存プロダクトの問題点と、それを新製品がどう解決するかが中心になる。」「ちなみに、Amazonでは社内グループでのパワポは非推奨だとか。なぜなら口答プレゼンは、プレゼンターの話術に依存するからだとか。最終出力であるプレスやQ&Aに落とし込むことで、商品価値を中立的に見極める為。」
TDDの使い道。目的じゃないしね。
リリース手順と開発サイクル
「会議をどう進めるのか。まず、模造紙数枚と大量の付箋紙を用意します。事前に会議のテーマや目的を聞いていた参加者は、自分のアイデアを付箋紙に簡潔に書き、模造紙にペタペタ貼っていく。最後に模造紙をデジカメで記録します。数十枚の直筆の意見をまとめて撮影した写真データは会議終了後にすぐさま関係者に配信されます。それが議事録の代わりになるのです。 写真を眺めれば、会議に参加していなくても、会議のプロセスやどんな意見のぶつかり合いがあったかの要旨をつかめます。後で修正をしようにも難しく、結論が複数ということにはなりません。」
ガントチャート描けるよ
「定例会議をすべて削除する」
「開発中は、進捗確認の為のMTGを週3回30分ずつ行いました。作業時間が削られることもあり担当者には当初嫌がられましたが、結果的に、タスクの細かい問題点などを共有する良い場となりました。」
アジャイル原理主義は本当に意味ないとしか思わない
「そもそも、定例会議って、上司側の都合な気がします。」
「サーバサイド、iOSエンジニア、Androidエンジニアの3名を1チームとし、既存のチームに加えてもう1チーム組成し、平行して2ライン体制を整えたいと考えている。」「口頭だけのコミュニケーションではなく、オンラインだとすべてログが取れているため、結果として抜け漏れがない密なコミュニケーションができている。例えば、Facebookグループで仕事の相談や情報共有をしたり、タスク化した事項に関してはRedmineに落とし込んで管理したりしているそうだ。その他に週に2度、1時間ほど『miil』関係者全員参加のグループチャットで業務連絡を行い、週に1度、全員がオフラインで顔を合わせた打ち合わせをしている。」
「作って壊して、純化しない限りは洗練された仕組みは出来ないと思います」「ゲームを作るというのは、仕組みを足すことではなく、仕組みを削ること。このゲームがなんであるかを一言で表せないといけない」「個人的にバハブレを作って思ったことは、この企画意図を最初から最後まで通すのが「ゲームディレクター」だということです。」
pull requestの使い方
「結局、見えない進捗を管理するのであればチームリーダーに頼らざるを得ない。逆に言えばチームリーダーに頼らないで良いように進捗を見えるようにできればチームリーダーに頼らなくても良くなる。」
Pivotal Tracker使い方
「こねくり回して改良していくプロセスこそ価値」
朝会。「要は呼び水になるようなコメントをして、ちょっとした議論や情報交換を促すのである。」
朝会。リーダーへの報告会ではない。「チームメンバが個々の作業，つまり昨日行ったこと，今日行おうと考えていることの同期を図る場なのです。」