チーム開発について
TL;DR
チーム開発することで
- 生産性(生み出した価値/コスト)を上げよう
- 価値のあるものをいち早くリリースできるようにしよう
- 同じクオリティで替えのきくものはコストの低いものに替えよう
- 不要なものは削ろう
この記事の目的
なんでチーム開発するんだっけ?
チーム開発で何を目指すんだっけ?
などのチーム開発に対する考えを整理したく書きました。
個人・チーム関係なく必要なこと
個人・チーム関係なく開発者に求められるものとして
生産性が高いこと
があるはず。
生産性の定義
生産性という曖昧な言葉でなく厳密な定義を確認する
経済学で生産活動に対する生産要素(労働・資本など)の寄与度、あるいは、資源から付加価値を産み出す際の効率の程度のことを指す。 Wikipedia:生産性
寄与度 効率
とあることから生産した量は関係なく、どれだけの価値を出したかということになる。
つまり
生み出した価値 / コスト
ここでいう生み出した価値は最終的には売上ということになる。
その途中の要素としてユーザー満足や会員登録数などのKPIの事とも言えそう。
つまり、価値のあるものをどれだけ早くリリースできるかが重要になってくる。
生産性を上げる要素
早い安い美味いが基本だと思う
- 早い(リードタイムが短い)
- 安い(コストが低い)
- 美味い(生み出す価値が高い)
早い(リードタイムが短い)
リリース(価値を届ける)までが早いこと
安い(コストが低い)
たぶん早いと同じ要素だと思う
美味い(生み出す価値が高い)
- サービス関係
- 機能追加、改善などのリリース
- 技術関係(システムの品質)
- バグ
- セキュリティ
- 可用性、保守性
チーム開発のメリット
個別作業するのに比べて生産性が向上する(はず)(だと思いたい)
重複するものもあるが以下のようなものが考えられる。
チーム開発の手法
チーム開発で生産性を上げる手法としていろいろある。
雑記:最強のチームとは?
sp.22a【ゲスト: kyon_mm】楽しい受託開発現場で作る「世界最高の開発チーム」で出てきた話
ソフトウェア工学の教科書にチームの名前が載る 歴史に名を残す
ここまで高い目標を持っていたら普段からいい仕事ができそう。
心に留めておきたい。
アジャイル開発って何だ
アジャイル開発とは
対話と協調をして、
変化に対応できる開発体制を整え、
価値のあるもの(動くソフトウェア)を作ろうという考え方。
具体的な開発手法ではなく何に価値を置くか。
具体的に重視する価値は以下
- プロセスやツール よりも 個人と対話
- 包括的なドキュメント よりも 動くソフトウェア
- 契約交渉 よりも 顧客との協調
- 計画に従うこと よりも 変化への対応
考え方ってなると若干宗教っぽい🤔
アジャイルの源流
なぜ↑アジャイル開発とは
なのかについて
アジャイルソフトウェア開発宣言という2001年に、アジャイルソフトウェア開発手法の分野において名声のある17人が提唱する重要な部分を統合した文書で以下のように書かれている。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル・プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
具体的な取り組み
この価値を重視し開発を行う上での具体的な取り組みを書きたい。
プロセスやツール < 個人と対話
スクラムで言う所の、スプリントプランニングやデイリースクラムやバックログリファインメントなど。
包括的なドキュメント < 動くソフトウェア
ドキュメントを作らないことではなく、何をすることで価値を提供できるのかということ。
基本的には動くソフトウェアが一番価値を届けるはずなので 包括的なドキュメント < 動くソフトウェア
なっている。
ドキュメントがあることで今後の開発効率が上がったり、ユーザーにとって価値を届けられるのであればドキュメントを作るべきだと思う。
契約交渉 < 顧客との協調
前述と同じ考え方の話だと思うので割愛
計画に従うこと < 変化への対応
変化(問題)に対応できる開発体制を作ること。
- バージョン管理
- テスト自動化
- 継続的インテグレーション
問題に対応する点で言うとスプリントレトロスペクティブなどの振り返りになる。
アジャイル開発の手法
- スクラム
- エクストリーム・プログラミング(XP)
- ユーザー機能駆動開発(FDD)
※ 具体的な手法については省略
参考
1つ目が一番アジャイルの本質や具体的な手法の取り込み方を説明していると思う。
- アジャイルとは何か? ツールと開発手法「スクラム/XP」、ウォーターフォールとの違い
- アジャイルとは何か?今あらためて誤魔化さずに実践的に説明してみる
- アジャイル開発とは?今さら聞けない開発手法のメリット・デメリット
最後に
このアジャイルについての認識・価値観が揃えばチームとしての生産性が上がると思う。
生産性の高い開発チームにしていきたい。
scouty ✕ Goodpatch Engineer MeetUp 〜プロダクト開発との関わり方〜
scouty ✕ Goodpatch Engineer MeetUp 〜プロダクト開発との関わり方〜 で聞いたことメモです。
@g = GoodPatch
@s = Scouty
TL;DR
GoodPatch
- スクラム
- ストーリーポイントはTシャツのサイズ(S,M,L,XL)
- カンバンで運用
- 目標設定はOKR
- 代表が会社OKRを作る→会社KRが部門Oになる→そこから個人にも
- 週次、月次で1on1して目標に対して足りてるのかフィードバック
- 最終的な評価にはOKR、社内外での行動(登壇、誰かの役に立つとか)、エンジニア評価
- エンジニアにどう評価されたいかヒアリングして評価軸を決めた
- サービス、プロダクトへの貢献
- 技術貢献(専門性
Scouty
- 教科書通りのスクラムを実施
- ZenHub利用
- 3ヶ月に1回給与には繋がらないフィードバックのための360°評価している
開発の進め方
ZenHub使って管理@s スプリントMTGでプランニングポーカー@s ベロシティと残業時間も計測している@s 逆算して開発以外の時間を割いてしまったのか見てる@s
カンバンでアナログにやっている@g 開発のカンバン、デザインのカンバン等分けてる@g ストーリーポイントはフィボナッチ数じゃなくS,M,L,XL@g 週に何回か改善タイムを設けている@g
デジタルで不便感じてるところは? KPTはホワイトボードに張ってる。KeepはTrelloに移してる@s
KPTでカンバンの改善してる@g マスキングテープで線引とか 剥がし方取り方のレクチャーとか 下に引っ張るか横からか
組織図、開発体制
ホロクラシー(階級のないフラットな組織)、フロント、バック、インフラなど専門職がいる@s
属人性高いと個人が決めた技術選定正しいのかとか、退職のリスクは? メインで持ってるロール以外にバックアップのロールがある@s 複数にまたがる場合は? 複数のロールで話し合ってもらってる@s
ペアプロ、モブプロ試してる@g
スクラムは基本的に多能工が理想だけどホロクラシーだとやりづらいのでは? 基本スキルは全員持っていることが前提なので大丈夫@s 飛び抜けた技術等についての属人化は許容している@s 多能工についてはあまり意識していない、諦めてる@g T字型がいいって言うけど突き抜けてるものもありだと思う@g 多能工ばかりになるとダイバーシティにもならない@g エンジニアチーム全体でいいポートフォリオが出来たら良い@g
採用手法
幹部候補にはリファレンスチェック@g 面接に出るメンバーには面接官トレーニングしてる@g
スキルテストしてる@s
コーディングテストはやってないけど良いサービス出てきてるので試したい@g 口頭でスキルチェックしてる@g
- Jsの言語仕様について
- Reactの実装聞いたり
- ネイティブはこういう時どう実装するか?
- アプリ見せてあなたならどうするか?
リストビューで実装する→データ多かったらどうチューニングする?
評価制度
3ヶ月に1回給与にはつながらないフィードバックのための360°評価している@s まだアイディアだけど1人が5万分持ってて人に送れるとかいいな@s
OKR(半期に1回、3ヶ月で見直し)@g 代表が会社のOKRを作る 会社KRが部門Oになる みたいに掘り下げている@g 週次、月次で1on1して目標にたいして足りてるのかフィードバック@g 最終的な評価にはOKR、社内外での行動(登壇、誰かの役に立つとか)、エンジニア評価@g
GoodPatchのエンジニア評価
ボヤージュのやつを参考にした 1. 評価して欲しい人を選ぶ 2. 評価ドキュメント作成 3. レビュー (ここらへんかな…? GoodPatchのブログ
評価制度だけじゃなく等級グレード、給与の3つを作らないといけない
どう評価されたいかをヒアリングして評価軸を決めた
- サービス、プロダクトへの貢献
- デザインに対する理解と実践
- 提案して採用されたもの
- アニメーションをどう実装していったか
- プロトのデザインを再現できているか
- QCD
- チームへのエンジニアとしての貢献
- プロジェクトの要件や制約条件に対してエンジニアとしてどう対応したか
- デザインに対する理解と実践
- 技術貢献(専門性
- 性能への取り組み
- レスポンス、TAT、FPS、バッテリー、メモリ
- セキュリティ
- リファクタ
- プラットフォーム理解
- 可用性への取り組み
- 保守性への取り組み
- 性能への取り組み
omoiyari.fm #30-1 モブプログラミング、モブライフ を聞いて
omoiyari.fm #30-1 モブプログラミング、モブライフ を聞いてモブプロについて勉強になった箇所をまとめました。
ざっくりいうとモブプロは全員で同じ作業をする。
生産性が下がるのでは?
ペアプロだと2人分の作業が1/2になるのでは…?
モブプロならそれ以上に…?
という声が上がる
そもそも生産性って?
生み出した価値 / コスト
生み出した価値 とは要するにお金
開発チームとしてはリリースできる状態の動くプロダクトのこと
量 / 時間 ではない
並列作業をしたらドキュメントやコードの生産量は増えるが最終的にリリースができる状態(価値を生む)とは限らない。
モブプロでは
モブでやることで作業の同期コストがなくなり、
レビューをする必要がなく、
常にリリース出来る状態になる。
→生産性が高くなる!
モブプロに向く作業 / 向かない作業
課題解決、知識共有、後進育成のためにやっているとのこと。
向く作業
後でチーム全員が知っていると価値があるもの。
問題解決などが向いている。
例えば環境構築
手順書があってもだいたい役に立たない。
手順書はその人の環境でうまくいったパターンの羅列なので意味がないが、
環境を構築するまでの作業・試行錯誤には価値がある。
また、レビューする時に仕様を聞かないとわからないような作業はモブに向いている。
同期コストが大きい作業のことですね。
向かない作業
誰がやっても同じになる作業
同期コストがかからない作業
どれくらいモブプロをやっているの?
その作業に貢献できる人が参加している
別の作業やMTGが会って外れる人は外れていい
最後に
めちゃくちゃモブプロやってみたくなりました👀
Step-to-Rails-Expert.rb#19 に参加しました
Railsの勉強会、Step-to-Rails-Expert.rb#19 に参加してきました!
Step-to-Rails-Expert.rb って?
公式の説明をそのまま…
本勉強会はStep-to-Rails-Expert.rbというRails関連中級者向けの勉強会です。 コンセプトとしては、初心者を抜けたレベルの人が中級者・上級者になる上で、一歩進んだ技術やハマリどころなどを議論形式で共有し、場合によってはともに解決策を考えていけるような勉強会を目指しております。 なお、2017年9月よりExpert-TodoというTodoアプリを各々作って来て参加者同士でレビューし合う企画を実施しております。アプリを作ってきた人だけでなく、そうでない人もレビューの仕方や実装方法などの知見を貯められる企画となっていますので、ぜひご参加ください。
step-to-rails-expert-rb.connpass.com
中級者向けの勉強会!
なんとか初心者からステップアップしたく参加しました👀
感想
今回はTodoアプリのもくもく会でした☁️
環境を作って実装していくはずでしたが、brewの環境がおかしくなってるのかbundle installでコケて環境直してるだけで終わってしまいました…💧
自分の成果としてはほぼゼロでしたが、途中の雑談や懇親会で、できる人達の話を聞いてるだけで勉強になることがいっぱいありました。
トピックス
話していたことをリスト形式でざっと
- データ変更したユーザーを保存しておく方法
- created_by updated_byってカラムを持つのはいいかも
- rails5.2から入ったCurrentAttributesヤバイ
- e2eとか振る舞いさえできれば単体テストいらないんじゃ?
- Custom Copはいいぞ
- RuboCop の実装見るといい
- current_user.posts.create したら異常系でコケる可能性がある
- invalidなレコードが残ってしまう
- 関数型言語勉強するといい
- 破壊するメソッドよくない
- pop shift使わないほうがいい
- after_create はコミットの前なのでメール送信処理とか挟むとsidekiqでnot found になる可能性
- after_commit にしたらupdateでも飛ぶので
on: :create
付けるのをお忘れなく - そもそもフィルターで書かないほうが良い。コントローラのsave後に書いたほうが圧倒的楽
- after_commit にしたらupdateでも飛ぶので
- 「気に入らないコードはapproveしない。こんなコードにapproveした歴史を残したくない」
- 「既存のコードだいたいだめなので」
- ActiveRecord eachで回すならsize、回さないならcountがよい
- bullet 誤検知ある?
- select * のクエリ重いのなんとかしたい
- 5.2から入ったbootsnap 起動が早くなるので良い
- Railsのビュー探索が重い
- SQLの実行待ちが遅いの
- 並列実行できたら早くなる
最後に
できる人達の会話、2,3割くらいしか理解できていなかったと思いますがとても勉強になりました。 つまり、
_人人人人人人人人人人人人人人人人人人_ > Step-to-Rails-Expert.rb はいいぞ <  ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄
ぜひ参加してください