クックパッドモバイルアプリの開発体制とリリースフロー - クックパッド開発者ブログ
こんにちは、技術部モバイル基盤グループの @slightair です。 今回は、クックパッドのモバイルアプリをどのような流れで開発しているか説明したいと思います。 この記事では技術的な話ではなく、どのようにして、どのようなことを考えて僕らがモバイルアプリを開発しているかに触れたいと思います。 開発体制 クックパッドにはモバイルアプリを専門で開発するようなチームはありません。 必要に応じて、誰でもモバイルアプリ開発に取り組みます。 機能追加・修正を行ったらリポジトリにプルリクエストを送ります。 プルリクエストが来たら、アプリ開発を行うエンジニア同士でレビューします。 様々な修正をひとつのバージョンにまとめるのは、僕が所属する技術部と後述するリリースマネージャーで行います。 リリースマネージャー バージョンごとに、そのリリースの責任をもつリリースマネージャーをひとり選びます。 リリースマネージ
サービス開発エンジニアからマネージャになった話 - クックパッド開発者ブログ
はじめに こんにちは、レシピ投稿推進室の勝間（@ryo_katsuma）です。 techlifeでの執筆は5年ぶり（！）になります。 さて、そんな私も今年2014年の5月にエンジニアからサービス開発の部署のマネージャに転身しました。 そこで今回のtechlifeブログは、いつもの技術ネタとは少し異なるテーマとして、「クックパッドにおいて、エンジニアからマネージャに転身する」ことが、どういうことなのかを自分自身で振り返り、まとめたいと思います。 エンジニアが自身のキャリアを考える上で、少しでも参考になれば幸いです。 現状 私は、2009年5月に中途入社し、今年で6年目になります。この年数は、エンジニア全体はもちろん、社内全体で見ても古い方になります。 これまで、技術部、HappyAuthor部（現在、私が所属している前身になった部）、新規事業部、プレミアム会員事業部...など、いろんな部署で
Readme駆動開発を和訳してみた - 生涯未熟
rebuild.fmで話にあがっていた「Readme Driven Development」について、 原文がどんな内容なのか気になったので訳してみました。 英語力が低いのでGoogle翻訳等をフル活用していますので、 間違っているところや日本語的に怪しいところなどありましたら、ご指摘お願いいたします！ 最近TDD（テスト駆動開発）やBDD（ビヘイビア駆動開発）、エクストリームプログラミング、スクラム開発、スタンドアップミーティングなど、より良いソフトウェア開発のための様々な種類の方法論・開発手法の話題をよく耳にする。 だが、開発しているソフトウェアに対して、それらの方法論・開発手法がマッチしていない限り、全く意味は無いものになっているだろう。 別の言い方をすると、粗悪な設計書に基づいた完璧な実装のように価値がないということだ。 同じようなもので、ドキュメントの無いビューティフルな技術を用
KPTで粘り強く品質改善に取り組んだ話 - クックパッド開発者ブログ
はじめに こんにちは、モバイルファースト室の@y_310です。 部署名からもお分かりの通りクックパッドでは今年からスマートフォンアプリの開発に特に力を入れて取り組んできました。 実際に昨年と比べて開発体制が大きく変化しています。以前はアプリ開発専門のエンジニアのみで開発していたものを、サーバサイドエンジニアもアプリ開発を学び、自分が所属する部署に必要な機能をアプリに実装するようになりました。 そのため、以前は2、3人のチームでの開発だったものが、現在は多い時には複数の部署にまたがって10人ほどのエンジニアが1つのアプリにコミットする状況になりました。 そのような環境の変化によりアプリの品質維持が大きな課題となり、この半年間継続的に品質改善に取り組んできました。今回はその改善プロセスについてご紹介したいと思います。 課題 取り組みを始める前は、様々な部分で課題がありました。 具体例を上げると
Webサービスが当たると、いずれ返済できない技術的負債に突入する由々しき構造について | F's Garage
Webサービスが沢山の人に受け入れられると、そのソースコードは長く運用ができる。外れると、気軽に廃棄することができる。 既にPHPやPerlで書かれたWebサービスが10年以上ビジネスに貢献している事例は沢山ある。Webシステムは気軽に作れて気軽に廃棄できます、というフェーズを超えている。そのコードが長期にわたって沢山の人に貢献し、かつ、それを維持することで沢山の人がお給料をもらっている事実が存在する。 もしそのサービスが、最初から10年動くことがわかっているなら、どういう技術を選ぶべきだろうか？ Web業界の問題は「最新のネタが欲しい、新しい話題を作りたい」と思っている人たちの影響で、その構成要素である開発言語がレガシーな技術になってしまい、人材採用の足かせにになるという構造的問題が起きること。「10年持つ技術」とは？を考えると、「10年人気を維持できる技術」という論点にすり替わってしま
Kobra.io - collaborative coding and programming, share code online
Kobra is an online code editor that allows you to collaborate with your team quickly and efficiently. After you connect to your development environment, you can see changes in your files as your team members type them. Kobra also has built in video, voice and text chat so you’re never more than a click away from your team. Moreover, you can even fill in Instagram and Youtube with the help of this
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
kintoneを支えるKAIZENの技術 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、kintone開発チームの佐藤鉄平 (@teppeis) です。 今回はkintone開発チームのKAIZEN（改善）活動について紹介します。 技術的負債が減らない！ サービスの開発を続けていくと、次第に技術的負債が溜まっていきます。kintone開発チームでは、開発期間中に溜まってしまった技術的負債は kintoneアプリ に登録しておき、あとで時間があるときに返済するようにしていました。 このあたりの開発プロセスについてはこちらの記事をご覧ください。 超速で開発・リリースするための6つのこと | Cybozu Inside Out | サイボウズエンジニアのブログ ところが、最近技術的負債がなかなか減らないという課題に直面していました。kintone開発チームでは主にメンバーの自主性に任せて負債を返済していましたが、この方法だと、 ビジネスサイドからのプレッシャー（もっと新
失敗プロジェクトの通夜 - Strategic Choice
どういうこと？心血を注いだプロジェクトが中断されたときは、「プロジェクトの死」を悼んで、「通夜」を開催します。どうして？仕方のない外的要因のせいであっても、チームにとって、心血を注いできたプロジェクトのキャンセルは、特に士気を下げる原因となります。キャンセルの裏にある事情を、チームが理解しているかどうかは、さほど問題ではありません。とにかく、悲しい気持ちになるのです。無力に感じたり、無気力に陥ったり、時には裏切られたように感じます。チームには、即座に始めなければならない次のプロジェクトがあったとしても、なんらかの休憩は必要です。です。最悪、チームメンバーは辞めてしまうかもしれません。プロジェクトがキャンセルされたのは、自分たちのせいではないにも関わらず、成功したプロジェクトにしか、報酬は与えられません。これは、きわめて強い不公平感を生む可能性があります。どうすれば？失敗したプロジェクトのた
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
OSSの開発モデルを、そのまま社内に持ち込むのは止めたほうがいい（もしくはコードレビューの話） - kazuhoのメモ置き場
以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G
チーム開発とクソコード - tototoshi の日記
今までパッケージソフトとかWebサービスの開発をしてきた中で、ビジネス上の納期や要求を満たすためにひどいコードを書くっていうのは自分の経験ではあまりなかった気がします。なにかひどいバグがあって、とりあえずのパッチを当てて間に合わす、ということはたまにあるけれど。SIの世界は知りませんよ。 そもそもコードを汚くかけば納期に間に合うということもないし、ビジネス上の近道になるということもない。コードをきれいに書こうが汚く書こうが無理なものは無理。第一汚いコードを意図的に書くというのも意外に難しいということは、普段まあまあきれいなコードを書いている人ならわかってくれるんじゃないかと思います。 仕様変更に設計がついていけてなくておかしいとかならともかく、関数が1000行あるとか、newした瞬間全てが終わるとか、変数のスコープがびっくりするくらい広い、みたいなコードについてははビジネス上の要求ではなく
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
「技術が古いとエンジニアがやる気をなくす」、クラウドワークスCTOの大場氏 | 日経 xTECH（クロステック）
日本最大級のクラウドソーシングサービスを手掛け、急成長しているのがクラウドワークスだ。サービスを開始した2012年3月以来、約2年でユーザー数は11万人を突破した。同サービスを使って仕事を発注した企業は、既に2万3000社に上る。 そのクラウドワークスに2014年1月、新しいCTOが誕生した。システムインテグレータ（SIer）とソーシャルゲーム会社を渡り歩いてきた大場光一郎氏である。「伸びる業界、成長するサービスを支えるのが、何より楽しい」と語る。 CTOの役目はエンジニアが働きやすい環境を作ることだと言い、そのためにも最新技術を使えるインフラ整備にはこだわるという。CTOの大場氏に話を聞いた。 大場さんは、SIerの伊藤忠テクノソリューションズ（CTC）からソーシャルゲーム会社のグリーに転職し、そして今のクラウドワークスに移ってCTOになりました。このキャリアについて聞かせてください。
入社二ヶ月経ちました - 銀の人のメモ帳
前職を数ヶ月で辞めて転職活動して、意外にすんなりと転職活動を終えてた。普通に転職活動をしてみて、一社内定頂いたけど辞退した。 今働いてるところは、前回の転職活動で意識高いエントリを書いたらメールくれたベンチャー。 前回の転職活動では、力が欲し〜とか自分より凄い人が居るところで働きたい〜とか言ってたけど、今回は、如何に自分が楽しく働けるか、もしくは自分が楽しいように変えられるかを重視してた。 今の会社、社員数は20人に満たないから、わがままじゃなくて妥当性を持って変えようとすれば変わりそうな感じで、そこらへんについてはストレスが少ない。 本当は入社一ヶ月くらい経ったあたりで社名を明かしてそれなりにひと目に付くような文章書こうと思ってたけど、炎上の火消しにぶっっっこまれてマジで糞な感じになってるから、こんな感じで、なんか適当に書いてる。 僕より前に入社したエンジニアは、わりとギークっぽい感じで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スマホネイティブゲーム 開発効率改善
捗るリコメンドシステムの裏事情（ハッカドール）
止まっちゃいけないフロントエンド開発
趣味プロダクトで楽しいコードライフワークを送る
