| 日時: | 2019-03-29 |
|---|---|
| 作: | 時雨堂 |
| バージョン: | 19.3.0 |
| URL: | https://shiguredo.jp/ |
銀の弾丸はない
複数の自社製品開発を同時に走らせる事になったので、書き出してみた
必要なタイミングで必要なリソースを投入する
- 自社ミドルウェア製品については @voluntas が全ての製品責任者
- OSS やについては技術者全員が製品責任者
- 関わっている技術者は全員でも 10 人いかない
- 全員が開発と設計を担当
- それぞれの製品は依存性がある
一緒に作業する相手を信頼する、信頼できない人と仕事なんかできない。
タスクが振ってきたらすぐにカードを切る。 レビューを定期的に行い不要なら削除する。
削除するときはコメントを付けておくと、他の人がなぜ不要なのかわかる。
余裕があるからと行って勝手に相手の仕事の範囲まで入らない、もし入る場合はまずは皆に相談する。
技術に明るい人に決めてもらう。好み問題は作業者優先。
動くところまでの期限をまず決める。 動いたらあとは細かくロードマップを決定しそれに沿って開発する。
ロードマップ自体は製品管理者が引く。
なぜその製品を開発するのかという理由を説明する。 利益なのか宣伝なのか、挑戦なのか興味なのか。その製品の立ち位置を明確に伝えておく。
設計者と開発者は同じとする
- 基本設計は製品管理者がすべて担当する
- 詳細設計は担当者が判断する
担当者が製品管理者が出した基本設計書に基づき設計を行う。
短期間で製品開発を回していく場合は、レビューを入れるのが一番効率が良い。 レビューなしで進めてうまくいった経験がない。
特に連携をとる必要がある場合はレビューを中心として議論するのが早い。
今回は社外のメンバーも製品開発に参加している。 社外メンバーはレビューを中心に入ってもらっている。 社内だけでは気づけないことは多い。
とにかく困ったら考え込まずに相談する。相談相手は誰でもいい。言語関係なく相談する。 ここでの相談は技術的な相談が主になる。
製品開発の方針的な相談は製品管理者にするというルールにした。
複数人数で実装するのではなく、担当を製品単位で分けた。 また、製品開発の中でもフロントとサーバで分けた。
小規模開発の場合は複数人数より一人で開発した方が早い。
それぞれ単独で開発を行う。ほかのメンバーとの疎通はドキュメントとレビューで行う。 主に API がメインになるので API のドキュメントを共有することを重視した。
期限が最優先。その期限までに品質が達成できない場合は機能を減らせ。 そもそも無理なら、期限を切っている製品管理者が悪いので、リリース時期の変更が必要。
技術または時間的に無理なら実装しないという選択を取れ。 ただし、個人で判断せず相談しろ。
まず手を動かして動くモノを作って見せてみる。悩むより動くコード。
手を動かさずに悩むな。
とにかく自分の担当以外の範囲でもレビューに参加する。言語やフロント、サーバ関係ない。 自社製品なんだからすべてを把握するべき。
会社の方針としてそれほど大きく複雑なサービスは自社では作らない。
レビューイーはレビューワーを育てる必要がある。
できるだけ最新の自分が良いと思う技術を使うこと。 それが古くなったのならすべて書き換えるという考えで開発する。
儲からなければ捨てれば良いし、儲かったのなら余裕があるはずだから書き直せば良い。
新しい技術を使うことは開発者を成長させる。問題が起きたら解決すれば良い。
基本なし。必要あれば集まる。Slack と Trello で事足りる。 会議は時間の無駄。決めるのがツライ場合は製品管理者が決めて、責任取るので良い。
担当者が好きに選定して良い。ただし選定責任は持つこと。 必要な OSS への貢献は製品開発の作業と見なす。
最小限でよい。利益を出せるようになってから充実させていけば良い。 基本はエンドツーエンドテストにすること。