開発をうまく回したいなと思って僕が意識している40くらいのこと

自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。
ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。

心構え

1 現状を受け入れる

環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。

2 遷移状態を受け入れる

現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。

3 正しいことが選ばれるわけじゃない

政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれるわけじゃない。なので、自分が持って行きたい方向があるなら「正しい」以外の動力について意識しておかないといけない。

4 アジャイルと呼ばない

賛成派も反対派も面倒くさいので僕はこの言葉はあんまり使わない。

あと「アジャイルではこうするんです」とか言わずに、アジャイルでは「何故」そうするのか？という理由の部分を「アジャイル」という言葉を使わなくても相手を納得させられるように説明する効果もあり。

コミュニケーション

5 信頼で結ばれた共同体

相手のことを信頼する。といっても責任を丸投げするわけじゃなくて。僕の場合は「相手も僕も良いサービスを全力で作ろうとしているのだ」ということを信頼する。ここに信頼関係があれば、あとはスキル不足やコミュニケーションミスだけを考えればいい。

エンジニアとして信頼してもらうのはシンプルで。「技術力があること」「ビジネスゴールを見ていること」かな。

6 相手の立場

どれだけ自分の目線で説明しても相手には届かない。相手がどんな環境でどんな立ち位置にいて何を見て、大切にしているかを考えて、相手の目線でメリット・デメリットを考える。

7 意図を伝える

自分が相手に対して何を望んでいるのかを明確に伝える。例えば「このままでは遅れそうです」とだけマネージャに伝えても「で？」ってなるよね。知っておいて欲しいだけなのか、スケジュールを変更したいのか、何をして欲しいのかを明確に伝える。それも、最初の一言で伝える。先に結論を言っておいて、その理由をその後に説明する。

8 選んでもらう

これは、ビジネス側の人と、開発チームとでは違う意味を持ってそうなんだけど。

ビジネス側の人には、いくつかの選択肢を渡して選んでもらう。相手の立場で考えると大体がコストや時間とスコープのトレードオフかなと。なので、開発作業やスコープを「お金」「時間」として落としこんでく感じ。

開発チームの場合は、開発タスクを押し付けるのではなくて、要件を渡して、タスクへの落とし込みはチームにやってもらう。自分で選んだ道のほうが当事者意識が高いし、失敗した時の学びも大きい。

9. レコメンド

相手に選んでもらうといっても、相手に全ての判断を押し付けるのではなく。「選択肢はいくつかあるが、自分はこの道を進むべきだと思っている。その理由は・・・」と開発の専門家としての意見を持って伝えておく。

10 ポジティブワード

「xxxができなかったら、yyyできない」と言うよりも「xxxができたら、yyyできる」と言いたい。できるだけポジティブな言葉を場に回すと、それだけで場がポジティブな空気に包まれる。

11 より良い選択肢

例えば、ビジネス側からは結構無茶な要望を言われたりするんだけど、それを「無茶だ！」とか「できない！」とか否定しなくていい。自分が「無茶だ！」と思ったなら、伝えるのはその結果じゃなくて、もういっぽ前の「Why?」。そして相手に選んでもらう。その時にはポジティブな言葉で回すようにするといい。

「機能Aは実現できません」じゃなくて「機能Aを実現する場合、プラス2ヶ月あればできます！」とできるための条件を伝えて「ただ、要望を満たすためなら、機能Aの一部を実装すればよさそうです。それなら言われた期間でできます。どっちにしましょうか？」て感じ。

12 感謝の言葉

足りないことは目に留まるし注意もするんだけど「ありがとう」とか「そういうところいいなー」とかは思ってもなかなか言わないよね。でも、ちゃんと意識して「ありがとう」って言うといい。「そういうところいいと思う」って言うといい。こっ恥ずかしいからなかなか言えないんだけども、ふりかえりの場を作ると言いやすいよ。

13 感情と事実を区別する

エンジニアは「自分への期待」で喋るときがある。いつぐらいにできる？と聞いて「3日後です」と言われた時に、果たしてそれが「自分は3日後に終わるくらいのエンジニアでありたい！そこに挑戦したい！」なのか「以前にやったときに2日かかったから1日バッファをみて3日かな」なのか、で全然違うので。感情で喋っているのか、事実や実績を元に喋っているのか、その見極めが大切。

ちなみに、エンジニアが「自分への期待」で喋るのは、もうそういうものとして受け入れたらいい。僕もリーダー側にいるときは客観的に見れるけど、エンジニアとして作業するときは大体短く言っちゃうすね。:P

14 ボールは手元に

他部署や社外とやりとりするときに「相手の返事待ち」のステータスってあるけど、それを「相手がボールを握っている」と表現するのが嫌いなの。相手に何かを依頼する場合は「回答をもらう」というチケットを切って自分にアサインする。ボールは自分の手元に置いといてコントロールする。

15 責任の境界でセクショナリズムが生まれる

個々にタスクを割り当てると、それぞれのタスクが責任の境界になってしまって。そこにセクショナリズムが生まれてしまう。チーム自体に対してタスクを割り当てて責任の境界をチームにしてしまおう。そうすると、チーム内でディスカッションや助け合いが発生しやすくなるす。

ゴール

16 ビジネスゴール

開発者は「システム」だけを見がちなんだけど。そのシステムってビジネスのためにあるもんで。なのでビジネス全体を見て、その中でそのシステムがどういう役割を担っているのかを考えたい。そして開発チームとして、ビジネスゴールに対してどんな風に貢献していけるのかを考えたい。

17 長期と短期のゴール

目の前で選んでる道が、最終的にどこにつながっているのかということを常に意識してたい。

例えば長期が3年、短期が1ヶ月として。3年後にA地点に辿り着きたいので、この1ヶ月はB地点を目指します！ということであって。B地点はマイルストーンであって最終目的地ではないことを意識したい。

透明性

18 見せる化

まずは作業の見える化をして、それをチームの外に見せる。見える化ってのはチームのモチベーションになる。んで、その情報を必要な人のところに見せていく必要があるす。見てくれない・・・と嘆いてても何も変わんないので、見てもらえるように見せていく。

19 言いたくないことほど早く伝える

開発してたら、これは言いたくないなぁって思う場面があるのだけど。そう思ったとしたら、できるだけ早くシェアする。ギリギリまで粘ったけどやっぱりリカバリーできませんでした！ってのは、導火線がもうほとんどない状態の爆弾をカバンから取り出して渡してるようなもんやで。はよ言えや！ってなるよね。

20 リカバリーは黙ってやるな

うまくリカバリーできたら言わずに済む。とか。余計な心配をかけたくない。とかで黙ってやろうとする人がいるけど。やめとけ。リカバリーしないといけないような状態になってるなら、もうそれは伝えた方がいい。伝えておけば、間に合った場合はもちろん問題ないし、間に合わなかったときの手もうっておける。

それは、エンジニアやチームのスキル不足を晒してしまうことになるのだけど、スキル不足なんだからしょうがない。

コミュニケーションロス

21 違和感を気のせいにしない

仕様の話とか、要件の話とかしてるときに。あれ？なんかちょっと違和感あるかも・・・でも、場の空気壊すのやだし、きっと、気のせいかな。で済ませない。お互いの前提知識の差や、コンテキストの違い、理解の違い、思い込みの違い、は微かな違和感になって会話の中で顔をのぞかせる。そこは面倒くさい奴だと思われても、違和感がなくなるまで踏み込むべき。

僕の役割は「面倒くさいやつだと思われないようにすること」じゃなくて「プロジェクトを成功させること」なのだよね。あいつと仕事するとすげー面倒臭いんだけど、プロジェクトはなぜか成功するんだよね。ってのでいいよね。

22 納得して作る

要件や仕様に納得してから作る。納得できないなら、納得できるまで話をしてから作る。納得できてなくて作ったものなんて、言われたとおりに作ったただのシステム以上にはならなくて、うまくビジネスに結びつかなくても「いや、あれ俺納得してないしー」と言い訳できちゃう。納得して作れば、誰か他の人のせいにせずに、当事者意識が持てて良い。

そして、チームの他のメンバーが納得してるのに、自分だけが納得してないなら、その間に何か違和感があるってことなので、踏み込むです。

23 頻繁な認識の統合

気が付くと隣の席の人が遠くの方に行ってたり、ガンガン進んで振り返ってみたら誰もいなくなってたり。認識ってのはすぐにずれちゃうので。頻繁に統合すると良いと思う。ペア開発なんかは即時認識合わせだね。

24 ペア開発

ペアプロで暗黙知の共有ができるし、即時レビューによってクオリティもキープできるのだけど。それを設計・実装・テストの全てのフェーズに広げてみた。ペア設計なんて、二人であーだこーだ喋りながらホワイトボードに書いてたりするんだけど。その会話の中で見落としに気づいたりするし、違和感を発見できたりするし。1人で抱え込まなくて済む。

25 DONEの定義

1日分のタスクにチケットを落としこんでなお、そのチケットで終わらせることの認識がメンバー間で違ったりする。明確に「これとこれが終わったらこのチケットはDONEってわけね」とか定義しておく。そのチケットが全体の中の何を担っているかを考えることができないメンバーがいると「実装終わったのでチケットクローズします！」「テストは？」「やってないです。実装だけです。」「テスト用のチケットないけどどこでやるつもりなの？」「知りません」とかなってあれ。

リスクヘッジ

26 早い段階で実際に動くものを見せる

できあがったあとに要望が上がってくること多いよね。先に言ってくれよ！って思う？けど、そういうものだとして、現状を受け入れるとすると、早い段階で実際に動くものを見せると良いよね。中身はグチャグチャでもいいから。捨てるプロトタイプでもいいから。

27 1回行ってくる

穴だらけの橋を渡るときにひとつひとつ穴を塞ぎながら渡ると安心感があっていいのだけど。そうやって渡った橋が最後の最後で向こう岸につながってないことがある。それって時間のムダだったね。

できるだけ早い段階で、穴をぴょんぴょん飛び越えながら、向こう岸まで1回ダッシュで行って帰ってくると良い。向こう岸までつながっていることが分かったら、じゃあ、今度は穴を塞ぎながら進もうか。

計画

28 短く切ったスケジュール

僕らは、10営業日ごとに区切ってるんだけど。その度に何か動くものを見せることにしている。それでも、10日目のギリギリまで開発した挙句に「動くものができませんでした」となることがある。7日目くらいで分かってそうなもんなんだけど、最終日まで粘ってしまう人がいる。

つまりそういうことで、スケジュールを短く切らずに3ヶ月とかにしちゃうと、3ヶ月分の遅れが最後の最後まで粘ってしまうので危険が危ない！短い方が集中して取り組むことができるしね。

29 ワークキュー

やって欲しいことを積んどいてくれたら上から順番にやっていくよー。優先させたいものを上の方に置いといてね。んで、できるだけ小さくしておいたほうがよいで！

30 YAGNI/KISS

今いらないものは作らない。今いらない機能のためにシステムが複雑になっちゃうし、作ったら作ったでテストしないといけないし、保守しないといけないし。それよりも、今必要な機能をさっさと出しちゃおうよ。

・・・これが案外判断難しい。どこまでを「今いらない」と判断するかとか。

31 ステップバイステップ

大きな変化ってのは痛い。ちょっとずつ、納得しつつ、ステップバイステップで変えていくとよいかなと。

今回、チームに色んなプラクティスを導入していくにあたって、短く切ったスケジュールでふりかえりをやりながら、ちょっとずつ導入していきました。例えば今はTDDで開発してますが、半年くらいかけてちょっとずつやってきました。

1. JUnitっていうものがあるんだよ
2. テスト書いてみる？
3. もっとテスト書いてみる？
4. テストを先に書いてみる？
5. TDDでやってみる？

32 やってみる

80%くらい考えたら、もう、やってみたらいいかなと。80%から90%に精度をあげるよりも、やってみた方が早かったり、予想もしなかった結果が得られたりするわけです。

成長

33 頻繁なふりかえり

10日に1回、ふりかえりをやってますが。これが開発チームの成長の起点になってると思う。ステップバイステップのふりかえりとか、感謝の言葉の交換とか。うまくいかなかったことの改善とか。

つか、今はそんな時間がないからプロジェクトが全部終わってから振り返ろうなんて言う人いるけど、3ヶ月後にふりかえっても覚えてないよね。

34 小さな前進を祝う

自分のエンジニアとしての目標を立てたとして、理想と現在のギャップを認識する。これはとても大切なんだけど。そこの認識が終わったらあとは、足りないことを数えるよりも、ちょっとでも前進した部分を祝おう。昨日は例外のメッセージも読まずに悩んでたけど、今日はメッセージは読んだうえで悩んでたんです！昨日より成長したよ！とか。

35 小さな失敗

チームには、小さくいっぱいこけてくれ！と思って見てました。DONEの定義がないから認識がずれたり、自動テストがないからバグ取りが大変だったり、要望の認識がずれてたり。擦り傷をいっぱい作って、その度にふりかえりで改善して成長してきたなーと。んで、小さく何度もコケてるもんだから、大きな怪我はせずにここまでこれたなー。

環境

36 防火壁

ベンチャーマインドがあるとはいえ、1チームで全てが完結するような小さな会社ではないので。社内調整は結構必要で。それとビジネス側からの問い合わせとかも結構ある。それを全部チームにそのまま流してしまうと開発効率が落ちちゃうので、自分がフィルタリングするようにしといた。たまに反動で、チームにお願いしてコードかかせてもらったりもしたけど。

37 名前付きの安定した基盤

gitで作業ブランチに名前をつけといて。「作業はstgブランチからチケット番号のブランチ切ってね。んでできたらプルリクエスト頂戴！」とか。それと、リリースタグとかバージョニングとか。あぁ、これも振り返りの時にgit-flowについてみんなで話したりして色々変わってきたなぁ。

38 最小限の管理作業

エンジニアはできるだけ沢山の時間を開発に充てるべきだなーと。管理のために必要な作業は自動化する、会議体は減らす、などしてできるだけ開発に集中できるようにしてみました。

39 プライベートな世界

開発環境/STG環境/PROD環境とか用意するとして。「開発環境」はどこか共通の場所ではなく、ローカル環境であるべき。別に共通環境にあげるのなんて1分位でできるじゃん？とか思うかもだけど、ほんの10秒でも開発効率が全然違うことはQuickJUnitが僕に教えてくれてます。

40 プライベートな時間

作業の透明化とマイクロマネージメントは違う。エンジニアなんて道草で成長したりするもんで。100%全力よりも80%くらいの力で仕事してて残り20%くらいはキョロキョロしてたり、SNSしてたり、新しい技術調べてたり、隣のチームと喋ってたり、困ってる人を助けたりくらいがいいかなと。

41 軽量リリース

開発のサイクルを良くするための起点って「リリースが軽いこと」かなと。例えば、まずはボタンをクリックするだけでノンストップでリリースできるようにする。そうすると、細かく何度も簡単にリリースできるようになって、そこから開発のリズムを良くなっていく。

最後に

42 正解は変わり続ける

一度答えを見つけてしまうと、次回もそれをそのまま使いたいかもなんだけど。時間とともに環境も技術も変化し続けるので、今日は昨日よりもっと良い方法があるかもしれない。なので、自分の過去の成功を疑ってたい。そして、今日の正解を見つけられるように、常に自分の力を磨いていたい。

おしまい

組織パターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン