猫が吠える

我輩は猫である。名前はみずき。

スクラムフェス札幌でスクラムやめた話をした - 私とスクラムの一年記 #scrumsapporo

この記事はスクラムフェス札幌アドベントカレンダーの23日目です。
adventar.org

スクラムフェス札幌に参加しました。初めての社外イベントでの登壇もしました。
www.scrumfestsapporo.org

登壇の経緯

 1年ちょっと前、2019年10月ごろにスクラムというものに出会って、11月からスクラム開発を始めた。スクラムマスターというのを名乗ってみていた。でもスクラムマスターってなにしたらいいいのかよくわからなくて、アジャイル札幌の紙粘土スクラムとか、Regional Scrum Gathering Tokyo(RSGT) 2020とかに、救いを求めて参加した。RSGTのときに、今回のスクラムフェス札幌の実行委員長でありRSGTに誘ってくれた人物でもある根本さんに、スクラムフェス札幌にプロポーザル出してよって誘ってもらった。
 当時スクラムに出会って2か月ぐらいだったのでそんな人前で話せることなんかないですよと思ったけど、プロポーザル出すというのはいまの私でもできるな、聞きたいと思ってくれる人がいたら(アクセプトされたら)しゃべろう、と考えて出すことにした。アクセプトされた。よーしフルリモートでスクラムチーム立ち上げてスクラムやってるよって話をするぞーと思っていたら、コロナ禍により開催延期。そして延期期間中に私はこのチームから抜けて、チームはスクラムをやめたし、その後チームが解散した。
 9月、11月にオンラインで開催することにしたけど話せますかと連絡もらって、とりあえず話しますって返事して、この状況で話せることを考えたけどわからなくて、困って根本さんに相談しにいった。相談内容をまとめてたら「なにもわからない」「つらい」「話せることがない」になってしまった。スピーカー降りようかなと思いながら相談しに行ったら、成功の話ばかりじゃなくてうまくいかなかった話も欲しい、共感するひともいるだろう、失敗からこそ学べるんだからぜひ話してよ、4月時点よりおもしろい話になるよ、と言ってもらった。ビールと日本酒たくさん飲んで、はい!しゃべります!がんばります!って言って帰宅した。
 うまくいかなかった経験として外で話してきてもいいだろうかとチームメンバーたちに相談したら、「ぜんぜんOK」「なにも隠すことない」って快諾してくれた。チームの歴史をふりかえりつつ、それぞれの時期にメンバーがどう思いながら開発していたのかなどインタビューした。メンバーたちには「いいかんじに発表できるように頑張ります!」とか言ってインタビューを終えたけど、そこからいったい何を伝えられるのか、よくわからないまましばらく悶々とした。開催直前になんとか資料にまとめて社内でリハーサルしてフィードバックもらった。社長とかも、なにも出しちゃだめとか言わず、いいね、頑張って、と送り出してくれた。でもなんか綺麗なストーリーにならなくてまた悶々として、発表当日にやっと言いたいことがわかった。私たちが実践してみたこと、実践してみてスクラムむずかしいって思ったことを、ひとつの経験として共有しよう、成功体験じゃない話をこういう場ですることで、だれかがじゃあ自分も試してみようかなと思うきっかけになれたり、だれかをちょっと勇気づけるようなことができたりしたら、私が人前で話をする意味があるんじゃないかな、と思った。

発表内容

speakerdeck.com

 今回のチーム、スクラム経験者もコーチもいない中、本やインターネットや社外コミュニティを頼りに手探りでスクラム開発をやってみた。チームとして開発を"じょうずに"やるために、いろいろ取り入れていった。取り入れて変化していったらスクラムじゃなくなった。スクラムじゃなくなってから開発は加速した。このチームにおいては「スクラムじゃない」状態になってから開発がちょっとじょうずになってきたので、スクラムフレームワークにのっとるよりもだいじなことがなにかあったんだろうと思った。だいじなこととは、開発者一人一人が、信念と自信をもって手を動かせることだ。信念と自信をもって手を動かせるようになるために、自分で手を動かして経験して、経験から学習していきたい、という話をした。
 良い手の動かしかた、手を動かせる環境の整えかた、失敗のコントロールのしかた、結果の計測のしかた、計測結果の活かしかたなどを明らかにして、じょうずに開発をやれる状態になるまでを再現性のある方法で表現できるようになるといいなと思うけど、それはまた今後。

登壇の感想

 発表が終わってから、何人かに、良かった、響いた、って言ってもらった。なにかを解決するような提案とか再現性のあるやりかたの紹介とかがないのに響いたって言ってもらえたのは、この話が頭の中で考えたことじゃなくて自分で経験したことだからだったのかなと思う。
 そして、話すのに勇気のいる話だったろうけどそういう話こそ聞きたい、失敗の経験を共有してくれて嬉しい、メンバーのみなさんにも良かったって伝えて、とも言ってもらった。社内で発表の動画見て、もらった感想も共有して、このチームのメンバーたちにも感想を聞いてみたら、こうして後からふりかえることでここまでやってきたんだなって自信になったとか、当時は苦しかったけどメンバー同士相談しながらなんとかやってきて、その過程について外からの感想をもらえて嬉しいとかってコメントをもらった。外で話してよかったなーと思った。うまくいかなかった話こそ聞きたいんだよっていって背中押してくれた根本さんには感謝しかない。ありがとうございます。
 島田さんの招待講演でアジャイル札幌立ち上げの話を聞いて、ああこうして先輩たちが必死に作ってきてくれた道の上にいま乗ってるんだなって、スクラムフェス札幌という場を作ってくれるひとたちがいて話ができるんだなって、すごくありがたいなと思った。

その後

 スクラムフェス札幌が終わってすこし経って、今のチーム内で、スクラムという名前では呼ばずに「イテレーション区切って小さく計画しみんなで仕事しこまめにふりかえる」ことを始めた。今回発表したチームでの反省やこの1年で得た知識によって、いまは前より「じょうずに」チームでの活動をやれてるんじゃないかなあと思う。手を動かして、経験して、計測して、学習して、再現性のあるものにしていきたい。ただなんかエモい話するだけで終わらないように、よりよいやり方を見つける旅をすすんでいきたい。

#1on1カンファレンス -「対話」を通じた「人の支援」を考える日- に参加した

1on1カンファレンス -「対話」を通じた「人の支援」を考える日- に参加しました。
www.conf.1on1meeting.org


 職場では、1on1というのはそれほど根付いていないのだけど(評価者が思い出したときにたまにやるぐらい。だれかにやろうよって言えばいつでもやれるけど、継続はしてない。)、私はこの夏あたりからリーダーとしてメンバーと1対1で面談したり、1対1でなくてもチームメンバー・社内メンバー・社外関係者と対話をしたりすることが増えてきた。「うまく対話できている」という感覚はなく、相手の意志や気持や機微をくみとれてないなあと思ったり、私の考えも伝えられてないなあと思ったりしていたところでこのカンファレンスを知り、申し込んだ。まわりの人たちと「うまく対話できる」状態に近付けるといいなあと思って。


 一日いろんなお話を聞いて気づいたのが、私は私の見ている世界だけでものごとの善し悪しを決めてかかっていたこと、それを周囲に押し付けようとしていたこと、周囲のひとたちの話をちゃんと聴けていなかったこと、それでは「うまく対話できる」状態にはなれないこと。「相手を変化させようとしても伝わらない」「まず自分がやってみてその姿を相手に見せる」「相手の話を聴く」というようなことを意識していたつもりだけどできていなかった、変化させようとばかりしてしまっている、しかも私に見えている世界だけをもとに、と気づかされた。なので、「ちゃんと相手に意識をむけて話を聴いているか」「自分や、自分のやりたいことばかりに意識が向いていないか」「自分に見えている世界だけでものごとを判断していないか」と、自分自身をつねに冷静に観察して認識する訓練をしよう、と思った。


 朝一、臨床心理士である重宗祥子先生。カウンセリングにおける対話についての講演と、主催の小澤さんをクライアント役としたカウンセリングのデモンストレーション。講演のなかで印象にのこったことを箇条書きで。

  • 自分の人生をより良くしたい・変わりたい人がカウンセリングを利用することも多々ある
  • カウンセリングは医療行為ではないので自費負担となることが多いが、それは自分で自分をささえるという意味で有意義なことでもある
  • 発される言葉だけでなくすべての感覚を動員して全身で話を聴く、自分というバイアスを理解する(離見の見)
  • こちらからアイディアを出したり押し付けたりするのではなく相手のなかにあるものを引き出すこと(これは教育というものも本来そういうものなのでは、と先生は言っていた)

 こういうお話を聞いたあとのカウンセリングデモ。”パフォーマンスが出なくて、上司に「ちょっと社内のカウンセリング行っておいで」といわれた若手社員”役の小澤さんを相手に重宗先生がカウンセリングする。講演で言われていた上記のような内容を体現していくあざやかさと、相手を安心させながらしんどさをすこしずつ言語化して問題をさがしていくやさしさにすごく感動した。
 さいご、参加者からの質問にこたえる時間で「オンラインでの対話のコツはあるか」というかんじの質問への回答のなかで「この1年で、オンラインでもできることがあるというのはよくわかってきた。オフラインで会えないからあれができないこれができないではなく、できることについてはできると発信していく必要がある」と話されていて、それがすごく嬉しかった。私はもう何年もフルリモートで個人事業主をやったり会社員をやったりしていて、それほど不自由を感じなかったし、そもそもひとと顔をあわせて話をするようなことが苦手でもあるのだけど、さいきんはリモートワークが浸透した反動のように「やっぱりオフラインじゃないとね」「オンラインでの会話やコラボレーションはやりづらい・できないよね」というようなコメントばかり聞いていて、オンラインって悪いことばかりじゃないんだけどな、と思っていたところだったので。オンライン・オフラインそれぞれ向き不向きがあるし、人によってどちらが得意かもいろいろだから、一律でどちらかが良い悪いじゃなくてそれぞれ合うものを取り入れたいよねと、1on1や対話の本筋とははなれるけど、思ったのでした。


 午後から、いろんな肩書・経歴の登壇者の方たちがそれぞれの立場・状況で1on1や対話に取り組んで得た体験や知識やノウハウなどを共有してくれた。1on1というものについて私はあまり経験もないし勉強しているわけでもなく、先人たちの得てきたものを分けてもらえるこういう場はほんとうにありがたい。以下のようなことを得た。

  • 「話を聴く」ばあい、自分ではなく相手にフォーカスすること。答えは相手のなかにある。
  • 相手の話を聞くのだけど、聞いているのは自分であり、自分がどう受け取ったのか(つまり自分自身)を理解しながら相手を理解し声をかけていく(「自分というバイアスを理解する」はなしだ)。これは、エンジニアでもあり産業カウンセラーでもある長谷川拓さんが発表のなかで”対話に参加することで自分自身を理解する”ことを体験するワークを提供してくれて、ものすごくむずかしい、ということがよく感じられた。
  • 「コミュニケーション」とは、たがいのできごと・考え・感情を交換すること(押し付けではない)
  • 話をするひとの安全(他人から心にブレーキをかけられない状態)を確保することが大事。そしてそのためには話を聞く側の安全も欠かせない。
  • うまくいかなかったことを書きだしておいてパターンを抽出すると、「馴染み」の問題ができてきて安心が醸成される


 最後は認知科学の教授である三宅芳雄先生による「わかるとは?」という講演。
 「綿1kgと鉄1kg、どちらが重いか?」、同じだ、と当然のように答えてしまうけど、それって正しい?「重い」という言葉を物理学が横取りしてしまったから同じだと思うのでは?と。ものごとをある側面から理解し理論を完成させても、それはその側面からの理解でしかなく、他の側面から見ればまた違う見えかたをするかもしれない。「わかる」ってなんだろう、ひとつの側面から見て「わかった」からって、なんなんだろう、という話だった(と、私はとらえた)。
 一日かけていろんな視点や立場からの1on1や対話についてのお話を聞いてきて、相手の話を聴くこと・自分というバイアスを知ること・そのうえで対話をすることについて考えさせられていたところで最後に「わかる」ってなに?、「わかる」ことなんてある?って話がされて、さらにいましめられた気持になった。たぶん先生は聴衆をいましめてやろうなんて思って話してはいなくて、ただご自身の世界の捉えかたのほんの一片を共有してみてくれただけなんだろうと思う、ご自身が「自分もまだわかっていないのだけど」という気持がある上で私たちに話をしてくれているのだというのが伝わってきて、「わかる」ことを追求しつづけてもまだ世界はわからないんだ、私が私から見える世界だけで話をしようとか、ましてや相手や周囲を変えようだとか、なんて傲慢なことをしてたんだ、と感じたクロージングキーノートでした。
 三宅先生のお話がおもしろかったのもあるけど、カンファレンス全体として「対話」というテーマが一貫していて、いろんなバックグラウンドや経験から対話について話してくれる方たちがいて、最後に「わかるとは?」を持ってくるこの構成、超すごい。一晩かけて咀嚼しないと理解できなかったけど、強烈に「対話」というものを考えさせられた。超よかった。

ひよっこ野良スクラムマスターによる #RSGT2020 感想

はじめに

 2020/1/8, 9, 10と、Regional Scrum Gathering Tokyo 2020に参加してきました。
 3日間参加して疲れ果てたので帰りの飛行機はぐっすり寝ようと思っていたのに目を閉じたら聞いた話がぐるぐると脳内を駆け巡って飛行機も電車も寝られず、いったん吐き出しておかないと夜も眠れないと思ったので吐き出します。とりあえずはなんの資料もノートも見直さず、私が感じたこと・解釈したことを書くので、参加レポートを期待して読むとがっかりすると思います。

参加の経緯

 アジャイル札幌の紙粘土スクラムに参加したときにスクラム始めてみたけどうまくやれてないって話をしていたら、チケットあるけど行かないかと誘っていただいた。行きたい!って言って、家庭内稟議と社内稟議通して参加させてもらいました。プロジェクトの話、うまくやれてない感の話は
n0mzk.hatenadiary.jp
n0mzk.hatenadiary.jp
あたりに書きました。あと、家庭についても課題を感じている。
n0mzk.hatenadiary.jp

 私はソフトウェアエンジニアはそろそろ3年ぐらいやってるとはいえ積極的に仕事や技術に向き合い出したのなんてほんの最近っていうひよっこエンジニアだし、スクラム勉強しだしてからはまだ2か月で、見よう見まねでスクラムマスター的な役割を社内でやらせてもらってるひよっこよわよわ野良スクラムマスターです。界隈の強い人とか有名人とかぜんぜん知らないでいきなり参加しました。学んだことあまりにたくさんあるけど、とりあえず今晩の安眠のために現時点でとくに印象に残ってることを吐き出します。

スクラムマスターの振る舞い

 スクラムやってみてるけどあんまりうまくいってない気がする、スクラムマスターどうしたらいいんだ、って思って参加した。これからやっていけそうだなっていうヒントをたくさんたくさんもらえた。
 参加前、スクラムチームとしてよい仕事をしていくためにどうやってチームを変えたらいいんだろう、メンバーになにをしてもらったらいいんだろう、なにかしてもらうためには私はどうしたらいいんだろうって考えてた。そうじゃなくて、まず自分が変わることと、チームに考えてもらうことだとわかった。

自分から変わること

 自分がやりはじめたら周りもそれを見て変わるかもしれない。私が行動・実践していたら、周りもよりよいマインドを持ち、よりよい行動をとろうと思うようになるかもしれない。最終日のスポンサーセッションでも、こんなイベントに参加してこんなこと学んできたんだ!やろうよ!!って一人テンション高く行っても周りには伝わらない、自分が行動し実験していこうという話があった。

チームが考える

 2日目夜の飲み会でスクラム道関西の強いアジャイルコーチ、スクラムマスターの方たちにカウンセリングしてもらったのだけど(贅沢!)、スクラムマスターはチームを導いたり変えようとしたりする役割じゃない、チームに考えてもらう、そのためにチームをよーく観察し、チームに質問を投げ、チームのまわりの調整やコミュニケーションをし、チームが楽しく気持ちよく動けるようにする役割なんだと話してもらった。それと、チームに対し選択肢を示すこと。チームはその選択肢を実験してみて、振り返り、自分たちのチームに合ったやりかたを自分たちで見つける。

コーチズクリニックとコーチズカウンセリング

 1, 2日目、アジャイルコーチに1対1で相談できる、コーチズクリニックというのがあった。めっちゃありがたい。コーチのみなさんがアジャイルスクラム人生のなかで培ってきた知見を分けてもらえるなんてすごい。やっとむさんにご相談したら、具体的な選択肢をいくつも提示してもらえた。すぐにチームで実験してみたい。ただし、一人で舞い上がってやろうぜ!ってならないように。
 飲み会でアジャイルコーチ・スクラムマスターの方々に相談・質問した。コーチズカウンセリングは今私が勝手につけた名前。スクラムマスターの心構えを聞けた。人たらし力が大事だよという話があり、それはたしかにそうだなと思うと同時に私はもともとコミュニケーション得意じゃない上に北海道に来てから引きこもって在宅リモートワークしてるうちに人たらし力をすっかり失ってしまったと感じている。でもそう話したら、ちゃんと目見て会話ができるし、スクラムやってみて、2か月経ってなんかうまくいってないと感じて、チームをよくしようとしているんだからスクラムマスターの素質があるよ、向いてると思うよなんて言ってもらえて、とても嬉しかったしすこし自信を持てた。

英語、コミュニケーション

 今回、おもしろそうなのに英語だからって話聞くのを避けたり、日本語を話さない人とコミュニケーション取れなかったりして、あ、やっぱり英語必要なのか、と思った。これまで英語を勉強するモチベーションがなかったのだけど、英語わかるとすごくいいことあるんだなって思ったので、英語やりたい。ひどい英語で話せるのがアジアのコミュニティのいいところだって言ってたし。
 あとコミュニケーションそのものに対する苦手意識はまだまだあって(昔は人前で食事できなかったのでだいぶ克服したとは思う)、こちらから声を掛けに行けなかったり輪に入りに行けなかったりした。でもありがたいことに話し掛けてもらって会話をしたり、頑張って参加し頑張って発言したらいいことあるんだなって実感もできたから、コミュニケーション苦手だって言ってるのってすごくもったいないなと感じた。クロージングキーノートの「自分のリビルド」の話、すごく響くものがあったので、私も取り組んでいきたい。でも無理はしない。

優しさ

 エンジニア怖い厳しい人が多いと感じることも多いが、優しさを感じる発表が多くて嬉しかったし感動した。

2日目キーノートのSahotaさん

 組織を変えるとき、だれひとり置いていってはいけない。とくにマネージャ。アジャイルな組織にするならマネージャはクビにしろと言う人がいるが、マネージャにはそれまでの(ピラミッド型組織での)マネジメントとは違う新たな役割を提示しそちらに移行していく支援が必要だと。まずは変えたいと思っている自分が変わることにより、自分がその支援をできるようになる。変わりきれていなくても、専門性を高める旅の途中にあっても、変わり始めていれば支援することができる。マネージャ本人が変わりたくないというのならそれは辞めてもらうことになるかもしれないけど、それは目指すところが違うのだから仕方ない。

しーばさん(テックリードは未来の話をしよう)

 ワークショップに参加していて聞けなかったけどスライドやツイッターに流れてくる情報や、お話させてもらったしーばさんが優しかった。だれかができないのがダメだとかじゃなくて、現状をそのまま受け止めること、そこからどうしたらプラスに積み上げられるかを一緒に考えること。期待して、それに沿ってくれなかったり応えてくれなかったりしたことにイライラするのはエネルギーの無駄だから、期待じゃなくて受け入れること。これ、たまたま前日夜にホテルで見たプロフェッショナル仕事の流儀で同じこと言ってた。中高一貫校の数学の先生が、大人が生きてる社会と照らし合わせて子どもを見るんじゃなくてひとりひとりをそのまま見て受け入れるって話をしてた。
 2日目夜の飲み会でしーばさんとお話できて、主に家庭内のコミュニケーションの話をし、私は家族に対して期待をしすぎていることは自覚したがそれをやめることができてないというお悩み相談をした。しーばさんも30代前半はイライラしてたって聞けてちょっと安心した。いま31の私も10年後には優しくなれているといいなあ。しーばさんは優しくないよって言ってたけど、そして、ただ性格として”優しい”っていうのとは確かに違うのかもしれないけど、でも後進をこういう視線で見られる優しい大人になりたいなあって思った。

藤村さん(最高のScrumキメた後にスケールさせようとして混乱した(してる)話)

 成功した話、失敗した話もとてもおもしろかったけど、最後に「コミュニティに恥を晒して場の心理的安全性を高めることをしたい」という話をされていて、スクラムを学びはじめて間もなくてRSGTに今回初めて参加してこれからコミュニティで活動していけたらいいなと思ってる私にはとても嬉しかった。私はつい、こんなひよっこがこんな場にいていいのかなって思ってしまいがちなんだけど、そうやって参加していいよ感を作ってくれる先輩がいるから参加していいんだなって感じられた。

アジャイルは人、楽しく幸せに生きる

 会社や仕事でやってる開発ってしょせん飯食うための仕事かもしれないけど、それを楽しく気持ちよく幸せな時間にすることで楽しく気持ちよく幸せに生きていこうとしてる人たちばかりいてとても嬉しかった。私は仕事好きだしコード書くのもチームや組織のこと考えるのも楽しいんだけど、メンタルが健康な人間じゃないからずっと勉強し続けるエネルギーがなかったり疲れて嫌になっちゃったりすることもある。けどやっぱり楽しく持続可能にやっていきたいし、チームメンバーや会社のメンバーたちにもそうあってほしいと思う(今年の私のテーマは”持続可能”です)。みんなが幸せにやっていけるチームや組織を作りたい。よいチームって、技術力の高いチームとか計画通りに進められるチームとかもよいチームだと思うけど、目指したいのはみんなが幸せに働ける、幸せにそこにいられるチームなのかなって思った。スクラムってフレームワークだけど、やっていくのは人であり、人がそれぞれのなかにアジャイルなマインドを持ってやっていくものなんだ。アジャイルなマインドを持つように変わりたいと思う人たちを私は支援することができたらいいと思う。

コードを書くか組織を作るか

 私はソフトウェアエンジニアとしてあまりに知識も経験も足りてない。スクラムやる上でこうしようよとか、組織をこうしたらいいと思うよとか、言うけどいまいちみんなに響ききっていないように感じていてそれは私にソフトウェア書く力が足りなくて説得力がないってことなんじゃないかと思ってた。だから組織の勉強もしたいけどその前にまずはソフトウェアの基礎を勉強しようと最近思っているところだった。
 今回、コード書くのはやめてチームや組織を扱うほうに舵を切ったという人の話を何人かから聞いた。会社にコード書ける人はたくさんいるから自分はそうじゃないところに強みを持とうと思って舵を切った話と、コード書く力で社内の他メンバーには敵わないから挫折感とともに舵を切った話を聞いた。私もいつか舵を切るのかなあと思う。でもまだ今じゃないな、もうちょっとコード書けるようになりたいな、でも組織作りしたいな。持続可能なやりかたで頑張りたい。

コミュニティに参加するということ

 エンジニアとしてもスクラムの経験もひよっこでよわよわで、参加して大丈夫かなってすこし不安に思いながら参加だった。でも参加してみたらおもしろく刺激的な話をたくさん聞けてよかった。でもそれ以上に、誘ってくれたアジャイル札幌のみなさんが初参加で知り合いのいない(会社からも一人で参加だった)私を気遣ってツイッターで声かけてくれたり、イベントの楽しみかたを教えてくれたり(コーチズクリニックとか)、いろんな人に紹介してくれたり、飲み会に誘ってくれたりとしてくれたのがとても嬉しかった。
 そうやって連れていってもらった2日目の飲み会、2日間濃密なインプットをし続けてヘトヘトだったし人がたくさんいる場苦手だしみんなは知ってる人同士っぽいところに入っていけないし一次会で帰ろうかなと思ったけど、せっかくすごい人たちがいるところに北海道から来たんだから頑張ってギャザリングしてみようと思って二次会にもついていった。そしたらコーチズカウンセリング受けられたし、まさかそんな話できると思ってなかった、モバイルネットワークやモバイルコア作る話ができたし、すごくよかった。
 こないだEOF2019で登壇されていた方とたまたまワークショップで同じチームになり、困っていることを話したら、同じことを悩んでると言ってくれてネットワーキングパーティでお話できた。「すごい人」って思ってた人とこうやって一緒に話ができるんだ、って感動した。EOF2019の主催の一人でありEM.FMでいつもお話を聞いてるゆのんさんにもごあいさつできた。ゆのんさんを紹介してくれたのが大学の研究室でお世話になった先輩だった。いつ以来かわからないぐらい久しぶりの再会だった!
 これがコミュニティというやつか、と、みんながコミュニティに勇気付けられコミュニティに感謝し恩返ししたいと言うのはこういうことかと理解した。恩返しできるまでにはまだ時間がかかるかもしれないけど、スクラムフェス札幌にはプロポーザル出すぞと決めました。

場の安全

 これはすごく残念なことに、飲み会の場で、性別や国籍によるハラスメント的な発言があった。その場にいない個人に向けられた発言だった。ウッと思ったら、「それはアウトですよ」とすぐに言ってくれる人がいた。私は嫌だなと思っただけで、なにも言えなかったし、ただやりすごしてしまった。本当はそんな発言があるべきじゃないんだけど、そういうことが起きてしまったときに毅然と対応できる人間でありたいなと思った。気持の良い話じゃないからこの話は書こうか迷ったけど、書くことでそういう発言や行動を排除することにすこしでも資することができたらいいなと思って書くことにした。
 ちょうど前日に札幌メンバーと飲みながらスクラムフェス札幌ではCode of Conductを作ってほしいという話をしていたところだった。作ってほしいって言ったら、こういう場に来る人たちはちゃんと考えてるから必要ないんじゃないかって言われて、そうなのかなあ、だとしても安心して参加するために立ててほしいなあって話した。実際は必要なくなんかなかった。私は安全な場を作るための労力は惜しまないようにしよう。

最後に

 上記の発言以外は、本当に楽しいイベントでした。みんなが年明けのこのイベントにエネルギーを持って来る理由がわかった。カンファレンスじゃなくてギャザリングっていうのはこういうことなんだなっていうのもわかった。みんな仲間がいて嬉しいんだな。私も今回学んだことを土台に頑張っていこう。まずは社内向けにどうやってなにを伝えたらいいのか、よく考えます。

無名の会社でアドベントカレンダーやってみた感想

はじめに

 この記事はBBSakura Networksアドベントカレンダー最終日の記事です!25日公開間に合わなかった……。
adventar.org

 今年8月に設立された無名の会社でアドベントカレンダーやってみた感想を書きます。
 「無名の会社」とは私が所属しているBBSakura Networksという会社で、会社については7日目に社長が記事を書いてくれています

きっかけ

 アドベントカレンダーが公開されだしたころ、BBSakuraでもやってみたらおもしろいかもなーと思ったのですが、25人も社員いないし、みんな書いてくれるかどうかわからないし、サービス出してるわけでもない会社のアドベントカレンダーなんて読んでくれる人いないだろうし、と思っていた。思っていたら、弊社でアルバイトしてくれている id:taketarou2 さんがアドベントカレンダーやりましょうよって言い出した。アドベントカレンダー作ったら書いてくれる人いますかってSlackで聞いたらあんまり反応なかった。なかったけど勢いでtaketarou2さんに立ててもらった。言い出しっぺのtaketarou2さんが1日目取らなかったので私が1日目取った

感想

意外とみんな書いてくれた

 アドベントカレンダーを立ててみたら、アドベントカレンダー文化に親しんでいる何人かは登録してくれたけど、25日埋まるのは程遠い。Slackやエンジニアの定例会議でみんなに登録してください書いてくださいとお願いする日々。全体に呼び掛けても反応はあまり芳しくないので名指しでお願いして回った。そうやってなんとか1週目を埋めてもらってみんなちゃんと記事を公開してくれた。時は経ちカレンダーの空きもあとは最終日ともう一つとなったとき、私が最終日を取り、”無名の会社でアドベントカレンダーやってみた感想”を書くぞって言ったら「みんなに書いてもらうのに苦労した話とか書けますね」って反応をもらったのだけど、私はそこに苦労した感覚はなくて、むしろ予想以上にみんな書いてくれたことに驚いてた。
 1日目のエントリでも書いたとおりこの会社はソフトバンク子会社であるBBIXとさくらインターネットとのジョイントベンチャーで、社員も両社それぞれからの出向メンバーで成り立っている。さくらインターネットは社名のとおりインターネットの会社なので、もう何年もアドベントカレンダーをやっているし、ブログやSNSなどインターネットで情報発信することに慣れている人が多い。対してBBIX(ソフトバンク)はモバイルの会社で、技術にしろビジネスにしろ、オープンにするよりは自社の権利を守るという文化にいた。だから、さくらからの出向メンバーが参加してくれるのはある程度期待通りだったけど、BBIXからの出向メンバーが参加してくれるのって、期待以上のことで、嬉しかった。
 さくらからの出向メンバーのうち何人かはすでにインターネット上のアカウントを社内にもオープンにしていて、またインターネット上でも勤務先を明らかにしていて、そういう人たちが参加して自分のブログに記事を書いて会社としてやってるアドベントカレンダーにリンクしてくれるのは、ある程度予想通りだった。でもインターネットのアカウントを社内に明かしていない人やブログを持っていない人たちも参加するって表明してくれたし、インターネットと会社のアカウントをリンクしたくはないけどアドベントカレンダーには参加したいと言ってくれるメンバーもいて、その気持を無碍にはしたくないからどうしようか考えた。結果、社内ドキュメントツールとして使っているKibelaで外部公開したらいいんじゃないかと思って、提案してみた。私が想定してなかったやりかたとして、Google Siteでサイトを作って公開してくれる人もいた。みんなそれぞれのやりかたで工夫して参加してくれていいなと思った。

読まれない問題

 でも、7日目に社長の番がきて、社長がKibelaで外部公開という手段をとっていて、その翌日、取締役も同じくKibelaを使っているのを見て、正直に申し上げると、ガッカリした。
 BBSakuraって、クローズドだったモバイルの世界をインターネットの世界みたいにオープンにしていこうっていうビジョンを掲げている会社で、そのビジョンの先頭に立っている社長と取締役がインターネットのアカウントを持たず社内ツールを使って会社のアドベントカレンダーに参加している、しかもKibelaって外に公開するのが本来の目的のツールじゃないから外部公開しても検索には引っかからない、その記事をSNSで宣伝もしない!(念のため書いておくと、Kibelaというサービスが良いとか悪いとか言っているのではなく、今回の目的には合わなかったという話です。Kibelaはとても便利に愛用させていただいています。)
 会社のアドベントカレンダーって、主には会社の宣伝のためにやってると思っていて、まあきっかけはなんとなく盛り上がって始めただけとはいえ、みんなにこんな時間を割いて書いてもらう意義ってエンジニアが楽しくやってる会社だとインターネットにアピールすることだろうから、誰からも読まれないような記事をアドベントカレンダーで書く意味はないと思った。adventarのページからリンクは貼ってるけど、この時期いろんなアドベントカレンダーがあって、名の知れた会社がそれぞれやってるなか、サービスを出してるわけでもない、なにかで有名になったわけでもない、だれも名前を知らない会社のアドベントカレンダーがあったって、だれも見に来ない。

読まれない問題への対策

会社ブログを作った

 どうしようかなあと思って、とりあえず検索に引っかかるツールが欲しいから会社ブログを作ることにした:BBSakura Networks Blog
 まずは無料で運用したかったことと、投稿する人がインターネットのアカウントと紐付けず書ける場を作りたかったことから、プライベートリポジトリでGitHub Pagesを使うことにした。詳細については11日目の記事をご覧ください:BBSakura Networks Blogで使っている技術 - BBSakura Networks Blog。これを作って、Kibelaで書いていた人たちにこちらに移させてくれないかとお願いし、移させてもらった。

社長と取締役にSNSの利用・宣伝を頼んだ

 会社ブログに記事を移してから、上記の「読まれない問題」を社長・取締役に対して訴えた。そして「インターネットの会社」の「強い大人」である社長や取締役に、インターネットで活動し、宣伝してもらいたいのだとお願いしてみた。人それぞれインターネットやSNSとの付き合いかたのポリシーがあるからこれはけっこう勇気のいるお願いだったけど、社長も取締役も応じてくれた。



社長はその後もBBSakuraアドベントカレンダーの記事をツイートしたり、弊社関連のツイートをリツイートしたりしてくれていて、お願いしてみてよかったなと思っている。

目的が共有されてない問題

 しかし、社長や取締役が乗ってくれたからよかったけど、私がガッカリなんてするのもおかしな話で、そもそもこのアドベントカレンダーはやりたい人が勝手に盛り上がって勝手に始めたものだったのだ。採用目的でもないし宣伝目的というコンセンサスを取ったわけでもなく、ただやろうやろうって始めて、始めたから書いてくれとお願いして回ったものだ。それを検索に引っかからないだの宣伝しないだのと文句言うほうがおかしい。
 みんなをこんなに巻き込んでしっかり宣伝したいなら最初から目的を定めて伝えておく必要があった。

業務かどうかわからない問題

 もうひとつ、アドベントカレンダー用にブログを書くことが業務なのかどうかわからないという問題もあった。最初はやりたい人だけで趣味的に始めたから、私は業務外の時間で書いてた。他のメンバーがどうしてたかわからないけど、業務時間内にせよ時間外にせよ時間を見つけてその日に間に合うように公開してくれていた。始めのほうに入れてくれた人たちがブログなどのインターネット向けアウトプットに慣れている人が多かったからかもしれないと思っている。後ろのほうになってくると、後述の社内事情もあって、公開されない日が増えてきた。「アドベントカレンダー用のブログ書くのも仕事のうちだと思うけど、普段の業務でそれどころじゃない」と言う人もいた。このあたりも社内での立て付けをちゃんとしてなかったから人によってスタンスが違ってしまったし、みんなにお願いするならその他の業務との兼ね合いを考えたり調整したりする必要があったなあと反省した。

障害発生

 話は少し戻り、2週目も完走できていいかんじに乗ってきたと思っていた頃、さくら側でもBBIX側でも障害が発生してしまった。それによりブログ書いている場合ではなかったり、障害に関係ない人が書いてくれても宣伝できなかったりという状況になってしまった。その影響もあり、それ以外もあり、25日時点で完走はできなかった。

それでも

 始めに書いたとおり、こんなにみんな参加してくれると思っていなかったし、25日分の予約が埋まるなんて嬉しい驚きだった。ほとんどの人が登録した日に公開してくれていて、いきなり言い出したにしては上々の結果なんじゃないかとみんなに感謝しています。参加者をエンジニアに限定しなかったし内容もなんでもありとしていたから、少ない人数の会社だけど、いろんな人がいろんな記事を書いてくれました。使っている技術の話、自作OSSの話、インターネット昔話、BBSakuraという会社の話、財務の話、趣味の話……。BBSakuraに興味を持ってくれた人が見て、いろんな人がいて楽しそうな会社だなと思ってもらえるアドベントカレンダーになっていたら嬉しい。

まとめ

 そういうわけで、完走祝いの記事は書けなかったけど、そして最終日遅刻してしまったけど、これが無名の会社でアドベントカレンダーやってみた、正直な感想です。
 せっかく作った会社ブログはこれからも更新していきたいし、会社としてインターネットにアピールしていきたい。ブログの立て付けを考えて仕事としてブログでアウトプットしてもらう仕組みを作るという宿題ができました(とはいえいちばんアピールになるのはサービスリリースだろうから、開発を頑張っていきたい)。来年のこの時期は、もっと積極的に、もっとスムーズに、みんなでアウトプットできる会社になっているといいなあと願って、BBSakuraアドベントカレンダーを締めくくります。参加してくれたみなさん、読んでくれたみなさん、反応をくれたみなさん、ありがとう!締めくくるけど、公開されていない記事はまだ待っていますよ!

紙粘土スクラムに参加した

はじめに

 この記事はBBSakura Networksアドベントカレンダー21日目の記事です。遅刻です!すみません!
adventar.org

 社内のプロジェクトで野良スクラムマスターみたいなことをしているけどスクラムマスターの仕事がわからなくなってしまい、12/21(土)に札幌で開催された紙粘土スクラム 2019に参加してきたのでそこで学んだことを書きます。

きっかけ

 前回の記事(アジャイルな家庭を目指して - 猫が吠える)は子育てエンジニアアドベントカレンダーに参加して書いた記事だったのですが、その翌日に参加されていた id:izumii-19 さんが私の記事にリンクを貼ってくださいました。そこからizumii-19さんのブログを読みに行ったところ「アジャイル札幌」というコミュニティがあることを知り、週末に紙粘土スクラムスクラムのやりかたに則って、紙粘土を使ってチームで動物園を作るワークショップ)が開催されることを知りました。ちょうどスクラムについてやスクラムマスターの仕事について悩んでいるタイミングだったので、参加してきました。

悩んでいたこと

 社内で11月から始動したプロジェクト(このプロジェクトの悩みについて詳しくは以前の記事に書いています)でスクラムを取り入れました。私はチーム開発というものをちゃんとやったことがなく、そもそもソフトウェアを書く経験も2年そこそこしかないのだけど、それも一人開発みたいなもので、今回初めてチームで開発に取り組んでいます。プロジェクト開始にあたりスクラムを取り入れようということになり、10月ごろに初めて『SCRUM BOOT CAMP THE BOOK』を読んでスクラムを勉強しはじめました。これはおもしろい!と思って、『アジャイルサムライ−達人開発者への道−』、『エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)』、『アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き』などを読んでアジャイルスクラムの考えかたが好きになり、プロジェクトでは野良スクラムマスターみたいなことをやり始めたところでした。
 プロジェクト開始当初、私は開発には入らずプロジェクトの推進のみをしていました。まず関係者に声をかけてキックオフを設定してビジョンとスケジュール・マイルストンの共有をし、各種スクラムイベントの設定とそれらの進行役をしていました。初めのうちはプロジェクトとしての形がなかったところからチームを作ってプロジェクトを推進している感があったのだけど、だんだんただの会議進行役になってきているように感じていて、同時にチームとしてもちゃんと目標やビジョンを共有してそれに向かって進めているのだろうか、という不安も出てきました。そこで一度仕切り直し会をやったり、私も開発に入ったりとしたのですが、こんな進めかたでいいのかな、スクラムマスターってもっとチームのためにできることがあるんじゃないかな、と思っていたところでした。

学んだこと

 今回は、最初にスクラムについての説明があり、それから2チームに分かれてワークショップを行いました。私のチームは4人構成で、プロダクトオーナー(PO)、スクラムマスター(SM)、開発メンバー2人という構成でした。チーム外にステークホルダー役が一人がいました。最初の自己紹介で会社で野良スクラムマスターのようなことをしているが進めかたに悩んでいると話したところ、主催の方にSM役やったほうがいいと思うと言ってもらい、私はSM役をやりました(POかSMどっちかやりたいなと思っていた)。ステークホルダーは主催の一人、POはアジャイル札幌コミュニティの中の人(?/コミュニティの構成をよくわかっていないのでハテナ付き)で紙粘土スクラム参加2回目の方、どちらも認定スクラムマスターを持っている方でした。開発チームのお二人は初参加でスクラム勉強中という方たち。このメンバーで、まず全体計画をやり、「スプリント計画・開発・ステークホルダーレビュー・レトロスペクティブ」というスプリントを4周回しました。
 具体的な内容について書いてしまうと今後参加する人へのネタバレになってしまって良くないようなので、以下、なるべく開発内容はぼかして書こうと思います。説明がわかりづらかったらすみません。

完成した動物園
完成した動物園

価値のあるものから作る、動くものを作る、レビューを受ける、次に活かすことの重要性

 今回は時間の都合上見積というものをやらなくて、各タスクの作業量がわからないからスプリント計画を立てづらいなあと最初感じた。スプリントごとに「リリースできる状態のものを成果として出す」ために、見積をして、確実にできそう(かつ重要)なものから手をつけたほうがいいんじゃないかと思っていたから。でも見積がわからなかったから、まずはステークホルダーから必須で作ってくれと言われている動物をプロダクトバックログの先頭のほうに持ってきて、はじめのほうのスプリントで作ることにした。1スプリント目に、けっこう手のかかりそうな動物を作った。完成はしたけど、ステークホルダーのレビューを通らなかった。それで2スプリント目も丸々使って作り直した。その結果、1スプリント目の成果はゼロになってしまったけど、レビューと振り返りを活かして2スプリント目に開発したことで、今度はちゃんとレビューを通って、必須項目として求められていた動物をリリースすることができた。このときチーム内では”産業革命”が起きて開発チームの技術力も効率も上がり、3スプリント目以降スピードを上げて開発することができた。
 ここから学んだのは、

  • 簡単にできそうなものから手を付けるのではなく価値の高いものから開発すること
  • デリバーできるプロダクトを完成させてレビューを受けること
  • レビュー結果を振り返り次のスプリントに活かすこと

の大切さ。スクラムの基本であり、知識としては読んだことあることだけど、こうやってワークショップで体験すると実感として理解できた。

細かく区切って振り返ることの重要性

 今回1スプリントは「スプリント計画・開発・ステークホルダーレビュー・レトロスペクティブ」の合計で20分。開発に使える時間は1スプリント6分しかなかった。作業時間としては6分×4スプリントで動物園を完成させたことになる。すべてのスプリントが終わったあとの全体振り返りで、「24分通して作業したとして同じものが作れたか?」と問われた。できなかったなあ!細かく区切って計画・開発・レビュー・振り返りを繰り返すからより良いものができるのだというアジャイルスクラムの本質的な良さを実感できた。

会話・対話の重要性

 私のチームでは、プロダクトバックログの整理やスプリント計画はPO主導、開発(粘土で動物たちを作る)を開発チーム主導でやってもらってしまい、SMである私はなにをしたらいいんだ、と終始オロオロしてしまっていた。SMの仕事はチームの障害を排除することだって言うけど、具体的になにをしたらいいのかわからない。私がやっていたことは、スプリント計画中、POがやろうって言ったことについて開発チームに6分でやれますか、きつくないですかと聞いたり、開発中に必要な粘土の色を聞いて袋を開けたり、開発チームに困ってることないですかって聞いたり(だいたいは「ない」と答えが返ってきて、なにもできない)、タイムキーピングしたり、ぐらいだった。言ってしまえば雑用係。会社のプロジェクトでのうまくやれてない感・何したらいいかわからない感がそのまま出ている!
 最終スプリントが終わった後で隣のチームのSMに何をしていたか聞いたら、開発の時間中は手を動かす手伝いに入りつつPOにバックログの整理を頼んで、整理されたバックログを元にスプリント計画を主導していたそう。一度私のチームで開発時間中にPOがやっていたバックログ整備に入ろうとしたら「こっちはいいからSMは開発チーム見てて」って言われて、一瞬「ほんとにSMはバックログ整理に入らなくていいのかなあ」と疑問に思いながらも、あ、そうなのか、と開発チームが作業しているところに戻ってしまった。結果、POが決めた順番で開発チームが開発する、SMは特にやることなし、となってしまい、開発チームの意見をバックログに反映させることができなかった。
 バックログの整備をPO一人に任せるのが良いのかSMが入るのが良いのかはわからないけど、どちらにせよ、このチームとしてどういう役割分担でやっていくのかについての会話が足りていなかった。日々大事だと思っている「期待値の擦り合わせ」というやつができてなかったから、メンバーそれぞれがなんとなく違和感は覚えているのにそれを言語化し共通のビジョンを持つところに持っていけなかった。互いに(個人間でも、役割間でも)もっと会話をして、あなたに何を期待しているのか、私はあなたから何を期待されていると思っているのかを言語化して擦り合わせないと、「ただなんとなくそれぞれが思っている自分のロール」をこなすことしかできない。その結果、私はこれをやっていていいのかな、やらなくていいのかな、あれをやりたいけど私がやるべきじゃないかもしれないな、とモヤモヤしたまま開発を進めることになる。「こっちはいいから」って言われたときに、「私はSMもバックログの整理に入ったほうがいいと思う」と言って話をすればよかった。

 また、隣のチームには同じ会社から参加している二人がいて、互いの特技を知っていたことでそれを動物園作りにうまく活かせたという振り返りがあった。初対面のメンバーでも、互いに会話をして特技ややりたいこと、なりたい姿などを最初に話せれば、それぞれの特性を活かした開発や役割分担ができていただろう。メンバー同士で会話しチームビルディングすることが大切だなと感じた。

発言しやすさの重要性

 バックログ整理やらなくていいよってPOから言われたときに疑問を持ちつつも納得してしまった理由を考えてみると以下の3つであるように思う。

  1. PO役の人が認定スクラムマスマーであり紙粘土スクラムも2度目の参加で、スクラムについて私より知っている人だ、この人が言うならそれが正しいのだと認識してしまったこと
  2. その場の雰囲気として認定スクラムマスターの4人(彼らは全員アジャイル札幌コミュニティの中核メンバーのようだった)は他の参加者に教える立場で、他の参加者は彼らから教えてもらう立場だという空気があったこと
  3. 分単位、秒単位で追い立てられるなかで、会話や期待値の擦り合わせが足りていないというところに頭が回らなかったこと

 これらは仕事でプロジェクトやるときにもそのまま陥ることだ。
 1つめについて、プロジェクトにはいろんな立場の人が参加するはずで、社内の役職、年齢やその会社にいる年数、それまでの経験や知識などで、言ってしまえばランク付けのようなことを無意識にして、この人は自分より上の人だから言っていることが正しいとか、自分より下の人だから自分の意見が正しいはずだとかってなってしまうことがあるのではないか。これは、自分の中での他者に対するランク付け。
 2つめについて、場の空気や雰囲気としてメンバー間で共有されているランク付けもあって、それによりなんとなく物が言いにくくなることがあると思う。社内やプロジェクト内での発言のしやすさ、どんな発言をしても許容され受け入れられる感については普段から気をつけているつもりだけど、今後より気をつけようと思った。そして、アジャイルな家庭を目指したいのに家庭内では完全に「教えてあげる親(私)」と「教えてもらう子どもたち」という構図になっている、というより私がしてしまっていることに気づいた。子どもたちの発言しやすさをもっと作っていきたい。
 3つめ、仕事なんてだいたいいつも納期やステークホルダーからの要求に追われるもので、その中で頭が回らなかったなんて言っていられないから、そのときに必要な行動を意識せず引き出せるくらい身に染み込ませておかなければと思った。

感想

  • 知識として知っていたはずのことも、ワークショップとして実際に体験してみると実感として理解することができる。「腑に落ちる」経験を繰り返してようやく、実際の仕事で使おうと思ったときに使える引き出しになるのだと思う。
  • SMやることなんもわからん感は、より深まってしまった!ワークショップに参加することで、わかってないことがよりわかるようになったという進化の意味です。1月のRegional Scrum Gathering Tokyo 2020に誘っていただき行けることになったので、それまでに自分の中で知識と体験を整理してから参加し、使える引き出しを増やしていきたい。
  • イベントとしてネタバレを避けているけど、むしろどんどんネタバレして、それらの知識を持った上で参加する人が増えていったほうが参加者のレベルが上がっていっておもしろいんじゃないかなあと思った。車輪の再発明をさせなくてもいいんじゃないかと。産業革命は二次、三次と起きるかもしれない。

 懇親会まで参加させていただき、アジャイル札幌のメンバーのみなさんにくっついて夜中の4時までお酒飲みながらエンジニアリングの話をして(私は主に聞いて)、とっても楽しく、視野の広がる一日でした。ここからRSGT2020にも誘っていただいたし、4月にはスクラムフェス札幌というイベントも開催されるそうでこちらにも参加させてもらおうと思っているので(できればなにかしゃべりたい)、これからもより深くスクラムアジャイルの勉強をしていきたいなと思いました。アジャイル札幌のみなさん、参加者のみなさん、ありがとうございました!

アジャイルな家庭を目指して

はじめに

 この記事は子育てエンジニア Advent Calendar 2019の14日目の記事です。
adventar.org  我が家の構成と状況は以下の通り。
 私:31歳女性、モバイル系(ソフトウェア・モバイルコアを作る)ベンチャー企業勤務のソフトウェアエンジニア、フルタイム正社員、フル在宅勤務
 夫:33歳(今年度34歳)男性、私と同じ会社勤務のインフラ~ソフトウェアエンジニア、フルタイム正社員、フル在宅勤務
 娘:2016年2月生れ、3歳(今年度4歳)女性、保育園の年少クラス
息子:2018年9月生れ、1歳男性、今年の4月から娘と同じ保育園に入園、0-1歳クラス

 私と夫は同じ会社に所属し同じ家で在宅勤務しているので、四六時中自宅で一緒にいます。

 以下はこういう我が家の最近の課題と、それをエンジニアリング組織作りの考えかたを取り入れながら解決しようとしている奮闘記です。まだ解決はしていないので、結論はありません。

課題

 娘が大きくなってきて、自己主張や反発も強くなり、それまでみたいにただかわいい生き物を育てるという心構えではうまくいかなくなってきた。
 うちの子育ての方針として、就学前の今いちばん身につけさせたいものは「意欲」であり、そのためには、親があれこれ指示したり禁止したりせず本人が興味を持ったことややりたいことをやらせたい、自由にしていていいんだという安心感を持って行動し、その行動の結果から自分で学んでほしいと思っている。たとえば食事中にコップを倒さないように「危ないよ」って声かけるんじゃなくて、倒して水をこぼしてから自分で片付けをして、倒さないためにはどうすればよかったのかを考えてほしい。そういう経験を繰り返して、自分で問題発見・問題解決ができる人になってほしい、そうやって本人の自主性を尊重する育てかたをしたいと思っている。
 反面、私自身は親からそれとは正反対の育てられかたをしてきた。人に迷惑をかけないことがなにより大事とされ、だから行動する前に指示を受け、困らないように準備することを教えられ、そうやって大人によって生活を管理されてきた。大人にとって都合の良いようにしつけられたので、親の指示や許可を待つ人間に育ってしまった。それが嫌だったけど、でもその「迷惑をかけない」、「失敗しないように準備する」が身に染みついてしまっているから、先に書いたような、自分で考えさせ、失敗を許容するような育てかたをするのがとても難しい。やりたい子育てと自分の身に染み付いたもののギャップに苦しんでいる。
 夫は話を聞く限りどちらかというと自由に育てられたようで、自身の育ちとやろうとしている子育てのギャップはあまり感じていないよう。私が一人でそのギャップにハマってしまって、疲弊したりイライラしたりしている。そしてそのイライラで子どもたち(主に娘)を萎縮させてしまっている。

対策

 そんな折、仕事ではエンジニアリングマネジメント・エンジニアリング組織作りについて考えていて、これは家庭にも通ずるところが大いにあると思ったので家庭作りにも取り入れてみることにした。以下のような観点を意識して家庭という組織を作ろうとしている。

自律可能な組織を目指す

 子どもを含めた家庭のメンバー一人一人が細かい指示を受けなくても自分ですべきことを考えて実行できる、各自が不確実性を減らしていける組織でありたい。
 食事の支度を例にとると、自律可能でない組織の場合、私が一人で献立を考え、食材をそろえ、料理し、夫や子どもたちに「お皿運んで」「ごはんよそって」などと指示を出すことになる。今日の献立が決まっていないところからテーブルに食事が並ぶところまで、ほとんどの不確実性を私一人で減らし、夫や子どもたちに対してはマイクロマネジメントが必要。対して自律可能な組織であれば、例えば私が「今日はカレーにしよう」と言えば、食材の在庫を把握している夫が玉ねぎが足りないことに気付いて買い物に行く。娘は私と一緒に台所に立って切れる野菜を切る。ごはんが炊けたら手の空いている誰かがごはんを混ぜる。カレーの匂いがしてきたら息子は自分でテーブルまで来て、みんなでカレーをよそってテーブルまで運ぶ。そういう組織にしたい。
 そのためには、私一人が握っていることが多かった家事の権限をメンバーに移譲する必要があり、また、メンバーはそれぞれどういう行動を期待されているのかを正しく認識している必要がある。

期待値の擦り合わせ

 期待されている行動を正しく認識するためには、メンバー間で互いに「相手に期待していること」と「自分が相手から期待されていると思っていること」を擦り合わせる必要がある。娘が野菜切りたいって思っているのに親がいつまでも包丁は危ないからやらせたくないと思っていたらうまくいかなくて、子どもが何をしたがっているのかを親が聞くことも大事だろうし、その行動はその年齢の子どもに対して求めて良いものなのかどうかを本や保育園などで学ぶことも大事だろう。そして子どもと対話して、したいこと・してほしいこと・したくないこと・させたくないことについて互いの認識を合わせておくと、自律可能な組織に近付くかもしれない。

オンボーディング

 互いの期待値の擦り合わせができたとして、権限を移譲しようとして、でもやってもらいたいことを子どもはいきなりできるわけではない。一緒に料理するなら包丁の持ちかたや置きかたを、荷物の準備を自分でやらせるなら服の置き場を教えてやらないとできるようにならない。家事のひとつひとつの考えかたやお作法を、これから家事というプロジェクトに入ってくる新メンバーに伝え、また、家庭とか、そもそも人間としての新人である子どもたちには、我が家の、人間界のお作法を子どもたちにわかる言葉で伝えながら、権限を移譲していきたい。プロジェクトの可視化して、情報の非対称性をなくしていきたい。

仮説検証を繰り返す

 息子が1歳になったころ、水の入ったコップににんじんを入れては出し入れては出し、それを真剣な目で観察していた。そうやって物事を試し、よく観察し、観察をもとに仮説を立て、また試し、検証するということを、家庭という組織としても、そこに属するメンバーそれぞれでも、やっていきたい。

変化を受け入れる

 子どもというのはあっという間に成長するものだから、昨日まで考えもしなかったことを今日いきなりやりだしたりする。それを見て親は驚くけど、驚いて禁止したりせず、この子はこんなことができるようになったのだと受け止める。受け止めて、それを元に子どもに対する期待値を再設定する。息子のこともいつまでも赤ちゃん扱いしていてはいけなくて、組織内での役割をすこしずつ担っていってもらわないといけない。そうやって日々互いの期待値をアップデートし、役割を変化させていくと、家庭という組織の構造もアップデートされる。いつでもその変化を受け入れられる用意をしていたい。

おわりに

 こういうことを意識して子どもと接するようにしようと思って、夫と話をし、具体的なタスクに落とし込もうとしている途中。タスク管理ツールはJiraを導入してみた。これまでいろんなタスク管理ツールを試しては続かず放置というのを繰り返してきたが、会社でJiraを導入したので同じように運用できるのではないかと考えて導入、まだ1か月くらいしか経っていないけど、今のところ一応続いてはいる。
 タスクに落とし込む作業は付箋を使ってやっていたけど、GuildHubという仮説検証支援ツールを知ったので使ってみようとしているところ。

 というわけでまだ具体的な行動には移せておらず、もちろん成果も出ていないけど、なんとなく子育てうまくいってないかもしれないというモヤモヤ感を言語化して課題と対策の方向性を定めることができたので、これから行動し、アジャイルな家庭を目指してやっていこうと思います。

リモートワーク前提の会社でのコミュニケーションの現状を紹介する

はじめに

 この記事はBBSakuraNetworksアドベントカレンダーの1日目です。
adventar.org
 ついにインターネット上に勤め先を書いてしまった。
 8月に設立されてからここの会社で働いています。

BBSakura Networksとは

www.bbsakura.net
 今年8月に設立された会社です。
 ソフトバンクの子会社であるBBIXと、さくらインターネットの両社で作ったジョイントベンチャーです。

 親会社のサービスの開発や運用を受託しつつこれから自社サービスも作っていこうとしている、エンジニアリングの会社です。社員は両社からの出向のみでエンジニアが15人ぐらい、大学生のアルバイトエンジニアが1人。人事とか総務とかの人たちは親会社の仕事と兼務でBBSakuraの仕事もしてくれている。
 主にモバイルの世界のお仕事をしていて、受託の仕事のひとつとして、さくらインターネットが提供している「さくらのセキュアモバイルコネクト」の開発運用があります。
 詳しくは7日に社長が会社紹介記事を書いてくれる予定です。

BBSakuraの働き方

 親会社のひとつであるさくらインターネットは大阪に本社があり、東京に支社があり、石狩にデータセンターがあり、他にも拠点があり、さくらインターネットからBBSakuraに出向しているメンバーも大阪・東京・北海道に散らばって仕事しています。大学生のアルバイトは仙台の自宅や大学で仕事をしているようです。
 もうひとつの親会社であるBBIXは仙石山にオフィスがあるので、そこにみんな出社したり、ときどき在宅勤務したりしています。
 両社が合流してJVを作るということで、多拠点に散っているメンバーを転勤させるということはせず(それぞれに生活があるからね)、多拠点でのリモートワークを前提とした会社になりました。私は夫と一緒に北海道小樽市にある自宅からフルリモート勤務しています。
 働き方についても、詳しくは16日にCOOが書いてくれる予定です。

情報の扱いかた、コミュニケーションの取りかた

 会社ができたばかりで互いのことをあまり知らない状況、これから新しいサービスを作っていくという状況でメンバーが一箇所に集まっていないというのは、もちろんやりづらさはあります。でも多拠点でやることが前提の会社なので、オフラインでのコミュニケーションをできる限り減らして情報をオンラインに上げることでやりづらさを解消しようとしています。最近またリモートワークについていろんな意見や感想が書かれているのをよく目にしますが、多拠点リモートワーク前提のBBSakuraではどんなツールを使いどうコミュニケーションしているのか、紹介してみようと思います。

 使っているツールは、最近の技術系の会社はどこも使っているようなラインナップだと思いますが、ツールを紹介しつつ、そこでの情報の扱いかたについて書いてみます。BBSakuraには情シスという部署や担当はいないので、導入したいツールがある人が調査して同僚や上司に相談して導入してきました。使い方やルールも決めたい人が決めて、周知する、変更したい人がいればその人が働きかけて変更するという運用をしています。

  • G Suite Bussiness

 社員情報のマスターデータ。カレンダー、ビデオ会議(Hangout Meet)、ドライブなどをよく使っています。メールは他社とのやりとりのみ。社内のやりとりはメールではやりません。
 他のツールはGoogleログインにしているので、各ツールでアカウント管理する必要がなく助かります。グループを作って付与する権限を設定したり、ログインを許可するツールを管理したりしている。
 カレンダーは、各親会社の社内カレンダーと連携できていなくて不便。連携ツールを同僚が作ってくれる予定です。
 会議はHangout Meetでやっています。音声のみで進行することにとくに問題を感じていないので、顔は映していません。必要に応じて画面共有しながら話します。各拠点に良いマイクと良い回線があることは必須です。音声が聞き取りづらいと、オンライン会議は不可能です。

  • Slack Plus Plan

 まあ普通にプロジェクトについての議論とか、雑談とかをしています。Slackで議論し(フロー情報)、決まったことは後述のKibelaなどにまとめる(ストック情報)。
 ただしチャットツールでの議論は、オンラインテキストコミュニケーションに慣れていない人やオフラインでの仕事に慣れている人にとってはハードルが高いので、みんなにオンラインに出てきて発言してもらうためには仕組作りが必要だと思っています。例えば私がやっているプロジェクトでは、メンバー全員に、プロジェクト用チャンネルでのデイリースクラム風進捗報告をお願いしています。毎日、「今日やったこと、明日やること、困っていること」の他に、「メンバーに共有したいこと(あれば)、なにか一言(その人の状態をなんとなく知るためと、メンバー間での雑談を生むため)」を発言してもらっています。そうやって強制的にオンラインに出てきてもらうとか、あとは事あるごとに「オンラインでやりましょう」、「雑談しましょう」、「何書いてもいいですよ」、「マイナスのことを書いたからと言って誰も責めませんよ」ということを発信するようにしたりして、オンラインでの発言のハードルを下げようと試行錯誤しているところです。times(分報チャンネル)も(私が勝手に)推奨していて、みんなに作ってねって言ったり、勝手に人のtimesを作って当人を招待したりしています。オリジナルemojiはたくさん登録されていて、emojiで会話したりリアクションしたりが一般的になっていますが、これはどちらかというとオンラインコミュニケーションに慣れた人にとって取っ付きやすいやりかたなのかなと思っています。
 議論や雑談以外の使い方としては、リモートワーク前提の会社なのと、コアタイムなしのフレックスなのもあって誰がいつ仕事しているかわからないので、「#timecard」というチャンネルを作って出勤・退勤を報告するというのがあります。
 最近はいろんなツールがSlack連携できるので、他ツールからの通知もSlackで受け取ることが多いです。

 ストック情報を貯めておくためのツール。記事の共同編集のオン・オフが設定できるので記事の目的によって使い分けています。プロジェクトの情報まとめや定例ミーティングでの各自の情報を共有するのための記事は共同編集できるようにしてみんなで作ります。社内手続の方法が野良でまとめられたページも共同編集できるようにしているので、気付いた人が追記したり修正したりしています。共同編集オフの記事は、社外の勉強会で聞いてきた内容の共有とか、個人的に調べた技術のメモとかがあります。このアドベントカレンダーに参加したいけどインターネット上の人格と勤務先を紐付けたくない人は、Kibelaに書いて外部公開してもらおうかなとも考えています。
 私がやってる新規プロジェクトではプロジェクト情報まとめ記事を1ページ作って、プロジェクトの基本情報(プロジェクトのゴールやビジョン、スケジュール、参加メンバー、ルール)と関連情報(Google Driveのフォルダの場所や関連Slackチャンネル、他のツールのプロジェクトページ)へのリンクをまとめています。メンバー間での情報の非対称性をなるべく小さくすること、後から参加したメンバーがいた場合にキャッチアップしやすくすることを目的としてやっています。
 あと、plantumlが書けるので、システムのフローを図示できて便利です。

 GitHub Enterpriseは求める機能の割にちょっと高いなってことでTeam Planになったんだったと思います。
 kibelaは自由に編集できるメモ、こちらは変更に承認が必要な文書の管理という使い分けです。ソースコードはもちろん、社内の規程もGitHubで管理しようとしていて、近日中に管理部門向けにgit勉強会をする予定です。

  • Jira Standard Plan

 最初は親会社からの受注案件の問い合わせ管理に使おうと思って導入しました。親会社の担当者にアカウントを発行して、技術面での問い合わせの管理をしています。このとき、入力項目や画面の表示内容、チケットのステータス遷移、権限設定などをカスタマイズする必要があってだいぶ苦労しましたが、Jiraの課題の設定方法を完全マスターしました。その後、毎週やっている社内勉強会で設定方法をみんなに伝えたので、みんなJiraマスターになっているはず。
 問い合わせ管理以外にも、プロジェクトごとの課題管理に使ったり、バックログやスプリントの管理に使ったり。あとは個人プロジェクトを作ってタスク管理している人もいます(私もそうしています)。これらも、情報を誰でも見えるようにすることが、目的のひとつとしてあります。
 Jiraのスマホアプリが使いやすいのだけど、うっかり私用スマホに入れてしまったら退勤後でも休みの日でも通知が来て仕事したくなってしまうので私用スマホに入れるのはおすすめしません!

  • その他

 勤怠管理、立替精算、稟議システムはどちらかの親会社から輸入したものを使っています。
 勤怠管理システムは、前述の「#timecard」チャンネルでSlashコマンドを利用することで自動で入力するツールを同僚が作ってくれたので、出退勤の報告と打刻を別で行う必要がなくなり便利になりました。

最後に

 BBSakuraでのオンラインコミュニケーションのやり方はこんな感じです。
 リモートワークって、良いことはたくさんあるけどコミュニケーションコストはやっぱり高いので、うまくやっていくためには工夫が必要ですね。人数の少ない拠点にいる人が疎外感を感じなくて済むように、多人数の拠点にいる人は、情報をオンラインに上げることを、より気をつける必要があると思っています。
 それからたまにはオフラインで顔を合わせて話をするのも大事です。少し前にキックオフの会があり、みんな東京に集まって会社のビジョン、事業の見通しなどを共有しました(うちは夫婦同じ会社に勤めているので二人とも参加するためには子どもたちの居場所確保に労力をかけなければならず、これについても今後考えねばと思っています)。オフラインで話を聞くと、普段バラバラの拠点で働いているメンバーたちのあいだで共通の認識や目的意識が作られるので、今後も定期的にオフ会をしたいねと話しています。

 BBSakuraでもまだまだ改善すべきところはあるので、うちの会社はこうしてるよって話も聞きたいです。
 

 さて、この人数の会社でアドベントカレンダー無事に埋まるのでしょうか。見守っていただけると幸いです!