スタートアップの現場で役立つ開発要件のまとめ方
こんにちは。ハウスマートの高松(@t2kmt)です。 皆さんは開発要件をまとめるのにどんなフォーマットを使っていますか？ 開発要件をいい感じにまとめるのって大変ですよね。 ドキュメント整備せずに開発に着手し始めてしまうと手戻り抜け漏れが出てしまいますが、一方で要件定義書をガチガチなフォーマットにするとドキュメントの作成自体の工数が増えてしまいます。 スタートアップはスピードが命。ドキュメントを書きまくって開発が進まないなんて言語道断です。 開発要件の整理はプロジェクトの成否に多大なインパクトを与えますが、ほとんどの現場では企画を考える人にフォーマットが委ねられていることが多いと思います。 今回は皆さんが快適に開発要件をまとめられるように、ハウスマートで利用している mini spec というフォーマットをご紹介します。 mini spec とは mini spec とは開発の要件をまとめる
OSSを読んでAirbnbのホーム画面の実装を想像してみた
OSSを読んで調査しながら、手を動かしているうちに出来上がったのがこちらです。 はじめに AirbnbのiOSアプリの実装に興味が沸いたのですが、Airbnbのソースを直接読むこともできません。そこで、似たような動作を実現しているOSSから内部実装を推測して自分でも書いてみることにしました。事前に調査したところ、既に似たようなことを考えている方がいて、大いに参考にさせて頂きました。感謝です。 今回の記事は、私が調査して気づいたことを再度整理した、という位置付けです。 これ以降の記述は下記のような読者を想定して書いていますので、ご承知おき下さい。 m(_ _)m iPhoneアプリ開発の経験は多少あるけれどもUIの実装は苦手 著名なアプリの実装に興味がある 画面の構成 TableViewが縦のスクロールを担い、各ジャンルのリストを横にスクロールしていく部分はTableViewの各rowの中に
会社の本番環境をDocker(ECS)に置き換えるために準備したこと気づいたこと
エンジニアの@macs_6です。 このブログでは社内のAWS EC2上で運用しているアプリケーション群をECS移行したプロジェクトについて紹介します。 ローカルの開発環境をDockerした話は以前の記事(複数の rails プロジェクトが共存する開発環境を Docker 化した話を晒してみる)で西辻が紹介しているので、そちらを参照して下さい。 概要 プロジェクトを始める前に感じていた課題 目指す状態 ECSを選択する理由 設計 移行のために必要な作業 Digdagによるスケジューリングについて ECSを使って見て気づいたこと 今後やりたいこと プロジェクトを始める前に感じていた課題 ローカル・本番で再現性のある環境を簡単に作れるようにしたい 簡単にスケールできるようにしたい コストを抑えたい ECS移行プロジェクトを始める前にはこれらの3つの事に課題感を持っていました。 1.ローカル・本番
大きめプロジェクトにスクラムを適用する
こんにちは！Housmartの宮永です。 過去に弊社のスクラム開発について概要をご紹介(スタートアップのCTOになって2ヶ月で作った開発サイクル)させていただきました。 今回はより実践的な話を説明します。 以前紹介しました通り、カウル開発チームは1週間／スプリントと短めに取ってますが、 1週間じゃ収まらないようなサイズのプロジェクトの時はどう管理するの？って話になりますよね。 アジャイルの考え方では、要件を細分化することで1スプリント内に収め、 あくまでスプリント終了時には新機能をお客様に提供しないといけません。 しかし、モノによってはそうもいかないケースも有ります（と思ってます）。 （特に弊社は1週間スプリントですのでザラにあります） そういった複数スプリントを要する規模のプロジェクトに対してスクラムをどう適用させるか弊社の事例とともに紹介します。 プロジェクト背景 まずはプロジェクト背
テレビ放送に向けての負荷対策(AWS x Rails の場合)[前編]
Housmart高松です。 先日、テレビ東京のWBS（ワールドビジネスサテライト）で弊社サービス「カウル」をご紹介いただきました。今回は、その前後でシステムの準備として実施したこと、当日の実際のアクセス数などをご紹介します。 WBSサイト(不動産流通に革新は起こるか): http://txbiz.tv-tokyo.co.jp/wbs/feature/post_107290/ 仲介手数料無料の不動産サイト「カウル」: https://kawlu.com/ 突然のテレビ取材！テレビに出るとどのくらいアクセスが来るの？サーバは何台増やしたらいいの？ そんな時の参考になれば幸いです。 内容 前提 前回の失敗 フロントエンド システム構成 事前準備 負荷予測 サーバ台数決定 サーバ増強 その他 実際のアクセス数と振り返り 1.前提 前回の失敗 つい半月ほど前に別の局で朝の番組にもちらっと社名を出して
![テレビ放送に向けての負荷対策(AWS x Rails の場合)[前編]](https://cdn-ak-scissors.b.st-hatena.com/image/square/af96ae194c704810158251c0810f13bf58c4d796/height=288;version=1;width=512/https%3A%2F%2Fkawlu.com%2Fjournal%2Fwp-content%2Fuploads%2F2016%2F02%2Fd5d5798d67a91b63cee313322be37a5f-1.jpg)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
