bon now

チーム開発は最近僕のトレンドワードなので行ってきた。 「強いチーム」という僕の定義には、多拠点/リモートでも問題なく業務が進みパフォーマンスが低下しないというものがある。 これは物理的な距離の問題だけじゃなく心の距離かもしれないし、インターネットの通信速度の問題かもしれない。 とにかくこういった面と直接対峙して開発してるチームの事例を聞ける機会はあまりない。

セッション別に僕の所感を書いていこうと思うのだが、最初に総括を述べるとまぁみなさん意識が高い。
俗語っぽくて嫌味くさい言葉かもしれないがそういう意味ではなく、 例えば今回の発表者のなかでマネジャーではなくエンジニアという役割で仕事をされている方は2名だったのだが、 彼らの役割というのはイメージ的にはやっぱり開発を終わらて価値をエンドユーザーに届けるという部分だろう。 しかしその彼らが「チームについて」を真面目に考えて議論して仮説からの施策の検証・評価をこうやってまとめあげて発表するというのは、 一般的なエンジニアの役割を明らかに超えた部分でチーム開発に向き合っているという証拠である。

こういうエンジニアいるかっていうと、いるだろうけど正直そのへんの中小企業なら1、2人いればいい方なんじゃないだろうか。 それくらい衝撃を受けたのと同時に、彼らのマインドをもっと知りたいなと思うのであった。

LINEリサーチ開発におけるScrumのこれまでとこれから

スクラムは1つの型だが、そもそもスクラム自体現状で存在する問題を抽出するための手法なので、 どっちかといえば自分たちのワークスタイルにスクラムをいい感じに当てはめるという方が近い。 そうすると当てはまらない部分も出てくるし、バッチリワークする部分も出てくる。 それはなぜか？そこを考えるきっかけを作ることができれば、最初の一歩は成功であるといっていい。

僕の経験ではめちゃくちゃ大事なのって結局振り返り。 人を詰めるわけじゃなくあくまでプロセスや生じた不具合などの課題に対する解決策を考える部分。 他のセッションでも触れるのでここでは詳しく書かないけど、振り返りのプラクティスみたいなのを自社で確立して それをベースにやっていくってのも大事かなと思う。 (人によってやり方やフィードバックが違うと正直受ける側は混乱する)

あとQAをスクラムに入れないっていうパターンにはまあまあ遭遇する。 しかしながら、むしろ品質は初期段階で作り込めば込むほど後工程で出てこないというのがV字型モデルでも言われていることで、 これはアジャイルになったとしても変わらないと僕は思うため、QAは最初っからスクラムにぶっこむほうが良いと感じる。 メルカリではQAがエンジニアとセットで行動することでテストの効率化とプロダクト品質向上を図ってる事例があるが、これもまだ「自動化以外でのテスト観点の網羅や設計の是非」についての取り組みは詳細に書かれてない。 つまり今がチャンスであると同時に黎明期だと思っていて、QAとエンジニアの二人三脚でのプロダクト品質確保という点においては、 まだまだ改善・改良の余地があるといえる。

また、スクラムは「めっちゃ面倒」という印象を受ける人も多いし実際そのとおりだと思う。 ただこの面倒な時間を費やすことで「無駄はなにか」「やらなくても良い作業はなにか」ってのを考えるきっかけにはなる。 それこそドキュメントをどれだけ作るかとか、作業自動化とかはそれへのソリューションになるだろう。 もしかしたらスクラムそのものをやめるという選択肢も出てくるかもしれない。でもそれでいい。 そうやってプロダクト開発に対してチームが課題意識を持って改善のサイクルを回せるのであればそれでいい。

それとスプリントプランニングでストーリーポイント(SP)出すってのがあるけど、これを日数で考えるようになってしまうと、 営業や企画が体外向けに「XXXX日でできるよ」とか言いかねないのでそこを注意したいところ。 僕の場合は営業さんにも理解をしてもらうために説明会を開いたり、 スプリントプランニングっぽい定例の場に営業さんも同席してもらったりして認識差異を埋めた。 本セッションのチームも結果的にはリリースサイクルやリードタイムが改善しているので良かったのだが、 この数字をあまり意識しないでチームの雰囲気やプロセスの改善にだけ囚われていると、 アジャイルそのものが解決子なければならない「顧客に価値を素早く届ける」が蔑ろになりがちである。 この点については、いわゆる「顧客視点」を持ってマネジャーはチームを正しい方向へ導くようにしなければならない。 (僕も最近までこの罠に陥っていた)

その他成長に寄与するリーダーの取り組みにはアサーティブコミュニケーションが役に立つよーだとか結局組織がどう改善しようと、 エンドユーザーに機能や改善を届けるサイクルが早くならないのなら価値は上がらないんじゃないですかーだとか、 そういう色々と議論したいところもあった。(懇親会不参加なんで会話できず)

あとサーバントリーダーという単語が出てきたけどどうしてもFateを意識してしまうというどうでもいい所感も書いておく。

「問おう、貴方が私のマスターか」

チームがうまく失敗し学ぶために私にできること

どのセッションもそうだったけどあいまいな言葉の表現を定義するというフローが発表の中に必ず入ってて、 これ誰か同じ人(もしくは同じ基準)でレビューされてるのかな？という印象を受けた。良いこと。

本セッションでは「失敗から学ぶ」という定義を3つのギャップに分けて定義されていた。

• 理想とのギャップ
• 期待とのギャップ
• 感覚とのギャップ

理想とのギャップはよく起きる。自分で作り上げた最高のアルゴリズムが、テストで不具合として返ってくるあれだ。 期待とのギャップはマネジャーがメンバーに抱く淡い恋心みたいなものだろう。 エンジニアリング組織論への招待漢語を借りれば、不確実な情報が生み出すギャップと言い換えることができると思う。 (双方の認識の差、考え方の差、捉え方の差は、情報がモヤっとしているせいということ) 感覚とのギャップは開発よりもスポーツで起きやすいんじゃないだろうか。ゴルフや野球、サッカーなどの球技では、 イメージではもっと遠くまで飛ばせる/投げれる/蹴れると思っていたのが全然うまくいかないというあれだ。 開発の現場では見積もりで3日かかると予想した課題が、あれよあれよと10日もかかってしまったみたいなこともまぁよくあるだろう。

これらのギャップについて、それぞれに対する解決手段が提示されていたかなと振り返ってみたが、 特にそこまで詳しくは述べられていなかったと記憶している。
本セッションではスプリントを回したあとの振り返りフェーズ(レトロスペクティブ)や1on1などで発生したギャップを集め、 時系列で並べることで問題の粒度やクラスタリングをしやすくし、見える化したという。 時系列初期では結構初歩的なミスが生まれていて、特に間隔とのギャップについては要素分析を通して解決していったとのことだった。

「カンバン仕事術」という本にはこの振り返りフェーズでメンバーにあげてもらった課題のうち 「今回改善に取り組みたい課題を2、3つ選んでもらう」ということをするようにと書かれている。 これは要するに改善提案はたくさん挙がってきて当たり前だが、それを1つの振り返りの時間内で議論できる時間は有限なので、 問題を絞り込んで対処するための方法である。

また、拠点間でのやり取りの問題として物理的にホワイトボードが分断されてしまうというものがあった。 Sansanの大阪拠点立ち上げの記事でも取り上げられていたけど、チーム開発でコミュニケーションを言葉や 付箋などの対面我必要なものに限定された状態が通常の手段となっている場合、拠点が別れたタイミングで 双方意図せずコミュニケーションの漏れと格差を生み出してしまうことが問題になる。 これを解決するソフトウェアとして「Miro」というものがある。Miroは延々に広がるスケッチフィールドのおかげで、 アクセス権を持つ人が自由に好きなところに図や文書を書いて行くことができる。僕はあまり使いこなせてないけど、 普段から付箋や壁を使ってコミュニケーション取っているチームにはオススメ。

あと僕がここで気になったのは2つあって、結局「ちょうどいい」って誰にとってのちょうどいいなのかというところと、 いくつかの失敗には根本的に個人が関わってるパターンもあるのでそれをチームで議論するのはやめたほうがいいということだ。

前者は「ちょうどいい」の曖昧さが招く悲劇であり、辛さ10倍カレーが丁度いい人もいれば、甘口が丁度いい人もいる。 「ちょうどいい」が施策を行う本人だけの感覚なのであれば、ひとり相撲になるリスクもあるのでここは結構難しい。 Aさんにとってちょうどいい失敗と振り返りの期間と、Bさんのそれとを調製しなければならないのだから。

後者についてはよく多様性という言葉で語られるけど、東南アジアでは人前で叱る(あるいは自分を咎められていると感じる場を作ることも)のは 良くない行為だと言われている。まぁ国のステレオタイプはともかく、誰だって自分の非を叱られたくはない。 本日このセッションの次にあったセッション内では、 「振り返りの際に事前に5分時間を設けて無記名でKPTを挙げてもらい、メンバー全員でそれに対してどうすればよいかを考える」というものがあり、 これなら個人が攻撃されている感覚は出にくいという話が語られた。とはいえ付箋なら筆跡でわかってしまう場面もあるので、僕なら物理付箋じゃなくツールを使うと思う。 あとやっぱりそれでも嫌な人は嫌だと思うんで、あきらかに人に由来する失敗ってのは 振り返りの場であればファシリテーターが遮って議論をやめさせるなり、1on1で面と向かって対処するなりの施策は考えたほうがいいかなと思う。 その他にも振り返りでおこなうのはKPTではなく、YWTのほうが心理的安全性を確保しやすいみたいな論説も存在する。

それと失敗から学ぶ方法について道を示すのもマネジャーの仕事の1つだと思うので、 そのへんを言語化できるスキルはある程度必要かなと感じた。他人の失敗からの学びに至る行動ってのは確かに見える化されていないので、 外側から見て分かりづらいところは多々ある。これについてはQiitaの本番環境でやらかしちゃった人 Advent Calendar 2019みたいに、自虐ネタっぽくやれるような場が作れたらいいよなーと個人的には思う。
他にもいっぱい感じたことはあったが、長くなるのでやめる。大変気づきの多い発表だった。

仲間の多様な価値観を尊重しつつ、チームとして成果を出すための戦略

このセッションを聞いて早速「異文化理解力」を欲しい物リストに突っ込んだ。 いつ読めるのかはわからない（他にも読まなきゃいけない本が大量に溜まってるので……）

どうでもいい話だが東京の満員電車は殺伐としていて、僕も1度前を歩く女性のパンプスを踏んづけてしまって睨まれたことがあったし、 電車乗り降り口付近で頑なに外に出ようとしないサラリーマンにタックルしたこともあるにはある。 今の心持ちならたぶん1ヶ月くらいは笑って乗れる気はするけど、その後はまたあの「やるかやられるか」の状態に戻ってしまう不安もある。 結局人は環境で人生どころか社会行動さえも左右されるというのがよく分かる。そんな背景があるせいか、都会のエンジニアは心を病んだら山、 海、ロードバイクあたりに現実逃避する人がやたら多い印象がある。自然(とモノ)は裏切らない。

この発表でも「成果を生み出す」という言葉の定義が行われた。
ここでの成果は意思決定とコミュニケーションが合理的(適切かつ効率性の最も高い手段)と定義された。 事例ではとある新規技術を開発に取り入れようとしたときに、メンバー全員の知識格差を埋めるための説明会や 合意形成のための会議などを実施したというものだった。 結論から言えばこのやり方は合理的だったという判断だったようだが、全部が全部そうであるとは限らないと思う。 この件はTHE TEAMの第4章に書かれているので、 あえて僕が主観を入れて説明するより本を読んでもらったほうが早い。 本を買う余裕なんてない！という方はこの記事を読んでもらうといいかもしれない。(タイトルが誇張されてるが)
話し合って決めるチームがほぼ失敗する理由

結局合理的かどうかというのはメンバーが納得してくれていることが前提であると思うわけで、 納得するにはそれぞれに論理的に理解してもらうための情報を提供することが大事なのである。 そういう側面から考えると日本の多様性でよく話題になる「空気読め」的な発想は、 本セッションでも言われてたとおり海外出身者にとっては「何考えてるか全然わからん。非合理的」とみなされてもしょうがないのである。 じゃあどうすればよいかというと、メンバー全員である程度相対的に「このくらいは必要」という情報量の合意をすることだ。 多分それは定量的ではないのかもしれない。そしてこれは独裁的にマネジャーが勝手に決めていいものでもない。
こんな感じに意思決定をどうやるかってのは意外と重要なのである。

また、よくアジャイルで誤解されがちな「設計書書かない」っていう話もこの合理性を用いることで解決できるそうだ。 確かにチームで決めた情報の粒度があれば、必要な設計書の量や内容は自ずと定まってくるだろう。良いソリューションだと思う。

最後に7 Levels of Delegationというカードの紹介があった。 このカードは議論となっている事象や物事に対してメンバーがどの程度関心を持っているのかを数字で示す道具である。 似たような道具のプランニングポーカーと合わせて持っておきたい。 またこれ以外にもwevox values cardみたいなのもあって、これを使って各メンバーが何に重きをおいているかを知ることができる。 アジャイルチームのマネジャーならこれら3つのカードを所持しておくことが定石になる日も近いかもしれない。。。。

そんな感じで多様性云々のみならず同じ日本人でも血液型ないしは育った環境も趣味も違うので、 どこまでいってもチームは1つとして同じ形であることはなく、相互の理解と信頼で成り立たせなければならないことを改めて感じたのであった。

余談

ところでみなさんメモ取ってますか？
僕がこの勉強会に参加したとき、僕の周りに座ってた5人のうち3人はノート+ペン、1人はパソコン、1人はスマホでした。 ちなみに僕もだいたいノートとペンです。

僕がなぜメモを取るのかというと、僕自身が当時の出来事を振り返るとき必ずやるのが「ノートを開く」ということだからです。 人によっては思い出せるキーワードでググるとかメモアプリとかで検索するとかでしょうけど、僕にとってはノートのほうが先にくる行動です。 これは当時新卒入社した企業が打ち合わせや会議にパソコンを持って行かせてくれなかったのでノートにペンで書くことを強制されていたからで、 最近の人なら別にノートじゃなくてもいいんじゃないかと思います。 ていうか現代ではパソコンの画面を通じて直接書けるしそっちが利便性良い。 じゃあなんでノートに書くんだよという疑問も当然湧くでしょう。これについて僕なりの考えを示しておきます。

ノートに書くことで意識しないといけないのが「時間」という限定的なもので、 僕は自分が読める文字をずらずら書くのに20秒はかかるんですね。そうなると1スライドの発表が終わってしまう可能性もまあまあ高いんです。 つまりノートに書くという制約を課すことにより、メモを取らなければならない情報を取捨選択すると言う状況を、 自ら生み出すことができるんです。 これの何がいいかというと、要するに「やればできるがやらないといけない状況にならない限りやる気にならない」というカビゴンタイプの私には丁度いいやる気スイッチになるということです。
そういう意味でも万人におすすめできるわけではありません。が、せっかく知識を得るために時間を作って勉強会に参加したのなら、 うんうん、そうだねー以上のフィードバックを自分ないしは周りに提供できるアウトプットは持ち帰るほうが良いですよね。

ということでアウトプットのためのインプットは、ある程度自分の性格やタイプを見極めながら精度上げていくことが重要というお話でした。

なおメモの書き方みたいなのも自分ルールがあったりしますが、これは多分メモの魔力みたいな 先人の実践書を読んで真似したほうが早いと思います。