Elastic Team Building referred from Elastic Leadership https://droidkaigi.jp/2018/timetable?session=15584

1. Elastic Team Building
2018.02.09 DroidKaigi
Yuki Nanri

2. Yuki Nanri
• Android Developer
• Twitter: @neonankiti
• Github: @neonankiti
• FiNC Inc.

3. 今日話すこと
現場感満載のリアルな
チームビルディング

4. FiNCとは
DATA SOLUTION
専門家の
知見やコンテンツ
独自の検査、評価
解析技術やシステム
特許出願状況 (AI関連も含む）
13件取得、累計出願件数75件
圧倒的な
技術力とスピード
“すべての人にパーソナルコーチを”

5. チーム体制
2014/5
Androidエンジニア
1人
１人
2人
Androidエンジニア
サーバーエンジニア
iOSエンジニア
7人
2018/1
iOSエンジニア
サーバーエンジニア
2人
10人以上
・・・
※フルタイムのみカウント

6. Elastic Team Building??
Roy Osherove著、島田 浩二訳(2017)
Elastic Leadership O'Reilly Japan, Inc.

7. 環境に応じたLeadershipの発揮
• サバイバルフェーズ
• 成長フェーズ
• 自己組織化フェーズ
Roy Osherove著、島田 浩二訳(2017)
Elastic Leadership O'Reilly Japan, Inc.

8. サバイバルフェーズの定義
チームに学習する時間が
十分にない状態

9. 学習フェーズの定義
十分なゆとり時間があり、
その時間を使って
学習や検証を行っている。

10. 自己組織化フェーズの定義
あなたが何も心配もなく携帯電話やノー
トパソコンの電源を切り、
数日間仕事を放置できる状態

11. ３つのフェーズの関係性
サバイバルフェーズ
・時間がない
・遅れと残業
・火消し
自己組織化フェーズ
・スキルフル
・生産性に関与しない
・意思決定できる
学習フェーズ
・時間の余裕
・計画的な訓練に時間を使う
・誤りの許容
・委任
• ゆとり時間を作る
• 残業を減らす
• ゆとり時間で見積もりを
見直す。
• チームへの欲求が変更
• 会社のダイナミクスが
変わる
• チームで問題解決できるように教える

12. FiNCの話プロローグ

13. 当時(4年前)の状況
• 大学3年生
• Android未経験
• エンジニア歴0.5年
• 仕事経験0.5年

14. CTOは言った
小林(エンジニア)、ネイティブアプリ作らなあかんねん。
iOSとAndroidどっちやりたい？
いや、まあiOSですね。普通に
わかった。じゃあ南里Androidな。
！？！？！？！！？！？！？！？！？！？！
CTO
CTO
小林

15. FiNCの話サバイバルフェーズ

16. サバイバルフェーズのおさらい
チームに学習する時間が
十分にない状態

17. 仕事が全く進まなかった
進撃の巨人: 諫山創

18. 何も出来ないエンジニアだった
• プログラミング経験の少ない漢(おとこ)に出来る
ことは少なかった
• 度重なる残業、徹夜の連続
• 会社を大きくするという想いだけはスーパーエン
ジニアだった。(自称)

19. 心は荒んでいた
• Androidわからなすぎて、めっちゃ辛い
• 進捗聞かれるの怖い(もうちょっとですってずっと
言ってる気がする。ダメ絶対)

20. 一つの結論が出た
「いや、普通にAndroid出来る人必要やろ。」
バイソンは思った

21. とりあえず採用に挑戦した
が、めっちゃむずかった

22. 数々の障壁
• FiNCの知名度が皆無で、募集があんまりない(お
金もかけられなかった)
• 知人いなさすぎ問題。
• 10人くらいのフェーズだったので、全員エンジニア
採用ってどうやってやるの？状態

23. それでも頑張った
• 色々な求人サイトに出して、面談して、お断りした
り、お断りされた。
• 色々な手段を使った。でもFiNCでAndroid開発出
来る人はなかなか現れなかった。

24. Global人材の存在に気づき始める
• 一定数Globalな履歴書が送られて来るが、Global
人材の採用は難しいと思っていたし、コミュニ
ケーションコストが高いのでは？
• でも、Githubを見て自分より優秀だったので、藁
にもすがりたくなった。

25. FiNCの話Global採用への挑戦

26. CTOにざっくり言ってみた
「Androidエンジニアって日本人は母数自体が少ないで
すね。ちょっと英語話せますし、Globalに攻めません？
僕らGlobal Company(予定)ですし。日本で働きたい
Global人材って普通にいっぱいいるし、ええと思うんで
すよ。僕より出来るし」

27. 無論、数は調べたわけではない

28. CTOは言った
「いこう！」

29. Global採用の取り組み
質より量で攻める

30. とにかく打席に立つ
• 英語の面談は初めて。結構不安
• エンジニアとしての知識も不安定。
• その分しっかり準備して(つもり)、とにかく打席に
たった。

31. 打席に立つと気づくことがある
• 採用効率が悪かった
• 英語に必死すぎている

32. 採用効率が悪かった
• 英語の面談の沈黙が怖い故、用意した英語質問
をたくさん浴びせてしまっている。
• しかも意味のない質問を結構してる。
• 1次面談で1人に対して、1時間くらい使ってしまっ
ており、採用効率が相当悪かった。

33. 自分面接ルールを変えてみた
• センター・2次試験用の質問をわけて、センター試
験不合格者は面談を早めに終了した。
• 面談者には、面談の時間に幅がある(15 – 30分)
ことを事前に伝えた。

34. より多くの候補者にアプローチできた
センター試験不合格者を
早めに判断することができ、
時間効率が良くなった。

35. 英語に必死すぎている
• 英語に必死すぎて、内容があまり入ってないこと
が多かった。
• ただ、専門的な英語は定型化しやすいことに気
づいた。(人間力が問われる”日常会話”はめちゃ
くちゃむずかった。)

36. スクリプトを用意する
• 基本的には、日本語の面談で利用する会話を英
語にすればOK。自己紹介、会社またはプロダクト
の概要、ジョブディスクリプションがスラスラ言え
るようになると大きな問題が起こらなくなる。

37. より話の内容に集中できた
英語に対する緊張感が薄れ
英語を文法的に正しく使うことよりも
話の内容自体に集中できた

38. 様々な苦労の結果
3人(NZ, ES, LB)の
多国籍なエンジニアたちを採用

39. FiNCの話障壁・妨害の排除

40. メンバーが増えるとだんだん
コミュニケーションが
指数関数的に増加する

41. コミュニケーションの問題
• ダイレクトコミュニケーションの増加
• アウトプットが明確でない会議
• 日本語ベースのコミュニケーション

42. ダイレクトコミュニケーション
プライベートメッセージが頻繁に来る
NG

43. デメリットは何か？
• プライベートでも問題自体は解決する。
• 問題は透明性とオーバーヘッドがあること。情報
はなるべく全体でシェアされている状態を目指し、
複数人で似たようなコミュニケーションの発生を
防ぐ。

44. 忖度する
何故なのか？を伝えていないコミュニケーションなので、伝え
るべきであった。。。
NG

45. エンジニア内で周知徹底
エンジニア内でプライベートメッセージを
もらった場合はパブリックチャンネルに
促すように周知徹底した。

46. Slackで統計が見れる
お見せできないのですが、
Slackでパブリックの率が見られるので、
その改善率を見るといいかもしれません。

47. アジェンダのない会議通知が頻発

48. 会議中は何も進捗しない
• 会議中は何も生み出していない。
• 特にエンジニアはざっくり技術的問題を解
決するために呼ばれやすい。
• メンバーからも会議が多いと問題視する
声が増えてきた。

49. アジェンダプロジェクト
• エンジニアでの催促の徹底
• アジェンダフォーマットの作成・シェア
• カレンダーに必ずアジェンダを貼る。

50. めっちゃ徹底した

51. 自分が出来てないこともある
• 自分が100%出来てなくてもどんどん指摘する。
(100%目指す)自分も指摘されて、改善しようとす
る。
• 重要なことは指摘し合うべきことであるという認
識を互いに持つこと
• そのためには人間関係は重要。

52. フォーマット項目
• タイトル(わかりやすく)
• 準備物(誰に何を何のために準備してほしいか
明確に)
• 内容と時間配分
• 参加者に期待すること
目的は会議を”効率化”すること。この項目以外でもOK。

53. ブレストはOK
• 会議には種類がある。意思決定を促したいもの
もあれば、アイデアを広く募るものもある。
• 例えば、ブレストなどを入れても良い。そのため
には事前に知っておくべきインプット、また期待
するアウトプットは定義しておく。

54. 無駄な会議を未然に防げるように

55. Globalメンバーがいるのに
日本語でチャットしてしまう。
(日本人同士でも基本NG)

56. 日本人同士は日本語でいいのでは？
Slack, Githubは基本的に完全に英語にするべき。上
記は議論のフィールドになりやすいので、
日本人以外の意見も取り入れるべき。
それがダイバーシティを謳う責任。

57. 徹底する・させる
• 議論が自分発の場合は、英語でスタートする。
そうすると日本人でも英語で書く傾向がある。
• 途中からでも、議論を英語にしてあげる、要約し
てあげる。(GlobalメンバーはもちろんGoogle翻訳
で戦っている)

58. 英語頑張ろうの空気
まだまだ浸透しきってはいないが、英語を学ぼうとす
る人が増えて、Globalメンバーにとって改善した環境
になったのではないか？

59. コミュニケーション問題の振り返り
• ダイレクトコミュニケーションの増加
• アウトプットが明確でない会議
• 日本語ベースのコミュニケーション
色々な対応をしたが、やったことは

60. 総じてScrum Masterぽかった
エンジニアリング以外(コミュニケーション)で
困っていることを徹底的に排除し、
集中できる環境を作った。

61. サバイバルフェーズまとめ
• 新たな人材を加えてドラスティックに変更
する
• コミュニケーションのロスが多いので、エン
ジニアリングのみに集中できる環境を作る。

62. FiNCの話学習フェーズ

63. 学習フェーズのおさらい
十分なゆとり時間があり、その時間
を使って学習や検証を行っている。

64. 学習フェーズで取り組んだこと
チームを成長させるための
• 私自身の成長
• チームメンバーの成長
に関して当時の課題感から話します。

65. 大人数(7人)での開発を行っていると
また新しく課題が出てきました。

66. 開発速度・クオリティが上がらない
• スループットはとある閾値を超えた
• しかし、高品質での機能リリースを迅速に行うこと
が難しい状態だった。

67. 2つの大きな問題
• ドメイン設計
• 技術負債

68. FiNCの話ドメイン設計

69. 当時の状況
• 当時はかなり新規実装が多かった。
• 機能チーム開発での縦割りの4,5人のチー
ム編成。
• ≒ ドメインごとのチーム単位。

70. 何が起こったか？
企画、デザイン、サーバー、クライアント
(Android, iOS)で認識がバラバラだった。

71. なぜ？
• ドメインへのメンバー間の知識の差異が問題。
• ドメインエキスパート(新規はプランナーになりや
すい)が 、チームメンバーに密なコミュニケーショ
ンが出来ていないケースが多い。

72. 知識の差を埋めにいった
• DDDについて学ぶ
• 発言しやすい環境づくり

73. DDDについて学ぶ
当時、あんざいゆきさんに
機能開発チームの問題点を相談しており、
「DDDとはなんたるか？」
を戦略的、戦術的な設計の
両方からアドバイスを頂いていた。

74. 戦略的設計に着手
• 当時はプランナーとエンジニア間、またサーバー
とクライアント間でのコミュニケーションの齟齬が
多かった。
• ユビキタス言語の浸透、コンテクストマップなど問
題領域への認識が実装前段階で正しくなかった。

75. 起こりやすい状況
• 人間は知らない != 恥ずかしいと思い込み
やすい。
• 新しい概念なので知らないことが多いはず
なのが、それが自分のキャッチアップ不足
だと勘違いする。

76. ハードルを下げる
ユビキタス言語やドメインの概念を浸透させるため
何度も確認、指摘する。
• 「すみません、それわからないです。」
• 「あれ、その言葉ってどの概念さしてましたっ
け？」
• 「その言葉ってどこのことさしてます？それは違う
ので、こっちの言葉使いましょう。」

77. 結果
新規実装ドメインに対する齟齬の減少
=
ユーザーの問題領域に
フォーカスできるようになった

78. FiNCの話技術負債

79. 技術負債を返せない
• 機能の追加・改修が定期的に行われていた。
• 技術的な負債のため非常に保守、運用が困難
だった。
• 技術負債は返していけばいいのだが、メンバー
はステークホルダーに上手く説明できず、結局
対応時期が引き伸ばされ続けていた。

80. こう考えた
• 自分がステークホルダーに説明するのは重要だ
が、チームの成長を考えると、各メンバーに説明
責任を果たしてもらったほうがいい。
• そのためには、まず何を問題として認識してい
るか、なぜそう思うかの認識を合わせなければ
いけない。

81. 問題への認識合わせ
• 何を問題と認識しているか上げてもらう
• 技術負債に対するオーナーシップは強い

82. なぜやるのか？がなぜ重要なのか
• Androidリソースは限定的
• インパクト(ビジネス・開発)が知りたい

83. じゃあなぜやるのか？
自分の思う答えを明示せず、考えてもらう
HUNTER×HUNTER:冨樫義博

84. ベストエフォートで定量化
• KPIが改善されるリファクタリング
• エンジニアの生産性に関わるリファクタリン
グ

85. 結果
メンバーがオーナーシップを持って、
問題提案から解決するプロセスに関して
取り組むようになった

86. 学習フェーズの他の取り組み
学習フェーズでは、
問題ドリブンの取り組みだけではなく、
未来ドリブンな仕込みを
行なっていくことも非常に重要

87. FiNCの話新技術の適用

88. 負えないリスクがなければ基本Go
• 不確実性の大きいソフトウェア開発では、
新しい技術・概念はどんどん試してノウハ
ウ化していく。
• リスクヘッジのみ正しくすればいい。

89. 採用例
• Kotlinの採用
• GraphQLの採用

90. Kotlin熱が社内で高まっていた
• Google採用前だった。
• とはいえ、日本でも当時Full Kotlinプロダク
トが数社あった。

91. 先頭を走っている人に聞く
リスクヘッジを正しく行うために
日本で一番Kotlinを考え、
実践してきた、たろうさんに
色々アドバイスを頂いた

92. リスクはほぼない
• JavaプロジェクトからのKotlin共存でも、リ
スクはほぼ無いと判断。
• Kotlinの採用を決定。
• 新規はKotlin(現在24.5%)

93. なぜGraphQL？
• UI依存なAPIになっていた
• 複数API間でレスポンスが不安定(リソース
指向じゃない)

94. フロントエンドチーム主導のBFF
Node.js + GraphQLでBFFを作った話

95. 先行者はかなり重要
• 先行者は実証・検証を繰り返す
• 浸透のための定期的内部シェア
• 先行者の率先したレビュー

96. 成長フェーズまとめ
• オーナーシップを意識した上での問題解
決を目指す。
• 目の前の問題解決のみならず、未来の
フェーズを見据えた取り組みも行う。

97. FiNCの話自己組織化フェーズ

98. あなたが何も心配もなく携帯電話やノー
トパソコンの電源を切り、
数日間仕事を放置できる状態
自己組織化フェーズのおさらい

99. • そんな状況は滅多にできない。有給で数週間バ
ケーションとる？
• トラブル起きない可能性も高いし自己組織化
フェーズの状況作れるの？
• 権限委譲したら、問題解決が必要なシチュエー
ションが作れるわけでもない。
シチュエーションの難易度

100. 実は直近アメリカで4ヶ月ほどリモートワークしてました。2/6
に無事帰国。
サンフランシスコ!!!

101. • 日本が働き始めるのが10時。アメリカ(PDT)では
18時になっており、基本作業は受け付けないスタ
ンスをとる方が依存性を断ち切るために重要です。
• なので、日本を出る前にこう言いました。
物理的に隔離された環境

102. 「僕は死んだものと思ってください。 」

103. 日本で色々な問題は
もちろん起こった

104. • メンバー同士が協力し、大きな問題になることは
ほとんどなかった。
• 緊急な電話もなかったので、本当の意味で問題解
決が出来ていたのではないか？と考えている。
• もしくは、そもそも小さな問題しかなかった説もあ
る。
チームで解決

105. 日本 -> アメリカより
アメリカ -> 日本の依存性で
自分が困ることの方が多かった
問題はそっちじゃない感

106. • 1対多での電話会議は非効率。流れについてい
けない。多対多だとみんなが同じシュチュエー
ションなので、忖度できる。
• 最新情報のキャッチアップが難しい。日本側は
口頭で済ませていることもあり、齟齬が生じやす
い。
例えば

107. • ただ、リモートはめちゃくちゃ作業に集中できる
ので、オススメ。
• 2/6に帰ってきたばかりで、まだリモート改善プロ
ジェクトは自己解決していないので、知見ある方
は是非教えてください！！
自己解決できなかった。。。

108. 「あれ、俺なしでめちゃくちゃ回ってね？むしろ
俺邪魔だった？」
結論

109. FiNCの話
そして、バイソンの
生き残りをかけた
サバイバルフェーズが始まった
~ fin ~

110. FiNCの話
自己組織化して
強いチームへ!!

111. FiNCの話ありがとうございました