voluntas · April 16, 2024 13:29 · Apr 16, 2024 · Apr 16, 2024 · Mar 29, 2019 · Feb 28, 2016
diff --git a/shiguredo_development_policy.rst b/shiguredo_development_policy.rst
@@ -1,145 +1 @@
-######################
-時雨堂を支える開発方針
-######################
-
-:日時: 2024-04-16
-:作: 時雨堂
-:バージョン: 2024.1
-:URL: https://shiguredo.jp/
-
-概要
-====
-
-**銀の弾丸はない**
-
-複数の自社製品開発を同時に走らせる事になったので、書き出してみた
-
-前提
-====
-
-**必要なタイミングで必要なリソースを投入する**
-
-- @voluntas が全ての製品責任者
-- 関わっている技術者は全員でも 10 人程度
-- 全員が開発と設計と検証を担当
-- それぞれの製品は依存性がある
-
-信頼
-====
-
-一緒に作業する相手を信頼する、信頼できない人と仕事なんかできない。
-
-Issue
-======
-
-すぐに GitHub Issue を切る。
-レビューを定期的に行い不要なら削除する。
-
-削除するときはコメントを付けておくと、他の人がなぜ不要なのかわかる。
-
-コーディング規約
-================
-
-技術に明るい人に決めてもらう。好み問題は作業者優先。
-
-フォーマッターやリンターを積極的に導入する。
-
-ドキュメントドリブン
-==========================
-
-基本的に期限は決めず、ドキュメントを先に書いてそれに沿って機能開発をする。
-年 2 回のリリースサイクルに間に合わなければスキップする。
-
-思想の共有
-==========
-
-なぜその製品を開発するのかという理由を説明する。
-利益なのか宣伝なのか、挑戦なのか興味なのか。その製品の立ち位置を明確に伝えておく。
-
-設計
-====
-
-**設計者と開発者は同じとする**
-
-- 基本設計は製品管理者がすべて担当する
-- 詳細設計は担当者が判断する
-
-担当者が製品管理者が出した基本設計書に基づき設計を行う。
-
-セルフレビュー重視
-==========================
-
-短期間で製品開発を回していく場合は、セルフレビューを徹底的に行うのが良い。
-セルフレビューなしで進めてうまくいった経験がない。
-
-相談
-====
-
-とにかく困ったら考え込まずに相談する。相談相手は誰でもいい。言語関係なく相談する。
-ここでの相談は技術的な相談が主になる。
-
-一人開発
-========
-
-小規模開発の場合は複数人数より一人で開発した方が早い。
-
-それぞれ単独で開発を行う。ほかのメンバーとの疎通はドキュメントとレビューで行う。
-
-機能を減らす
-============
-
-技術または時間的に無理なら実装しないという選択を取れ。
-ただし、個人で判断せず相談しろ。
-
-コードファースト
-================
-
-まず手を動かして動くモノを作って見せてみる。悩むより動くコード。
-
-手を動かさずに悩むな。
-
-全員参加
-============
-
-とにかく自分の主担当以外でも積極的に口を出す。言語やフロント、サーバ関係ない。
-
-リライト
-========
-
-できるだけ最新の自分が良いと思う技術を使うこと。
-それが古くなったのならすべて書き換えるという考えで開発する。
-
-儲からなければ捨てれば良いし、儲かったのなら余裕があるはずだから書き直せば良い。
-
-新しい技術を使うことは開発者を成長させる。問題が起きたら解決すれば良い。
-
-定例
-====
-
-基本なし。必要あれば集まる。Slack と Trello で事足りる。
-会議は時間の無駄。決めるのがツライ場合は製品管理者が決めて、責任取るので良い。
-
-ライブラリ選定
-==============
-
-担当者が好きに選定して良い。ただし選定責任は持つこと。
-必要な OSS への貢献は製品開発の作業と見なす。
-
-テスト
-======
-
-最小限でよい。利益を出せるようになってから充実させていけば良い。
-基本はエンドツーエンドテストにすること。
-
-
-参考
-====
-
-- `時雨堂コトハジメ <https://gist.github.com/voluntas/8183054>`_
-- `時雨堂を支える技術 <https://gist.github.com/voluntas/6308998>`_
-- `時雨堂を支える環境 <https://gist.github.com/voluntas/6333304>`_
-- `時雨堂を支える採用 <https://gist.github.com/voluntas/9306271>`_
-- `時雨堂を支える食堂 <https://gist.github.com/voluntas/565dce2e7fd803a61340>`_
-- `時雨堂を支える製品戦略 <https://gist.github.com/voluntas/a0d15830ef0ac55ed46e>`_
-- `時雨堂を支える開発方針 <https://gist.github.com/voluntas/cb7158f9813f9d7fed34>`_
-- `評価制度の無い評価制度 <https://gist.github.com/voluntas/4f90a626adae624d8c23>`_
+現状と大きく変わったのでいったん削除しました。
diff --git a/shiguredo_development_policy.rst b/shiguredo_development_policy.rst
@@ -2,9 +2,9 @@
 時雨堂を支える開発方針
 ######################
 
-:日時: 2019-03-29
+:日時: 2024-04-16
 :作: 時雨堂
-:バージョン: 19.3.0
+:バージョン: 2024.1
 :URL: https://shiguredo.jp/
 
 概要
@@ -19,42 +19,36 @@
 
 **必要なタイミングで必要なリソースを投入する**
 
-- 自社ミドルウェア製品については @voluntas が全ての製品責任者
-- OSS やについては技術者全員が製品責任者
-- 関わっている技術者は全員でも 10 人いかない
-- 全員が開発と設計を担当
+- @voluntas が全ての製品責任者
+- 関わっている技術者は全員でも 10 人程度
+- 全員が開発と設計と検証を担当
 - それぞれの製品は依存性がある
 
 信頼
 ====
 
 一緒に作業する相手を信頼する、信頼できない人と仕事なんかできない。
 
-タスク
+Issue
 ======
 
-タスクが振ってきたらすぐにカードを切る。
+すぐに GitHub Issue を切る。
 レビューを定期的に行い不要なら削除する。
 
 削除するときはコメントを付けておくと、他の人がなぜ不要なのかわかる。
 
-範囲
-====
-
-余裕があるからと行って勝手に相手の仕事の範囲まで入らない、もし入る場合はまずは皆に相談する。
-
 コーディング規約
 ================
 
 技術に明るい人に決めてもらう。好み問題は作業者優先。
 
-ロードマップドリブン
-====================
+フォーマッターやリンターを積極的に導入する。
 
-動くところまでの期限をまず決める。
-動いたらあとは細かくロードマップを決定しそれに沿って開発する。
+ドキュメントドリブン
+==========================
 
-ロードマップ自体は製品管理者が引く。
+基本的に期限は決めず、ドキュメントを先に書いてそれに沿って機能開発をする。
+年 2 回のリリースサイクルに間に合わなければスキップする。
 
 思想の共有
 ==========
@@ -72,45 +66,24 @@
 
 担当者が製品管理者が出した基本設計書に基づき設計を行う。
 
-レビュー重視
-============
-
-短期間で製品開発を回していく場合は、レビューを入れるのが一番効率が良い。
-レビューなしで進めてうまくいった経験がない。
-
-特に連携をとる必要がある場合はレビューを中心として議論するのが早い。
-
-外部の目
-========
+セルフレビュー重視
+==========================
 
-今回は社外のメンバーも製品開発に参加している。
-社外メンバーはレビューを中心に入ってもらっている。
-社内だけでは気づけないことは多い。
+短期間で製品開発を回していく場合は、セルフレビューを徹底的に行うのが良い。
+セルフレビューなしで進めてうまくいった経験がない。
 
 相談
 ====
 
 とにかく困ったら考え込まずに相談する。相談相手は誰でもいい。言語関係なく相談する。
 ここでの相談は技術的な相談が主になる。
 
-製品開発の方針的な相談は製品管理者にするというルールにした。
-
 一人開発
 ========
 
-複数人数で実装するのではなく、担当を製品単位で分けた。
-また、製品開発の中でもフロントとサーバで分けた。
-
 小規模開発の場合は複数人数より一人で開発した方が早い。
 
 それぞれ単独で開発を行う。ほかのメンバーとの疎通はドキュメントとレビューで行う。
-主に API がメインになるので API のドキュメントを共有することを重視した。
-
-期限優先
-========
-
-期限が最優先。その期限までに品質が達成できない場合は機能を減らせ。
-そもそも無理なら、期限を切っている製品管理者が悪いので、リリース時期の変更が必要。
 
 機能を減らす
 ============
@@ -125,15 +98,10 @@
 
 手を動かさずに悩むな。
 
-全員レビュー
+全員参加
 ============
 
-とにかく自分の担当以外の範囲でもレビューに参加する。言語やフロント、サーバ関係ない。
-自社製品なんだからすべてを把握するべき。
-
-会社の方針としてそれほど大きく複雑なサービスは自社では作らない。
-
-レビューイーはレビューワーを育てる必要がある。
+とにかく自分の主担当以外でも積極的に口を出す。言語やフロント、サーバ関係ない。
 
 リライト
 ========
@@ -175,4 +143,3 @@
 - `時雨堂を支える製品戦略 <https://gist.github.com/voluntas/a0d15830ef0ac55ed46e>`_
 - `時雨堂を支える開発方針 <https://gist.github.com/voluntas/cb7158f9813f9d7fed34>`_
 - `評価制度の無い評価制度 <https://gist.github.com/voluntas/4f90a626adae624d8c23>`_
-
diff --git a/shiguredo_development_policy.rst b/shiguredo_development_policy.rst
@@ -2,27 +2,26 @@
 時雨堂を支える開発方針
 ######################
 
-:日時: 2016-02-28
+:日時: 2019-03-29
 :作: 時雨堂
-:バージョン: 0.2.1
-:URL: http://shiguredo.jp/
+:バージョン: 19.3.0
+:URL: https://shiguredo.jp/
 
 概要
 ====
 
 **銀の弾丸はない**
 
-複数の自社製品開発を同時に走らせる事になったので、自分の考えを書き出してみた。
+複数の自社製品開発を同時に走らせる事になったので、書き出してみた
 
 前提
 ====
 
 **必要なタイミングで必要なリソースを投入する**
 
-- サーバ製品については @voluntas が全ての製品管理者を担当する
-- サービスについては社員が製品管理者を担当する
-- OSS 製品については主に社外のメンバーで開発を担当する
-- 参加メンバーは 1 桁
+- 自社ミドルウェア製品については @voluntas が全ての製品責任者
+- OSS やについては技術者全員が製品責任者
+- 関わっている技術者は全員でも 10 人いかない
 - 全員が開発と設計を担当
 - それぞれの製品は依存性がある
 
@@ -176,3 +175,4 @@
 - `時雨堂を支える製品戦略 <https://gist.github.com/voluntas/a0d15830ef0ac55ed46e>`_
 - `時雨堂を支える開発方針 <https://gist.github.com/voluntas/cb7158f9813f9d7fed34>`_
 - `評価制度の無い評価制度 <https://gist.github.com/voluntas/4f90a626adae624d8c23>`_
+
diff --git a/shiguredo_development_policy.rst b/shiguredo_development_policy.rst
@@ -4,7 +4,7 @@
 
 :日時: 2016-02-28
 :作: 時雨堂
-:バージョン: 0.2.0
+:バージョン: 0.2.1
 :URL: http://shiguredo.jp/
 
 概要
@@ -21,6 +21,7 @@
 
 - サーバ製品については @voluntas が全ての製品管理者を担当する
 - サービスについては社員が製品管理者を担当する
+- OSS 製品については主に社外のメンバーで開発を担当する
 - 参加メンバーは 1 桁
 - 全員が開発と設計を担当
 - それぞれの製品は依存性がある

diff --git a/shiguredo_development_policy.rst b/shiguredo_development_policy.rst
@@ -2,9 +2,9 @@
 時雨堂を支える開発方針
 ######################
 
-:日時: 2015-12-07
+:日時: 2016-02-28
 :作: 時雨堂
-:バージョン: 0.1.0
+:バージョン: 0.2.0
 :URL: http://shiguredo.jp/
 
 概要
@@ -19,8 +19,8 @@
 
 **必要なタイミングで必要なリソースを投入する**
 
-- @voluntas が全ての製品管理者を担当する
-- 数ヶ月の短期間
+- サーバ製品については @voluntas が全ての製品管理者を担当する
+- サービスについては社員が製品管理者を担当する
 - 参加メンバーは 1 桁
 - 全員が開発と設計を担当
 - それぞれの製品は依存性がある
@@ -175,4 +175,3 @@
 - `時雨堂を支える製品戦略 <https://gist.github.com/voluntas/a0d15830ef0ac55ed46e>`_
 - `時雨堂を支える開発方針 <https://gist.github.com/voluntas/cb7158f9813f9d7fed34>`_
 - `評価制度の無い評価制度 <https://gist.github.com/voluntas/4f90a626adae624d8c23>`_
-
diff --git a/shiguredo_development_policy.rst b/shiguredo_development_policy.rst
@@ -2,16 +2,11 @@
 時雨堂を支える開発方針
 ######################
 
-:日時: 2015-11-07
+:日時: 2015-12-07
 :作: 時雨堂
-:バージョン: 0.0.0
+:バージョン: 0.1.0
 :URL: http://shiguredo.jp/
 
-- `時雨堂コトハジメ <https://gist.github.com/voluntas/8183054>`_
-- `時雨堂を支える環境 <https://gist.github.com/voluntas/6333304>`_
-- `時雨堂を支える採用 <https://gist.github.com/voluntas/9306271>`_
-- `時雨堂を支える製品戦略 <https://gist.github.com/voluntas/a0d15830ef0ac55ed46e>`_
-
 概要
 ====
 
@@ -30,6 +25,29 @@
 - 全員が開発と設計を担当
 - それぞれの製品は依存性がある
 
+信頼
+====
+
+一緒に作業する相手を信頼する、信頼できない人と仕事なんかできない。
+
+タスク
+======
+
+タスクが振ってきたらすぐにカードを切る。
+レビューを定期的に行い不要なら削除する。
+
+削除するときはコメントを付けておくと、他の人がなぜ不要なのかわかる。
+
+範囲
+====
+
+余裕があるからと行って勝手に相手の仕事の範囲まで入らない、もし入る場合はまずは皆に相談する。
+
+コーディング規約
+================
+
+技術に明るい人に決めてもらう。好み問題は作業者優先。
+
 ロードマップドリブン
 ====================
 
@@ -144,3 +162,17 @@
 
 最小限でよい。利益を出せるようになってから充実させていけば良い。
 基本はエンドツーエンドテストにすること。
+
+
+参考
+====
+
+- `時雨堂コトハジメ <https://gist.github.com/voluntas/8183054>`_
+- `時雨堂を支える技術 <https://gist.github.com/voluntas/6308998>`_
+- `時雨堂を支える環境 <https://gist.github.com/voluntas/6333304>`_
+- `時雨堂を支える採用 <https://gist.github.com/voluntas/9306271>`_
+- `時雨堂を支える食堂 <https://gist.github.com/voluntas/565dce2e7fd803a61340>`_
+- `時雨堂を支える製品戦略 <https://gist.github.com/voluntas/a0d15830ef0ac55ed46e>`_
+- `時雨堂を支える開発方針 <https://gist.github.com/voluntas/cb7158f9813f9d7fed34>`_
+- `評価制度の無い評価制度 <https://gist.github.com/voluntas/4f90a626adae624d8c23>`_
+
diff --git a/shiguredo_ development_policy.rst → shiguredo_development_policy.rst b/shiguredo_ development_policy.rst → shiguredo_development_policy.rst
@@ -30,6 +30,14 @@
 - 全員が開発と設計を担当
 - それぞれの製品は依存性がある
 
+ロードマップドリブン
+====================
+
+動くところまでの期限をまず決める。
+動いたらあとは細かくロードマップを決定しそれに沿って開発する。
+
+ロードマップ自体は製品管理者が引く。
+
 思想の共有
 ==========
 
@@ -41,10 +49,10 @@
 
 **設計者と開発者は同じとする**
 
-- 基本設計は @voluntas がすべて担当する
+- 基本設計は製品管理者がすべて担当する
 - 詳細設計は担当者が判断する
 
-担当者が @voluntas が出した基本設計書に基づき設計を行う。
+担当者が製品管理者が出した基本設計書に基づき設計を行う。
 
 レビュー重視
 ============
@@ -67,7 +75,7 @@
 とにかく困ったら考え込まずに相談する。相談相手は誰でもいい。言語関係なく相談する。
 ここでの相談は技術的な相談が主になる。
 
-製品開発の方針的な相談は @voluntas にするというルールにした。
+製品開発の方針的な相談は製品管理者にするというルールにした。
 
 一人開発
 ========
@@ -84,7 +92,7 @@
 ========
 
 期限が最優先。その期限までに品質が達成できない場合は機能を減らせ。
-そもそも無理なら、期限を切っている @voluntas が悪いので、リリース時期の変更が必要。
+そもそも無理なら、期限を切っている製品管理者が悪いので、リリース時期の変更が必要。
 
 機能を減らす
 ============
@@ -123,7 +131,7 @@
 ====
 
 基本なし。必要あれば集まる。Slack と Trello で事足りる。
-会議は時間の無駄。決めるのがツライ場合は @voluntas が決めて、責任取るので良い。
+会議は時間の無駄。決めるのがツライ場合は製品管理者が決めて、責任取るので良い。
 
 ライブラリ選定
 ==============

diff --git a/shiguredo_ development_policy.rst b/shiguredo_ development_policy.rst
@@ -22,6 +22,8 @@
 前提
 ====
 
+**必要なタイミングで必要なリソースを投入する**
+
 - @voluntas が全ての製品管理者を担当する
 - 数ヶ月の短期間
 - 参加メンバーは 1 桁

diff --git a/shiguredo_develop.rst → shiguredo_ development_policy.rst b/shiguredo_develop.rst → shiguredo_ development_policy.rst
diff --git a/shiguredo_develop.rst b/shiguredo_develop.rst
@@ -1,6 +1,6 @@
-############################
-時雨堂を支えるプロダクト開発
-############################
+######################
+時雨堂を支える開発方針
+######################
 
 :日時: 2015-11-07
 :作: 時雨堂
@@ -17,21 +17,22 @@
 
 **銀の弾丸はない**
 
-複数の関係するプロジェクトを同時に走らせる事になったので、自分の考えを書き出してみた。
+複数の自社製品開発を同時に走らせる事になったので、自分の考えを書き出してみた。
 
 前提
 ====
 
+- @voluntas が全ての製品管理者を担当する
 - 数ヶ月の短期間
 - 参加メンバーは 1 桁
 - 全員が開発と設計を担当
-- プロジェクトはそれぞれ依存関係にある
+- それぞれの製品は依存性がある
 
 思想の共有
 ==========
 
-なぜそのプロジェクトをやるのかという理由を説明する。
-利益なのか宣伝なのか、挑戦なのか興味なのか。そのプロジェクトの立ち位置を明確に伝えておく。
+なぜその製品を開発するのかという理由を説明する。
+利益なのか宣伝なのか、挑戦なのか興味なのか。その製品の立ち位置を明確に伝えておく。
 
 設計
 ====
@@ -46,15 +47,15 @@
 レビュー重視
 ============
 
-短期間でプロジェクトを回していく場合は、レビューを入れるのが一番効率が良い。
+短期間で製品開発を回していく場合は、レビューを入れるのが一番効率が良い。
 レビューなしで進めてうまくいった経験がない。
 
 特に連携をとる必要がある場合はレビューを中心として議論するのが早い。
 
 外部の目
 ========
 
-今回は社外のメンバーもプロジェクトに参加している。
+今回は社外のメンバーも製品開発に参加している。
 社外メンバーはレビューを中心に入ってもらっている。
 社内だけでは気づけないことは多い。
 
@@ -64,15 +65,15 @@
 とにかく困ったら考え込まずに相談する。相談相手は誰でもいい。言語関係なく相談する。
 ここでの相談は技術的な相談が主になる。
 
-プロジェクトの方針的な相談は @voluntas に相談するというルールにした。
+製品開発の方針的な相談は @voluntas にするというルールにした。
 
 一人開発
 ========
 
-複数人数で実装するのではなく、担当をプロジェクト単位で分けた。
-また、プロジェクトの中でもフロントとサーバで分けた。
+複数人数で実装するのではなく、担当を製品単位で分けた。
+また、製品開発の中でもフロントとサーバで分けた。
 
-小規模開発は複数人数より一人で開発した方が早い。
+小規模開発の場合は複数人数より一人で開発した方が早い。
 
 それぞれ単独で開発を行う。ほかのメンバーとの疎通はドキュメントとレビューで行う。
 主に API がメインになるので API のドキュメントを共有することを重視した。
@@ -126,8 +127,10 @@
 ==============
 
 担当者が好きに選定して良い。ただし選定責任は持つこと。
+必要な OSS への貢献は製品開発の作業と見なす。
 
 テスト
 ======
 
-最小限で、エンドツーエンドテストにすること。
+最小限でよい。利益を出せるようになってから充実させていけば良い。
+基本はエンドツーエンドテストにすること。
diff --git a/shiguredo_project.rst → shiguredo_develop.rst b/shiguredo_project.rst → shiguredo_develop.rst
@@ -1,6 +1,6 @@
-##############################
-時雨堂を支えるプロジェクト管理
-##############################
+############################
+時雨堂を支えるプロダクト開発
+############################
 
 :日時: 2015-11-07
 :作: 時雨堂

diff --git a/shiguredo_project.rst b/shiguredo_project.rst
@@ -22,9 +22,9 @@
 前提
 ====
 
-- 1 ヶ月の短期間
-- メンバーは一桁
-- 全員が開発と設計が可能
+- 数ヶ月の短期間
+- 参加メンバーは 1 桁
+- 全員が開発と設計を担当
 - プロジェクトはそれぞれ依存関係にある
 
 思想の共有
@@ -54,7 +54,8 @@
 外部の目
 ========
 
-今回は社外のメンバーもプロジェクトに参加している。社外メンバーはレビューを中心に入ってもらっている。
+今回は社外のメンバーもプロジェクトに参加している。
+社外メンバーはレビューを中心に入ってもらっている。
 社内だけでは気づけないことは多い。
 
 相談
@@ -120,3 +121,13 @@
 
 基本なし。必要あれば集まる。Slack と Trello で事足りる。
 会議は時間の無駄。決めるのがツライ場合は @voluntas が決めて、責任取るので良い。
+
+ライブラリ選定
+==============
+
+担当者が好きに選定して良い。ただし選定責任は持つこと。
+
+テスト
+======
+
+最小限で、エンドツーエンドテストにすること。
diff --git a/shiguredo_project.rst b/shiguredo_project.rst
@@ -0,0 +1,122 @@
+##############################
+時雨堂を支えるプロジェクト管理
+##############################
+
+:日時: 2015-11-07
+:作: 時雨堂
+:バージョン: 0.0.0
+:URL: http://shiguredo.jp/
+
+- `時雨堂コトハジメ <https://gist.github.com/voluntas/8183054>`_
+- `時雨堂を支える環境 <https://gist.github.com/voluntas/6333304>`_
+- `時雨堂を支える採用 <https://gist.github.com/voluntas/9306271>`_
+- `時雨堂を支える製品戦略 <https://gist.github.com/voluntas/a0d15830ef0ac55ed46e>`_
+
+概要
+====
+
+**銀の弾丸はない**
+
+複数の関係するプロジェクトを同時に走らせる事になったので、自分の考えを書き出してみた。
+
+前提
+====
+
+- 1 ヶ月の短期間
+- メンバーは一桁
+- 全員が開発と設計が可能
+- プロジェクトはそれぞれ依存関係にある
+
+思想の共有
+==========
+
+なぜそのプロジェクトをやるのかという理由を説明する。
+利益なのか宣伝なのか、挑戦なのか興味なのか。そのプロジェクトの立ち位置を明確に伝えておく。
+
+設計
+====
+
+**設計者と開発者は同じとする**
+
+- 基本設計は @voluntas がすべて担当する
+- 詳細設計は担当者が判断する
+
+担当者が @voluntas が出した基本設計書に基づき設計を行う。
+
+レビュー重視
+============
+
+短期間でプロジェクトを回していく場合は、レビューを入れるのが一番効率が良い。
+レビューなしで進めてうまくいった経験がない。
+
+特に連携をとる必要がある場合はレビューを中心として議論するのが早い。
+
+外部の目
+========
+
+今回は社外のメンバーもプロジェクトに参加している。社外メンバーはレビューを中心に入ってもらっている。
+社内だけでは気づけないことは多い。
+
+相談
+====
+
+とにかく困ったら考え込まずに相談する。相談相手は誰でもいい。言語関係なく相談する。
+ここでの相談は技術的な相談が主になる。
+
+プロジェクトの方針的な相談は @voluntas に相談するというルールにした。
+
+一人開発
+========
+
+複数人数で実装するのではなく、担当をプロジェクト単位で分けた。
+また、プロジェクトの中でもフロントとサーバで分けた。
+
+小規模開発は複数人数より一人で開発した方が早い。
+
+それぞれ単独で開発を行う。ほかのメンバーとの疎通はドキュメントとレビューで行う。
+主に API がメインになるので API のドキュメントを共有することを重視した。
+
+期限優先
+========
+
+期限が最優先。その期限までに品質が達成できない場合は機能を減らせ。
+そもそも無理なら、期限を切っている @voluntas が悪いので、リリース時期の変更が必要。
+
+機能を減らす
+============
+
+技術または時間的に無理なら実装しないという選択を取れ。
+ただし、個人で判断せず相談しろ。
+
+コードファースト
+================
+
+まず手を動かして動くモノを作って見せてみる。悩むより動くコード。
+
+手を動かさずに悩むな。
+
+全員レビュー
+============
+
+とにかく自分の担当以外の範囲でもレビューに参加する。言語やフロント、サーバ関係ない。
+自社製品なんだからすべてを把握するべき。
+
+会社の方針としてそれほど大きく複雑なサービスは自社では作らない。
+
+レビューイーはレビューワーを育てる必要がある。
+
+リライト
+========
+
+できるだけ最新の自分が良いと思う技術を使うこと。
+それが古くなったのならすべて書き換えるという考えで開発する。
+
+儲からなければ捨てれば良いし、儲かったのなら余裕があるはずだから書き直せば良い。
+
+新しい技術を使うことは開発者を成長させる。問題が起きたら解決すれば良い。
+
+定例
+====
+
+基本なし。必要あれば集まる。Slack と Trello で事足りる。
+会議は時間の無駄。決めるのがツライ場合は @voluntas が決めて、責任取るので良い。