猫が吠える

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

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

組織作り エンジニアリング コミュニケーション 働く 振り返り 感想

はじめに

　この記事は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でもまだまだ改善すべきところはあるので、うちの会社はこうしてるよって話も聞きたいです。
　

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

前回のエントリに反応をもらって嬉しかった

働く 生きる コミュニケーション エンジニアリング

前回の記事 ひよっこエンジニアによる #EOF2019 感想 兼 転職エントリ - 猫が吠える を深夜に公開して寝て起きたら広木さんにふぁぼられてた。
f:id:n0mzk:20191105222059j:plain
ゆのんさんがこんなツイートをされていた。


OSTでたくさんの知恵をくださった方たちがそれを引用してツイートされていた。

他にもふぁぼとかはてなスターとかもらって嬉しかった。


　週末、家事に追われながら子どもたちにいろんな要求されることにわりといつも疲れて夫にも子どもたちにもイライラしてしまうことが多いのだけど、この週末は3連休だったのに比較的心穏やかに過ごせていて、なんでだろうって思ったら、こうして家庭以外のところで認められていると感じられたからかもしれないなと思った。些細なことかもしれないけど、書いた文章に反応をもらえるのって私にとってはとても嬉しいことで、それがほとんど初めて書いたエンジニアとしての文章で、エンジニアコミュニティの、私にとっては憧れみたいな存在の人たちから反応をもらえたっていうのは、その喜びをより強く感じさせてくれた。拙い文章だけど書いてよかったなって思った。
　夫は私とは違ってあまり子どもたちにも私にもイライラしないで日々を過ごせる人で、息抜きに飲みに行くとか音楽聴きに行くとかをそれほど必要としない人間で、それを私は不思議に思っていたのだけど、夫はこうやってエンジニアコミュニティでインターネットを通して交流をし、他者から存在を認められているからなのかなと想像し納得した。
　誰かから認められているという感覚をこれまでほとんど持てず、だから作った料理を家族の誰もおいしいともまずいとも言わないとか、片付けたり掃除したり（あんまりしないけど）して家が綺麗になったのに誰も反応してくれないとか、そういうことでいちいち心を磨り減らしていた。それはたぶん家庭内にしか私のことを評価してくれる人間がいないと認識していたからなだ。仕事は仕事であるけど、ちゃんと評価を受ける立場（正社員）で働きだしたのはこの10月のことで、それまでは裁量もなく判断を必要とされずただ時間を切り売りするアルバイトだったから。下請けで書いたコードが世にリリースされたときも嬉しかったけど、そのサービスに私の意思決定はなかった。転職によって裁量と責任をともなう会社員という軸を得たし、これからさらにエンジニアコミュニティの中にも一人のエンジニアとして軸を置くことができるようになると、家族だけに理不尽に評価を求める気持を捨てて健康にやっていけるようになるのかもしれない。

ひよっこエンジニアによる #EOF2019 感想 兼 転職エントリ

エンジニアリング 働く 生きる 感想

前提

　コード書いてる歴2年半ぐらい、これまでは言われたコードを書くだけで主体的に勉強とかしてなかった、この10月からようやく目的意識を持って（ソフトウェア）エンジニアをやりだしたところ、勉強会に参加するのも2度目、技術的なことなんてブログに書いたことない人間が、EOF2019に参加してすごく感動して感銘を受けて仕事にもフィードバックできて嬉しいのでポエムを書く。
eof.connpass.com

略歴と転職について

　大学卒業後新卒でISPやってる会社に入った。1年間の研修を経て品質管理の部を希望して希望通り配属された。仕事や会社が辛かったという記憶はないのだが配属されたその年に鬱になって休職し、そのまま退職した。その後は休職中に結婚した夫に扶養されながらニートしたり、ラーメン屋でバイトしたり妊娠出産したりして、ようやくまた働きたいな、夫がやってるエンジニア業楽しそうだな、って思って、個人事業主として開業し、夫のやってる仕事の下請けをやるようになった。IoT向けMVNOのモバイルコアを作る仕事で、Golangを書いた。28歳にして初めて、仕事としてコードを書いた（大学のときに授業とその延長でRailsでウェブサービスの開発をしたことはあった）。2年間下請けをやり、出産のため一度辞めて、しばらくしてから今度はアルバイトとして同じ仕事に戻った。それが今年の2月のこと。
　今年の8月、その仕事をやってるチームともう一社でジョイントベンチャーを設立した。アルバイトだけど出向という形でそのJVに参加することにした。それまでなんで個人事業主だったりアルバイトだったりしたかというと、夫の所属する会社では、夫婦を同じチームで正社員として雇えないという暗黙のルールがあったから（これについてはめちゃくちゃ文句言いたいんだけど、本筋じゃないからやめておく）。でも2年半も非正規でやっていると、同じように仕事をしているのに正規雇用の人たちと受けられる待遇が違いすぎることへの不満は大きくなっていて、JV設立時もアルバイトのままなら辞めようと思っていた。そんな話を上司にも伝えていたら、ジョイントする相手の会社で正社員として雇っても良いと言ってもらえ、中途採用の試験を受けて10月から無事に正社員として働けることになった。これが転職の顛末。
　正社員になると、黙っていても毎年給料上がるチャンスがあり、どうしたらここから給料上がるかなということを考えて仕事するようになった。これまでみたいに言われたコードだけ書いていても給料は上がらない。ようやく、私がやりたいこと、私がやるべきこと、私でないとできないことはなんだろうと考えながら仕事するようになった。

EOF2019に参加した背景

　そういうわけで8月に設立したばかりの会社で働いているのだけど、どうもうまくコミュニケーション取れていないし、うまくプロジェクトが始まらない、と感じていた。前述の通りこの会社は2社で作ったジョイントベンチャーで、これまでは設立前から互いの会社で持っていた仕事をそれぞれ元のメンバーでやっていた。これからようやく出向元関係なくチームを組んでこの会社でのプロジェクトを始めようとしているのだけど、どうもうまくいかない、という状況だった。
　少し前に広木大地さんの『エンジニアリング組織論への招待』を読んだり先日聞きに行ったAWS DevDayで広木さんの講演を聞いたりしてエンジニアリング組織の作りかたに興味を持ち、このイベントが開催されることも知っていた。私はマネジメントなんて程遠いひよっこエンジニアなので、エンジニアリングマネージャのためのイベントに行かせてもらっても会社に還元できるのはずいぶん先になるかもしれないと思って迷っていたけど、上記のような状況をいよいよどうにかしないといけない、そのためのヒントをもらえるんじゃないか、そしてそれはそう思ってしまった私がやるべきことなのかもしれないと思って、行きたいですって上司に言ってみたら、5分で「どうぞ！」って返ってきた。北海道住みの上に直前に予約したので飛行機代ホテル代で8万ぐらいかかったけど会社負担です。良い会社です。でも結局聴いてきた話を翌日から仕事に活かせたので、上記のような「プロジェクトをうまく始動したい」という観点から、得たことを書いておこうと思う。ひよっこエンジニアにとっても本当に学びの多いイベントだった。

参加したセッション

　どのセッションも魅力的で、フェスぐらい迷ってマイ・タイテを作った。

f:id:n0mzk:20191103001507j:plain
タイムテーブル

　始発で行ってこの内容聴くの、めちゃくちゃ疲れた。それでもその後飲みには行ったけど。で、飲みの席でも新卒時の同期たち（このイベントには参加していない、転職経験者）と組織や人間について話したりした。楽しかった。

感想

　上に書いたような会社の問題をどうにかしなきゃという目的意識で行って、そのヒントをもらえそうなセッションを選んで聴いてきた。
　その結果、ここで得た知識と知恵によって翌日にプロジェクトを始動させるための提案ができた。

困っていたこと

　2社によるジョイントベンチャーで、2社間の文化や仕組が違っていた。片方は東京のオフィスにみんなで集まって仕事するスタイル、片方は東京・大阪・北海道に散って主にslackでコミュニケーションをとるスタイル。その両社が一緒になった結果、いざ混合チームでプロジェクト始めようと思っても、拠点がバラバラなのにオンラインコミュニケーションがあまりとれていなくて互いの人間性や持っているスキルとそのレベルがよくわからなかったり、メンバー間の知識の偏りが大きかったり、プロジェクトのゴールやマイルストンもはっきりとは共有されていなかったりして、プロジェクトが始まってるのかどうかもよくわからない、メンバーも確定しない、参加したいと言ったものの何したらよいかわからず何もできないメンバーがいる、というような、こうして書き出してみるとなんともカオスな状況になっていた。それでも高速に開発する必要があるから、スクラム風にやろうということは決まっていた。
　経営陣からの要求はちゃんとあって、そこで使う技術については国際標準があるのでドキュメント読めば作るべきものはわかる。でも理解するには前提知識がだいぶ必要で、理解した上で作り方を考えたりスケジュールを見積ったり実現できるゴールを定めたりできるレベルの人はおそらく一人しかいなかった。その一人っていうのが、今も一緒に仕事している私の夫であり、夫から、チームを作ってプロジェクトを進めるのが困難だという話を聞かされてもいた。夫は強いエンジニアで、なんとなくマネジメントみたいなこともしなくてはならない立場にいるけど積極的にやりたいとはまったく思っていない人間である。私はエンジニアとしての力は弱いけど、組織を作ること・動かすことにとても興味がある。

OSTについて

　「17:00～ EM Meetup vol,#7-2「一人では解けないパズルがそこにある」~ 技術と組織が交差する複雑系 ~ に参加」と書いたのだけど、「EM Meetupで行われている、Open Space Technologyというアンカンファレンスの手法を用いて、来場者が主体的に参加して議論を起こしていくことで、エンジニアリングマネージメントの意識や学習が生まれることをゴールとして、開催します。」と書かれていて、困っていることについて相談できたらいいなって思って覗いていたら部屋に誘い込まれてしまい、挙手してしまい、この議題について話したいと来てくれる人はいなかったのだけど運営の方たちに来ていただき、できたての組織でプロジェクトを始動させる方法について知恵をいただいた。あの場での議題として適していたのかわからないけど、私にとっては実り多いどころではなく救いのような内容でした。

f:id:n0mzk:20191103224552j:plain

  1. 困っていることを説明して、このプロジェクトをちゃんと始動させたい、チームとして働ける状態を作りたい、という話をした
  2. まずやってみたらいいと思うことを各自付箋に書き出し、それを「すぐできること <-> 実施まで時間がかかること」、「リーダーが一人でやること <-> みんなでやること」の2軸でプロットした（参加してくれた運営の方たちによる提案）。
  3. これから実施すべきことが明確になった

いろんな話を聴いて

  • とにかく不確実性を減らさないといけないと思った。仮説検証、考えるよりなにかやってみなければ、と思った。だから、私はリーダーでもなんでもないけどやりかたを提案してみようと思った。
  • まず決めるべきことは参加メンバーだと思った。それなりの負荷のプロジェクトだと感じているから、今ある業務と照らし合わせて本当に参加できるかどうかを検討しないといけないと思った。みんなの今の業務状況が見えていないから、挙手制でやってもらうのが良いかなと思った。
  • みんなに見える見通しがないといけないと思った。だから、ゴールを経営陣に決めてもらおうと思った。それより近い期日と目標を定めて、マイルストンを置こうと思った。
  • 夫の頭の中にある情報をみんなの見えるところに出してもらわないといけないと思った。だから、最低限読んで理解しておくべき資料を決めてもらった。
  • メンバーが決まったらまずはキックオフが必要だと思った。だからその日程の目安と、それまでにやっておく必要のある事柄を考えた。
  • そのあとはやはり手を動かして目に見える成果物を作っていかないといけないと思った。だからキックオフしたら開発に入ろうと思った。

　帰ってきてこれらの話を夫に共有して、3月末までのマイルストンと、年内に作る範囲を決めてもらった。
　その上で、プロジェクト始動のためのスケジュールを提案してみた。金曜日の退勤間際にslackに投下したのでこれがどうなるのかわからないけど、私個人としてはだいぶ不確実性が下がったように感じて、進められそうだという手応えがある。どうなるかわからないけど。

その他に得たこと

　プロジェクトを始動すること以外にもいま会社が抱えている問題の解決を助けてくれそうな学びがたくさんあったのでメモ。

コミュニケーションをやらないと

　一箇所のオフィスに出勤して仕事している文化の人たちは、当然だけど、slackでのコミュニケーションに慣れていない。 チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019 を見たり、参加したOSTでslackでのコミュニケーションを扱っていた2つのグループの発表（以下の写真）を聞いたりして、ルールが必要かもしれない、作ろうかなと思ってる。

f:id:n0mzk:20191103231035j:plain
f:id:n0mzk:20191103231109j:plain
　この1枚目の写真は、参加者の会社でのslack利用事例を挙げているもの。細かいルールを決めることで議論への参加や発信を促している例が紹介されていてとてもおもしろかった。テキストとかチャットコミュニケーションに慣れてない人は使うための努力が必要だし、慣れてる人はビジネスとして使って人を不快にさせない、疲れさせない、出てきてもらうための努力をしないといけないと思った。

ちゃんとやりたい

　テストちゃんと書く、細かく振り返る、その情報を集約して可視化する、メンバーの抱えてる仕事やモチベーションの棚卸しする、みたいなの、ちゃんとやりたいと思った。そのためにプロジェクトや社内を整えていくことを働きかけていきたい。

学習する組織・人間でありたい

　私のいる会社でも社内勉強会を週1でやっているのだけど、発表したいことがある人が挙手するスタイルなので、全員が発表するわけではない。まだ回数が多くないこともあり、組織全体の底上げになっているかどうかはわからない。毎週だれかが作ったものデモするのいいなと思った。社内ISUCONとかやりたいって話もあったけどそんな余白がない。強制的にそのための時間を作ることを組織として決める必要があるのかもしれない。演習型研修を作って基準をクリアしないとプロジェクトに配属しないっていうの、全員のレベルを引き上げるのにとても良いアイディアだと思う。うちの会社にも必要かもしれない（それが導入されたら現状では私はどのプロジェクトにも配属されることができないだろう！）。

ビジョンと期待値

　会社としてのビジョンはあって、会社を作るときにみんなで集まった合宿で話されたし、それらを理解した上で希望したメンバーがJVに参加しているのだけど、文化にまではなっていないように感じる。組織目標とか評価方法もよくわかっていない（新入社員を受け入れる態勢も整ってない。採用戦略と受入の体制が必要）。それではみんな不安。期待値のすり合わせが必要。1on1もやってない。各自が、誰に何を期待されていて、どういう基準で評価されて、どういうビジョンを持って働けばいいのかわかっていなくて、それはとても不安で孤独なことだなと思った。私は夫から多少情報が共有されていることによって孤独や不安が和らいでいる部分は多分にある。情報の非対称性が大きすぎては、人は幸せにならない。

組織を作ること

　会社っていろんな人間が集まるところだからそれぞれ苦手なことはあるけど、それを避けようとばかりしていては成長できない。苦手なことにも挑戦するから成長できると思った。ただし自分ができたことを他のメンバーもそうすべきだと考えて押し付けてはいけないし、自己責任論ではよい組織は作れない（私は性格がキツいという自覚があるから優しくありたいと思っている）。

人生

　ようやく目的意識を持って仕事しだしたらとっても楽しくて、こんなにたくさん学ぶことがあって、これまでの2年半の下請けとアルバイト時代、なんてもったいない時間の使い方をしてしまったんだろうと思った。大学卒業までもなんとなく流されるままいたし、社会人になっても私がやりたいこと、私がやるべきこと、私でないとできないことがわかっていなかった。結局メンタルを壊してなにもせず過ごした数年があって、受動的に仕事していた2年半があって、31歳にしていまようやく人生が始まったと感じているので、いままでの空白を取り戻したいし、先人たちに追いついて対等に会話できるようになりたいと思う。今回言われていた「廊下での会話」（カンファレンスって、資料や動画はあとから公開されるけど、大事なのはその場で、廊下で参加者たちと会話することだ）ができるレベルになく（それでも話しかけていただいてすこし「廊下での会話」ができたことはほんとうに嬉しくありがたい）力不足をあらためて思い知らされたので、EOF2020までに、「廊下での会話」ができるようになろうと決めた。EOF2020、開催してほしい。

最後に

　会社の良くないところばかり目立たせてしまったかもしれないけど、不満だって言いたいわけではまったくなくて、おもしろいことをやっている会社だと思っているし、私はいまとても楽しく働かせてもらっている。設立間もないから問題もあるけど、それを良くしていきたいと強く思っています。
　EOF2019を開催してくださったみなさん、行かせてくれた会社、留守中子どもたちを一人で見てくれていた夫、ありがとうございました！

『色彩を持たない多崎つくると、彼の巡礼の年』

小説 感想 生きる

　ずっと読みたいと思っていて、文庫化されるのを待っていたと思うのだけど、2015年12月に出ていたらしい文庫本を今になってようやく読んだ。

　彼の巡礼が、後になるほどとにかく苦しかった。

　こういう終わりかたは好きではない。読者に委ねないでぜんぶ書いてほしい。

　私は幸いにもと言うべきか残念ながらと言うべきか、ここまで生き残っている。そうでないことを願っていたしそうでなくなるよう働きかけたことがあったにも関わらず。だからこのまましっかりここに生き残り続けないといけないのかもしれない。クロの、いやエリの、乳房の密な重みを感じながら。