一人 CTO Night での発表資料です
![開発組織マネジメントのコツ - Speaker Deck](https://cdn-ak-scissors.b.st-hatena.com/image/square/6b5365352e5be5ec172dcf07ccaa4835a6b45798/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F260103925c89449284c877b895e09e29%2Fslide_0.jpg%3F6766656)
Photo credit: Dushan and Miae via Visual hunt / CC BY-SA今回は、前回紹介した『UNIXという考え方』の続きで、定理の一つのご紹介です。「初期から動くものをつくってフィードバックをもらって、軌道修正しながら、ゴール見つけて達成しましょう」は、アジャイルな開発でも指摘していますが、Unixの哲学でもその重要さが語られています。 定理3:できるだけ早く試作を作成する ソフトウェアを使って、誰向けに何の問題を解けばよいか、どう解けばよいか、予めはっきりと分かっているのであれば、わざわざトライアンドエラーで失敗しながら学ばなくても、一度立てた計画通りにものごとをすすめることができるでしょう。例えば半年間の開発の初期段階で仕様・設計を作成して固定し、実装・テストして完成させる計画を立てても実現できるはずです。 ところが、終盤に実際に動くものを見て
こんにちは、株式会社ビットジャーニーに出向中の出口 (@dex1t) です。ビットジャーニーでは、社内情報共有ツール Kibela*1のサービス設計やプロダクトマネジメントに責任を持ちつつ、エンジニアとして開発全般に携わっています。 今回は、新サービスの立ち上げ時にどのような考えで重要指標*2を設計し、それを実際の開発のなかでどう使っていくかという話をします。 なぜ検証をするのか そもそもなぜ新サービス立ち上げ時に、重要指標や検証といった考えが必要になるのでしょうか。それを考えるにあたって、クックパッド的なサービス開発の流れを改めて整理してみます。 企画と検証は表裏一体 サービス開発といえば、企画・開発・検証をぐるぐる回すというのが一般的だと思います。指標は検証段階で活用する道具です。企画で考えたことを確かめるのが検証段階であり、企画と検証は表裏一体です。 したがって、指標の設計をするにあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く