#RSGT2019 参加ログ1日目

11月、macの前で正座待機してチケットをゲットしたRSGTの1日目が終わりました。
印象に残ったフレーズとそれに対する自分なりの意味づけをメモしておきます。
内容の要約ではありませんので、あしからず。

Gabrielle Benefield - Outcome Delivery: delivering what matters

Gabrielle さんのkeynoteでした。
前半はデザインの話から始まり、後半アジャイルな話題に急加速していき最初からダイナミックな展開で、期待をはるかに超えたエキサイティングな内容でした。
そして公式サイトから各種ツールを配布されています！

印象に残ったフレーズ

  • もはやアジャイルはシンプルでない
  • とにかくwhy? なぜそれをやるのかを全員で納得できるまで話す。
  • 計測できるもの＝得られるもの。計測できないものからは得られない。
  • ただアウトプットをするだけでなく、どのくらい目標に近づけたかを計測する

自分への意味づけ（自身への問い）

  • メビウスのキャンバスは永続的に価値を届けるための考え方。これをどうやって適用できるのか、今は使えないのかを考えてみる
  • 自分が何をやっているのかわかっているのか？要件だしてもらうの待ってるだけなのか？
  • 自分の活動は誰のどんな問題をどのくらい解決しているの？（定量的に言えない今の自分には苦しい問い）

Matteo Carella - Coaching resilient Scrum teams

Matteo さんのアジャイルコーチのお話。
とても大きな組織（2000名規模）に、少ないアジャイルコーチ（10数名）がどのように変革を促していった内容でした。

印象に残ったフレーズ

  • 普遍的な成功モデルはなく、会社ごとに必要なモデルが自然発生してくるはず
  • 限られたリソースでどれだけチーム・会社にインパクト（成果）を与えられるか
  • 実装ではなく原則をコンパスとする
  • レールの敷かれた電車ではなく船で航海にでるようなもの。その時に必要なのは計画ではなく、地図とコンパス。
  • 不確定性・不安定性にチームとしてどうやって臨むか→キーワードは弾力性resilience（チームが生き残るちから）
  • 土壌を作り、その中でアジャイルな何かが芽生えるように導く
  • 会社とはエコシステムそのもので、プロセスと文化が相互に影響を与える
  • ヒエラルキーではなく非公式なネットワークが重要
  • 組織は生き物だ、本当にアジャイルな職場というのはその職場から生まれくるもの。どのように人々が繋がりコミュニケーションをしているかが本当に重要。

質問

[Q] コーチングコンパスの右上、非定型のチームとは具体的にどのようなコミュニケーションをとって、何をどのようにしてカイゼンしていったのかを知りたい

[A] プロダクト開発ではない、例えば広告運用などを行なっているチームではスクラムの導入はできない。
だが、アジャイルなプロセスを導入することはできる。
上記の広告運用などを行なっているデジタルマーケティングチームでは、カンバンによる可視化による作業の無駄の排除、広告パフォーマンスの継続的な改善によるコスト最適化など。

自分への意味づけ（自身への問い）

  • 地図とコンパスを自分で作って常にアップデートしているか？レールを探して乗ろうとしていないか？
  • スクラムやアジャイルの原則を見失ってはいないか？
  • 自分たちのチームの弾力性はどうやって可視化できるだろうか？

Takuo Doi - 行動分析学に基づくScrumの導入

お昼休憩のとき、ふと隣に立っていた人に話しかけてみたらこのセッションのDoiさんでした。
立ち話でこのセッションのことをざっくり聞いて、俄然興味が湧いて参加しました。

印象に残ったフレーズ

  • scrumの習得の難しさは状況によって解決策が変わるところにある
  • 開発プロセスに従うのでなく、そこにいる人に従う
  • 行動分析学は目の前の行動を変える変数を実験によって探る方法論をもつ。何かができない、を人の意志の弱さや能力のせいにしない
  • 必ず好子が出現するよりも確率的に好子がでる方が行動は継続する
  • 悪子によるマネジメントの方が即効性があるけど、モチベーションの低下が起きやすい
  • 目先の好子、悪子に囚われた行動に陥りがちだが、長期的に逆に作用するものがある（筋トレが続かない、カロリー高いおやつ食べてしまうなど）
  • 行動分析学をscrumに応用するには、まず対象とする行動を特定して、その行動の先行事象・後続事象を分析、そして好子を増やすもしくは悪子を減らすことで行動が改善されるかを検証する
  • scrumの原則によればうまく行っていないのは定められたロール・イベント・成果物のいずれかであるはず
  • 同じ事象であっても好子と捉えるか悪子と捉えるかは個人によって変わる

自分への意味づけ（自身への問い）

  • プロセスに頼りすぎていないか？チームの個人にきちんと目を向けているのか？（特に最近自分に最適化しすぎていたので耳痛い）
  • チームで起こっていることについて、能力ではなく事実として客観的にどんな行動を改善したいのかを考える
  • 目先にとらわれた行動をしてしまう自分を変えるために、仮説を立てて検証せよ

Mitsuyuki Shiiba - ちゃんとやってるのになんかうまくいかないスクラムからの脱出

タイトル的にぐさっとくる感じで参加しました。
とても熱量高く、惹きつけるものが強かったです。

印象に残ったフレーズ

  • やったことマップはあくまでも結果。最初から描けていたわけではない
  • 形骸化したレトロスペクティブはリアルの感触を大切にしつつ感謝と対話を中心に
  • 一本道を作って、平行作業をやめる
  • コードレビューの基準は、チームとしてそのコードに納得しているか
  • 希望的な観測ではなく、過去の実績に基づいた計画を立てる
  • スプリントゴールは誰がみてもわかるものにして、デイリースクラムでそこにたどり着けそうかを確認する
  • いきなり全ての実装をリリースすることを目標にすると厳しいので、ステージング環境でハマりそうな道のりを一度歩いてみる、それ自体をゴールとして設定する
  • できないことがあるのは事実だけど、できていることもある。そこに目を向けつつチームに頼る
  • スクラムは期待を打ち砕く。現実を見なければ改善が進まない
  • スクラムの基本から外れている部分には期待値が入り込みやすい

自分への意味づけ（自身への問い）

  • スクラムから外れているところをもう一度見直そう
  • そこに入り込んでいる期待を認識する（チームで）

kyon_mm - 超Scrum入門〜未完成フラクタルと15minSprint〜

www.youtube.com

とにかく映画が最高でした。

印象に残ったフレーズ

  • 超個体を目指す。設計書や指示はない。コンパクトなルールに個体が従って行動することで美しいものを生み出す
  • いつモブ/ペア/ソロワークをするか、そのきっかけづくりは難しいので、15分ごとにきっかけを作る
  • アートとしてのKPT
  • 定量化できない改善策ではふりかえったところで右往左往してしまう
  • 短い期間での正のフィードバック（改善する）&長い期間での負のフィードバック（意味をなさなくなったこをやめる）
  • やれてないことは、本当はやりたくないことなのでは？
  • 気を回していてすり減る部分は自動化して受動的になる

自分への意味づけ（自身への問い）

  • 気を回してすり減ってしまっているポイントを洗い出す
  • 改善策、定量化できてる？

まとめ

このほかにも、きろーさんにコーチセッションの時間をいただいたり、合間のLTを楽しんだり、ネットワーキングの時間で濃い話をたくさん聞けたりしました。
総じて最高すぎるので明日に向けてそろそろ寝ます。

スクラムチームの引き継ぎで崩壊した話

この記事はDevLOVE Advent Calendar 2018の20日目の記事です。

adventar.org

概要

先日イベントに参加してLTしようとしたが、仕事忙しすぎて参加できなかったので、資料の行間を文章にまとめておこうと思います。

↓発表予定だった資料

引き継ぎ前の我流スクラム

  • 2wスプリント
  • プロダクトバックログはスプレッドシートに羅列
  • ホワイトボードと付箋でタスク管理
  • 担当者ごとにタスクレーンを作成
  • ストーリーに対して見積もりはほぼ行わず、「だいたいこれくらいできるかな？」をメンバーが各々に判断してスケジュールを作成
  • リファインメント、レビューは未実施
  • デイリースクラムは実施

所感

メンバーとしてはスクラムに関する知識が浅く、当時のリーダーに運営を頼りきりでした。
また、「見積もりが担当者に依存している」＆「タスクレーンが担当者ごとに分かれている」ことで、お互いの作業に対して積極的に情報を取りに行かないといけない状態になっていました。ここは当時のリーダーが交通整理をしていました。
そして、チームとして達成すべきゴールが不明瞭であるため、計画したタスクが終わらないことに対する危機感が薄い状態になっていました。（そもそも妥当な計画がわかっていない）

チームを引き継いだ結果

見よう見まねでスクラムマスター的な振る舞いをした結果

  • プロダクトバックログは優先順位もつかず、やるべきもの、捨てるものがごちゃまぜに
  • スクラムボードには数ヶ月前に貼られたタスクがdoingに残りっぱなし
  • いつdoneしたかわからないタスクも残りっぱなし
  • そして実際にメンバーが取り組んでいる作業はボード上にはない

所感

スクラムで開発する目的が不明瞭でした。
自分たちがなぜこの方法で開発しているかを理解していない上、手法についても理解が浅かったため、ふりかえりすらも義務感からやっている状態でした。
さらに、過去ある程度コミュニケーションをお互いに取らなくてもリーダーが補完してくれていることで回っていたことに気づかず、少人数ながらお互いにやっていることがわからず、お互いのサポートができない状態になっていました。

改善フェーズ1

  • とりあえず物理ホワイトボードからTrelloに移行
  • ふりかえりの学びを活かすためにホワイトボードに気をつけるポイントとかを明文化

所感

根本的な問題に気づかずに場当たり的にツールを試していました。
結局問題は解決できず、ツール上でもすぐに荒廃してしまいました。

改善フェーズ2

  • アジャイルの勉強会に参加して、先人の知恵をいただく
  • 書籍からメソッドを学んで実践する
  • スクラムマスター研修への参加

所感

自分の現在のスキルではどうにも対応することができないことに気づきました。
そこで勉強会に参加して生の声を集めること、書籍からメソッドを学ぶことにシフトしました。
ここで重要だったことは「学んだことを素直にそのまま試す」ということでした。
中途半端に知ったかぶりをせず、学んだことをそのまま実践したことで、チームの成長が加速していきました。
また色々なことを同時に試すと、何が良くて何が悪かったかが見えなくなってしまうため、1スプリントで1つずつ改善をしていきました。

まとめ

  • ぶっこわしてもいいんだ。 →何をやってもうまくいかないフェーズは避けては通れないので、大きく失敗する。ただし、信頼できるチームメイトに恵まれていないと危険。
  • 人に依存していると退職のダメージは大きい。 →全員がチームの成長を実感してそこに貢献していることを感じていないと、依存している1人がいなくなった時に死にます。
  • 近くにいてもチームであるとは限らない。 →コミュニケーションは場を設けなければ自然発生させることができません。そのためにスクラムのイベントを活用しましょう。
  • スラム化してしまったら、意識のドラスティックな変革を。 →過去にしがみついても仕方がない、今まで自分たちがやってきたことは捨てるという勇気が必要です。
  • 書籍は実際に試さないと勿体無い。 →逆に言うと、現場ですぐに実践できないような内容の書籍を読んだとしても、スキルを身につけることは難しいので、投資効果が悪いです。
  • 経験者はやさしいから思い切り甘える。
（ただしできる限りのアウトプットを） →無料の勉強会を続けているコミュニティを尊重しましょう。タダ乗りはダメです。Twitterで呟くもよし、参加レポをブログで書くもよし。
  • 認定スクラム研修はいいぞ。
（参加前にあがいていたからこそだったかも） →参加前にいろいろとうまくいかなかったことの答え合わせができました。そこで知識として頭に定着した感じがあります。

チームの引き継ぎで悩んでいる人に届けば幸いです。

社内で最初のリモート正社員の苦闘（1.5y経過）

はじめに

このpostはIT地方エンジニア Advent Calendar 2018 15日目の記事です。

adventar.org

想定する読者

以下のような読み手の方に楽しんでいただけることを想定して書きました。

  • リモートワークにチャレンジできるチャンスがあるが、躊躇している
    • 一人一人に最適な解は違いますが、何かの励みになれば
  • リモートメンバーを抱えていてマネジメントに困っている
    • 私がメンバーとしてうまくいったこと、うまくいかなかったことが参考になれば。
  • リモートワークをしているが、キャリアパスに不安がある
    • 一応メンバーからリーダに昇格しました。リモートでもなんとかなるという励みになれば。
  • リモートワーク？なにそれ？たべれるの？
    • リモートワークを本当にやってる人もいるんだよ。

想定しない読者

逆に以下のような読み手の方の期待にお応えするのは難しいと思います。

  • リモートワークで悠々自適田舎ライフを満喫したい
    • 私が知りたいです
  • 社内にリモートワークの制度を作りたい
    • 制度を上から押し付けたらうまくいかないと思っています。やりたい人がその人なりにやって、自ら制度になることがおすすめです。
  • 地方でキャリアの選択肢が詰んでる
    • 私も詰んでましたが、偶然知り合いがいてなんとかなりました。再現性は謎です。

前提条件

会社について

  • 非IT企業
  • オフィスは東京
  • ITプロダクトは基本的に外注して作っていたが、近年新規事業を中心に内製化を進めている

個人について

  • ソフトウェアエンジニア（web中心）
  • 就職〜6年半は東京でエンジニアとしてSIer、web事業会社に所属
  • 結婚し、妻の実家近く（長野県）に移住し、地元のSI企業に勤めたのち、リモートワークで現職に

どのようにして最初のリモート正社員になったか

経緯

当時のチーム

前提条件に書いた通り、私が現在所属している会社はIT企業ではありません。 ITを使った新規事業を立ち上げるも、ITベンダーに丸投げになってしまいプロダクトを成長させることができずにいました。
そんな状況に危機感を持ち、IT系出身の事業責任者を引っ張ってきて、新規事業を任せました。
その事業責任者は、プロダクトを改善するためには強い内製チームが必要であることをよく理解しており、気心の知れた優秀なエンジニアを最初に一名正社員として採用しました。（この正社員一名は私の最初のリモート上司になります。）
当然一名では足りず、業務委託でフリーランスのエンジニア数名も平行して採用して、内製チームを作り上げました。 正社員一名＋衛兵チームで開発の最初の波を乗り切りつつ、事業責任者は正社員のエンジニアの採用を模索していました。
採用はwantedlyを中心にしたリファラルに特に力を入れていました。

この時採用をサポートしていたのが、私が東京のweb事業会社に在籍していたときに人事で同僚だった人でした。
その方はフリーの人事コンサルタントとして活躍していて、このチームの採用のwantedlyの記事をfacebookでシェアしていました。
そのシェアされた記事が私と現職の最初の出会いでした。

当時の私

私は当時地元のSI企業に勤めていましたが、東京のweb事業会社から転職した自分としては、スピード感や事業の成長といった側面で物足りなさを感じていました。
とはいえ、地元のIT企業は選択肢も少なく、キャリアに思い悩んでいました。

そんな中、現職の求人のwantedly記事と出会いました。
普段ならwantedlyの記事を開いて中身をみることもないのですが、

  • 知り合いがかなり具体的に紹介していたこと
  • その会社（現職）について、東京のweb事業会社時代に関わりがあったこと

が重なり中身を覗いて見ました。 内容を読むと、新規事業のグロースを支えるエンジニアを募集していて、JD的にも自分のスキルセットとマッチしていて、以前の経験から得られた業界知識も活かせそうであることが判りました。
チームが必要としていた人材像とマッチし、かつ自分が仕事に求めていたスピード感や事業の成長という部分がハマる。こんなスイートスポットを逃してしまってはいけないと思い、私はすぐにその記事をシェアしていた人にメッセージを送りました。

先週○○さんがFacebook にpostしていた××社のエンジニアの募集に興味があって連絡させてもらいました。 もしリモートでの勤務が前提でも大丈夫であれば、一度お話を伺ってみたいと思っています。 よろしければ確認していただけないでしょうか？

互いにリスクを取る

すぐに返信があり、数日後事業責任者とハングアウトで面接を行いました。
業界の話で盛り上がりつつ、技術的なバックグラウンドについてもかなり突っ込んで聞かれました。後からわかったのですが、この事業責任者はもともとプログラマでした。
話の流れで、「じゃあ後はテックリードと役員とそれぞれ面接してもらいますね。まだわからないけど、私としてはもう採用でOKです。」と言われ、すっかり気をよくしました。
ところが数日後、改めて事業責任者からこんな連絡がきました。

私としては全然OKなんだけど、リモートでの採用の実績もないし、会社としてはかなり難しい感じになってます。正社員ではなく、業務委託という形ではダメでしょうか？

チームとしては採用したいけど、会社としてその後のキャリアも含めて何も保証することはできない、ということでした。
私としてはその会社がリモートで採用した実績がないことも知っていたので、会社側の事情も理解できました。しかしこのチャンスを逃してしまってはこの先キャリアの選択肢が減ることはあっても増やすことはできないと考え、以下のような提案をしました。

では3ヶ月間業務委託として雇ってください。それでリモートでも成果が出せると会社で判断してもらえたら正社員として雇ってください。

会社としてリモートで正社員を雇うというリスクを負うことに対して、自分も一時的にフリーになるリスクを踏む形で提案しました。
結果としてこの提案を受け入れてもらい、業務委託の3ヶ月を経て正社員として採用されました。

なぜうまくいったか

一般的な解

リモートであれオンサイトであれ、求人に応募する場合は自分のスキルセットや志向がそのポジションにマッチすることが前提です。
当然リモートワークの求人数はそうでない求人数に比べると格段に少ないので、私もリモートワークの求人の中から自分にあったポジションを探そうとしていたら、もっと苦労していたと思います。
その意味では、自分自身のシーズと採用する側のニーズがマッチする求人と巡り合ったということが一番の要因だと思います。

不確実要素をいくつ受け入れるか

採用する側としては一度にたくさんの不確実要素を受け入れるのが難しいという課題があります。
例えば求職者をチームのメンバーとして採用する場合、「年齢（≒のびしろ） × スキル × 業務知識」のような複数のディメンジョンを考慮して採用をするのが一般的です。
「この人は別の業界から来るから業務知識は少ないけど、若くてのびしろもあるし、エッジの効いたスキルを持っている」など、仮に一つのディメンジョンが採用の基準に到達していなくても、他のディメンジョンでカバーできると思います。 これを、採用する側もされる側もリモート未経験とう状況に適用すると、かなり難しい状況になるのが想像できると思います。
幸い私は、年齢はチーム内で比較的若く、面接の結果スキルセットは問題なく、業界知識はある程度あり、かつ紹介者から性格についてもある程度問題ないという事前のインプットをしてもらっていました。
これらの要素が重なり、採用する側として受け入れなくてはいけない不確実要素が「リモートワークである」という一点のみに絞ることができました。 その不確実要素についても、正社員として雇用する前に業務委託としてトライアルすることにより事前に潰すことができました。

採用する側、される側のどちらかがリモートワーク未経験という場合は、いかに事前に不確実要素を抑えられるか、これが重要だと思います。

人に依存する部分も大きい

採用する側がリモートに対して寛容であることは前提です。
特に直接の上司となるリーダやマネージャが、過去リモートワークでの失敗体験などを抱えている場合は難しいと思います。
その意味で、リモートワークでの人材募集をしていないポジションにリモートとして応募する場合は中の人といかに繋がれるかが勝負になります。 （私の場合も、正面からwantedlyに応募していれば書類で弾かれたと思います。）
もし中の人とつながることができたら、次のようなことを確認してみると良いと思います。

  • リーダー・マネージャはリモートワークに対してポジティブか、ネガティブか
  • そのチームは会社の現在のメインストリームか、あるいは今後メインストリームになる可能性がどのくらいあるか
  • 経営層はオープンなマインドをもっているか

正社員として所属する場合、チームが解散した場合には他のチームに異動になることがほとんどです。
特にこれまでリモートワークが採用されていない会社の場合、チームを出ると社内で風当たりがきつくなることがあります。 そこで、チーム内でリモートワークを受け入れられるか、そもそもそのチームは安定的に仕事を続けられるか、そして経営層はこれまでなかった働き方に寛容であるか、ということが重要になります。

私の場合、リーダ・マネージャについてはリモートワークに対してかなりポジティブであることは事前情報としてキャッチアップしており、業務委託期間に2番目、3番目を確認しました。
正直なところ、今もまだメインストリームにはなっていませんが、なんとか同じチームで継続して働けているので、そこまで大きく見誤ったわけではなさそうです。

マネジメントされる側としてのリモートメンバー

私が業務委託として入場したタイミングで、件の正社員のエンジニアがリーダーとして私の上司になりました。
最初はオンボーディングのため1週間オンサイトに出社し、その後は2週間に一度水曜〜金曜出社するというリズムです。
単純に考えると4週のうち6営業日出社していることになっています。

マネジメントされる側としては基本的には良いメンバーシップ、フォロワーシップを発揮するということにフォーカスすることが大事だと考えています。
リモートから良いメンバーシップ、フォロワーシップを発揮するために特に気をつけて実践していたことを以下に書いていきます。

出退勤

基本的にはslackで朝作業を開始するタイミング、お昼で席外すタイミング、仕事を終えるタイミングでslackでつぶやきます。
毎日同じリズムで仕事をすることで、マネジメントする側に安心感を与えることができます。
リーダーや他のオンサイトメンバーから見たときに、毎日同じくらいの時間に情報がpushされてくると、それだけでチームの一体感が生まれます。

これは一見簡単なことのようですが、忙しくなったり仕事へのモチベーションが下がったるなど、不調になるとついつぶやくのを忘れるようになってしまいます。
特にリーダーになってから思うのですが、メンバーごとのルーティン作業の質や量に変化があったときには、何かしらの合図だと考えられます。
リモートで顔を合わせないからこそ、自分でも気付きにくい自身の変化を周りにpushする方法としても、出退勤の合図はとても役立ちます。

少し古いツールですが、私たちのチームではこのツールを使っています。

blog.masuidrive.jp

朝会

毎日の朝会には、ビデオチャットで参加しています。
ここでメンバーシップとして重要なことは、いくつかあります。

  • 朝会の前に、前日の日報を見直して喋ることを準備する
  • 簡潔に、はっきりと喋る
  • 自分のタスクに関連するメンバーの表情や雰囲気を読み取る
  • よく聞こえなかったり、多少情報が欠落しても気にしない
  • それでも知りたいことがあるときには、容赦なく他の人の話を遮って聞く
  • 朝会の後に自分が喋ったことをslackで再度共有する

事前準備に関しては結構重要です。
丸腰でいくと「なんか色々やってました」のような報告になってしまいがちです。
オンサイトの場合は「あれ、昨日あの作業やってたよね？」のようなフォローが相互になされるのですが、それがないリモートメンバーは自分のことは自分で伝えるしかありません。
「どんなことでハマったか」「誰とやりとりして時間を使ったか」など、その人の1日が想像できるような報告が望ましいです。

また、どんなに頑張っても、1:Nのビデオチャットではリアル対話の70%くらいの情報量をゲットするのが限界です。
2~3割くらいは聞こえなくても気にしないおおらかさが必要です。
それでも「ここだけは」という部分に関して、文脈や誰かが喋っているかなど気にせずズケズケと聞くことが大切です。その姿勢がリーダーや他のメンバーに安心感を与えてくれます。

日報

基本的にリーダからは毎日ソースコードがコミットされることが一番見えやすい進捗です。
しかし現実の仕事の中では調整や思考に費やす時間もかなりの割合を占めると思います。
隣で仕事をしていれば、「あーいまハマってるな」とか「こいつ今完全に充電（twitter）してんな」とかわかるのですが、リモートだとその塩梅をどのように伝えるかが難しくなります。

当初私はこんな感じで毎日メールでリーダーに日報を送っていました。

・XXXXXXXXXXXX（案件名）
→先方と仕様について調整済み。明日実装完了し、prお送りします

・YYYYYYYYYYYYY（案件名）
　YYYY抽出条件の変更：完了
　htmlへの変数埋め込み：完了
　メールのレイアウト修正：完了
　単体テスト：作業中

これの良い点は日報を書くためにタスクをきちんとこなすことができる点です。
そのために、日報は1日の終わりに書くのではなく、作業しながら書くことがおすすめです。
メールでもslackでもテキストエディタでもよいのですが、下書きとして朝から「これから一時間でこのタスクやろう」と決めて1時間ごとに日報をアップデートします。
そうすると自分の1日のリズムもわかるようになるし、夕方1日何したかを思い出すような無駄な時間を無くすことができます。

ペアプロなど

チームではペア（モブ）プロ、ペア（モブ）運用作業を取り入れ、チーム内でのスキルの平準化を進めています。
最近のビデオチャットツールでは、どれでも画面共有機能があるので基本的にはリモートでも問題なく参加することができます。
ただ、モブプロのモデレータ側の場合にオンサイトの温度感に乗り遅れることがあります。
特に自分の不得意分野であったり、slackなどの通知がうるさいとオンサイトに比べて集中しにくい状況になります。
この解決策はまだ見つけられていないので、リモートモブプロのライフハックをお持ちの方に是非聞いてみたいです。

マネジメントする側としてのリモートリーダー

チームに入ってから1年弱が経過する頃、件のリーダーが退職することになりました。
その時点でチームには私を含めて4名の正社員が在籍しており、その中で一番早くjoinした私がチームのリーダーを引き継ぐことになりました。 チームでは当時スクラム開発を導入しており、私もそれを引き継ぐ形でスクラムをベースにしたチームのリーダーになりました。 スクラムを引継ぐ難しいポイントやリモートスクラムについては、別記事にしようと思います。

リモート面接

私がリーダーになると同時に、業務委託メンバーの退場、正社員メンバーの配置換えが行われ、最初の仕事としてチームメンバーを集める必要がありました。
特に最初は業務委託メンバーを採用するため、毎日レジュメに目を通し、毎週面接を行いました。 とにかく早急にメンバーを採用する必要があったため、先方の都合に合わせて面接のスケジュールを組み、結果的に私がリモートで面接をする機会が増えました。

面接スタイル

面接は毎回オンサイト側に来社してもらい、面接対象のエンジニア、そのエージェント、私（リモート）、チームメンバー1名の合計4人で行いました。
面接の流れは、私がプロダクト、技術スタック、実際にお願いする業務の説明を行い、先方のエンジニアに自己紹介をしてもらい、そこから質疑応答というスタンダードな流れで行いました。
このようなスタイルの面接は他に行っている会社がないのか、エージェントの方が驚くことが多かったです。
ここでもいくつかtipsがありますのでご紹介します。

tips

  • チームメンバーのマシン以外に、ビデオチャット用のマシンを1台用意する
  • たいていレジュメはその場で手渡されるので、事前に入手して開いておく
  • 難しい名前の読み方の場合、ビデオチャットで聞き取れないことがあるので、事前にわかれば聞く。最悪わからない場合でも動揺しないように心の準備をしておく
  • ホワイトボードを使って何か説明してもらうタイプの面接内容の場合は、事前に何パターンかイメージを膨らませておくとディテールが見えなくても動揺しない
  • オンサイトの場合でも事前に質問したいポイントを絞っておくことが重要だが、リモートの場合会話がターン制になるので、タイミングを逃さないためにも事前の質問事項の作り込みは重要になる

朝会のところでも触れましたが、どうしても細かい部分で聞き取れなかったり読み取れないことがあります。そこで、実際に交わされる対話のイメージをどこまで事前に膨らませておけるかがとても重要になります。 また、マシンなどハード面の準備はできる限り万全を期しておかないと、相手に悪い印象を与えてしまいます。逆にリモートでもスムーズな面接が実施できると、働き方の多様性をアピールできる良いチャンスになります。
また、今後の取り組みとしては、面接相手のエンジニアの方、エージェント、チームメンバーも含めて全員ビデオチャットで環境を揃えて面接ができるとよりスムーズな面接ができるのでは、と考えています。

情報共有

問題があることに気づかなかった

リモートメンバーのときには、リーダーに自分の情報をpushすること、朝会でチームの情報をpullすることで、オンサイトのチームリーダーがhubとなり情報を共有することができていました。
リーダーになってしばらくの間、私はその前提がよくわかっておらず、メンバーのときと同様に自分の情報は一日に数回push、朝会でチームの情報をpullしていました。
程なくして、これまでhubとなっていたリーダーの役割がなくなったことにより、メンバー間でお互いがやっている仕事、チーム外の情報などが全く把握できなくなりました。

ツールでは解決できず、悪循環に

この状態になって、初めて情報を共有するということに対して能動的に考えて働きかける必要性に気づきました。
最初にTrelloを取り入れました。朝会で各メンバーがTrelloに登録済みの当日の行動計画を共有し、翌日に進捗状況を共有をすることで、デイリーで作業状況を把握することが狙いでした。
しかしTrelloは2週間ほども持たずに形骸化してしまい、実作業とTrelloとの乖離が大きくなってしまいました。
状況をお互いに共有しても、その状況をより良くするためにチームとして何も改善することができなかったためです。
実際に積極的に情報を共有してくれるメンバーがいても、その情報をチーム全体としてプロダクトやプロセスを改善するために役立てる方法がわからず、そういった状況が情報共有へのモチベーションを下げていました。

何のために情報を共有するのか

転機となったのは、メンバーの入れ替えでした。
前任のリーダーがまだ在籍した頃チームから退場した業務委託メンバーが、縁あって戻ってきてくれたことをきっかけに過去と現在のギャップを客観的に、かつ前向きに共有してくれました。
これをきっかけに、「前を向いて改善するための情報共有」の仕組みをチーム作ることに注力し始めました。
まずはそれまで2週間だったスクラムのスプリントを1週間に縮めふりかえりの頻度を高めました。 また、この時期に参加したアジャイルの勉強会で「ふりかえりの問題のひとつは、ふりかえりをやるまで各メンバーが問題を抱え込んでしまうことだ」という話に感銘を受け、朝会でも問題点を抽出できるように工夫を加えたりしました。
この頃になると、朝会のファシリテートは基本的にリモート側の私が行い、自然に私が情報を積極的に集めに行くようになっていました。

更にその後、認定スクラム研修を受講するなど、スクラムをベースにした開発プロセスの改善を繰り返し、現在では朝、昼、夕方の1日3回、あくまでも積極的なメンバー間での情報共有の場を設けるようになりました。
その場では、各自の状況を共有しハマっていることがあれば「ペアプロでやっつけよう」などの改善策をその場で考えて実施できるようになりました。
情報共有から改善へとつながるポジティブなフィードバックループを作ることで、物理的な距離を意識しなくても、お互いが考えていることや実際に行っている作業が見えるまでに情報が同期されるようになったのです。

まとめ

長文になってしまいました。
書いている最中に気づいたのですが、リモートとして最もハードルが高いのは、やはり最初にチームにjoinするフェーズなのだと思います。
それ以降のメンバーとして、リーダーとしてという話は、リモートでもオンサイトでも本質的にはあまり変わらず、そこを押さえた上でコミュニケーションチャンネルをどう確立するか、という問題なのだと思いました。

リモートワークがすでに文化として根付いている組織であれば別ですが、これからリモートワークを導入するのであれば、制度を先に決めないことをおすすめします。
リモートで働くメンバーや、そのメンバーを擁するチーム、そのチームのプロダクトなど、状況によって必要な仕組みは変わっていくと思います。
その変化の中でポジティブなフィードバックループを生み出す仕組みというのは事前に決められるものではなく、失敗を繰り返しながら当事者が自発的に作り上げていくものだと思います。

リモートワーカーの皆様や、これからリモートワークにチャレンジする方の励みに少しでもなれば幸いです。

子供に自分の言葉を伝える方法を考えた

この投稿は子育てエンジニア Advent Calendar 5日目の記事です。

adventar.org

先日子供（1才半）と遊んでいたら、ふと子供に良い話をしたくなってきました。
良い話とは、いわゆる「君が２０歳になった時に伝えたい話」みたいなやつです。
とりあえずEvernoteにメモし始めたのですが、「自分が事故とかで明日死んだらこれは永遠に読まれないのでは…？」と不安になってきたので何かしら工夫しなければと思いたち、でいろいろと手段を調べてみました。

何も伝えるものはない派

少し年上で父親経験も豊富なエンジニアに話を聞いたところ

子供に伝えたい言葉はなにもない。自分が子供に成長させてもらっている。自分が成長させたいっていうのは親の自己満足で、子供は勝手に育つから何も心配していない。

なるほど、、、
確かにそのとおりですね。自分の子供もまだ1歳ですが、子育てを通じて自分が成長させてもらっているな、と日々感じています。
そして自分の子供時代を思い出すと、確かに親の言葉など聞いた記憶がありません。
進学先の進路を決めるときや就職先を決めるときなど、完全に決定後の報告でしたし、ましてや転職に至っては転職したあとに報告していました。

ですが、それはあくまでも自分の両親が健在だからなのかもしれないとも思います。
それと、自分が「何か言葉で子供に伝えたい」という思いと、その言葉から子供がなにを感じるか何も感じないか、これらは本質的に無関係なので、自分が伝えたいという思いを持っている以上、その方法を考えて実践することは無駄ではなかろうという結論に至りました。

引き続きソリューションを検討します。

SNSで公開しておく派

別のもう少し年上で、4人の子宝に恵めれたエンジニアに話を聞いたところ

あー、それ自分もすごい悩んだんだよね。とりあえずFacebookに書いてたんだけどさ、なんか良いこと言いたいおっさんみたいになっちゃったんだよね。

そうそれ、完全に良いことこと言いたいおっさん。
私もこれを考え始めて最初に思いついてのが、とりあえずFacebookやTwitter、ブログに書くことでした。
でも書きたいことは、然るべきタイミングに、然るべき相手だけに伝えたいことなのです。
不特定多数の人間に対してそれを書いて、それに何かコメントなど付きようものなら、、、
考えただけでも恐ろしかったので採用できませんでした。

遺言サービス

なんとなくやりたいことが「遺言」なのではないかと思い、遺言に類似するwebサービスがないか調べてみました。

camp-fire.jp

やってました。芸人の田村淳さんがプロデュースしてます。
しかし、公式ツイッターは半年以上更新されていないなど、進捗が闇に眠っているようです。
クラウドファンディングも未達のまま終了していますし、これはちょっと期待するのが難しそうです。

遺言としては、明日必要になるかもしれないし、来年かもしれないし、あるいは10年以上先かもしれません。
そう考えると、クラウドファンディングで短期的に調達したサービスだと少し不安もありますね。
まあ子供向けに残したいメッセージであれば、最長でも20年くらいサポートされる見込みがあればよいのかもしれません。

この他遺言サービスを探しましたが、弁護士事務所のサイトや終了済みのサービスしかヒットせずあまり望ましい結果は得られませんでした。

タイムカプセルサービス

次にタイムカプセルサービスを調べてみました。
いくつかのサービスがありました。

物理タイムカプセル

物理的なタイムカプセルのサービスを行っている会社がありました。

www.timecapsule.co.jp

倉庫の会社ですね。
たしかに最長10年のタイムカプセルであれば良いかもしれません。10年後であれば子供もある程度大人の言葉も理解できそうです。
ただ、難点は一度封入するとその内容に追加したり変更したりすることができないことです。
私がやりたいことは、今思いついた言葉をつたえるというよりも、この先日記のようにインクリメンタルに伝えたいことを育てていき、あるタイミングでその言葉のストックを子供に伝えたいのです。
なので、イミュータブルな物理タイムカプセルは私の用途には不向きだと判断しました。

郵便サービス

指定した経過年数後に郵便を送ってくれるサービスも多数ありました。
例えばこちらです。

npo-mirainet.com

ちゃんとしていそうなサービスです。
手紙そのものはイミュータブルですが、一通あたりのコストも安いですし、QRコードを埋め込んでおくという方法もありかもしれません。
しかし、自分がサービスの申し込みをしたタイミングと、それを受け取るタイミングで住所が変わっている可能性が非常に高いという大きな問題があります。
実家を宛先にするなども考えましたが、実家こそ10年先まであるかはわかりません。
なのでこのサービスも用途には不向きだと判断しました。

アプリ

変化球ですが、こんなアプリもありました。

jp.techcrunch.com

これは写真に特化して時間差で撮影した写真を特定の宛先にメールで送ってくれるサービスです。
本質的にやりたいこととは少しずれているのですが、おもしろかったのと、5年以上サービスが継続していてすごいな、と思ったので共有してみました。
カジュアルに写真をとって数年後に共有するというのは面白いかもしれません。

ただ、やはりやりたいこととは少しずれています。

自分でなんとかしよう

公開されているwebサービスはどれも継続性が怪しい＆それなりのランニングコストがかかるので、いくつかのアプリケーションを組み合わせて自前で何とかすることにしました。

文章のストック

はてなブログのなぞなぞ認証機能を使うことにしました。
伝えていことははてなブログに書いていき、なぞなぞ認証で一般には見れないようにしておきます。
はてなブログが終了するリスクはありますが、日常的に投稿をストックしていれば、サービス終了のタイミングを検知することは難しくないと考えました。

自分の死活監視

twitterのアカウントで死活監視を行うことにしました。
twitterが終了する可能性もかんがえられますが、これも日常的に利用しているため、検知することは容易であろうと考えました。
また、後述する監視方法でAPIを利用しますが、APIのIFが変更されるリスクもあります。
これについては、アプリケーションで検知して対応することにします。

ステートマシン

Google App Scriptを利用して、Google Spreadsheetをステートマシンとして利用します。
twitter APIから自身のアカウントの最新のアクティビティを取得してSpreadsheetに日付を記録します。
この日付を別のスクリプトで監視し、1週間アクティビティがなければwarningを自分自身に発信します。
そして、そのまま1ヶ月アクティビティがなければ家族向けになぞなぞ認証の答えと、ブログのURLを発信します。

GASからtwitterのAPIを叩く部分はこのライブラリを利用しました。

github.com

まとめ

テストする際には間違えてご家族に本番アラートを発信しないように気をつけましょう。

レガシー感謝の日でLTしてきました

先日 ASKUL さんで開催されたレガシー感謝の日というイベントに参加してLTをしてきました。

askul.connpass.com

このレガシーという絶妙なテーマ設定が奏功して、時間の経過とともに会場のボルテージ&一体感が高まり、（少なくとも自分は）参加者同士が身近に感じることができるとても良いイベントでした。

以下個人的に印象に残っている部分をまとめます。

レガシーとは何者か

主催の @dskst9 さんの冒頭のトーク。
私のLTでも「レガシーとは」みたいな話をする予定だったので、内容かぶるのでは？と思ってヒヤヒヤしながら聞いていました。
結果的にはその後の発表でもそれぞれに「レガシーとは」の話をして、重なる部分も違う部分もあってヒヤヒヤし損でした。 個人的には

今のプロダクトはレガシーでできている

というフレーズがとてもしっくりきました。
プロダクトは1日にしてならず、レガシーの積み重ねこそが今のプロダクトの全てなんだ、と勝手に拡大解釈してともて納得しました。

レガシーフロントエンド / LEGACY FRONEND BY LOHACO

同じくASKULから @Kotanin0 さんのトーク。
比較的広義なwebアプリのフロントエンドの段階的なリニューアルのお話。
個人的に現在の仕事の技術スタックにとても近くて勝手に胸熱になっていました。
プレゼンスタイルはタイムラインに沿って、good / badを箇条書きにされていて、とても聞きやすかったです。
のちにtwitterで、パブリックイベントで話すの初めてだったと告白していましたが、全く気付きませんでした。

「新」とか「極」といった中二な開発チームのテンションが上がるコードネームをつけるのは、ぜひパクろうと思いました。

レガシーコア 不変の価値

@k_h_sissp さんのトーク。
レガシーシステムを恐竜に例えてのお話でした。
何より恐竜愛が伝わってきて良かったです。

さらっと言っていた、「レガシーから進化したものの、本質的に良くなっているわけではなく、部分的に環境に適用しただけという場合もある」（言い回しはちょっと違ったかも）という部分は耳が痛いところでした。

最初はより良くしようとしていたリニューアルPJが、リニューアルそのものが目的化してしまい、「言語のバージョンアップはしたけど本質的なビジネスロジックは全く変わらず」といったこと、みなさんも経験あるのではないでしょうか。

レガシーシステム・レガシーソフトとむきあって

www.slideshare.net

@warumonogakari さんのトーク。
登壇して客席を見回してひとこと「私の存在そのものがレガシーですね」でつかみはバッチリでした。

クローンコード（コピペコード）の定量的な解析はとても説得力がありました。
実際に社内でリファクタリングの地位を勝ち取るためにやってきたことがわかりやすかったです。

また、個人的にはイベント終了後のtweetが印象的でした。

やはり世代を超えてコラボレーションしながら前に進んでいくことが大事だなと。

人のレガシーを笑うな

www.slideshare.net

@m_norii さんのトーク。 「タイトル出オチです」とのことですが、次の自分もタイトル出オチの予定だったので、「2連続で出オチだと会場シラケちゃうかな」と心配していましたが、全く出オチしていませんでした。
主にPHP系のレガシーの話で、誰もが一度は経験するようなあるあるレガシー連発で爆笑が起きていました。
個人的には個体識別番号あたりで一番笑いました。
そして最後には、レガシーへのエールと、それでもだめなら撤退せよ、というハートフルな締めでした。

@m_norii さんの会社に前職の知り合いが数人働いているので、今度ツッコミ入れようと思いました。

本当にあった爆速でコードをレガシー化させる怖い話

私のLTでした。
一般登壇がメインのイベントにしては珍しく時間が巻き気味だったので、当初の想定よりもややのんびり話させていただきました。
以下にて名言認定していただきました。ありがとうございます。

また、意外と他の方の発表では具体的なTIPSが少なかったからか、以下の内容も反応良かった感じしました。

和やかで会場の一体感もあり、安心して話すことができました。ありがとうございます。

レガシーインフラと向き合った三年

レガシーインフラと向き合った三年.pdf - Google ドライブ

@ni3shi9p さんのトーク。
ここまでソフトウェアのお話しが中心でしたが、インフラの話も聞けてより満足感高かったです。
物理サーバとかなにげにここまでで最も怖い話なのかもしれないと思いながら聞いていました。

そして、@ni3shi9p さんの最後のスライドがこのイベントのすべてを表していました。

根底は愛 思想は優しく、決断は厳しく

まとめ

自分の観測範囲だけですが、総じて参加者の満足度が高いイベントだったと思います。
冒頭にあった通り、レガシーというテーマ設定がとても良かったのと、ゆるすぎずきつすぎない場のセッティングが素晴らしかったです。
今年の反省を踏まえ、また来年話したいと思います。

どうもありがとうございました！

webviewにデフォルトで何かのページを表示する

objective-c

該当のwebviewを包含するViewControllerのviewDidLoadで該当のwebviewに対してloadRequestメソッドを呼び出せばOK

単純にURL文字列でできるインタフェースを作ってくれりゃいいのに…