TechとPoemeの間

Qiita に書かないエンジニア業の話

社員数が100人に迫っても社員と社長との距離を保つ「CEO Radio」の取り組み

今年の2月より、FOLIO という会社で働いています。本業はバックエンドシステム開発とかエンジニアリングマネージメントなのですが、それとは別に、「社長による社内向けの音声コンテンツ」の企画及びインタビュアーをやっているので、その話をしようかな、と思います。

この記事は、そんな FOLIOアドベントカレンダー 2日目 の記事です。昨日は id:ken5scal による 『踏み台環境でテレポートする』でした。

adventar.org

組織の「100人の壁」

自分が入社したときの FOLIO は50人から60人という会社でしたが、私の加入後にも続々とメンバーが参画し、今では100人に迫ろうとしています。 一般に、組織には「100人の壁」と呼ばれる、会社規模が大きくなることで発現する組織課題があると言われています。実際に FOLIO でも、今年の初めには1フロアだけだったオフィスも3フロアまでに拡大し、コミュニケーション不足を感じることも増えてきました。

中でも、社員と社長の関係という観点では、去年は CEO の甲斐ががオフィスをフラッと歩いて社員と気軽に話して事業のビジョンなどを共有することができたものが、メンバー社歴やオフィスの中のよく活動する場所、仕事の内容によっても甲斐と慢性的に距離のある立ち位置にいる社員が出てきたのも事実です。もちろん、甲斐もそのことは理解しており、各メンバーとコミュニケーションが取れるように考えたり動いたりしてくれますし、実際お昼時にオフィスの真ん中でメンバーの皆とカレーを食べている姿もよく見かけるのですが、「気をつける」のではどうしようも出来なくなるのが、「100人の壁」の特徴のひとつなのかもしれません。

理想を述べれば、社員の一人ひとりが社長のビジョンを理解し、共感できることが大事であることは疑いようがないでしょう。特に、今年の FOLIOLINE との資本業務提携を発表したり、新しいサービス「おまかせ投資」の提供を開始したりと、会社としてのこれまでにない動きも多かったので、今、社長がどのようなことを考えていて、自分の仕事にはどのような意味があるのか?をメンバーがより深く知る機会を設けることは非常に重要でした。

その理解を助けるための試みとして今年の7月から始めたのが、CEO Radio です。

CEO Radio のきっかけ

f:id:mura-_-mi:20181128202013p:plain
CEO Radio の社内向け配信サイト (2018年12月現在)

CEO Radio は1回10分~20分程度、CEO の甲斐と、聞き手の私、そして時には FOLIO の様々なメンバーが何らかのトピックについて話したものを、社内でメンバーが好きなときに聴ける音声コンテンツです。

この CEO Radio の始まりは、6月のとある社内の食事会にて、社長とバックエンドエンジニア数名で、「最近の会社の課題」に関する話題になり、上述のような課題をメンバーが挙げた際に、私が言及したのがきっかけでした。

FOLIO のメンバーは原則として、ジョインする際の選考プロセスの中で必ず CEO の甲斐と話すようになっており、メンバーの多くが甲斐の「世の金融の常識を変える!」というビジョンに共感して参画しているのではないかと思います。それでも、甲斐の考えを、入社時や偶発的なコミュニケーションだけではなく社内の興味あるメンバーには継続的に伝えられるようにし、しかも形に残すことで将来ジョインするメンバーにも FOLIO の文化や価値観を知ってもらえるようにすることは有意義なのではないか、と考えたのが CEO Radio の始まりでした。

私の頭の中にあった先行事例

私が「CEO Radio」を提案した際、頭の中には2つの先行事例がありました。

ひとつは、 2017年にあった 「XP祭り 2017」にて、ソニックガーデンの倉貫社長が紹介されていた、ご自身が取り組まれている「社長ラジオ」です。ソニックガーデンはほとんどの社員がリモートワークをしている会社であり、メンバーと社長のフェイス・トゥ・フェイスのコミュニケーションが比較的少ない会社であるために、会社全体のことを伝えたり、会社の価値観や動機づけになるような話をするための仕組みだったそうです。

また、私の前職であるサイバーエージェントの「カルチャー推進室」が、私の頭の中にあったもうひとつの事例でした。
サイバーエージェントは広告・ゲーム・メディアという大きく3つの部署に分かれていますが、その部署の垣根を越えて仕事を行わないメンバーというのも多く (私もその1人でした)、部署などの組織ごとに独自の慣習や価値観が醸成されている会社でした。しかしながら「サイバーエージェントらしさ」という価値観や文化は明確に存在していましたように感じました。その全社で一貫した文化の醸成に一役買っていた仕組みのひとつが「カルチャー推進室」の活動だったと私自身は理解しています。各部署のキーパーソンへのインタビューや、社歴の長いメンバーのキャリア遍歴、過去にメンバーが苦闘したプロジェクトの歴史などが社内ポータルサイトや社内刊行物などを通して全社員に発信されており、サイバーエージェントにジョインしてすぐのときに感動したことを覚えています。

明確に形に残されているものを追うことで、文化や会社の歴史に対する理解を深めることができました。私にとっては初めての転職であり不安も大きかった中で、「お客さん」になってしまって会社の文化に馴染めないようなことがなかったのはとても大きかったなと感じています。

CEO Radio を支える技術

f:id:mura-_-mi:20181201111525j:plain
最近の CEO Radio の収録風景

CEO ラジオの収録を行う際には、以下のような機材を用いています。

マイクなどの各機材は、当初は社内メンバーの私物のマイクを使っていたこともあったのですが、回数を重ねて CEO Radio の有意義さに対する理解が会社全体に浸透してきたタイミングで、会社の経費で購入したのが現行の機材です。

機材選びで気をつけたポイント

マイク選びは、複数の話者がいるなかで1本のマイクを利用するので、当然ですが無指向性マイクを利用すること。そして、盲点になりそうですが重要なのがサウンドカード選び。サウンドカードを単純に「USB と 3.5mm ジャックのアダプタ」と捉えると痛い目を見ます。実際、当初購入した安価なサウンドカードでは細かい音が全く拾えず、後から現行のサウンドカードに買い替えたことでしっかりとトークの内容が聞き取れる音声を収録できるようになりました。

収録と編集

収録ソフトは、以前は QuickTime Player で収録して、特に編集もせずそのままアップロードという形にしていました。回を重ねるにつれて、収録後に一部カットが必要になったり、複数の音声ファイルを接合しなければならない需要も出てきたため、GarageBand で最低限の編集をするようにしています。やってみて改めて思うのですが、編集は凝ろうと思えばどこまでも手を入れられてしまうのですが、私の本業は別にあるので、時間を使いすぎないよう気をつけています。

社内配信

社員への配信方法は、当初は Slack アプリケーション内で再生できる形でアップロードしていたのですが、最初の配信から2回ほど回数を重ねたタイミングで、とあるエンジニアが社内のみから閲覧できる配信サイトを構築してくれました。もともと社内サイトの立ち上げは考えていたのですが、あっという間にできてしまうスピード感にとても驚いたのを覚えています。 このサイト立ち上げを契機として、今では社内で行われる勉強会やワークショップも有志が音声もしくは動画を収録し、このサイトでアーカイブをいつでも視聴できるようになっています。

CEO Radio で何を話しているか

CEO Radio でどのような話題を取り上げるのかについては、特に決まりはなく、いろいろな試みをしているのですが、その中のいくつかをご紹介してみようと思います。

会社の直近の動きに関わる話

今年の11月に、投資一任型のプロダクトである「おまかせ投資」をリリースしたタイミングなどで、なぜ FOLIO はこれまで展開していた「テーマ投資」のみならず、複数のサービスを展開するのか、そこにどのような狙いがあるのか?今後どのようなプロダクトを展開するのか?などについて語ってもらったりしています。 FOLIO が提供する投資プロダクトや開発するシステムはそれぞれ単体で充分に巨大であり、メンバーは自分の担当範囲のことは知っていても、それ以外の部分についてはどうしても疎くなったり、複数のプロダクトやプロジェクトが会社全体の観点からどのようにつながっているのかも意識しづらくなってしまうことも、しばしばあります。CEO Radio で会社全体からみた各プロジェクト・プロダクトの位置づけをフィードバックし、メンバーのモチベーションに繋がるようにしています。

You は何しに FOLIO へ?

FOLIO メンバーをゲストに呼び、ゲストが FOLIO にジョインする前に何をしていたか?なぜジョインしようと思ったのか?について語ってもらうシリーズ。あるメンバーは「FOLIO に入るか、プロのポーカープレイヤーになるかを悩んだ」と語ったり、甲斐が、あるメンバーとの初対面を振り返って「最初は感じの悪い子だと思った」と思っていたという、今でこそ言える話が出たり… FOLIO メンバーの個性も相まって、毎回楽しく興味深い話を聞かせていただいています。

スタートアップ入門

もともと投資銀行でのトレーダーというキャリアを歩んできた甲斐が、スタートアップを立ち上げるうえで気をつけたこと、大切にしていることを教えてくれるシリーズ。いずれは FOLIO で成長したメンバーが "FOLIO mafia" として新たなベンチャー企業をどんどん立ち上げて行ってほしい、という甲斐の願いが込められているシリーズでもあります。

お便りのコーナー

社内のみからアクセスできる投稿フォームがあり、ここに集まったお便りに甲斐が答えるコーナーを定期的に設けています。FOLIO メンバーからはよく鋭い質問が飛んで来ますし、質問した人が納得できるようなトークにできるのかという意味で、聞き手としては比較的緊張するのがお便りのコーナーだったりします。個人的には、最近収録した「FOLIO のミッションとバリューに込めた意味や意図を教えてほしい」という回が非常に良かったなぁと思っています。

まとめ

FOLIO での、会社規模が大きくなってもビジョンや文化を組織の隅々まで浸透させるための取り組みについてご紹介しました。もちろん CEO Radio を聴くかどうかは社員にとっては任意ですし、このような取り組みで全てを解決しようとは考えていないからこそ、他の手段も使いながら組織のスケールアップに合わせた文化形成は引き続き頑張っていきたいと思っています。

そんな FOLIO では、一緒に働くメンバーを募集しています。少しでも興味を持った方は、一度気軽に FOLIO のオフィスに遊びに来てみませんか? www.wantedly.com

明日の FOLIO Advent Calendar 2018 - Adventar は、いつも何から何までお世話になってる kenchan0130 による Google App Script の話 です!

Scala関西Summit 2018 で喋ってきた

昨年は参加者だったけど、今年はスポンサーセッションを喋る立場になった。去年の記事はこちら↓↓

t-and-p.hatenablog.com

去年の9月に Scala関西Summit 2017 に参加して、懇親会で id:itohiro73 に誘ってもらったことがきっかけで FOLIO に入社したので、1年経って FOLIO の人間としてしゃべるようになるというのは不思議というか、この1年が色んな意味で激動だったなぁとしみじみ思いました。

登壇資料はこちら。FOLIO のバックエンドシステムがどうできているか、いろんな側面からご紹介できるないようになっているかなと思います。20分という時間の制約がなければもっとお伝えしたいことがあったので、それはまた近いうちにどこかの機会で。

speakerdeck.com


ここから先は比較的エモい話。

そもそもこういうイベントで登壇するのは初めてだったことと、しかもそれが僕個人の発表ではなく、会社がスポンサーとしてお金を出してくれて、なおかつスポンサーセッションとして弊社の取り組みを紹介するという重大任務だったので、いろいろと頑張った。結果として、エンジニア採用などでも使えるような資料ができたり、トークの内容を考えることで気づけること、仕事自体にフィードバックできることもあったので、ちゃんと取り組んで良かったな、と思う。 会社の Slack を見返したら8月11日にまず話す叩きを作ってた。これを id:itohiro73id:matsu_chara にレビューしてもらったりしてた。

もちろん3ヶ月間ずっとこれやるわけではなく、時々思い出したようにちょっとずつ進めたりしてたんだけど、2週間前くらいからはスライド作って、一人で喋るだけじゃなくてメンバーに見てもらってどう思うかを聞いたりと、ひたすら叩いてもらう機会を作らせてもらった。こういうのに付き合ってくれたメンバーに本当に感謝。

そして、一部デザインに凝ったスライドは CDO の広野 (https://hajipion.com/) に手伝ってもらった。いろんな場面で思うけど、職種とかも関係なく惜しみなく協力しあえる関係は、この会社にいて心地よいなぁと思う理由の一つだったりします。感謝。


そして!Scala関西Summit に来たからには食い倒れも重要!

1日目の朝はカフェのモーニング

1日目のランチは天満のお好み焼き「千草」豚肉めちゃ肉厚!

2日目は前日の懇親会の後3次会まであって二日酔いだったので、かすうどん。かすうどん初めて頂いたけど良いな

2日目終了後は梅田食堂街にて食いだおれます

"管理"という言葉の曖昧さ,またはなぜ自分が仕事で "管理" という言葉を嫌うか

仕事をしていると,よく "管理" という言葉に遭遇する.でも,日本語の "管理" という言葉に色んな意味があったり,文脈で "管理" という言葉が指す望ましい行動が違ったりして,辛いなぁと思うことが少なくない.だから自分は,仕事でなるべく "管理" という言葉を使わない.使うとしても,なるべくなら明確にしたいなと思うポイントがいくつかある.
いまの自分が思っている "管理" という言葉が刺しうる意味の文脈ごとの違いを整理して見たいと思う.

Administration / Control / Management

他にもいろんな英語があるけど,個人的に好きな分類だと, "管理" の英訳は "Administration", "Control", "Management" に分かれる.*1 *2自分なりの定義や意味合いを考えてみたい.

Administration

予め決められたプロセスやワークフローが正しく運用されていることを担保するような "管理" を指す.例えば "System Administration" と言えば,システムを運用する上で決められたフローやルールを遵守する活動を指すと思っている.
例えば規定に則ったソフトウェアのみが職務用端末にインストールされているというルールが遵守されていることを担保するために,ソフトウェアのインストールは "管理者" すなわち "Administrator" のみが実行することが出来る,という制約を設けるという例が浮かぶ.
かつて働いていた職場では,チームやグループに1人,「アドミさん」と呼ばれる,会社の決められた稟議やワークフローを進めてくれる人がいた.*3 よくある職務名称だと「総務」というやつなんだけど,細かいことなら会社の経費で文房具を発注するとか,大きなことなら人事異動にともなって新しく部署に参加する従業員のシステムアカウントや座席を用意することなど,予め会社を運営する上での取り決めを実行することが責務になる.

Control

"Control" は "制御" であって,直接,またはほぼ予測可能な因果関係を通じて間接的に,何らかのアウトプットを思うように動かすことを指す.*4
例えば「支出をコントロールする」といえば,具体的には現在支払っている何らかの支出を支払わなくすれば,それは「支出をコントロールした」と言える.また,プロボクサーは試合のスケジュールに合わせて「体重をコントロールする」が,体重は直接制御することは出来ないものの,摂取するカロリーを減らせばほぼ確実に体重を減らすことは出来るので,摂取するカロリーと体重の因果関係を利用し,カロリー摂取量をコントロールすることで体重をコントロールしたと言うことが出来る.

Management

Manage という言葉の語源は,暴れ馬を乗りこなすという意味であり,経営とか組織運営とかプロダクト開発の文脈に落とし込めば「直接制御できないアウトプットが好ましいものになるように働きかけること」だと思う.馬術のアスリートが,自分の意図するように馬を操ることは,"Control" ではなく "Management" であることは自明だ.馬も自分の意志を持ち,騎乗している人間の思うとおりには動かないからだ.
例えば何らかの事業の責任者は本質的にはマネージャーだろう.世の中の企業が営んでいる事業の殆どは「あちらを立てればこちらが立たず」の関係に囲まれているのみならず,それらが複雑に絡み合っているから,「あちらを立てれば,全く関係ないと思っていた遠くの何かが倒れる」ような状況にある.このような直接制御したり完全に予想できない因果関係の上で,利益を上げたり売上を上げたり知名度を上げることがマネージメントの本質である.

何を / どのように / どうする

"Administration", "Control", "Management" のいずれも動詞を名詞化したものである.動詞は単体で使うものではなくて,これらの3つ (の派生元) の動詞は必ず「誰が」「何を」「どのように」「どうする」という主語,目的語,副詞,目的語と併用されることになる.
これらの中で「誰が」というのは自明で,Aministration なら administrator だし,Control だと Controller だし,Management だと Manager だ.
「何を」「どのように」「どうする」のかは文脈によるけど,その難しさはこの3つの動詞で異なってくると思う.

Administration に考える余地はあまりない

Administration は予め決められた決まりを正しく運用することが目的だ.だから「どうする」は「決まりを守る」ということになるし,そのためには「決まりのとおりに動いて,決まりに反する行動をしない」という他に得策はなくない.たまにとても気を利かせてくれる総務の人はいて,彼らは効率が良かったり利用者の立場に立って考えたり,決まりにない部分を踏まえてショートカットをすることに長けているということはあるのだけど,それでも原則としては「決められたことを決められたとおりにやる」ということ以上のことはしていない.*5
「この草野球場の管理人は融通が利かなくて,プレーが続いてたとしても時間を過ぎると夜間照明を切っちゃう」とか,「大学の卒業論文の提出が1分遅れて受理されず留年されることになった」とかいう愚痴を耳にしたことがある人は多いと思うけど,彼らの職務は規則を守ることである以上はナンセンスだ.そしてその規則がなぜ存在するのかは,大体の場合その Administrator の与り知らないところにある.

Control の「どうやって」「どうする」は割と明確

Control の「どうやって」は,「どうする」さえ決まっていれば明確だ.体重を増やしたければ摂取するカロリーを増やせばいいし,体重を減らしたければ摂取するカロリーを減らせば良い.「どうする」という問題も,文脈によって結構簡単に決まりやすい.部屋に入門したばかりの力士はひたすら体重を増やせばよいし,ズボンのベルトの上に腹の肉が乗っかっているのが醜くて改善したいと思っている人は体重を減らせば良い.

Management の「どうやって」「どうする」を決めるのは難しい.

Management が必要な分野では,因果関係が複雑であって予測が難しいから,目標を達成するための「どうやって」の選択が難しい.確実に効果があると思った施策が効果を発揮しなかったり,想定していなかった反作用が想定した作用を上回ってしまってマイナスになることもある.営業チーム全体の成績を競争を通じて引き上げることを意図して成果報酬制を設けたら,競争が激化してしまいノウハウを共有するインセンティブが発生せず,チーム全体の営業成績は向上しなかったり,競争を通じてチームメンバーのメンタルが疲弊して営業成績がむしろ下がってしまう可能性すらある.
そして,場合によっては「どうする」自体を明らかにすることが難しいこともある.ソフトウェアやサービスを展開する企業の「プロダクトマネージャー」は,その名前からプロダクトをあるべき方向に導くことが責務であり,そのための方法を見極めて実行する仕事だと思われる.しかし,「どのように」を決めるためにはそもそも「どうする」が明確でなければ行けないのだが,事業の成長フェーズを見極めて,利益を多少度外視して売上を伸ばすのか,売上は伸ばさずに利益率を高めて利益を上げるフェーズなのか?が明確でなければ「どのように」は議論すら出来ない.それなのに「どうする」を明らかにしないまま「どのように」ばかりにフォーカスしてしまう人はそんなに珍しくは無いんじゃないかと思う.

なんでこんなことを思ったのか

なんで自分が突然こんなことを思ったのかというと2つ理由がある.

まずひとつは,一言に「管理」と言って求められているのが Administration なのか Control なのか Management なのかは結構違うのに,その違いを明らかにしないまま,Management をしなければいけない状況で Control するようなアプローチを取るなどの間違いを犯してしまうケースをいろんなところで見るからだ.理論と現実の紐付けやギャップを埋める努力が足りなかったり,組織が「考える人」と「手を動かす人」という分業の考え方から脱却できないまま複雑で変化の激しい仕事に取り組もうとしているときにこの状況は容易に発生するんじゃないかなぁと思っている.Management 3.0 では,こういう状況を "Management 2.0" と呼んでいて,その有様を「Doing the right thing wrong」と称している.ここでいう right thing とは "Manage されるべきものを Manage する" ことで,wrong とは "Control や Administration するアプローチ" だと思ってもらって良いと思う.Management 3.0 は,"Doing the right thing in right way" をすることを目指している.

もうひとつは,「アジャイル」や「スクラム」に,何らかの "管理" が求められるようなケースによく出くわすからだ.特にスクラムマスターの仕事を「マネージャー」だと思ったり「チームのタスクを管理する人」だと思ってしまうような誤解には残念ながら頻繁に出会う.「チームを支援する」だの「自己組織化を促す」だの言われても,そんな能力を持っている人や,それが実現された状況を見たことがなければ無理もないことだ.でも,「アジャイル」だ「スクラム」だという言葉があったから自分のキャリアが開けたり,それを通じて誰かのためになることを仕事にしてきた,そして今後もそうしていきたいと思う身としては,こういった誤解は解いていきたいなぁと思った次第なのである.

*1:もちろん,他にいろんな言葉が思い当たるだろうけど.

*2:https://brevis.exblog.jp/26270824/ に強く影響されているんだろうなぁと思う.この記事の中でも,幾つか例を拝借させてもらっている

*3:多くの場合,派遣契約の女性の方が担当していた

*4:Handle とかも結構近い

*5:たまに,規則を破ってでもうまいことやってくれる人はいるけど

大規模スクラムにおけるプロダクトの定義

単一のチームでスクラム開発を行う時と比べて,LeSSNexus といった Scrum of Scrums,または大規模スクラムを実践する際,「プロダクトは何か」という定義はより重要になります.
LeSS の解説書である Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn)) を読み進める中で,プロダクトの定義についての記述が結構良いなと思ったので,自分なりの例も交えつつ説明したいなと思います.

なぜプロダクトの定義が重要なのか

大規模スクラムに限らず,スクラムにおいてプロダクトの定義が明確であることは極めて重要です.プロダクトの範囲が明確でなければ,プロダクトバックログがどこまでをカバーするべきかも,プロダクトバックログアイテムの受け入れ基準にどのようなことが書かれているべきかも判断することが出来ないし,誰がプロダクトオーナーとして適しているかを判断することも出来ないからです.

これが大規模スクラムとなると,その重要性は更に増します.

複数のスクラムチームがひとつのプロダクトバックログを実現していくようになると,ほとんどすべてのケースでプロダクトは複数のシステム (LeSS では コンポーネント と呼びます) から構成されるようになります.プロダクトを構成する特定のシステムの開発や改善に注力する中で,システム単体が大きくなったり,複雑さが増すに従い,各システム単体での最適化を目的としてしまう心理が働いたり,他システムとの関連や顧客への影響がわかりにくくなったりします.このことは,LeSS でいうところの プロダクト全体の観点顧客中心的 といった価値観の促進を阻害してしまいます.

この問題を解決するためのアプローチとして最初に取られるべきなのがプロダクトの定義の明確化です.プロダクトの定義が明確になることで,プロダクトを構成する各サブシステムが最終的にどのような価値を顧客に提供するのかを明らかにし,この定義に従ってプロダクトバックログの作成や詳細化,価値ある単位へのスライスが可能になります.

なぜ,より広いプロダクトの定義が好まれるのか

プロダクトの関心や価値の範囲は,可能な範囲で広く取る ことを LeSS は推奨しています.

例えば,大規模な EC サイトの開発を例に取りましょう.EC サイトの運営には大雑把に言うと大きく2種類のシステムが必要になります.ひとつは商品を購買するエンドユーザーが回遊し,商品をカートに入れ,チェックアウトを行うフロントサイトであり,もう一方は在庫や価格を管理するために, EC サイトを運営する企業の担当者が利用する商品管理システムです.
ここでプロダクトを「EC フロントサイト」と捉えるのが狭いプロダクトの定義であり,「EC フロントサイトと管理システム」と捉えるのが広いプロダクトの定義です. どちらの定義でも,エンドユーザーに多くの購買行動を EC サイト上で起こしてもらうことで収益をあげよう,としている点は同じですが,そのアプローチとして取れる範囲が両者の間では異なります.

仮にプロダクトの定義を狭く取り,フロントサイトの開発に最適化した組織があったとしましょう.フロントサイトでストレスなく驚きや楽しみを与えるユーザーインターフェース (UI) を提供することで顧客のアテンションを惹き,ショッピングが楽しくなる環境を作り上げたとしても,そこに並ぶ商品自体が魅力的でなかったり,頻繁に欠品を起こしていたり,価格設定が不適切であったりという商品管理システムの機能不全が起きていれば台無しです.このような状況は「局所最適」と呼ばれます.

プロダクトの定義を広く捉えることで,フロントサイトと商品管理システムを合わせてどのような価値や強み,魅力といったものを提供するかを決め,一貫して実現に向かうことができるようになります.これが,より顧客にとって意味のあるプロダクトを開発するために必要不可欠だということは明白でしょう.

プロダクトの定義を拡張し続けること

プロダクトの定義は広いほうがよいとは言えど,大規模スクラムチームの所属する組織や企業の構造などが妨害となって実現が難しいケースがあります.例えば,そもそもフロントサイトを開発する部署と商品管理システムを開発する部署が分かれていたり,開発拠点が物理的に離れていたり,どちらかのシステム (または両方) の開発をアウトソースしていれば,プロダクトの定義を広く取って全体最適を図ることは難しくなります.

また,スクラムチームのスキルの範囲が限られているために,理想的な広いプロダクトの定義を持ってプロダクトに携わることが出来ないケースも多いでしょう.フロントサイトでリッチなユーザーインターフェースを実現するスキルも,スマートフォン向けのネイティブアプリを開発するスキルも,堅牢なな商品管理システムを構築するスキルも,収益効率を改善する価格設定アルゴリズムを実装するスキルもそれぞれ専門性が高く,一つの組織が持つスキルのバリエーションを増やすことは比較的長期的なスパンで考えなければならず,一朝一夕に実現はできません.このことは多くのソフトウェア開発者にとっては想像に難くないでしょう.

このような状況で LeSS が提唱しているのは,大規模スクラムの開始時点では現実的な範囲で組織が対峙するプロダクトを定義し,その後に定期的にその定義を見直しながらプロダクトの定義を継続的に拡張し,理想的な広さに近づけてゆくという方法です.これはさながら,スクラムチームが成熟するとともに 完成の定義 が拡張されてゆく現象と類似しますが,プロダクトの定義を拡張するということは組織の構造自体を変更する必要が生じるため,完成の定義の拡張よりは難しくエネルギーを要することだと述べられています.


ということで,興味を持った人は読んでみてください. (というかぜひ一緒に読みながらディスカッションしてくれる人とかいたら嬉しい)

Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn))

Large-Scale Scrum: More with LeSS (Addison-Wesley Signature Series (Cohn))

スウォーミングとは何か,なぜやるか

スウォーミングとは何か

スウォーミング (Swarming) とは,無数の虫が何かの場所や標的に群がって何かを行うことであり,ソフトウェア開発の文脈では,一つのタスクや開発トピックにチームの全員 (全員ではなくても,多人数) で取り組むことを指します.
最近しばしば話題に上がるモブ・プログラミングも概念としてはスウォーミングのひとつといえますが,もっと幅広く,ひとつのユーザーストーリーにチーム全体で取り組むことがスウォーミングという言葉がソフトウェアの文脈で一般的に指す活動です.

ソフトウェア開発チームは,一度のタイムボックス (スクラムに習って スプリント と呼びます) で複数のユーザーストーリー (例えば 注文の一覧を表示する というユーザーストーリーと,1つの注文の詳細情報を表示する というユーザーストーリー) に取り組むかと思います.
1つのユーザーストーリーを実現するためには複数のタスクをブレイクダウンできるでしょう.(例えば 注文の一覧を表示する というストーリーなら, デザインの決定, 一覧として表示する注文の定義の確定, プロダクトコードの実装, 単体テストの実装, 手動テスト とか) スウォーミングでは,これらのタスクをチーム全員で取り組みます.このときに重要なのが,チームが並行して複数のユーザーストーリーのタスクに取り組むのではなく,一度に (できるだけ) ただひとつのユーザーストーリーのタスクのみに取り組みます.

例えば 注文の一覧を表示する というユーザーストーリーの実現に取り組み始めたら,理想的にはチームの誰ひとりとしてその他のストーリーには取り組みません.まずチーム全員で デザインの決定 をする中で実装の詳細なポイントについてチーム全員で理解した後,プロダクトコードの実装 を行ったり,テスト実装が得意なメンバーがテスト駆動開発に疎い開発メンバーと一緒に テストコードの実装 を行ったり,仕様に詳しいメンバーが 手動テスト のテスト観点を洗い出したりテストを実施したりします.

なぜスウォーミングをするのか

「一度に複数のストーリーを並行して開発したほうが効率がいいんじゃないの?」と思う気持ちになる人がいて当然だと思うし,その人達にとって「スウォーミングだなんて効率が悪そう!」と思うのも無理はないでしょう.では,なぜスウォーミングをするのでしょうか.

完成までのリードタイムの短縮

チームが1スプリントに完成させるべきユーザーストーリーが3つあって,その3つをチームメンバーの間で分担して並行して取り組み,全てスプリントの最後に完成させるとなると,それぞれのユーザーストーリーのリードタイムは1スプリントの最初から最後までとなってしまいます.
どのようなプロダクトに取り組んでいるかにもよりますが,リードタイムを短くして,機能の一部でも素早く価値を実現させるステージまで持っていく (リリースをしたり,顧客の目に見えるところに持っていくなど) ことで,チームがプロダクトやプロダクトの取り組む問題について高速に学習することが出来るようになります.そのため,まずひとつのユーザーストーリーを全力で実現して,プロダクトのフィードバックを得ることがスウォーミングをする大きなモチベーションです.

手戻りの改善

作業を工程に分けることで,認識や想定の違いや,ある工程での設計上想定していなかったことが見つかったりすることで,手戻りが発生します.手戻りが発生すると,その分機能開発が完了するまでのリードタイムが長くなります.

例えば,最初の1週間をサーバーの API 開発に使い,次の1週間にウェブフロントの開発を行うとします.ウェブフロントの開発をする中で想定していなかった例外ケースに出くわしたり,API に項目の追加が必要になったりすることで,すでに完成したはずの最初の1週間の API 開発の大部分を見直す必要に出くわした経験のある人は多いでしょう.

このような手戻りに遭遇すると,「手戻りが発生しないように設計をしっかり行ってドキュメントを充実させよう」と考えることも出来なくはないですが,結局リードタイムを長引かせてしまうので,あまり良い策とはいえないでしょう.逆に,このような想定外が生じることを想定し,手戻りが起きてもダメージが少なく,リードタイムも伸ばさないように,チーム全員でひとつのユーザーストーリーに取り組み,ひとつのユーザーストーリーの粒度を大きくなりすぎないようにすることが重要になります.

知識移転の促進

チームでのソフトウェア開発を計画する上で,「この仕事は〇〇さんしかできない」というたぐいのものがあると思います.「ネットワークはあの人しかできない」などという制限がチームの開発の流れをよくすることを阻害します.知られた言葉をつかうなら「ボトルネック」というやつです.

技術的に限られたメンバーしか持っていないということにチームが自覚的であるならまだ良いのですが,それがいつしか「このタスクはこの人がやるもの」と前提にすらなってしまうことすらあるでしょう.その制限を意識的に崩すのがスウォーミングです.共同作業をすることでメンバー間での知識移転を促進し,知識やスキルのボトルネックを除くことが,スウォーミングを上手くやることで可能になります.

まとめ

スウォーミングとは何か,なぜそれを行うのか,について書いてみました.
また別の稿で,具体的にどのようにスウォーミングを実施するのかについての自分が経験してきたテクニックを書ければと思います.

非スクラムチームに贈る「ふりかえり」の処方箋

最近のソフトウェア開発チームの多くは,スクラムフレームワークを適用していなくても,いわゆる「アジャイルなプラクティス」に則ったイテレーティブな開発スケジュールを持っている組織が多いのではないかと思います.
自分もそのような組織に幾つか属してきた中で,周囲のやり方やインターネット上で見られる事例を形だけ適用してイテレーション *1 の「ふりかえり」*2 を行っているもののうまくいかない,という組織をこれまで多く見てきました.本稿では,特にスクラムには特に精通していないチームに向けて,スクラムから得られる知見や,自分がこれまでスクラムに取り組んできた中での経験を元に,よく見受けられるパターンと,それに対する処方箋をまとめようかなと思います.

時間内に議論が収まらない

チーム規模やイテレーションの長さに対して,どういうことが起きたか,何が問題だったか,どう改善するかという話が,予め予定したタイムボックスで終わらないというケースを良く目にします.

スクラムのルールを規定している Scrum Guide では,1ヶ月のスプリントの場合,スプリントレトロスペクティブの長さは最大4時間まで と定義しています.
単純計算が成立するのかも議論するべきポイントかもしれませんが,例えば1週間のスプリントのふりかえりを30分でやって足りている感じがしないという場合,「単純計算で言えば最大1時間使っても不自然ではない」と思うのも一策つかもしれません.組織によっては,「会議は1時間でスケジューラ上の予約する」のが暗黙的なパターンになってるといったケースも多いかと思いますが,それに引っ張られないことが大事だと思います.
スクラムのパタン・ランゲージをまとめている Scrum Pattern Community も,スプリントレトロスペクティブについて 「たっぷりと時間を取らないと,問題の根本にあるより深い問題にまでたどり着くことができない」と解説しています.
原則として会議は短いに越したことはないし,チーム全体のファシリテーションスキルが高ければ短い時間で収めることも可能でしょうが,ふりかえりに関しては長く時間を取って,タイムボックスを守るプレッシャーを比較的少なくするほうがチームの改善を促す観点では得策なのかなと思っています.

ふりかえりに参加するステークホルダーの苦しみを聴くのに心が痛む

例えば組織の中に,ソフトウェアを開発するチームと,そのソフトウェアを用いて収益を上げるビジネスチームがあり,ソフトウェア開発を行うという文脈でふりかえりを行うとします.ふりかえりにビジネスメンバーが参加し,「xxx の機能がないから営業がはかどらない」とか「xxx の機能が欲しい!」という改善要望や問題点が挙がり,ソフトウェアの開発者やリーダーが心を痛めたり,「そんなの言ったって人手が足りないよ」という気持ちになってしまったり,エンジニアは技術的な改善について議論したかったり,というケースが有ると思います.

スクラムには,スプリントを終了させるときに行うイベントが2つあります.ひとつは「スプリントレビュー」,もうひとつが「スプリントレトロスペクティブ」です.この2つには明確な違いがあります.
スプリントレビューは,チームの外側にいるステークホルダを呼び,スプリントの成果を確認した上で,プロダクトを良くするためには今後どうするべきかをスクラムチームとステークホルダーを交えて議論することが目的です.
一方で,スプリントレトロスペクティブでは,参加者はスクラムチーム *3 のみで,話題とするのはチームの生産性についてです.
特に組織が「エンジニアリング」と「ビジネス」に分かれている場合,この2つを適切に使い分けることが重要なのだと思います.当然ながらエンジニアとビジネスがプロダクトについて会話することも大事ですが,それを行う場を「ふりかえり」と称し,エンジニア単体でエンジニアリングの問題点について話す場所がなくなってしまうのを防ぐのが重要だと思います.

リードメンバーの独壇場になってしまう

他のメンバーが頭を捻って考えたアクションや改善策を,技術的に長けたリードエンジニアが否定してしまったり,チームリーダーがトップダウンで解決策をバンバン挙げてしまうケースもしばしば見受けられます.短期的な問題解決という意味では悪くないのかもしれませんが,チーム全体の学習の促進や,変化に対応した自己組織化されたチームを作るという長期的な視点では問題となるケースが有るでしょう.
技術や業務知識でチームをリードしている人が体制上チームリーダーとなることは何も問題は無いでしょうが,仮に彼らがファシリテーションスキルを充分に持ち合わせていない場合,リーダーだからとふりかえりの司会にしてしまうことは良い選択とは言えません.

スクラムでは,「プロダクトオーナー」という役割と「スクラムマスター」という役割が分かれていることで,取り組むプロダクト開発について責任を持つ役割と,ファシリテーションスキルを発揮してチームの自己組織化を手伝う役割が分かれています.ふりかえりに特化して言えば,聞き役に回れるような人を「チームリーダー」とは別にファシリテーターとして置くことは検討に値するでしょう.

また,ファシリテーターをチームメンバーが順番に担当することで,チーム全体のファシリテーションスキルを向上させるのも良い取り組みだと思います.このときに注意するべきなのは,ファシリテーション自体に対して継続的にフィードバック出来る人がチームにいて,ファシリテーターを順番に回すのも単なる「当番」や「仕方なくやるべきこと」なのではなく,ファシリテーションスキル向上という目的が共有されていることだと思います.

ふりかえりで出た改善アクションが取り組まれない

ふりかえりを始める際に,前回のふりかえりでチームが決めた改善策やアクションが全く取り組まれていないケースが多くあります.この状況を改善するためにチェックするべきポイントは2つあると思います.

改善策は「実行可能」か,または「追跡可能」であるか

「xxx に気をつける」「xxx するようにする」という改善策は,どうなったら完了したと言えるかが分からない点で「アクション」ではありません.振り返りで決めた「アクション」は,次のイテレーションでのタスクの1つとして「取り組んだ」か「取り組めなかった」かを明らかにできるようにするべきです.
2017年の Scrum Guide の改訂では,スプリントバックログの中に,前スプリントのレトロスペクティブで上がった改善策のうちの優先度の高いものを少なくとも1つ含めるべきだという記述が追加されました.これはスクラム実践者の中でも好みが分かれるところですが,常にチームの見えるところに置かれるスプリントバックログやカンバンにアクションが書いてあり,デイリースクラムでその取組を確認できるようにするというのは現実的な解決策だと思います.

また,アクションではなく,なんらかのメトリクスに落とし込むことも解決策でしょう.例えばチームがソフトウェアの機能開発をする際に自動テストを書かないという問題が上がったとしたら,「テストを書くように気をつける」のではなく,「各機能開発時に追加された自動テストのテストケースを可視化する」という解決策で,実際に書かれたテストケースを追跡可能にするのは,アクションの第1歩として有効でしょう.まずは現状を可視化して,チームの意識や認知に働きかけるという作戦です.

ここらへんの「振り返りの続け方」に関しては,中村洋さんが Regional Scrum Gathering Tokyo 2018 にてトークした 「ふりかえり」の始め方と続け方 // Speaker Deck が大いに参考になるかと思います.

speakerdeck.com

ふりかえりで出したアクションで全てを解決させようと期待しない

これは個人的に大事だと思っているのですが,ふりかえりで上がる問題には,1つのアクションを実行することで簡単には解決しないような問題も多くあるのではないかと思います.そんなときに大事なのは,ふりかえりで全ての解決策を考えたりするのではなく,少し問題を和らげるファーストステップをアクションとしてまず取り組んでみることだったり,複雑でまだチームが原因を理解しきれていないな問題を少しでも明らかにするためのアクションを考えることなのではないかと思います.

結論

ということで,「なんとなくやっているふりかえり」から「上手く回るチームのふりかえり」に昇華させる方法として最近自分が感じていることを挙げてきました.チームがスクラムに取り組んでいないとしても,スクラムのプラクティスの背後にある価値観や原則を知ることで意図を理解することは有用なんじゃないかと思います.
「みんなやっているから」とか「以前からやっているから」という理由でふりかえりに惰性で取り組むことは簡単ですが,少しコツを得ることで良くすることが出来るのではないかと思います.

自分がかつて所属した組織でやってたレトロスペクティブに関しては,以下のような記事も書いているので,参考にしてみてください.

t-and-p.hatenablog.com

*1:以下では,スクラムに限らないイテレーション開発の際に「イテレーション」と呼び,スクラムの文脈でのイテレーションスクラムの語彙に則り「スプリント」と呼びます

*2:イテレーション」と「スプリント」という呼び方と同様,スクラムに限らない場合に「ふりかえり」,スクラムの文脈のふりかえりを「レトロスペクティブ」と呼びます

*3:プロダクトオーナーがレトロスペクティブに参加するかどうかは,チームが決めます.

小さな変化を生み出すときの「エバンジェリスト」の小さな自覚

「それまでなんとなく,特段良いわけではないが,とりあえずうまく回っている」ような組織に新しい「変化」を起こすことはちょっと怖かったりする.

労務管理の文脈で言えば,それまで常態化していた長時間労働のマインドを180°変えて生産性を上げて勤務時間を短くしようとしたり,
古くから使われている比較的生産性の低いプログラミング言語でのソフトウェア開発を脱却して,モダンでイケてるプログラミング言語を導入しようとしたり,
もっと一般的にビジネスの文脈で言って,それまで経験や知見のない分野で新規事業を立ち上げてみたり.

その是非はそれぞれの文脈において語られることなので置いておいて,その「変化」を導く立場は,総じていつでも大変なものだと思う.

そもそも自分が正しいことをやっているのか自信を持てなくなることもあるし,その変化の向かう先にあるものについて,自分だって本当にマスターしたり理解しているわけでもない. ただ,「変化」を導くことの一番の大変さは,周囲の人々の認識や気持ち,習慣を変える大変さだと思う.

周囲の人々がその変化の関心を持っていなかったり,必要を感じていなかったり,もしくはその変化にそれまでいい思い出がないから,少し敵対心を持っていることもあるかもしれない.
それこそ,先日の Regional Scrum Gathering Tokyo 2018 で行われた Open space technology では,そんな「変化を起こしたいけれどもどうしたらいい?」という悩みが元になったディスカッションテーマもたくさんあった.

f:id:mura-_-mi:20180202003657j:plain

例えば,それまで混沌とした開発をしていた組織に,スクラムアジャイルの導入という「変化」を起こそうとする.そのとき,変な反骨心を買って反発を呼んだり,自分の変化の起こし方がうまくなくて失敗してしまった時,周囲の人達に,「たまたま,彼があの状況でうまくできなかった」と理解されたり評されたりするのは,すごい幸せなことだと思う.恐ろしいのは,「あの変化は起こすべきじゃなかった」と言われること.スクラムで言えば「ほら見たことか,スクラムなんて導入するのが間違いだったんだ」と言われることだ.
どこかのアイドルの「私のことは嫌いになっても,AKB48 のことは嫌いにならないでください」というセリフがどんな背景で発せられた言葉なのかは理解していないけれど,まさしくそんな言葉も言いたくなるような状況だなぁ,と思う.

その「変化」を主導する立場の人にとって,ちょっとした「エバンジェリスト」の自覚って大事なんじゃないのかな,という気がしている.まさに,そのような「変化」の現場では,その変化を先導する役割はまさに「変化」そのものなのだ.自分が彼らの「変化」をうまく導けなかったら,それはまさしくその「変化」自体にダメだったという烙印を押されかねないという,大げさに言えば覚悟みたいなものは持つべきなんじゃないのかなという気がしている.

エバンジェリスト」とは,もともとの意味は「伝道師」である.まさに,その「教義の伝道」に失敗した時,その宗教自体が「良くないもの」と捉えられかねない.自分の評判が落ちることはまだしも,その変化自体が意味のないものだと思われることは,その「変化」を信じる人にとっても痛手であるという意味で影響する範囲が大きいということを何処かで感じているべきなんじゃないのかな,とか思うわけである.


「組織」の「変化」と言えば,真っ先に Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン という本が浮かぶ人もいるだろう.この本の48のパターンの1つ目は,まさに「エバンジェリスト」である.自分がその「変化」に情熱を傾け,自分自身を突き動かす,というパターンが1番最初に書かれている.なによりも「変化」を主導するのに,その「変化」を自分ごとにする情熱こそが一番の原動力であるというメッセージが,48パターンの1つめというところにあるのかなと思う.
そして一方で,このパターンの注意点もこの本には書かれている.引用したい.

一方で、あなたが新しいアイデアに対して情熱的になりすぎると、周囲の人が引いてしまうリスクがある。情熱をコントロールし,決して我を忘れてはならない。(中略) あなたが身につけるべき重要な能力の一つが、忍耐強さと性急さの両方を同時にもつ能力かもしれない。

エバンジェリスト」を中心に置いた考え方をすれば,この書籍に書かれた残りの47のパターンは,エバンジェリストの情熱が暴走しすぎないために,忍耐強く「変化」を推し進めるためのテクニックなのかもしれないな,と思った次第.

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

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