デブサミで僕が話したことの簡単なまとめ
デブサミが 10 周年でした。
残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので
「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。
そこでチームビルディング的な話を話させてもらいました。
資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。
- テストを書け
- 問題を根性で解決するな
- 人を殺す以外なら何やってもいい
- 失敗を引きずるな
個別に補足書いて行きます。
一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに
「手伝ってくれないか？」と言われ合流しました。その後、僕がリーダーになり
今は 15 人前後のチームで動いています。
テストを書け
これは僕がチームに入るときに最初に宣言しました。
「テストを書かないようなプロダクトだったら俺はやらないよ」と
そこでその時のリーダーにも「もちろんだ、むしろ推進してくれ！」と言われたので
合流してまず最初に jenkins を立ち上げ、trac に
「テストを書かない奴は屑だ！テストを書く奴はよく訓練された屑だ！」by リーダー名
と書きました。
突然合流したエンジニアよりリーダーが言ったほうがいいだろうなぁと思って勝手にリーダーの名前で書きました。
それ以降、チームではテストは絶対になっています。
jenkins が赤かったら絶対にリリースさせない環境になっています。
それはエンジニア全員がその意識でやっています。
「ローカルでもテスト動いてるし検証環境でも実際動いている、でも jenkins でだけ何故かテストが落ちている」
という状況（やってる人間はよく知ってると思いますが、それなりに発生する状況です）
でも絶対にリリースに OK をだしません。
それはもしかしたらその「何故か jenkins で赤くなる部分」にバグが潜んでいるのかもしれないからです。
でも、これやるの結構大変です。
メンバーには
「jenkins でテスト通るようにして！」
と伝えたあとに企画や全体を統括している上司に
「すいません、今日 xx:xx にリリース予定だったのですが、まだ不安定なため延期させてください」
と頭を下げインフラの方には
「すいません、この時間抑えていたのですがまだリリースできる状況になっていないので一旦延期させてください。」
と頭を下げに行きます。
でも、それがリーダーの仕事だと思っているし今までちゃんとしたものをリリースしていれば理解はしてもらえるはずです。
ということでウチのチームではテストは必須になっています。
問題を根性で解決するな
問題を根性で解決するのは馬鹿です。
問題をエンジニアリングで解決するのがエンジニアの仕事です。
「夜中まで/土日も仕事すればなんとかなる」
というのは馬鹿です。
そうならないようにエンジニアリングで解決するのです。
例えばテストでしょう。テストを書いていることによって新しい機能が増えた時にも他の機能に影響が無いことをいちいち自分の手で全部確認しなくても済みます。
根性で解決してしまうと次も根性で解決してしまうでしょう。
もうそれはエンジニアリングではなく、頑張っている馬鹿でしかありません。
問題を解決できなくなってしまってはエンジニアリングに価値がなくなってしまいます。
もちろん、どうしても伸ばせない納期のためにエンジニアが夜中や土日などにコードを書く状況になってしまうこともあるでしょう。
でも、それはリーダーも含め仕事を振った側の責任です。
逆にどうしてもそういう状況は発生してしまうのでそのためのバッファのためにも問題は技術で解決しないといけないのです。
人を殺す以外なら何やってもいい
これは半分ネタで半分本気です。
本気の部分を話すと例えばさっきも出たスケジュールの話です。
ついつい「土日頑張れば何とかなるかな？」と思ってしまうのもわかります。
でも、ダメです。人というのはもちろん自分も含まれています。
そんな事をしていては良いコードは書けません。
「風邪っぽいけど頑張って仕事する」ももちろん禁止です。
チームに風邪が流行ってしまってはマイナスだし体調悪い時に書いたコードが良い訳がありません。
それ以外の開発の障害になるようなことは聖域などなくどんどん取り除いていくつもりです。
失敗を引きずるな
これも僕がよく言う台詞の一つです
「多少反省したら引きずるな」
引きずって良いコードが書けるのならばいくらでも引きずってください。
でも、絶対にそんなことは無いです。だからといって何も気にするなとは言いません。多少反省しましょう。
これはバグが出てしまった時も一緒です。
自分が書いたコードにバグがあった場合も引きずりそうになりますが、僕は間髪入れずに聞きます。
「これはテストが足りなかったから出たの？テストがしにくい場所だから出たの？」
テストが足りなかったならばテストを書けば次から発生しません。
テストがしにくい場所ならば長期的にはテストを書きやすくするべきでしょうが、そうも行かない時もあるでしょう。
そんなときは「ココはテストがしにくい場所なので弄るときは注意して！！」と周知すればいいのです。
アタリマエのことです。失敗したら次に失敗しない策を練ればいいだけです。
失敗しないようにするのは大事です。
なのでうちのチームは出社時間も決めていません。
例えば遅刻してしまった時
「しまった遅刻してしまった！」
と思うでしょう。
次の日も遅刻してしまったら
「どうしよう＞＜ 二日連続でやってしまった！！」
と思うでしょう。
さらに次の日も遅刻したら
「やばい、さすがに三日連続はまずいから体調悪いことにして今日は休もう」
と思ってしまったりすることもあるでしょう。
この感情、無駄です。そんな感情で良いコードは書けません。
ミーティングがあったり外出があったりする以外は別に何時に出社してもいいと思っています。
最後に
以上のようなチームビルディングが出来るのはメンバーを信用しているからです。
メンバーを信用出来ない様な人間にリーダーは出来ないと俺は思っています。
なんの本だったか忘れてしまいましたが、XP 関係の本に
「今イテレーションにどんな問題が発生したとしても、チームメンバーは全員、その時に自分が出来る最大限の事をしたことを疑わない。それを前提に問題を解決しよう！」的な話があったのですが、それが凄く心に残っています。
アジャイルではコミュニケーションを重視していますが、コミュニケーションを重視するためには相手を信頼して尊敬するというのは不可欠だと思います。
「何馬鹿みたいに理想的な事言ってんだ！！ こんなこと、うちの会社では許されない！！」
と思う人もいるかも知れません。
でも、僕も一緒です。
別にうちの会社でコレが許されているわけでもありません。
でも、僕はコレで良いコードが書けるようになって良いプロダクトが出来ると信じているのでやっています。
もちろん企画の人などにはちゃんとこの事を話しています。
例えばこのブログをみてもっと上の人に怒られたとしても、僕が顛末書書けばいいだけですし、最悪クビになる程度だと思います。
『俺は正しいと思ったからやったんだ後悔はない、、、こんな世界とはいえ俺は自分の信じられる道を歩いていたい！』
『覚悟はいいか？俺はできている』
僕もまだまだ出来ていないところも多いと思いますが頑張って行きましょう。
