ダーク ローンチとは何か : CRE が現場で学んだこと | Google Cloud 公式ブログ
新しいサービスを立ち上げるときは、予期されるトラフィックに対応したいと思うと同時に、途中で何かが起こっても実際のユーザーに影響を及ぼすことは避けたいと考えるものです。では、どうすればサービスの本格稼働の前に問題を見つけることができるのでしょうか。そんなときはダーク ローンチ（dark launch）を検討してください。 ダーク ローンチとは、実際のユーザーから発生したトラフィックをコピーして新サービスに送信し、新サービスからの結果をユーザーに返す前に破棄することです（注 : ダーク ローンチを “フィーチャー トグル”（機能切り替え）と呼ぶこともありますが、それだとサービスの立ち上げに伴う “ダーク” な隠れトラフィックの側面を捉えることはできません）。 ダーク ローンチでできることは次の 2 点です。 新サービスが、既存サービスと同様に実際のユーザーのクエリに対応でき、以前にはなかった不
日本の技術系カンファレンスまとめ - Qiita
日本にはどのような技術カンファレンスがあるのかを調べたことがあるのでメモを残しておこうと思います。「これも載せるべき！」というカンファレンスがある、もしくは説明に不備があるという場合は編集リクエストを送っていただけると幸いです。 全体の雰囲気を知ることができるようなカンファレンス参加レポを見つけたらそれも貼っています（★マークのやつです）。 2016年には開催されていないカンファレンスでも後に復活する可能性はあるので一応載せています。 iOS try!Swift 世界中のSwiftデベロッパーが集まって知見を共有するカンファレンスで、海外からのスピーカーも多く存在していました。同時通訳も付いていたようで、英語が苦手でも安心です。平日3日間を使っての開催です。 ★try! Swift 全日程聞き起こしまとめ | #tryswiftconf 3日間を終えての感想、家に帰ってからが try! S
イベント「CTOだったNight」@dotsに参加してきました！ - tchikuba's blog
最近比較的よく行ってる渋谷dotsで行われた「CTOだったNight」というイベントに参加してきました！ 主催はnanapiの元CTO和田(wadap)さん。 話の内容をメモっておいたんですが、思いの外面白かったのでブログ記事としてアップしておきます！ 最初は自分用の箇条書きとして書いてたのでちょっと読みづらいかもですがご容赦を… ビズリーチ/レイハウオリ竹内さん はじめに ビズリーチ最近CMやってるらしい CTOを1年前に退任した理由 マネジメントの割合が大きくなる エンジニアが自由に研究開発するのもお金がないと そのための事業創造したい うまくいくCTOとうまくいかないCTOの10の違い (1)なんでも作れる技術力 人間力があって技術力はそこそこだと超技術力があるエンジニアに尊敬されない (2)技術を手段として使える 技術を目的化した発言する人は経営陣が耳を貸さない (3)経済のルール
CTOという職業の人を採用するときに気をつけるべきこと - Qiita
このポストを書こうと思ったのは、先日参加したIVS CTO Night & Day 2015 Winter powered by AWS で「アンカンファレンス」がきっかけ。IVS CTO Nightに参加しているので自分も当然CTO(テモナ株式会社)なのだが、衝撃だった。 ※他の登壇やインタビュー記事はWantedlyから見てください。 アンカンファレンスでは以下の画像のようなコンテンツに分かれてワークショップに参加した。 その中で自分は「経営者としてCTOがすべきこと」というお題目にも参加したのだが、CTOという職業ほど、CxOといわれるオフィサーの中でも幅が広い役職は無いということを痛烈に感じた。 一般的に高給ポジションであるにも関わらず、求めている人物像とミスマッチングが起こるポジションだなと思ったのである。少しでもミスマッチな採用により、不幸せな人が増えぬようCTO採用を検討して
米国スタートアップにおけるCTOの役割とは？ | Tech Babies
スタートアップでは、当然CTOの存在とそのパフォーマンスは事業の成否に大きく影響します。テック系スタートアップでなくとも、ITを活用するサービスである限り、チームの開発力によってプロダクト/サービスの質、オペレーションの効率が大きく異なるのが現状です。またエンジニアはスタートアップで職を探す際に、事業内容やCEO以上に、CTOやVP of engineering（開発チームの現場リーダー）がどんな人間なのかを注意深くチェックしています。そのような重要なポジションである一方で、スタートアップにおけるCTOの役割についての記事や書籍が少ないように思われます。そのため、今回はスタートアップにおける一般的なCTOの役割について簡単にまとめてみました。 CTOに求められるのはシンプルにアーキテクトとしてのスキル 様々な意見がありますが、特にアーリーステージのスタートアップのCTOに最も求められること
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
スケールする会社を支える開発組織のマネジメント
スクラムチームに入れないという選択: フルサイクルチームにおける開発者のステップアップ / Why We Don’t Add Newbies to Our Scrum Team
要求定義と要件定義の違いを考える：会社はハードとソフト：図解で描く仕事の設計図は成功へのプロセスデザイン
実は．． 事業運用をオペレーションレベルに展開しないままに、 システム開発をしてしまうことにあります。 入力画面や出力を決めても．． それを使って、いかに日々の仕事をこなすのか？ オペレーションレベルまで突き詰めた創りこみをしないで、 専門家だから、プロだからと．．． コンピュータの専門家に、業務運用の仕組みまで 丸投げにしてしまうことが問題なのです。 要求定義と要件定義の違いを考える どの会社でも、コンピュータのシステムを導入しています。 実績のあるパッケージソフトの導入なら問題ありませんが、 自社のシステムを開発するとなると失敗もあります。 特に、経験の少ないＳＥが担当した場合や無理な要求をした場合に失敗する可能性が高まります。 その原因は何でしょうか？ そこで重要となるのが、システム化の「要求」を 正しくＳＥに伝えるということです。 ＳＥは、エンドユー
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜 Problemが10分で解決するチャットを作ろう
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 開発プロジェクトを進めていくと、チームは様々な課題に直面する。こうした課題は、週次のミーティングや日報で共有して解決していくことが多い。 課題は大小様々だが、特に数時間で解決できるような小さな課題をいかにリアルタイムで解決していくかで、チームのスピード感が大きく変わってくる。 僕のチームでは、リアルタイムの課題解決の為に、社内チャットSlackを社内Twitterのようにする邪道な使い方「分報」という取り組みを実践している。 > 日報の弱点日報の弱点 日報は一日の業務の報告書で、一般的に「進捗状況」「体験」「学習」「課題」が記載される。これらをチームで共有することで暗黙知を減らし、個人とチームを成長されることが目的だ。報告方法はチームによって様々だが、メールをはじめ、
スタッフもクックパッドの１ユーザー - クックパッド開発者ブログ
こんにちは、会員事業部でプロのレシピを担当しています ツヤ です。 2015年10月にプロのレシピ（プレミアム会員プラン）をリリースしました。クックパッドプレミアム会員であれば（決済方法に条件あり） プロのレシピを月額100円(税別)で利用できるプランです。 開発中に発生した検証についてのお話です。 プレミアム会員であれば・・・ サービス内にはユーザーの状態による条件分岐が随所にあります。 ここでのユーザーの状態とは、クックパッドに登録済みかどうか。またどのような方法でログインしているか。プレミアム会員であれば、どの決済方法を選択してるユーザーなのか。ということにします。 プロのレシピ（プレミアム会員プラン）の「プレミアム会員であれば」という条件に対して、ユーザーの状態は クックパッドで提供している 決済方法の種類と同じだけ存在します。 ※ クックパッドで提供している決済方法 クレジットカ
プロダクトマネージャーについて - naoyaのはてなダイアリー
Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。 プロダクトマネージャー制度を導入するにはどうすれば良いのか プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。 プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。 プロダクトマネージャーは新しいユニコーンか? 昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの･･･い
プロダクトマネージャー制度を導入するにはどうすれば良いのか - 小さなごちそう
KAIZEN platform Inc. 技術顧問 伊藤直也さんの、プロダクトマネージャーに関するツイートがとても示唆に富んでいるのでまとめさせていただく。 ソフトウェアエンジニアのひとがなにかと口うるさいの、組織的な怠慢のツケをはらう羽目になるのがだいたい自分たちだから、というのはあるだろうね。ごまかしがきかない仕事だし — Naoya Ito (@naoya_ito) 2015, 10月 21 良く見る典型例は、企画とか品質を保証する仕事までエンジニアに丸投げして、エンジニア側にはその期待値がなくてお互いの思惑がずれる、みたいなケースだな。この場合にエンジニアがしょぼいものを作るから、と指を指されてるけど、問題は製品企画開発の責務を組織の中で曖昧にしてるところにある — Naoya Ito (@naoya_ito) 2015, 10月 21 たまたまエンジニアの中にそこまで含めて上手な
プロダクトマネージャーとプロジェクトマネージャーはどう違うのか - 小さなごちそう
両方ともPMと略されるため混同する人が多いが、プロダクトマネージャーとプロジェクトマネージャーは明確に役割が異なる。 Quoraに素晴らしく簡潔な回答があったので引用して紹介する。 Product managers own "What" and "Why". Project managers own "How" and "When". (a simplification, but generally holds true) Ian McAllister's answer to What's the difference between a Project Manager and a Product Manager? - Quora プロダクトマネージャーは、「何を作るか」「なぜ作るのか」に責任を持ち、プロジェクトマネージャーは、「いつまでに作るか」「どうやって作るか」に責任を持つ。 別の言
突撃！隣の開発環境 パート5【Goodpatch編】 | DevelopersIO
こんにちは！おおはしりきたけです。パート5の今回は、ユーザーインターフェースの設計･デザインに特化しているGoodpatchさんに突撃させていただきました。その中でも今回は弊社でも利用しているプロトタイプツールProttのチームに突撃してきました。インタビューに答えていただいたのは、エンジニアのひらいさんです。 突撃！隣の開発環境とは 技術事例やノウハウなどは、ブログや勉強会などで共有されることが多いと思います。しかし、各社の開発環境や開発体制などは意外と共有されていないこと多いと思います。ノウハウの流出になるかもしれませんが、それ以上に、より良い開発を目指している会社さん同士で情報交換を行い、良いチーム、良いプロダクトを作っていくという志の会社さんの為の情報共有のための企画になります。開発環境や開発体制なども技術領域によっても変わってくると思いますが、この突撃！隣のシリーズでは様々な会社
クックパッドモバイルアプリの開発体制とリリースフロー - クックパッド開発者ブログ
こんにちは、技術部モバイル基盤グループの @slightair です。 今回は、クックパッドのモバイルアプリをどのような流れで開発しているか説明したいと思います。 この記事では技術的な話ではなく、どのようにして、どのようなことを考えて僕らがモバイルアプリを開発しているかに触れたいと思います。 開発体制 クックパッドにはモバイルアプリを専門で開発するようなチームはありません。 必要に応じて、誰でもモバイルアプリ開発に取り組みます。 機能追加・修正を行ったらリポジトリにプルリクエストを送ります。 プルリクエストが来たら、アプリ開発を行うエンジニア同士でレビューします。 様々な修正をひとつのバージョンにまとめるのは、僕が所属する技術部と後述するリリースマネージャーで行います。 リリースマネージャー バージョンごとに、そのリリースの責任をもつリリースマネージャーをひとり選びます。 リリースマネージ
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | POSTD
“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to Look Before You Leap: A Guide to Mapping Assumptions for Product Development Teams | Mural
Failure teaches Success
開発組織マネジメントのコツ - Speaker Deck
デブサミ2015、講演関連資料まとめ
