１泊２日でウェブサービスを産み出すペパボの社内ハッカソン「お産合宿」 | Sanow Labs blog（サノウラボブログ）
GMOアドパートナーズ(株)がソーシャルメディア・Web広告戦略を提供するラボサイト!Web広告のトレンドや、SEO/SEM、ソーシャルメディアの最新手法の紹介から、ニュース、インタビュー記事等を掲載していきます。実績を通じて得た経験や専門的且つ、実践的なテクニックを活かして、他社の先を行く実効性のあるマーケティング戦略論を提供します。こんにちは、paperboy&co.（以下、ペパボ）の安宅です。 弊社ペパボでは、毎年夏に１泊２日で新しいサービスを産み出す社内ハッカソン／開発合宿「お産合宿」というイベントを開催しています。 先週末に、今年で6回目の開催となる「お産合宿６」が開催され、総勢６０名以上２１組のチームが参加し、様々なサービスをリリースしました。 今回の記事では、ペパボの「お産合宿」から新規サービスができるまでを簡単に紹介します。 ペパボの「お産合宿」とは paperboy&c
Feelingplace
bite the hand Photo by Old Sarge もうタイトルそのままなんですけど。 なぜか久し振りにAppStoreのレビューのレビュー欄を見てみようと思い、愛用しているアプリのレビューを見た時のことで […]
デプロイ作業の属人化を徹底的に排除したい話 - @kyanny's blog
ここ数カ月、デプロイとリリースについて、同僚や友人と議論したり雑談したりする機会が数多くあった。そんな折に、友人から Facebook のリリースエンジニアリングチームについて教えてもらった。曰く、 Facebook ではリリース作業を専門とするチームがあり、そこのメンバーは開発ブランチのコミットとそれに付随する ITS の議論を精査した上でリリースに値する変更をリリースブランチへ cherry-pick するのだそうだ。 2012/07/25 追記 Facebook のリリースエンジニアリングについては Facebook のリリースと文化 - Kato Kazuyoshi を参照のこと cherry-pick は無いわー、というのは置いておくとしても、リリースという極めて重要な作業が特定の人たちに委ねられている点に恐ろしさを感じた。嫌だと思うのはなぜなのかしばらく考えて、デプロイ作業の属
ウェブの「受託開発」が面白くないという8つの誤解 - Zerobase Journal
ぼく自身は多くのベンチャー企業とかよりよっぽど面白い仕事を「受託開発」でやってきているので（あ、もちろん「面白い」というのは主観的な問題だとお断りしておきますが）、ウェブ業界にはびこる「受託開発はダサい」という思想に強い反発を持ってきました。今日はそいつらをバッサリ斬ることにします。 ぼく自身は多くのダメなベンチャー企業とかよりよっぽど面白い仕事を「受託開発」でやってきているので（あ、もちろん「面白い」というのは主観的な問題だとお断りしておきますが）、ウェブ業界にはびこる「受託開発はダサい」という思想に強い反発を持ってきました。 今日はそいつらをバッサリ斬ることにします。 これまでに見聞きしてきた「受託開発が面白くない理由」を一つずつ取り上げて検証します。 × 受託開発なんて所詮「自分の事業」じゃないから自社事業がやりたい。 ○ 「受託開発」でも「自分の事業」としてコミットすることができる
受託開発脳から自社開発脳へ切り替えの7つの壁 - ヴェルク - IT起業の記録
これ、思ったより大変でした。 自分含め、うちにいるメンバー全員、 これまでの経歴では受託開発をメインにやっていたため、 自社サービス開発の経験はかなり少なかったです。 でも、ヴェルクでは、受託開発をしつつ、 時間を作って色々と作っていこう、というスタンスのため、 起業直後から色々と企画を考えていました。 でも、受託開発脳から自社開発脳への切り替えは思った以上に苦労しました。 要件定義等でお客さんと一緒に要件を考えたりしますが、 最終的に「やりたい事」を持っているのはお客さんになります。 要件定義の前の企画やグランドデザインと言った分野は お客さんの戦略に沿ったものになります。 だから、最終的には、誰かが答えを持っている事が殆どです。 そのため、ゼロからそれを考える事があまりないんですよね。 いざ、ゼロから自分たちで企画を考えようと思った時、 いろいろと壁がありました。 1. 本当の意味での
ウェブサービスをゼロから作って成功したこと、失敗したこと - id:k-z-h
php, 雑記いつもなら寝ている時間なのだけれど、なぜか睡魔がやってこないので過去の思い出をまとめてみる。去年の2月ごろ、新規案件のウェブサービスに開発メンバーとしてアサインされた。作るべきものが大量にあったため、4チーム（工期中多少増減したが）に分けてドメインごとに作業分担をした。そのうち、ウェブアプリケーション本体（フロント、API、マネージツール）を担当するチームのサブリーダーが自分の役割だった。そのプロジェクトは去年の末に一旦の区切りを迎え、自分はそこで退職し、新たな環境に身を置くことにした。それから丸4ヶ月経って、自分が書いたコードと新しい環境で書かれていたコードを見比べて、思うところが多々ある。それらを文章としてまとめたいと思う。 失敗したこと簡単な骨組みを作ったあと、デプロイの仕組みを作った。php には phar という仕組みがある。これは jar/war のようにウェブサ
最強のIT系かあちゃんからたかしへのアドバイス
バーンれっどさーん @ledsun たかしへ あなたの勤怠確認しました．こんなに残業が多い割に大して売上が上がってないのはどうしてですか？顧客との信頼関係の構築も甘いとと思います．来月からは頑張って下さい．ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 バーンれっどさーん @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか？残業でカバーですか？お客様が参加するイベントが入っていません。都度調整ですか？事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか？ バーンれっどさーん @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかったです。でも、このシステムを使う人にどういうメリットがあるか分かりませんでした。
Web プログラミングってこんな感じじゃなかろうか - 偏見プログラマの語り！
この歳になって初めて Web プログラミングの現場を見て、刺激的な毎日を送らせていただいています。さて、仕事をしていて一番強く感じるのは前職での開発（スタンドアロンパッケージソフト開発をしていた会社の文化）との違いです。で、Web 開発とは何たるかを表現したくて悶々としていたのですが、ある程度整理ができてきたので文章にしてみようと思います。僕はアカデミックな話よりも現場の話をしたいので、いくつもレイヤをまたいだ文章になります。そのため本稿では具体的な技術の詳説とかアジャイル的な用語が飛び交う説明とかはありません。そういうのを期待している人は読まないでください。 ・Web に限らず、お仕事プログラミング全般で共通のこと プログラムを知らない人がイメージする開発というものは、粘度をこねたりくっつけたりするような作業じゃないでしょうか。つまりそれは、知識さえあれば難しいものではなく、モチベーショ
チャットワーク開発の裏側 - EC studio 技術ブログ
大変ご無沙汰な技術ブログ更新となってしまいました。 振り返ってみると、前回の記事がもう約2年前！ ブログ記事を楽しみにしていただいていた方には申し訳ない限りです。 この2年間、何をやってたかというと、 「チャットワーク」というサービスの開発に全社を挙げて取り組んでいました。 チャットワークはおかげさまで2011年3月1日のリリース以来、 1年で6万ユーザーを突破し現在も順調に成長を続けています。 そして今年の4月1日に、創業から12年使用し続けてきた 「株式会社EC studio」という社名を「ChatWork株式会社」へと 変更することを発表しました。 （※エイプリルフールに発表しましたが、本当です＾＾； 変更の実施は6月ごろを予定） それなりに親しんでいただけていた EC studio という社名を 変更するのは勇気のいることでしたが、チャットワークというサービスには それだけの可能性
何故バグ報告の99%が役に立たないのかもしくは何故プロのテスターが存在するのか - oops
テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても本当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定
「どうしましたか？」「お腹が痛いんですけど…」「もっと詳しくおしえてください」「えっ、お腹が痛いだけですけど」「それでは診断できません」 - uzullaがブログ
医者「今日はどうしましたか？」 患者「今は落ち着いてるんですが、最近どうも腹痛がひどくて…」 医者「もうちょっと具体的に言ってください」 患者「そうですね、なんとなくシクシクと…」 医者「なんとなくとかいわれても困りますね、もっと具体的に現象を教えてください」 患者「えっ」 医者「たとえば、脇腹に針をさしたようにいたい、とか。みぞおちに重い鈍痛があるとか、具体的に」 患者「ううん、そうですね…みぞおちが痛かったかも…」 医者「かも！？」 患者「みぞおちがいたいです！刺すように！」 医者「みぞおちがいたい、刺すように、なるほど（カリカリ」 患者「どうなんでしょう…胃炎とか…」 医者「素人が症状を断定しないでください」 患者「すみません…」 医者「今の症状はわかりましたから、どこで、いつ、どうやったら腹痛になったか、状況を詳しく、順番に教えてください。まず痛くなったのは何時何分何秒で、その何分
シリコンバレーの英語: 英語でのバグレポートの書き方
3月 21, 2012タイムラインに流れてきたこのリンク先の記事を見て下記の内容を書き込んだところ、いくつか反応を頂きました。せっかくなので、英語でのバグレポートの書き方について簡単にまとめてみます。ポイントは「英語に頼らずに英語を書く」です。 英語でのバグレポートが難しいという人は、日本語でもレポートが書けてない可能性を考えるべき。フォーマットに従って「現状の動作」「期待される動作」を書いて、後は再現ステップと再現環境を書けば、英語が理由で伝わらないということはあまり無いと思う。バグレポートの文章の大半は固有名詞だし。 3月 21, 2012「問題となっている現状の動作」「期待される動作」「再現手順」を意識して書く 「バグレポートを読む」という意識でいる場合、読み手が期待するのはこの3点だと思います。逆に、この部分が書かれていれば、コミュニケーションを成立させることができます。 「現状の
新社会人のためのバグレポートの基本 - mixi engineer blog
はじめまして、品質管理部門の柿崎です。 最近、Skyrim にハマってしまい、人生一回休みになりかけています。 季節は春ということで、新社会人になられる方も多いと存じます。 新社会人が会社勤めをするようになって、初めて書くビジネス文書といえば...... そうですね！「バグレポート」ですね。 今回はバグレポートの基本について書きたいと思います。 近年、開発現場ではバグトラッキングシステムが定着し、ドッグフーディングのような社内テストを行う現場も増え、テスト担当者以外の方でもバグレポートを提出する機会が増えています。そして前衛的なバグレポートによって、プログラマ達が理不尽かつ不可解なバグ地獄に叩き込まれる機会も増えています。 バグレポートは諸刃の剣です。 良いバグレポートはアプリケーションの問題を速やかに解決まで導きますが、反対にダメなレポートは現場に混乱をもたらします。 良いバグレポートを
小野和俊のブログ:メンテナビリティの高いソースコードを目指して
ソフトウェアを中長期にわたってメンテナンスしていく場合、メンテナンスしやすいコードと、メンテナンスしにくいコードとの間には、同じ機能を実現していたとしても、その価値には雲泥の差があります。 メンテナンスの容易さを示す言葉として、メンテナビリティ(Maintainability)という言葉がありますが、私自身、アプレッソでDataSpiderを11年間開発・メンテナンスしていく中で、「この人の書いたコードは本当にわかりやすいし無駄がない」とメンテナビリティの高いソースコードに感心させられることもあれば、「急いでいたとはいえ、このソースコードはリファクタリングしないと・・・」と、メンテナビリティの低いコードがソフトウェアに混入してしまったことを嘆くこともありました。 このエントリでは、一本のソフトウェアを11年間開発・メンテナンスしてきた経験から、ソフトウェアのメンテナビリティについて考察して
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
変化の時代で勝つための開発組織のあり方 2011 12-22
This document introduces Aiming, a startup founded in 2011 by Toshiaki Katayama. It previously worked on Community Engine from 2001-2003 and Play Online China from 2003-2007. Aiming focuses on building online and mobile games using technologies like HTML5, Unity, Ruby on Rails and Flash. It aims to create fun and social games and uses agile practices like Git and continuous integration. The compan
「開発チームを改善するためのスクラムTips」についてのあれやこれや - kawaguti’s diary
今年始めさせていただいた事の一つは、エンジニアライフさんでちょこっと連載を始めた、「開発チームを改善するためのスクラムTips」です。 ３月くらいからスクラムについてなにか書く、というお題をいただいていたのだけれど、私にどのようなことが書けるのか、全く思いもよらず、のらりくらりとかわしてました。 「スクラムギャザリング東京」だとか「Scrum Boot Camp」という企画をみんなでわいわいと進める過程で、これからスクラムを始める人に、どういった事を話したらいいか、ということに考えを巡らせる事が多くなって、うーん、そうか、こういう風に言ったら通じやすいのかな、というポイントに、自分なりに気付く点があったので、そういう事を、ひとつひとつ文にしていったらいいのかな、という風に思うようになりました。 そこで、夏くらいに正式にお話をお受けする事にし、秋からの連載スタートとなりました。 開発チームを
トランザクションデータ（とマスターデータ）について思うところ - 急がば回れ、選ぶなら近道
業務系のデータ処理では、大きくはトランザクションとマスターに分かれる。 マスターデータは特に、モデルや制御の方法が何かと面倒くさいので、よく議論になる。「マスターデータの管理の手法」というセミナーまで定期的に普通に開かれることも多い。他方、トランザクションデータ（以下TXデータ）は、普通に受け渡しのデータなので、フラットにダラダラ書いておけばよい、という扱いが大抵になる。そもそもER志向でモデルを設計すると、ほとんどは図面はマスターで占められ、TXデータはやたらなんか大量のフィールドを持つ大きなクラスがあるわいね、という扱いも多い。 あと、設計の観点からいうと、ERベースだとマスター設計が花形になる。まぁわかりやすいし、設計作業がしやすい。マスターは「構造」になり、TXデータは「構造」になりにくい。設計者は「構造」が好きだ。良くできた設計は確かに堅牢で、一定の変化にも追随できる。ある種の「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散開発
"費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた
