概要

2018年のサービス規模

2018年で維持していたサービスの規模は以下の感じ。

本番サービス数でいうと 20個ほど
OEM提供の個人向けサービスが20社程
社内向けのサービスでさらに5~10個ほど
それとは別にワードプレスが50個
サーバー数でいうと570台@本番 + 200台@開発環境 + 50台@社内環境 (ほぼオンプレのみで)
これらの他にもAWSアカウント23個とAWS上のサービスが月500万~800万円分程
外部サービス(CircleCIとか)の利用数が25個 (AWSとかGCPとか)
ミドルウェア/言語等のライブラリの管理が 40~50 (makeしたopensslとかからruby/javaとか)
活動内容としても、Githubの管理、CIの整備、CDの整備、AWS/Sakuraの構築、運用、保守、障害対応、パフォーマンスチューニングの提案(CI/CD/SQLが多い)、アーキテクチャの相談、新規インフラプラットフォームの検討、運用->SaaSへの移管、社内ルールの整備、セキュリティについての検討/整備、要件仕様の整理検討、コスト管理、アカウント運用の整備、Botの作成等　
年平均で新サービスが3~5個くらい出ていくイメージ。
ユーザー数が個人向けで700万超、企業向けで50万社超
社員数も250 -> 350
連携先のシステム数が2700

と幅広く関わっていた。 2017年から多少増えているけど1~2割なので、2017年はこれと同等規模をこれ3名で回してた。(回ってなかった)

2017年を振り返ると

2017年の振り返りでは、このままでは攻めができない。既存のインフラの上に汚いながらも現状維持でやっていくしかなくていつかスペックが足りなくなったり、より開発者が増えていってサービスの増えるスピードが増えたときについていけないとか課題があった。

1名はDBAとしてスケールアップ作業とか複雑になったDBを紐解いて維持していくので過ぎたし

1名はスケールの早いサービスの維持と小さな改善で過ぎたし

1名はレガシー部分の保守を請け負って1年過ぎたし

どう頑張ってもスケーラビリティ/アジリティのあるインフラになってなかった。

2018年はこうしたいと思って始まった

これからどんどんサービスが増えてもついていけるインフラづくり (スケーラビリティとアジリティ)
アプリケーション開発者側にもインフラをメンテナンスする権限を移譲出来る土壌づくりを意識して戦っていった年でした。

入社した3年前からこの構想を実現し続けていたのが2018年でやっと花開いた感じだ。

やってきたこと

取り組み

採用を頑張った！　※ 予算が許すならこれが即効性1番です。
クラウド化の推進を行った！
スクラムで運用を行った！

この３点が主だった。

採用を頑張った！

2018年には

インターン生 1名 (2018年10月)

ジュニアクラスを1名 (2018年7月)

ミドルクラスを1名 (2018年4月)

シニアクラスを2名 (2018年6月と 2018年10月)　増員。

(採用を頑張ったのはほとんどリーダーの人だったけど。)

チーム的には、増員によるコストは受け入れるメンタリティが出来ていたし、もっと色々やるにはもっとメンバーもスキルも必要だ！っていうマインドシップが常にあったので若者が多くても後ろ向きな気持ちはなかったと思われる。

新メンバーは旧メンバーを、旧メンバーも新メンバーを敬意を持って仕事していたのでチームは非常にいいメンタリティで過ごせたと思う。上は44歳から下は20歳まで幅広いメンバーが揃ったと思う。

チームファシリティ

私がリーダとしてチームファシリティで意識していた事を振り返ってみる。

取り組みと狙いと結果

スクラムの導入

全般的にはスクラムのフレームワークに乗った感じだ。

個人としてはスクラムを何度か取り組んでは、「思った通りにいかない…」を経験している為、今回が三度目の正直なのだ…

裁量が増えてから取り組んだ為か、視野を広く取り組めた。

スクラムを通じて楽しく活発に働く事を目的としている。スクラムは便利なフレームワークで意図した効能を作り上げる事が出来る道具だと意識している。

スクラムを入れると効率的になる！という盲目的な時期と失敗はもう経ている。チームを作るのは人であり、人を活かす為のフレームワークであると肝に銘じて取り組んだ。

後述するいくつものフレームワークは最初から同時に導入してはいない。チームに効果をもたらすことを意識すると順次入れていく事が望ましいと仮説を持っていたからだ。

イテレーション&カンバンの導入

やった事

2週間でイテレーションを導入した。スクラムに対応したタスク管理サービスを利用し、2週間ごとにイテレーションの開始/終了を行った。イテレーション中のタスクの進捗はカンバン方式を利用した。(そのイテレーションでだけ使うカンバン)

狙い

タイムボックスを区切る事で、"やれる量" を意識していける状態を狙った。優先度付を強制的に行わせたかった。インフラチームは依頼事が多く、タスク管理が属人的＆どんぶりになりがちで、なおかつタスク管理は受け取った個人に委ねられていた為に

* タスク管理能力の高い人しかQDCが維持できない。
* タスクが見えないので若者のフォローが出来ない。
* タスクに振り回されてしまう。集中出来なくて効率が落ちる。突発的タスクにメンタルが持たない。
* 何が優先か？をチームで議論&把握出来る状態を作る (あれ先じゃないの？っていう議論をやめたい)。

という状況があり、タスクを見える化する事と先回りしてやることを決める事でこれらを解決する事を狙った。

結果

狙ったことは満たされた。が、タイムボックスを区切るだけでは "自分たちがタスクに振り回されてしまう" は解消しきれなかった。これは後述の「チームの分割/チームの整備」で語る事とする。

意識した点として、日々同じタイミングで後述のスプリントプランニングとかデイリーミートアップとかを続けたことだと思われる。チームが "スクラムするよね。" って意識を "軽く" 持つ事が続けられる秘訣だったのかもしれない。チームメンバーがスクラムについてなんとなく前向きな印象を持っていた事も導入はスムーズにした事に寄与していると思われる。

スプリントプランニングの実施

やった事

スプリントは 2週間を1スプリントとし、大型の開発では3ヶ月(概ね 6回~7回のスプリント) を 1セット(1クォーター)として目標管理をしていた。大型の開発や新規開発では1スプリントでは進みが小さく全体感が追えないのと進捗が見えないので年間の目標に合わせ、1クォーターでこれくらい完成させるぞ！と、大きめのビジョンスケジュールを組み、そこからタスクを1スプリントに落とし込んでいった。 (チケットの洗い出し手法については今回は記載していないが、これも良いテクニックがある。)

運用保守はクォーターの意識はなく1スプリント毎だけ向かい合った。

大型の開発といっているのは、サービスの基盤をオンプレミスからAWSに移行していく目論見のタスクの事で、1~2年をかける大型プロジェクトである。またアーキテクチャも刷新し、コンテナ化も推進する大胆な移行計画を検討している。とイメージしていただくと今後も読みやすいと思う。

2週間イテレーションの初日にプランニングを実施していた。

(出来る限り必ず初日に)プランニングを開催してメンバーを集めて、次のイテレーションでやるものを選んだ。最初は全員同時にすべてのタスクでプランニングしていたが、関係ない仕事に対してはプランニングモチベーションがわかずよそ見するので途中からはチームを分けて、チームに関わるタスクだけ実施していた。

インフラチームは運用/保守的な仕事と、新規開発的な仕事がMixで、特に前者の方が曖昧さと属人性が強かったのでプランニングの場を通じて関係者に情報がシェアされる状態を作っていった。

※ じつはそんなにかっこよくは実施できなくて半年間なんとか継続してプランニングを開催するがマインドだった。。。というのも、これやって意味ある？ってならないか常にヒヤヒヤしていたのだ…。

スプリントプランニングの流れとしては

前イテレーションで浮いているやつのクローズ＆持ち越し確認 (※ ここで責める事はまったくせずに淡々と持ち越しをやっていく。)
前イテレーションを完了のチケットだけにしてクローズ。ここでどれくらい終わったかが全員でなんとなくシェアされる。
次イテレーションでやる予定のものをざっくり積む。これはプロダクトオーナーの代わりになるインフラリーダーがざっとやる。その後バックログを眺めながら必須タスクがないか？を見た。※ 次イテレーションだけど忘れるとまずい…みたいなタスクは次の次のイテレーションの枠に先に置いたりした。
各タスクをプランニングポーカーしていく。プランニングポーカーを実施するためにタスク起票者(または把握している人)が、以下の点をはっきり述べてもらう。(スクラムマスター(私)が画面上でチケットに議事する。& ファシリテーションする。)

1. 目的とゴール設定 (ゴールは具体的であるほどよいので具体化を対話の中で行う。何が出来たら完了か？をはっきりする。また足りないものがないか？意見を集める。)
2. 作業の全体感とテストの重さ (テストは何をするのか？もここで多少議論を促した。)
3. 期日とその期日が設定された理由 (これは優先度を判断する為のヒアリング項目だった為、オプション的に聞いていた。)

あとは全体を最後に眺めて多すぎたら優先度が "相対的に" 低いものを取り下げて、チーム外関係者にごめんなさいの連絡をした。

狙い

スプリントプランニングでは、やるやらをはっきりする事を意識した。"やらない事" を共通認識もてる様にする為だ。

強い強制ではないが、優先度を会話で決めていた時は、「とはいってもこっちからやろうかな。」と開発者の裁量で (悪くいうと) "寄り道" が生まれてた。

「次何やるかな〜」を個々人が考えていくのは時間の無駄、議論の増加、意思の相違(こっちからやってもらうつもりだった) みたいなのが発生しがちで、それを適度に抑制するために行った。簡単や慣れているものからやってしまう(私みたいな)タイプもいるのでレールを敷くイメージで開催していた。

当初はその場でベロシティを確認しながら、積める量を意識してやっていましたが、結果的にそれは定着できなかった…。(ベロシティの項目で後述する。)

結果

当初狙っていた "やらない事を意識する" "寄り道を減らす" は寄与した。チームがレールに載って動いている感があり、リーダー側から見るとタスク管理に安心感が出てきた。"えーこっちが先でしょ？" っていう会話がめっちゃ減っていた(と思う)。 (※ メンバーが気づいているかはさておき)

回を重ねるに従ってプランニングは慣れてくるので初回に1時間かかったプランニングは、15分程度まで縮小された。事前にチケットにゴール設定等を正しく書いてきてくれる為、議論や促しが減った為だ。

チームで仕事が進んでいる感が少しあったかな？と思うが、あと一歩何かが足りなかったかな…という気もしている。(直感である。)

プランニングポーカーの際にタスクの作業内容/難易度を共有するのが意外な効能だった。

* ゴール設定は何か？
* テストは何をするのか？

等、真面目にポーカーに取組むと "担当予定者" と "担当じゃない人" の間の情報格差を埋めないといけない。その為説明が求められた。

説明によって "担当予定者" は認識がクリアになるり、"担当じゃない人" もその仕事の範疇をしっかり認識出来る様になり、結果的に情報共有の場になったのは意外だった。

ゴール設定の過程で "あれが足りないのでは？” "そこまでやらなくて良いのでは？" という会話がその場で出来たのも良かったと思う。

ありがちだが人によって "ここまでやったほうがいい" みたいなラインが違う為 "やりすぎ" "やらなさすぎ" が後出しで出てくる事を防げたのではないだろうか。

当事者とチームメンバーで同じ方向を見て一体感を持つことにも間接的にも寄与できたんだろうなと思います。

反省点としては、若者/入社したてはスプリントプランニングの場は難しかった事で、そこに対して "時間をかけて" 以外に解決策を見いだせなかったのは反省点かなと思います。

デイリーミートアップの実施

やった事

最初は夕方(17:00)に、途中から朝(10:30)になったが毎日スタンドアップミーティングを開催していた。制限時間は15分。報告内容は一般的なものを採用した。

昨日やったこと
今日やること
困っていること/相談したいこと/報告事項

狙い

端的に言うと進捗を好ましくする為の場である。その中でも意識していたのは以下だった。

* 情報や悩みを抱え込まない環境を作る事 (心理的安全性の確保)
* 本人に一日の仕事何するかを意識してから仕事に取り組ませる事 (考えてから取組む。という癖付け)
* やばい匂いを嗅ぎつける事 (炎上の種の予防)

運営では "言葉の使い方" と "気軽さ" と "議論は別枠で！" を意識していた。毎日同じリズムになる様に、淡々となる様に意識した。開催と終了の言葉を毎日同じ様に繰り返す事だ。

「では朝会始めます。<↑の報告内容> をお願いします。」

「では、今日も一日よろしくおねがいします。」

「白熱しそうなので、朝会後にもう一度相談しましょ。(朝会は報告のみ)」

リズムが淡々とするので、朝会の開催が重くならないし、誰でもファシリテーション出来る環境になった。ファシリテーターを固定化させない為に途中から最後に輪にはいった人がファシリテーションをやる。しようと思ったが、 (私の引き継ぎ先の)新リーダーがオーナーシップ取ってくれた事、おやすみの日は別メンバーが勝手にファシリテート始めてくれた為、やる必要性がなくなった。

朝会は「めんどくさい」と思われたら負けだと思う。それは「こいつらとコミュニケーション取るのは無駄だ。」と思われている状況である。

報告内容を真剣に聞く。とか当たり前の事もサボらない様にする。臭い時は議論をわざと火をおこすが、議論の場は別で確保する等も意図して行った。

白熱する前に「では、朝会後に相談しましょう」となる様に癖付けを意識していた。もちろん終わりのタイミングで、じゃぁさっきの続きを...と忘れないように回収もする。

「朝会があるから、何か拾ってもらえる事がある。セーフティネットになっている。」とか

「朝会の後に関係者を集めてパッと相談できるので、MTGの時間を確保しなくて良い。楽ちん」とかのイメージを持ってもらう様に意識していた。

重くもないけど、軽くもない相談事項については積極的に朝会後に関係者あつめてサッとやる。っていうのを促した。

MTGの場を設けるとどんどん時間を食ってしまう事と、集める事が億劫で悩みを続けてしまったり思考をやめてしまうのを防ぎたかった為だ。

積極的に相談・議論をさせて、良いものを作る。というマインドセットにもかなり寄与していた。

朝会後に相談する事が慣れてくると日中帯でも「ちょっと相談いいですか。」とスッと会話できる状態を作っていっていたと思う。

結果

狙いはほとんど満たされていた。「めんどくさい場。」よりは、「便利な場。」とチームは思ってくれていた(と思っている。)

不思議だが午前中開催の方がうまく回りやすいっぽい。

午前中が良いという論理的な理由が述べられないが、無理やり述べるとすると

夕会の場合、「今日やること」がなくって「今日やったこと」だけになりがちで(そういう場の引力が強い)、そうすると議題に突っ込めない。もう終わってしまったことなので。で、「明日やること」はみんな漠然としていてこれまた突っ込めないし、突っ込んでも翌日また忘れてたりする。なんなら状況が変わったりする。そういう雰囲気が出来上がってしまっていた為に"ただの報告会"に成り下がっていた。「めんどくさい場。」となっていたと思う。

朝会の場合、「今日やること」がこれからの予定なので、「○○気をつけてね。」とか「○○忘れないでね」と声が掛け合えるし、朝会の為に報告事項をまとめてくるので会話が洗練されている。

とかあって午前中がおすすめな印象だ。出社が難しいような朝早く(8:30とか9:30)よりは、出社して15分~30分程度余裕がある所にセットするのが良いように思う。

遅刻をある程度許容できる様にするほうが揃いやすい為だ。

ベロシティの計測と活用

やった事

スプリントプランニングでポイントをつけていたのでそれを以てベロシティを計測していた。予実はしっかりは取らずに、基本的には予定のポイントだけで集計していた。

が、これは結局廃ってしまった…。

狙い

うまく回せなかったが、ベロシティを計測して活用する狙いは以下だった。

* ベロシティを計測する事でタイムボックスで実現可能なタスク量の見積もりの精度をあげる。それによって優先度付をより一層加速させる。
* ベロシティを計測する事でチームが捌ける量が可視化され、数カ月先のスケジュールも立てやすくなる状態を作る。
* スケジュールプランニングを上手になる事で、"個人の頑張りによるタスクの完了" という状態を解消して、タスクマネジメントによってチームの負荷をコントロール出来る様にする。 (チームの負荷のコントロールが出来ると、余白を意図的に作り出して別のモチベーショントリガーを引きたかった)
* 他チームとの連携案件のスケジュールを計画しやすく＆守れる様にする。

結果

結果的にはベロシティの計測と活用は継続できなかった。厳密には、プランニングポーカーでポイントはつけるものの精度へのこだわりが薄くなりベロシティの値の信頼度が低く、活用する程の数字にならなかった。と思っている。

> また当初はその場でベロシティを確認しながら、積める量を意識してやっていましたが、結果的にそれは定着させれませんでした…。(これもベロシティの項目で後述します。)

その為、前述の↑のベロシティの向上を狙った施策とか、ベロシティに合わせたタスクマネジメントは実現出来なかった。

失敗の要因の仮説としては

ベロシティの数字に対して強い意識を持てなかった。(私：スクラムマスターが)
その為に数字に対する感度 / 重要度がチームごと落ちてしまった。
ツールがベロシティの計測をサポートしていたが、仕様により普段の運用方法だと正確な数字が取れなかった(イテレーション完了日後にタスクステータスをDONEにしても計測対象にならなかった)為に、数字を活用しずらかった。
インフラチームは割り込みが非常に多く、事前見積を努力するメリットが薄くなってしまった。チーム外のタスクによって非常にブレてしまう事でベロシティのコントロールを失った。とも思っている。(タスクの割り込みが多く、優先度判断して溢れ分を先回りして落とす。等の作業が毎日発生する状況だったので疲れてサボってしまった。)

これは、また次回やるときには頑張って取り組もうと思う。プランニングポーカーで見積もりはしていたので、ツールで可視化が信頼出来る数字を適切に出来る状態を作っていたならば強い意思を持って維持できた… かもしれない。

ベロシティの計測とバーンダウンのコントロールは連戦連敗中だ。。。サービスの保守運用で適用するにはマメさが必要で苦手かもしれない…。

スプリントレビューの実施

やった事

真面目にスクラムが始まった半年で1回しか開催しなかった為(できなかったので)、まだしっかりやれてないですが書いておく。

元々スクラムを始めたときには導入しておらず、プランニングとスプリントの運用が安定してきた所で開催した。

主なやった事は以下だ。

* 1クォーターの中で開発した成果物のチーム内への共有
* チーム外への発表 & 共有

チーム外への発表 & 共有では、関係する外部チームを招待して、新しいインフラの基盤についてのプロトタイプのお披露目と設計の共有、質問会の場を設けた。チーム内への発表 & 共有では、最終的にまとまった設計とデモを行って褒める！祝う！という事をやった。

狙い

全体的な狙いとしては、

* 達成感を作る。
* 進捗してる感を発信する。
* 新しいインフラへのアプリケーション開発者の適合を促す
* 設計を共有する

だった。インフラは共通基盤的な要素が強い為、個別に開発して成果物が完成してからシェアして、導入していく流れがあったのだがそれが良くないと仮説を持っていた。

作った人が一番くわしいままで引き継ぎが進まない (チーム内の話)
導入先の理解度が高まらない (今後、開発や保守を部分的にも引き継げない) (チーム外の話)
(難易度は高いのに) 達成感が少ない (個人の話)
使う人達からのフィードバックが遅い(導入後にしか貰えない)為、導入後に要望が増える。設計間違いに気づく。

のがあり、それを解消する手段としてスプリントレビューを活用しようとしました。

結果

1回しか開催できてないのでなんとも言えないが

チーム外に発信する場が出来たのは良かった。受け入れ側も「おぉ！いいね！楽しみ！」とか「そろそろAWS勉強しないと！」と、マインドを持って帰ってもらえたので心の準備が進んだと思われる。今後推進していく為の土壌が育った感じがあった。受け入れ側も「どこまで何が進んでいるんだろう？」というのが見えなかったのが少し見える様だ。

"新しいモノは楽しい！" っていうみんなでワイワイ出来る場になったのは良かったと思う。一体感が出た。敵対しあうのではなく同じ仲間で改善に向かうマインドに寄与したと思う。

チーム内に関しては、最終的な完成形 (途中の議論は知っているが) を把握する場となり、情報共有が出来る様になった効果はあったなと思う。

達成感みたいなのはもっとお祭り感を出していったほうがよかったと思う。乾杯とかしたい。

一般的な書籍に書かれるスプリントレビューよりかなりカジュアルに実施したのが良いか悪いかはまだ判断できないが、共通部門的な動き方をするチームには良いのかもしれない。

プロダクトバックログリファインメントの実施

やった事

ほとんどやれなかった。スプリントプランニングの際になんとなく全体を眺める。くらいしか出来なかった。

狙い

リファインメントの実施の必要性をインフラチームでは認識できず、後送りにしたまま半年が過ぎてしまい、1年を終えた。

やることの優先度付で必要なのはわかっているが、ついつい後からくる優先度高いものに取り組んでいるとバックログの中に古いタスクが残ったままとなっていた。

バックログに対する効果的な打ち手 / スケジューリングが出来なかったな。という印象である。

結果

あまり真面目にやれなかったので特に振り返りはない。

本当は計画的に改善系を少しづつ取り組む。とかしたかったが日々の保守に負けない様にするので精一杯だった。

レトロプロスペクティブの実施

やった事

振り返り会も1回しか実施できていない。本当は早くから導入したかったが、私が開催する振り返りがうまくいかない例が多くあり苦手意識もあって先送りしていた感じだ。^^;;;; また、振り返りに対するニーズがなかったので、チームから「振り返りしたほうが良いのでは？」という意見を待っていた事もある。自主性に勝るものはないのである。

という訳で、出てきたタイミングで開催を始めた。

開催方法は KPT + Lean coffee という手法を独自で考えて実施した。

最初によかった事、よくなかった事をポスト・イットで一人２個づつ書き出す。
ポストイットをグルーピングする。(重複を重ねる、似た議題をまとめていく)
「せーの」で最初に議論したいカードを指差しする
7分間、改善の為の議論を行う。
7分後、多数決で議論を継続するかを確認する。
継続ならもう5分追加する。 (-> 5に戻る/繰り返し)
MTGが残り5分になったら強制的に終了する。まとめをする。改善アクションの整理と担当を決める。
終わり

狙い

レトロプロスペクティブをする事でチーム/個人がよりステップアップできる改善策を見つけて、改善していくのが狙いだ。レトロプロスペクティブを通じて PDCAサイクルをぐるぐる回して、チームで「おぉ！我々は成長して学んで強くなっていっている！」という自尊心を高めたり自信を高めていきたいと思っている。そのサイクルの起点になるのがレトロプロスペクティブだと思っている。

ただ、私の過去のレトロプロスペクティブでは KPTを通じて内容も大量に出るし、それなりに次のアクション等も検討があがるのだが以下の問題点があり、「レトロプロスペクティブは辛いもの」「レトロプロスペクティブは効果がイマイチ」と思われてしまう事が多くPDCAのサイクルが加速するどころか停滞させてしまう要因になっていたと思っている。

1. 改善が多すぎて次のレトロプロスペクティブまでに改善に着手できていないものが多い。「やっても改善仕事できへんやん。」という状態になっていた。
1. 改善が多すぎて改善の仕事が増えまくる(なおかつ、捌けない)。やったほうがいいのはわかるがやれない。みたいな状態がレトロプロスペクティブのせいで作られていた。(その結果、タスクが多くて終わらない〜！改善仕事なんて後回しだ〜！みたいなマイナスメンタリティを作る要因になっていた。)
1. レトロプロスペクティブ後に取り組むアクションが重い (設計、調整、実装などフルセットある)ので着手が辛い。優先度後にしてしまう。

今回は、レトロプロスペクティブが重いタスクを生みすぎてしまう事を防止しつつも全員がやってよかった。改善した！と実感できるレトロプロスペクティブを企画した。

問題意識が高い / 興味が強いものを選んで
それの解決策をその場で練る (設計レベルまでしてしまう。)

となる様に仕掛けた。

結果

開催した1回では、1個の議題しか議論出来なかったが、非常に問題意識に高いポイントに絞って解決したので満足度が高いアクションが取れた。また設計も有識者達がその場でパッとしたので、実質1時間程度の枠組の中で実装以外の面が解決までもっていけて、軽めのタスクをこなすだけで解消する。という状態をレトロプロスペクティブ後に作れたと思う。

またやってもいいかな。とメンバーが思ってくれていれば大成功だ。

マイナスな振り返りが減ってきたらLean Coffeをやめてみて、KPTで出てきたものの半分くらいをActionにしていけばいいのかもしれないが、

忙しい日々の中で、何か一つだけでも！！！とやるのは結構アリだと思うし、ゲーム形式を取り入れたので他の課題が無視されてしまったなという

意見を受け入れられなかった。という事も感じさせずに良かったと思う。

チームの分割/チームの整備

チームの分割とミッションの明確化

やった事

スクラムをやっている中でチームを分割した。インフラチームが3名 -> 7名程に膨れた中で、一つのボードでスクラムをやってると優先度付において良くない傾向が目についた為だ。

具体的には、

未来の基盤となる新規開発(投資的な開発)と、

既存を運用する為の開発(保守的な開発)と、

がMixされるとどうしても前者が優先度付で弱くなる傾向があった。

これはリーダーの資質や大胆さの問題も含まれているのだが、チームのミッションが大きすぎて不明瞭な為に優先度付が狙った方向に行かないのではと仮定した。

チームが邁進するにはミッションが明確な方が良いよねとの事で保守運用のチームのミッションと、新規開発のミッションを一緒にしない事でよりチームを加速させる様にした。

狙い

新規開発(未来の投資的な開発)を行う、AWS化推進チームと、コンテナ化推進チームと、保守運用チームの３つに分けた。

それぞれにミッションを定義し(保守運用チームのミッションは難しいのだが...)、しばらく運営した結果、人的リソースの関係と設計の関係で AWS化推進チームとコンテナ化推進チームは一緒になり、

「1年以内にインフラのアジリティとスケーラビリティをインフラに確保する」というミッションを定義し、

* 脱オンプレ/AWS化 の推進
* Infra as a Codeの推進
* コンテナ化の推進

に取り組んでいる。ここに所属するメンバーはこのチームのミッションが最優先となる為、オンプレミスの環境の保守運用については、あまり意識しなくて良いように(集中してAWS化のコードをかける様に)なった。

保守運用チームは、「引き続き現状のクオリティを維持ししていく。」という低めの目標で、ただし関与するメンバーが若手とシニア1~2名と少ないメンバーにする事にした。ここにコストをかけるよりAWS化にコストをかけるという判断だし意思表示でもあった。

結果

これによってAWS化の開発速度が爆速になった…!!! 集中的出来る状態、取捨選択しやすい状態を作る。というのは正義だなぁ。という感想を持っている。

主担当の人の頭の中のコンテキストスイッチの回数が明らかに減ったので集中して設計＆実装が出来ている様に見えており、結果として、プロトタイプの出来上がりが5ヶ月後を想像していましたが3ヶ月で実現出来た。

保守運用においても「これはAWSに行ったら解消するし…」みたいなのを割り切ってやらない。という方に舵を切れる様になり、またクレームが入る事も減った。以前はAWSに行ったら…とは行ってもいつ行けるの？という状態で悩んでスケジュールを押す事も多かったが、割り切る事でスピードもあがった為だ。

目的がゴチャっとしたら、メンバーに判断の回数が増えたり悩ましいことが増えたらチームを分割するのはおすすめだ。

オンボーディング / フォローアップ

やった事

これは2年前からやっている非常に良いアクションだ。新規入社の人には必ずやってるオンボーディングである。

1. オリエンテーションのDocを用意する
  - 受け入れの手続き一式 (カレンダーへの招待とかSaaSへの招待とかWelcomeランチとか) (受け入れ側向け)
  - 作成するアカウントとかの一式案内 (以下、受け入れ者向け)
  - Slackのチャンネルの案内
  - キャッチアップドキュメントの案内
1. 入社後は毎日1時間既存の環境についての説明会の時間を設ける
  - 提供してるサービスの全体像 / システムの全体像(DC/サーバー構成) / ビジネスの全体像
  - ミドルウェア構成 
  - CI/CDの構成とか運用とか
  - 社内環境とか
1. 立ち上がりに必要なタスクを狙って見繕う
  - 立ち上がった後にどうなって欲しいかをイメージしてタスクの見繕い
  - フォローアップの体制も一緒に
  - 期限緩めのやつから

狙い

以下に早くチームで立ち上がって自走できるか。を意識して企画している。どちらかというと中途転職者向けだ。新卒だと理解できない内容が多い為だ。(だが実施はする。その場を通じて学びにもなる為だ。)

立ち上がりは、"見て学べ" よりは "しっかり伝える" "一人で情報を探せる" "手続き系に迷わせない"事を意識してオンボーディングを開催している。

特に説明した内容のソースコード、ドキュメントの場所をしっかり伝える事で、後ほど一人で探したり振り返ったり出来る様になる事を意図している。

自走の定義は、

自分で問題点が把握できて
自分で調べて
自分で仮説を立てれて
自分で結論を導き出せて
自分でレビューをうけたりしてクオリティをあげられる。

というイメージをしている。その為に必要となる情報やオーバービュー(全体像)は先人から引き継ぐのが最も早いと考える。

結果

これはやらない理由がないくらいに、立ち上がりが早い。

"あれってなんか聞いた気がするけどなんだっけ？" って会話になるのが良い証拠だと思う。

頭の中にIndexが貼られた上で作業すると、優秀な人ほど初回から正しいゴール/答えを出せている印象だ。

"育てる"という負荷も減る為、新しいメンバーに対する心理的負荷を下げる事にも寄与していると思われる。

マインドの醸成/対話

やった事

日々、対話しながら、チームはこうゆうマインドセットを持っていくといいよねー。みたいなのを模索している。リーダーとしてチームを作っていく上で個性や文化になるポイントだ。

それをどうやって持たせるか？は会話だったりスクラムのフレームワークを通してだったりするが以下のようなマインドを持つように会話を行っている。

* とにかく明るく、楽しく
* チャレンジな失敗は褒める / 貶さない ( challenge )
* 新メンバーは積極的にみんながフォローする ( all for one )
* セクショナリズムを持たない ( one for all )
* 課題は技術で解決する (technology driven )
* 批評家にならない
* 器を大きく
* あるべきを考える / 本質的を想像する
* 個人を責めない、仕組みを責める
* 当事者意識を持つ
* 意見を批判しない。意見を尊ぶ
* 敬意を持つ (スキル不足をバカにしない)

狙い

こうゆうマインドのチームは強い。成長する。貢献度も高い。他のチームへも良い影響をもたらす。楽しい。という考え方だ。

楽しく！成果高く！を実現する為のマインドシップと思ってそうゆうチームになるのがいいかなー？と思って会話をしている。

日々の中で、いや、こうじゃないな。もっとこうだな。ってのもある。それは日々対話を通じて修正を行っていく。

例えば、中央集権的にハンドリングするほうが幸せかと思ってたけど、インフラも含めて権限委譲を進めてプロフェッショナルな部分だけ関与していくとかプラットフォーム部分だけ関与していく。と可能がいいのかも。とかはやっていく中で気づいていったりしている。

若者も、玄人も育つ環境だし、ブラックさ(過酷さ)を使わずに育てる環境を意識するとこうなってきた感じだ。 Web屋っぽさを感じる。

結果

意図した通りなチームになっていると思う。

* 意見は活発に行われる
* 心理的障壁は低い
* 若者も活躍できる / 積極性を持てる
* 働いていて楽しい
* 探究心は挫かれない
* 好奇心は褒められる
* チャレンジ精神も褒められる
* 失敗は経験値になる

スキルの交換/発火のきっかけ

やった事

タスク振る際に、意図してやっている事を紹介する。

Aという初タスク、ZZZさんが実現してくれました。Aの横展開でBというタスクが来る。ZZZさんが経験値もあるのでサクッとやるのが早いが、タイミングがあえば、あえて未経験のYYYさんに任せてる。(で、ZZZさんがフォローに入ります。)

つまり、慣れている作業ばかりを(タイミングがあれば) やらせない。

慣れてる人が慣れてる作業やりがち ^^; なので入社/退職等があるタイミングとか、ダイナミックにチーム変更するとかのタイミングでこのカードを切る様に意識している。

ただし、新規開発案件の場合は立ち上がりに開発スピードが大事な面もあるのである程度は属人性を認識して走らせたりしている。

プロトタイプやパブリックβ版が出来上がったくらいで、改善案件とかバグ対応から別メンバーに実装を引き継いだりしている。

狙い

スキルトランスファーによるスキルの冗長化 (属人性の解消) と、成長のきっかけづくり。

知ってる作業ばかりじゃなくて、知らない作業をやる事で "知らない事" に気づけるきっかけになる。

チーム的には属人性がなくなることで保守の可用性があがってWinWinである。

教える側も教える事を学べるし、引き継ぎの為に必要な情報の過不足も認識する事ができる。

小さく失敗して見直せるいいタイミングとなる。

頻度高くやりすぎるとチーム負荷があがる為、狙ったタイミングで実施している。いつも数日で終わる作業が2週間かかるかも。みたいな見込みを考慮し、全体調整も行った上で取り組んでいる。

見えない所でのフォローアップ/お膳立てが重要である。

結果

誰々さんに聞かないとわからないな。っていうのが減った。

3名の時はしょうがなかったが7名もいて、属人性があるって相当チームとしてはレベルが低いと思ってたので、解消できてよかった。

スキルの高い人のスキルマップで、まだ知らない所。を知るきっかけにもなった。(人は完全ではないのである。)

待つ。

やった事

育ってくるのを辛抱強く待つ。これ結構大事なファシリテーション(?)。

急かさない、期待をいだき続ける、辛抱強く待つ、サポートを続ける。

これらを新メンバー入る時や新卒等の若手がいる時、新しい技術に取組む時には意識している。

立ち上がってくるまでには個人差があるので、適切なサポートはしながら立ち上がりは辛抱強く待つ。 1ヶ月くらいは、うまく回ってなくても辛抱強くまって、頭出ししつつ、聞かれたらフォローくらいにしている。スキルが低いと、ゴールに到達するのが遅いのですがそれも含めて辛抱する。

また、あえて知らなさそうな仕事や今後使っていくであろうスキルが必要な仕事をワザと渡している。

(これは受けたアドバイスだが) 1ヶ月くらいは積極的な関与/施策を打たずにベーシックなサポートだけして立ち上がりを見てみる事で、その人と成り、行動指針、癖が結構見える。

狙い

心理的安全性 / 信頼感が生まれるのを狙っている。立ち上がった後の振る舞いが前向きになる傾向がある。(臆病にならない)
その人と成り、行動指針、癖を見抜くタイミングにしている。

その間に、何が得意で何が苦手かを横から見ている。半月から1ヶ月くらい経ったら、その人にあったアプローチでフォローアップを積極的に行い立ち上がりのサポートをする。すると、本人も途中から "○○が足りなかったかな？" とか気づく。

現在の仕事において知らない事を知るいい機会になる。

あと新しいものに触れる時は情報のインストールが必要なので、その時間をちゃんと確保してあげる事で立ち上がった後のクオリティやスピードも上がる。

結果

まずあえて期待しない事で、立ち上がり期に入社したメンバーが成果を出さない事にイライラしなくなる。(笑)

立ち上がった後に戦力になるまでが早くなる。応用力も上がってる印象。

その人の事の理解度があがるので立ち上がり後のメンタリングもやりやすくなる印象だ。

振り返り

一年取り組んできたチームファシリテーション (≠ チームマネジメント) についてつらつら書いた。漠然と頭の中でやってきたことが文字化できて疲れたけど満足。また未来に対して貯金が出来たと思う事にしよう。

ファシリテーションをやっても狙っていたことができなかった事としては

* PDCAサイクルを回す事によって改善していく実感をチームに持たせる
* チームがどんどん高速化していって自尊心/自信がみなぎる

こうゆうのがスクラムの効能であるんだけど、引き出せてないな～と反省している。

過去の失敗したスクラムと今回うまくいった面を振り返ると差分が2点あると思う。

* スクラムマスター(私)が人を見れる様になった。
* チームメンバーがスクラムに対して正しい知識を持ち合わせていなかった。

前者は年齢と経験によって良くなってきたと思うが、後者が以外にも大きな影響を持っていたのではないか？と推測している。

新しい仕組みは抵抗感が生まれるが、メンバーがメリットとデメリットをなんとなく認識している事で、"スクラムを回す"事自体を、改善しつづける体質にチームがなっていくのが速かったと感じている。次回のチームはスクラムに慣れる所からフォローしたいと思う。

前者に関しては、うまくまだ伝えられないが、メンバーをプロファイリングして自分なりに理解する様に意識をしている。何が好きで何が得意なのか、次の成長には何があるといいのか等を日々意識して考えている事で力がついてきた様に思う。狙った所に狙ったボールを落とすに重要なスキルである。

また、スクラムの弊害(っていうと違う気もするけど)として効率化しすぎて遊びがない。面もどうしたらいいかな？と考えている。 "遊び(余白)"って大事で、"遊び(余白)" の時間があると

* 自己学習したり
* 遊びながら腕を磨いたり
* 興味や好奇心を発揮できたり

と、仕事とは別軸でエンジニアをやること。ものづくりをやること等に対する楽しさを再発見する場になったりする気がする。

そうゆう場をスクラム(というか現場)の仕事の範疇だけでやるには狭すぎるので、うまく "遊び(余白)" を作ってキッカケづくりに活かしたいなと思っている。

ものづくりするメンバーが * 楽しく * 明るく * 前向きに

で、働いて行くことが

成果もあがる
スキルも上がる
給料もあがる

と思っている。