KPI 設定の難しさについての思索とそれに付随した細かな考察 - クックパッド開発者ブログ
こんにちは、事業開発部でプロジェクトマネージャー兼エンジニアをやっている新井(@SpicyCoffee)です。10 万円の申請書を書く前に 20 万円のパソコンを買いました。 クックパッドでは、毎日の料理を楽しみにするべく日々サービス開発がおこなわれています。本稿では、サービス開発の中でも重要かつ難解な「KPI の設定」について、私がプロジェクトマネージャーとして普段考えていることや注意している点を紹介します。 KPI を決めるのは難しい サービス開発において KPI を設定し、それを改善するような施策や検証を繰り返していくことは基本中の基本です。しかしながら、現実には「KPI を設定する」という行為自体の難易度が非常に高く、日夜頭を悩ませている開発者のみなさんも多いのではないでしょうか。 以下では、その要因の一つである「KPI は複数の要件を満たす必要がある」ことについて考えます。 満た
サービス開発でぶつかってきた壁と、そのとき助けてくれた本 - クックパッド開発者ブログ
こんにちは、開発ディレクターの五味です。クックパッドにレシピを投稿してくれるユーザーのための機能やサービスを開発する「投稿開発部」に在籍しております。 投稿開発部は、2018年1月に前身となる部からメンバーを一新して発足した部署です。自分たちで1から戦略を作るため、強い実感を持ってユーザーを理解することを信条に、資料を読んだり前任者に聞いたりするだけではなく、実際にユーザーとたくさん話し、たくさんレシピを投稿し、ユーザーのことをたくさん考えてきました。 この記事では、その中でぶつかった課題を解決するために取り入れた書籍や、それをうまく業務に取り入れるために行っている工夫を紹介します。 サービス開発にはさまざまな壁が現れる ユーザーと事業目標に真摯に向き合うほど、サービス開発にはたくさんの壁が現れます。私たちも例外ではなく、部の発足以降、以下のような壁に激突してきました。 「ユーザー課題の見
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
Android開発をする上で知っておいてほしいなと思うこと 2 - こやまカニ大好き
nein37.hatenablog.com 上記の記事の続き。 開発時に引っかかりがちないくつかの注意点と、リリース時に知っておいたほうが良いと思うことについてまとめてみる。 開発時の知見 主にチーム開発時の注意点と標準ツールの活用、よく嵌りがちな落とし穴について。 前回記事の アプリの実装について でも少し触れていたが、もう少し広い範囲について必要だと思うことを書いてみた。 チーム開発の注意点 他の開発者と開発環境を揃えることで開発を効率化できる他、他のメンバーに自分の変更による差分をチェックして貰う必要がある。 また、Android開発者ではない人に対する技術的な説明もできたほうが良い。 ビルド設定を整備する productFlavors, buildTypes でビルド設定を定義しておくと共通言語化できて開発時に役立つ よくある例： productFlavors で本番/開発の環境切
Android開発をする上で知っておいてほしいなと思うこと - こやまカニ大好き
現在の Android Developers の情報は非常に充実していて、Developer Guides を順に読み進んでいくだけで開発に必要な知識とGoogleが想定している(であろう)最も基本的な実装を学ぶことができる。 特にこの「基本的な実装」というものが重要で、これを知っておかないと開発者間の意思疎通がスムーズに行えなかったり、そもそも気をつけておくべき注意点を見落としがちになってしまう。 とはいえ、今の膨大な公式ドキュメントをただ読めというのは厳しいので、Android開発をする上で最低限理解しておいてほしい(と僕が思っている)事柄と、それについて知ることができるドキュメント類についてまとめてみることにする。 2018/03/25 : リリース周りについて別記事に追記した。 nein37.hatenablog.com 公式ドキュメントの重要ページ 公式ドキュメントと言った場合、
［CEDEC 2017］「ゼルダの伝説BotW」の完璧なゲーム世界は，任天堂の開発スタイルが変わったからこそ生まれた
［CEDEC 2017］「ゼルダの伝説BotW」の完璧なゲーム世界は，任天堂の開発スタイルが変わったからこそ生まれた ライター：西川善司 CEDEC 2017は，任天堂からの登壇者が例年に比べて非常に多い。数えてみると8件あった。「海外のカンファレンスでは登壇する一方，日本国内のカンファレンスにはあまり出てこない」という，これまでの傾向からは一転した新しい動向と言える。「ゲーム開発シーンにおける知見の共有」において，これまであまり積極的でなかった任天堂だが，意識を変えてきたのだろうか。 いずれにせよ，CEDEC 2017で任天堂は，「ゼルダの伝説 ブレス オブ ザ ワイルド」（Nintendo Switch / Wii U，以下，ゼルダの伝説BotW）関連セッションを4本も持った。今回はその中から，開発者でない一般のゲーマーにも分かりやすかったと思われる「『ゼルダの伝説 ブレス オブ ザ
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
インディーデベロッパーが失敗から学んだカジュアルゲームデザインの哲学【NDC17】 | ファミ通App【スマホゲーム情報サイト】
6000万DLのヒット作『Rodeo Stampede』を開発したオーストラリアの小規模なチーム2017年4月25日から27日の3日間開催されている、ネクソングループ主催のゲーム開発者向けカンファレンス“Nexon Developers Conference 17”（以下、NDC17）。 25日に行われたオーストラリアのインディーデベロッパー、Featherweight Gamesによるセッションをリポート。 ▼NDC17関連記事まとめはこちら ネクソングループ主催によるゲーム開発者向けの大規模カンファレンス“Nexon Developers Conference 17”が開幕【NDC17】 ネクソングループが主催する最大規模のゲーム開発者向けカンファレンス“Nexon Developers Conference 17”（略称、NDC17）が、2017年4月25日より韓国・ネクソンコリアに
Golden Weekに読むべき本3冊
ゴールデンウィークが近づいてきました。 最近つくづく思うんだけれども、ぼーっと生きてると本当に人生が一瞬で終わる。そして努力しないと、日々感動することも少なくなるし、知的に刺激されるみたいなこともなくなる。だからこそ、読書の時間は大事にしてそれなりに確保しているつもりだけど、長い休みはさらに贅沢に時間をかけて本を読むべき。 本が凄いのは、例えば第一人者と言われる人と頑張って知り合って（笑）直接話さなくても、そういった人たち（もうこの世にはいない偉人も含めて）がそれぞれの領域で長い年月をかけて考えたり研究したりした思考を、非常にわかりやすく整理した状態で、相手に一切気を使うこともなく一方的かつ短時間で堪能できるところ。 そこで最近読んで面白かった本を幾つか紹介したい。サピエンス全史 フランス人の知り合いが面白いよと言っていたので去年の後半に読み始めたこちら。圧倒的に面白い。歴史学から生物学、
Spotifyはどのようにプロダクトを開発しているのか？
(注)昨日の「Spotifyのスケーリングアジャイル」に続き、ヘンリックの許可を得てversion 1.1をざっくり意訳しました。細かい表現は主観で訳したので、気になる方は原文：How Spotify builds productsをどうぞ。訳に対するヘルプも歓迎します。 プロダクト開発は簡単ではない。実際に、そのほとんどの努力が失敗している。そして、その失敗に共通するほとんどの理由が、間違ったものを作ってしまうことだ。 Spotifyはスウェーデンのリーンスタートアップだ。そして、Spotifyはプロダクトデリバリーにおいて素晴らしい実績を持っている。Spotifyのプロダクトはユーザーやアーティストによって愛されており、ウイルスのように世界へと広がっている。アクティブユーザーは2000万人を超え、課金ユーザ（paying subscribers）は500万人と急成長している。例をあげる
コードの半減期とテセウスの船 | POSTD
プロジェクトが発展する際は、単純に新しいコードが古いコードの上に追加されているのでしょうか。もしくは、時間をかけて徐々に古いコードが新しいコードに置き換えられているのでしょうか。これを解明するために、手ごわい GitPython プロジェクトの助けを借りて、Gitプロジェクトを分析する 簡単なプログラム を構築してみました。履歴を年ごとに振り返り、 git blame を実行してみようと思ったのです（この処理を多少でも速くすることは簡単ではないと分かりました。しかし、ファイルのキャッシングを便宜的に含ませることや、変更された点を履歴から見つけること、 git diff を使って変更したファイルを無効にすることなどの詳細を、いつかお伝えします）。 頭がさえている時に、 テセウスの船 をダサくもじって、 “テセウスのGit” と名付けました。私は父親になって、ひどいダジャレを作れるようになった
物理サーバを選定する際のポイント – Eureka Engineering – Medium
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
割れ窓理論を導入してWebサービスのクオリティに直結した話 - pixiv inside [archive]
ピクシブ株式会社 Advent Calendar 2016 @8日目の記事です。 こんにちは、エンジニアのdo7beです。pixivFANBOXの開発などに携わっています。 さて、今回は新規開発プロジェクトに「割れ窓理論」を導入してサービスのクオリティ向上に繋がった話をご紹介したいと思います。 割れ窓理論とは 「割れ窓理論」とは、アメリカの犯罪学者ジョージ・ケリング氏が提唱した「建物の窓ガラスが割れたまま放置されると住民もゴミを捨てるようになり、治安が悪化し、より重大な犯罪が発生してしまう」という理論です。 つまり軽犯罪を取り締まることこそが、重大な犯罪を防ぐために重要であることを指しています。 私たちのチームではこれをWebサービスの新規開発プロジェクトに取り入れています。 WEBサービスにおける割れ窓は「軽度のデザイン崩れ」や「表記ゆれ」に、重大な犯罪は「バグ」や「全体のクオリティ低下
![割れ窓理論を導入してWebサービスのクオリティに直結した話 - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/a00de9ce0520f085a20aefec43b00295df450362/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20161208%2F20161208130750.jpg)
複雑なJavaScriptアプリケーションを考えながら作る話
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
iOS6とNSDateFormatterと和暦と24時間表示オフで発生しやすいバグについて | Technology-Gym
まず、iOS6でのNSDateFormatterの変更点について ios6 – NSDateFormatter show wrong year – Stack Overflow で書かれているようにYYYYを使った場合の挙動が変わっている。 基本的はyyyyを使うべきな場合が殆どなので、yyyyをつかうのを推奨 ここから先は、<strong>iOS6だけではなく他のバージョンも共通</strong>で、<br />iOS設定とNSDateFormmaterでよく発生させてしまうバグについて 和暦バグ iOSの設定.app -> 一般 -> 言語環境 -> カレンダー -> 和暦 or タイ歴 を設定したい場合に、 平成xx年のxxがyyyyに入ってしまい、表示がおかしくなったり、この結果を取得して加算などを行なっていた場合にはアプリがクラッシュするなどのバグが発生する。 NSDateFor
新サービス立ち上げ時の重要指標のデザイン - クックパッド開発者ブログ
こんにちは、株式会社ビットジャーニーに出向中の出口 (@dex1t) です。ビットジャーニーでは、社内情報共有ツール Kibela*1のサービス設計やプロダクトマネジメントに責任を持ちつつ、エンジニアとして開発全般に携わっています。 今回は、新サービスの立ち上げ時にどのような考えで重要指標*2を設計し、それを実際の開発のなかでどう使っていくかという話をします。 なぜ検証をするのか そもそもなぜ新サービス立ち上げ時に、重要指標や検証といった考えが必要になるのでしょうか。それを考えるにあたって、クックパッド的なサービス開発の流れを改めて整理してみます。 企画と検証は表裏一体 サービス開発といえば、企画・開発・検証をぐるぐる回すというのが一般的だと思います。指標は検証段階で活用する道具です。企画で考えたことを確かめるのが検証段階であり、企画と検証は表裏一体です。 したがって、指標の設計をするにあ
モバイルアプリ開発環境のためのフェーズ別チェックリスト - Speee DEVELOPER BLOG
こんにちは、 id:gfx です。この8月から技術顧問としてSpeee社に関わることになりました。普段はビットジャーニー社で情報共有ツールKibelaの開発をしています。 技術顧問として関わるというのは色々なやり方があると思いますが、私の場合はモバイルファーストなサービスの開発チーム作りやメンバーのスキルの向上などのお手伝いする予定です。 さて本エントリでは、アプリ開発の初期から開発メンバーが数名〜十数名になる成長期において、モバイルアプリの開発基盤チームとして何ができるかということをチェックリストにして紹介します。これはあくまでもモバイルファーストなサービスを効率よく、かつ安定して開発するために、開発フェーズごとにこんなことをやればよいのではないかという提案です。 開発フェーズごとに区別したのは、たとえば「最初期」に「成長期」のタスクをやろうとするのは間違いだからです。最初期は安定したリ
ペロリ流 開発要件のまとめ方 - peroli Developer's Blog
2016 - 07 - 22 ペロリ流 開発要件のまとめ方 開発プロセス list Tweet こんにちは。開発部のマネージャーをやっている mizushimac です。 今回は開発するモノの要件のまとめ方についてペロリ開発部が実践している内容を少しご紹介したいと思います。みなさんの会社やプロジェクトではどうやって開発するモノの要件をまとめていますか？ パワポ ですか？ spreadsheet ですか？ 流れ行く slack や github issue で議論しながらコメントに埋もれていき誰かが箇条書きでまとめますか？ きっとカオスなことが多いかなと思いますのでこのエントリーが少しでもご参考になればと思います。 ちなみに、ペロリはカオスを楽しめる人を求めていますw 開発要件のまとめ方って色々あって難しい 私が学生の時に所属していた ベンチャー企業 では、数十MBもある パワポ に画面イメ
開発コストを最小限にして施策を進める - クックパッド開発者ブログ
投稿推進部・ディレクターの中山です。 普段ディレクターはエンジニアとペアを組んでサービス開発をすることが多いですが、エンジニアが別の開発に集中したい時は、ディレクターだけで施策を進めることもあります。エンジニアがいないと動くものができない…と言っていては何もできません。 既に多くのディレクターの方が試していることかもしれませんが、実装に入る前に紙レベルでモノを作ってテストしたり、一般に出回っているツールを活用してみたり…と方法は色々とあります。私がここ数ヶ月で実践してきたことを、おさらいも兼ねてご紹介したいと思います。 方法１：紙でイメージを膨らませる サービスを考える際、いきなり実装に入ることはまず無いと思います。 当たり前の話かもしれませんが、スピーディにイメージを掴むには手書きが便利。何度も書いたり直したりしつつ頭の中のイメージを具体化し、周囲のスタッフに当ててみることがができます。
スマートフォンアプリ開発における共創的な開発チーム
複雑かつリッチな体験を提供するスマートフォンアプリを開発するためのチームワーク、その中でのエンジニアの役割について
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
