これはただの日記

なにも考えていないようだ

2019年の振り返り

去年もやったので、今年もやろうと思う。2018年の振り返りはこちら。 kths.hatenablog.com

仕事

今までと違う脳みそを使った一年だった

以前の記事でもちらっと書いたけど、2019/9から開発チームの副部長をしている。といっても2019/10中旬から育休にはいっているので、実質まだ1ヶ月しか活動していないけど…2018/9からSREチームのEngineering Manager業をしているので、2019年は基本的にはそういった方面のお仕事をしていた。

最近よく意識しているのは、自分の仕事は開発チームが継続的に成果を出すためのアーキテクチャをつくることだということ。アーキテクチャには、どんなチームにしたいかという言語化だったり、その文化を下支えする技術的な仕組みの整備だったり、その文化をよりよくしてくれる仲間の採用だったり、様々なものが含まれる。単に人の採用や育成や評価だけに取り組むわけではない。

で、そういったお仕事に取り組んできて痛感したのは、どの施策がどのレイヤーの課題に効くか?という観点整理の難しさ。また、優先順位の並び替えも難しい。これは、取り組む対象は異なるが、PdMのお仕事が難しい理由と同様のものだと思う。多くの仕事において、成果は複雑。AとBをやっていれば成果が出ていると思い込んでいたけれど、実際は別の施策が効いていたりすることもある。または、思わぬ副作用が出ていたり、実は想定していない方面での成果につながっていたり。もちろん、紙に書き出して、観点整理をするだけならかんたんだけど、現実で起きている問題を色んな角度から眺めてみて、背景分析をするには、まだまだ自分の中では解像度を高める余地があることを実感している。向き合う問題の複雑さや難しさは、自分にとっては仕事のおもしろさにつながるので、楽しく仕事ができている。

複雑な問題と向き合うには、複雑な問題を複雑なまま扱うのではなく、特定の観点やレイヤごとのシンプルな問題の組み合わせとして扱うことが効果的だと思っている。ので、その切り取り方をもっとうまくできるように、自分の仕事や向き合う対象の解像度を高めることに引き続き向き合いたい。チームの課題は様々な場所にあり、ともすると発生した問題に対処していたら1年が終わっていた、なんてことになりかねない。何から変えると、組織の成果を出すための最短経路なのか、というのは常々よく考えながら仕事をしたい。目的達成のための資源配分を間違えると、本当に多くのものが無駄になってしまう。常に自分の見えている視野を広くしておくためにも、真面目に仕事しつつも寄り道を楽しむ。

コードを書く時間が減った

2018年までは、仕事でコードを書く時間がまだまだあったが、今年からは極端に減った。ただ、そのことによる不安感はそこまで大きくない。というのは、プライベートで新しい技術を試す時間を確保する過程で、技術を使ってやりたいことが多くあるから。僕自身は、技術を使って何かをつくるモチベーションを失うことを1番恐れている。 また、今のチームなら、再びコードを書くことをメインの仕事にすることも、きっとうまくできるだろう、という安心感があることも大きい。これは今いっしょに働くメンバーに恵まれているので、そう思えるのだろう。で、その安心感がなぜ生まれているのかというと、採用活動において、○○がワカランやつは採用しねえってことをやっていなくて、技術との向き合い方だったり、その人の好奇心がどこにあるのかを見ているからだと思う。これはもちろん技術面を軽視するということではなく、技術的な素養は選考時にも見ることを大切にしている。

ただ、今後特定の技術領域の問題解決が、組織の成果を最大化するための重要度が大きく上がれば、Job Descriptionのつくり方も方向転換する可能性はある。そうなれば、僕も社内転職をする際にはその技術レベルを満たせるように必死に努力する。「THE ENGINEER/MANAGER PENDULUM」の考え方を参考に、すべての職種で、スペシャリスト⇔マネジメントのお仕事を行ったり来たりできるようになるとよいなーと思っている。先日書いた記事で、「ジョブ・クラフティング」が大切だと書いたけど、これはスペシャリスト⇔マネジメントを行ったり来たりできることにおいても同様に大切だと思う。(ただし、前述したように、社内転職をする際にも、社外に公開しているJob Descriptionに書かれた内容を満たすことは前提。)また、単に会社の中でスペシャリスト⇔マネジメントの職種を変えることだけでなく、自分の人生の時間の使い方のバランスを変えることも含まれると思う。

charity.wtf

発表してきたもの

SRE Lounge主催者が見てきた各社のSRE的取り組み / SRE in Japan

speakerdeck.com

名古屋での登壇で印象に残っている。名古屋のSREの皆さんも、東京にいる人たちと同じく、SREの考え方を自分の関わる環境に適応するために尽力されていて、素晴らしいなと感じた。お誘いいただいた @gkuga さん、本当にありがとうございました。

AWS サーバーレスアーキテクチャでつくる Slack ChatOps / Use Slack ChatOps to Deploy Your Code

speakerdeck.com

久しぶりにサポーターズさんの勉強会で登壇させていただいた。ChatOpsの話をしたが、本当に言いたかったことは、ChatOpsでできることを増やそうぜ、ということではない。むしろ、どこまでを、何を、ChatOpsで実現するかの線引をするのはSREの腕の見せどころだと思っている。コードを書いて問題解決するのは最後の手段であるべきで、できるだけコードを書かずにやりたいことを実現できるような仕組みづくりにより時間を使うべきだと思っている。そうすることで、本来メンテしたいコードに、まとまった時間を使うことができ、結果としてそのコードに向き合う人たちの幸福度も向上すると信じている。稼働しているのに、メンテされないコードが増えるほどつらいお気持ちになるのは誰もがそうだと思う。

www.intercom.com

medium.com

NoOpsを実現するSREの存在意義と役割 / class SRE implements NoOps

speakerdeck.com

NoOps Meetupさんに登壇させていただいた。細かい話はこちらに書いたので詳細は割愛。

kths.hatenablog.com

プロダクト開発における暗黙知との向き合い方 / Strategies For Tacit Knowledge Transfer At Software Development

speakerdeck.com

ガイアックスさんの勉強会で登壇させていただいた。細かい話はこちらに書いたので、こちらも詳細は割愛。

kths.hatenablog.com

スタディスト開発部が面接で大切にしている 3つのこと / 3 values in interviews at Studist

speakerdeck.com

転職透明化らぼに登壇させていただいた。開発部の副部長に就任した直後の登壇で、自分自身が採用活動に向き合う、改めての決意表明も込めて話してきた。採用は、組織において最も大切な人事活動なので、今後も1つずつ誠実に向き合うしかないと思っている。

チームで取り組む障害対応 / Incident response as a team

speakerdeck.com

福岡のSRE Meetupで登壇させていただいた。障害対応について話してきた。お誘いいただいた@transnanoさん、@matsumanaさん、ありがとうございました。

私事

SRE NEXTの準備を進めていた

sre-next.dev

2020/1/25に開催する日本初のSREのカンファレンス「SRE NEXT」の準備を進めていた。おかげさまでチケットは完売いたしました。スポンサーの皆様、登壇者の皆様、参加者の皆様、そしていっしょに準備を進めてくれているスタッフの皆さんに、本当に感謝しています。準備期間は残りわずかですが、SRE同士が知見を交換する最高の場にしたいので、引き続きよろしくお願いいたします。

見たもの

今年はNetflixをとうとう契約した。オリジナル作品が良いのはもちろん、シリーズ作品を見る時の映像の切り替えの体験だったり、最高です。もっとはやく契約しておけばよかったなーと思った。

クィア・アイ in Japan!

www.netflix.com

あなたはあなたのままで良いんだというメッセージの尊さに気づかせてくれた作品。人が変わる(というよりも、その人らしさを取り戻すという意味では元に戻るといった方が正しいかもしれないけど)瞬間に立ち会う素晴らしい体験だった。

天才の頭の中: ビル・ゲイツを解読する

www.netflix.com

世界一の大富豪と聞くと、多くの人は優雅にリタイア生活を送っているように思えるかもしれないけど、ビル・ゲイツは今でもバリバリ仕事をしている。…映像を見る前から、ある程度そうだと分かっていたけど、改めて、彼が今どんな問題に向き合っているか、何を考えているかを知って、自分も規模や方向性は違えど、生涯こうありたいと心から思った。

グリーンブック

gaga.ne.jp

個人的には今年ナンバーワン。いっしょに過ごす人間と、あるがままとして付き合っていくことで、最高の友になれることを伝えている作品だと思う。

バイス

longride.jp

利己的な人格が壊れた人間は遅かれ早かれ人生をめちゃくちゃにする。本作品はその最悪のケースとして、世界の政治情勢までも塗り替えてしまう結末まで描かれている。作品としては、組織としてやってはいけないこととは何か?を客観的に見れるのも良い。その観点では、ドラマ「チェルノブイリ」も同様の学びが得られた。こちらもまだすべて見れていないが、非常にオススメ。

その他

  • 年明けから10月にかけて、10kg痩せた
  • 5年住んだ広尾から護国寺に引っ越した
  • めっちゃ過ごしやすい
  • 子どもが生まれた
  • 妻の里帰り出産の付き添いで、福岡で10月から3ヶ月間生活した
  • 育休とってよかった
  • 福岡は飯がうますぎて本当に危険な街
  • その結果、5kg太った
  • ワインにはまりだした、今は大まかな味の分類を覚えようとがんばってる
  • たぶん太ったのはワインの影響もある
  • そういえば、Pythonの本を書いている
  • 本書くのたいへん
  • BRING ME THE HORIZONのライブ、まじで最高だった
  • 来年もよろしくおねがいします!

Engineering Manager になってから身に沁みた12のアイデアと言葉

本記事は、 Engineering Manager Advent Calendar 2019 の21日目の投稿です。

あなたはだれ

スタディストという会社で、2018/9から SRE チームの Engineering Manager を担当しています。2019/9より開発組織全体の副部長を兼任し、活動をしています。

この記事を書く背景と目的

そこそこ昔から、チームや組織に関する書籍が好きで読み漁っていたのですが、 Engineering Manager になってから改めてそれらの書籍を読み返すと、これまでとは違った感じ方をできるようになりました。また、買った本の読み方も大きく変わったような感覚を持っています。そんな気持ちを皆さんとも共有したいと思い、私が最近よく読み返す書籍の中から、身に沁みた言葉・考え方をいくつか紹介したいと思います。何か1つでも参考になるアイデアがあれば幸いです。

Engineering Manager に限った話ではなく、いわゆる組織の Manager にとって大切な言葉や発想が中心になっていますが、ご容赦いただければと思います。

ジョブ・クラフティング

皆さんも肌感覚としてはあると思うのですが、人は自分の仕事に対し価値を実感している時の方が人生の幸福度は高いものです。「ジョブ・クラフティング」のアプローチは、この心理的な習慣をキャリアに応用したもので、端的に言うと、「自分が価値や意味を感じやすいような仕事を自分でデザインしよう」ということです。この考えに、私自身もたいへん影響を受けており、自社のチームポリシーに、自身の役割に囚われず、やりたい仕事には手を上げて欲しいことを明文化しています。そして、そのことを実践している仲間がすでに複数名おり、彼らはモチベーション高く働いていて、ジョブ・クラフティングの考え方に価値があることを実感しています。

参考書籍:『Learn Better』

継続的な帰属シグナル

帰属シグナルとは、自分のことを気にかけてくれている人がいるというメッセージのことです。そして、帰属シグナルがあることによって、人間の態度は一変します。(もちろん、良い意味で。)ただし、ここに1つ大きなポイントがあり、帰属シグナルは継続的に送らなければならないということ。人間は、「危険」のシグナルを常に探しているため、継続的に帰属シグナルを送ることで、はじめて良い関係性を維持することができます。

参考書籍:『THE CULTURE CODE』

THE CULTURE CODE 最強チームをつくる方法

THE CULTURE CODE 最強チームをつくる方法

レッテルではなく、いま目の前にいるその人とコミュニケーションしなさい

私たちは、何に対してもレッテルを貼ります。一度、頭で「この人は◯◯な人」と思い込んでしまえば、例え目の前にいて対話をしていたとしても、その先入観で相手のことを見てしまいます。結果、相手との接し方も、レッテルに縛られたものになります。レッテルが、その人ではないにもかかわらず。 「いま、ここ」に意識を向けることで、相手のことを真に理解しようとしなければ、と改めて考え直した一文でした。

参考書籍:『こころの対話 25のルール』

こころの対話 25のルール (講談社+α文庫)

こころの対話 25のルール (講談社+α文庫)

相互探求

最も生産的な学習は、主張と探求がバランスしている時に起こります。全員が自分の考えを明らかにし、意見し合うことで、学習をより一段階深めることができます。つまり、相互探求を意識的にデザインすることが、チームの学習を促進する上で大切なことなのです。では、このことを Engineering Manager の普段のお仕事にどう活かすかというと、チームで意思決定をする際に、お互いの意見をテーブルの上に出し切ってもらうようなファシリテートを意識する…といった具合です。

主張一辺倒の場合、議論に勝つことが目標になる。探求と主張が融合されている場合、「議論に勝つこと」はもはや目標ではなくなり、「最善の議論を見出すこと」が目標になる。

参考書籍:『学習する組織』

バイパス管理

皆さん、ホーソン実験はご存知でしょうか。結論部分だけをお伝えすると、組織におけるインフォーマルグループ(非公式な集団)の有無が組織の生産性に大きく関わるというものです。この時、インフォーマルグループの有無は、物理的条件や金銭などの外部誘因よりも生産性に寄与することが分かっています。つまり、組織の成果をマネジメントするにあたって、インフォーマルグループを活用しない手はないのです。このことを、本線ではない、という意味で、バイパス管理と呼びます。以下の参考書籍では、「良いバイパス管理とは何か?」といったテーマにも触れられているので、気になった方はぜひご一読を。

参考書籍:『無理・無意味から職場を救うマネジメントの基礎理論』

無理・無意味から職場を救うマネジメントの基礎理論

無理・無意味から職場を救うマネジメントの基礎理論

  • 作者:海老原 嗣生
  • 出版社/メーカー: プレジデント社
  • 発売日: 2015/04/06
  • メディア: Kindle

感情報酬

感情報酬は、言葉の通り、ワクワクやドキドキのような感情の報酬のこと。近年、機能的な価値から感情的な価値に重きを置かれるようになってきていて、チームで働くことにおいても同じことが言えます。つまり、自分たちと一緒に働くことに対し、ワクワクやドキドキを提供できないと、採用における競争力がなくなってしまうということ。感情価値や感情報酬という言葉は、昔の自分なら綺麗事と一蹴していたかもしれないなーと思いつつ、 Manager になった今なら分かります。目に見えないもの、大切ですよね。

参考書籍:『ハートドリブン』

人間は限定合理的な生き物である

限定合理は、感情が行動に影響を与えることです。そして、すべての人間は限定合理的な生き物です。先ほどの感情報酬に書いた内容とも共通しますが、いっしょに働く仲間の感情はとても大切なのです。そういったものを無視し、戦略を突き詰めようとする姿勢は、いかにも一流のビジネスマンのように見えますが、結果は逆です。組織の成果が、戦略×行動だとすれば、戦略にしかアプローチできていないことになるため、効果は半減です。組織と事業が両輪の関係にあるとはそういうことです。

参考書籍:『すべての組織は変えられる 好調な企業はなぜ「ヒト」に投資するのか』

4Dx(実行の4つの規律)

4Dxは、『戦略を、実行できる組織、実行できない組織。』という書籍で掲げられている戦略を実行するための4つの規律のことです。本書の考え方は、何度も参考にさせてもらっています。具体的には、私が Engineering Manager を務めるSREチームでは、4Dxの考えをもとに仕事のリズムを組み立てています。

  • 第1の規律:最重要目標にフォーカスする
  • 第2の規律:先行指標に基づいて行動する
  • 第3の規律:行動を促すスコアボードをつける
  • 第4の規律:アカウンタビリティのリズムを生み出す

参考書籍:『戦略を、実行できる組織、実行できない組織。』

戦略を、実行できる組織、実行できない組織。

戦略を、実行できる組織、実行できない組織。

課題葛藤と関係葛藤

仕事においては、私たちが想定しているよりも、遥かに信頼関係が重要です。課題葛藤は決定に関する意見の不一致のことで、関係葛藤は感情の行き違いのことです。課題葛藤は健全なもので、組織の意思決定をより良くするために必要ですが、課題葛藤が高まると関係葛藤も高まる傾向にあるそうです。結果、チームの士気の低下につながります。 …では、どうすれば関係葛藤の高まりをおさえられるのかというと、まずは信頼関係を築き、関係葛藤をコントロールすることからはじめよ、というのが結論です。そうすることで、心置きなく課題葛藤に向き合うことができるのです。ビジネスにおいては、何よりもまず信頼関係が大切ですが、そのことを分かりやすく示した言葉ですね。

参考書籍:『一兆ドルコーチ』

ヤンキース戦略か、ベアーズ戦略か

『ワーク・ルールズ!』で紹介されている一節です。ヤンキース戦略は、最高の人材を雇ったチームの例え。一方、ベアーズ戦略は、平均的な人材をじっくりと育てようとすることの例え。どちらのチームのパフォーマンスが優れているか?の答えは、ヤンキース戦略だと書籍では結論づけています。この話題は、「採用は最重要の人事戦略である」ことを示す最適な例だと思います。この事実とあわせて「最高の人材は、知性や専門技術といった唯一の属性によって定義されるものではない」という言葉も肝に銘じておくべきでしょう。

参考書籍:『ワーク・ルールズ!』

生産的なよそ見

組織は生産的なよそ見を推奨することで、今後の新たな機会を先に試すことができます。特に、同僚の仕事を見る機会をつくることは、生産的なよそ見として良いプラクティスです。お互いにフィードバックを送り合うことで、同僚から学べるようにし、ときにはチームの垣根を越えた取り組みを生むきっかけにもなるからです。

参考書籍:『EXTREME TEAMS』

チームが良くなれば事業やプロダクトが良くなるという思い込み

最後に、最も大切な点について触れておくべきでしょう。それは、私たち Engineering Manager の役割は、チームを良い状態に保つことだったのか?ということです。いいえ、違います。あくまでも、私たちが目指すべきは、自分たちのチームに求められる責務を果たすことであり、それは事業やプロダクトを良くし、お客様に貢献することなはずです。ですので、その目的達成のために、チームを良い状態に保つことは、必要条件なのか、願望なのかは切り分けて考えるべきです。いくら良いチームでも、事業やプロダクトに大きな価値を生み出せていない状態では、チームそのものの存在理由を失ってしまっているのではないでしょうか。Engineering Manager の仕事の話題は、ピープルマネジメントに焦点があたりがちですが、自分たちの責務をまずは果たせるようなチーム運営を念頭において仕事をしていきたいものです。自戒を込めて。

参考書籍:『エラスティックリーダーシップ』

エラスティックリーダーシップ ―自己組織化チームの育て方

エラスティックリーダーシップ ―自己組織化チームの育て方

体験の良いSelf-Serviceを提供するために必要な3つの心構え

本記事は、SRE Advent Calendar 201920日目の投稿です。@katsuhisa__ がお送りします。

今年の6月に登壇した際に、Self-Serviceで物事を進めることの大切さと、SREがSelf-Serviceを構築することに責務の一端を持つことについてお話しました。

speakerdeck.com

「class SRE implements DevOps」という言葉もありますが、私はSREがDevOpsを実装するにあたって大切なことの1つは、開発者によるSelf-Serviceを構築することだと考えています。

www.youtube.com

Envoy開発者のMattが「DevOpsとは、開発者が24/365でサービスの運用に対する責任を負う慣行である」としたことは有名です。私もその言葉に影響を受け、SREが開発者による運用を支えるツールやPlatformを開発することは、SREにおける責務の1つであると考えています。(もちろん、自分たちが掌握する範囲におけるOps業務を効率化・自動化するための実装も大切です。)

The human scalability of “DevOps” - Matt Klein - Medium

本記事では、これまでの経験をふまえつつ、体験の良いSelf-Serviceを構築するために必要な3つの心構えについて意見を述べたいと思います。「うちではこうやってるよー」「こうすると良いですよー」といった意見があればTwitterでご意見いただけると嬉しいです。エゴサします。

1. 学習コストが低くなるよう工夫する

私が働く会社では、開発者自身がTerraformでInfra構築できる環境が整っています。具体的には、Pull Requestをつくれば、CIで、 terraform plan の実行結果が分かるようになっているため、「開発者によるPull Request」と「CODEOWNERSであるSREによるレビュー&マージ」の2ステップを踏めば、誰でもInfra構築ができるようになっています。

皆さんの働く企業の中で、開発者自身がTerraformのコードを書いてPull Requestを送ってくれる会社はどれくらいあるでしょうか。または、その割合はどのくらいでしょうか。…私たちの会社では、数人の有志がTerraformを書いてPull Requestを送ってくれることはあれど、開発者全体にその文化が広まっているとは今の所言えません。

では、なぜ開発者自身でInfra構築できるにも関わらず、従来通り、環境構築を依頼するのでしょうか。その理由の1つに、学習コストの問題が挙げられると思います。当初、SREの私たちは、「開発者自身でTerraformによるInfra構築できる環境を整えた!これでSelf-Serviceを推進できる!」と思い込んでいました。というのも、Infra環境の大半は、SREがTerraform化をすでに行ったため、開発者は既存のTerraformを参考にコピペするだけで思い通りのInfra環境を手にすることができると感じていたためです。

しかし、実際はそうではありませんでした。もちろん、その理由はTerraformのせいではありません。実際は、私たちの環境におけるTerraformの学習コストの大半は、既存のInfra構成に関する学習コストでした。既存のTerraformもコードをコピペすればできる!と思っているのは私たちSREだけで、大半の開発者は、既存のInfra構成に関する理解度がそこまで高くないため、どこまでをコピペで流用して良いかが分からない状態でした。

もちろん、私たちSREも開発者に対してSystem Architectureを伝えるトレーニングを行ってはいるのですが、限られた場では、業務で自分たちに必要なTerraformをスムーズに書けるほどの理解度には達しませんでした。これらの経験から、学習コストが高いものはワークしづらいことを実感しています。ということで、学習コストを下げられるようなチームでの取り組みが大切だと感じています。

2. Self-Serviceをどのように使うべきかの思想をチームで対話する

私たちのチームでは、開発者がボタンをクリックするだけで、ProductionへのDeployやロールバックを簡単に行うことができるように実装しています。このDeploy Pipelineを使うことで、開発者はSREの手を借りずともProduction Deployを完了させることができます。さて、この自動化されたDeploy Pipelineをつくるにあたって、SREは1つ大きな願いを込めていました。それは、手作業時代には、(SREのリソース都合で)頻度を増やせなかったDeploy回数を、大幅に増やしたいというものでした。先日、社の開発ブログにも書きましたが、私たちは、チームで対話を行うことにより、この変化を実現することができました。

つまり、「リリース頻度を高めつつ、障害発生頻度の極小化」を目指すことが私たちにとって求められる姿勢です。スタディスト開発チームでは、過去に、リリース頻度に関して問題意識のあるメンバーの発案をきっかけとし「リリースサイクルと開発スタイル」に関する意識統一の話し合いが行われました。現在も「リリース頻度を高めつつ、障害発生頻度の極小化」を目指す道半ばではありますが、少なくとも今のスタディスト開発チームには「障害を起こさないためにリリース頻度を減らしさえすればよい」と考えるメンバーはいません。こういった文化の1つ1つがユーザー価値の最大化につながると考えています。

medium.com

単にSelf-Serviceをつくる以上に、「class SRE implements DevOps」は奥が深いものだと思っています。

3. サービス開発者とSREの間に壁がないこと

2の内容とも通じるのですが、サービス開発者とSREの間には、壁がなく日頃から継続的に対話できる環境が整っているべきだと考えます。また、その結果として、Self-Serviceが普及したり、次のSelf-Service化する対象を考えるアイデアを得たりするのがよいのではないでしょうか。

私が働く会社では、チームで働く仲間が、サービス開発者とSREの間の壁をつくらないような活動に熱心に取り組んでいます。

某社のSREは役割が多岐に渡るため、組織が急激に成長するといつか破綻してしまうというリスクがありました. そういったリスクに対して事前に対策を打つための1手段として、SREが持っている知識や経験則を共有、SREと一緒に悩む場として「SRE Office Hours」という活動を毎週金曜日に枠を設けて実施しています. この活動はマイクロサービスについて何でも聞けるOffice Hoursに参加したよ! #メルカリな日々に影響を受けて企画し、今も開催し続けています. ※2 技術書の輪読もそういった活動の一環で、「仕組みはどうなっているのか」「弊社ではどうなのか」「これを改善していけるのではないか」といった疑問を持つきっかけだったり、議論をする場として活動しています. 社内勉強会のLT枠でも、SREが持っている知識を共有する場の1つとして利用させてもらっています.

www.khasegawa.net

キャッキャウフフ会とは 名前だけ聞くとただただ楽しそうなだけの会ですが、実態は至ってまじめ。 WebチームとSREチームがチームの垣根を越え、互いの知見を活かしてチーム横断的な課題をモブワークで解決する会 です。

okadato623.hatenablog.com

Self-Serviceとカッコよく言っていますが、突き詰めると、Self-Serviceを構築する人と、使う人(プラクティショナー)がいるだけです。その間に溝があれば、お互いに「あいつらがつくった自動化イケてねーわー」のようにギクシャクするのではないかと思います。繰り返しになりますが、「class SRE implements DevOps」の言葉の裏には、そういったわざわざ明文化されていないけれど、チームで働く大切な前提条件がいくつも含まれているのだと私は信じています。

皆さんも良いSelf-Serviceライフを!

プロダクト開発における暗黙知との向き合い方

先日、「プロダクト開発における暗黙知との向き合い方」というテーマで Gaiax Technical Meetups でお話をしてきました。

f:id:kths:20190630135840j:plain

先月の NoOps Meetup での登壇 然り、僕は話し始めに下を向く癖があるようです・・・なおさねば・・・

話したこと

speakerdeck.com

暗黙知とどう向き合うか?について普段意識していることを話しました。とはいうものの昔の自分は実践できていなかった内容なので、世の中に需要があるかもしれない、と思いこのテーマを選びました。結果、懇親会や、資料を見た方から共感の感想をいただいたりと、各所でご参考いただけてよかったな、と思っています。

当日の様子

https://twitter.com/saiid_kk/status/1143471752976068608

みなさんありがとうございました。特に、Gaiax の皆さん、いつもあたたかく迎えてくださり、本当に感謝しています。

参考文献の詳細な紹介

今回、登壇するにあたって久しぶりに色んな文献を読み返しました。自分が無意識でやっていることが、いろんな情報をもとにつくられていることがよく分かったり、また、自分としても再度文献を読み直すことで発見が多々ありました。

伝統という言葉を出すといろいろ誤解を生みそうだけど、不自然な目的合理(べき論と表現すると多くの人にとってはしっくりくるかな?)を重んじることの危うさについて触れた書籍。今回の登壇にあたり、なぜこの本を再度読み返したかというと、技術知と実践知について触れられていたことを急遽思い出したから。部分的に読み返し、自分の中での技術知と実践知の差分を深化させたれたような気がします。 実はこの本を読み返したのは大学以来で、登壇が良いきっかけになって本当に良かった。この本は、最近読んだ『測りすぎ――なぜパフォーマンス評価は失敗するのか?』でも引用されていました。

エンジニア界隈で言わずと知れた広木さんの書籍。ビジネス書と技術書のいずれでも二冠をとった初の書籍だそうで。マネージャーになってから何回も読み返していて、今回も参考にさせていただきました。

伊藤直也さんの過去の登壇資料。プロダクト開発における暗黙知を単に放置するだけの危うさについて触れた発表資料で、今回の私の発表の前半部分でも引用をさせていただきました。

いつになったら日本語版が出るんだろう。人の学習をデザインするために大事なことが様々な観点からまとまっていて本当に良い書籍。本書は、今回の資料内では直接引用していませんが、自分がチームでの場を考える時にたまに読み返しています。そして、スタディストSREでのチームの場づくりについても今回紹介したので、本書へのリスペクトを込めて参考文献として記載をしました。

これもいつになったら日本語版が出るんだろう。本書のメッセージの一つである「knowing what gets done is not the same as knowing how it gets done」は、自分が今回の発表で伝えたかった内容と同じです。チームとして不確実性をマネージするために非常に参考になる一冊。

言わずと知れた野中先生の論文。SECIモデルについてはご存知の方が多いですが、もととなる論文に目を通したことがない方も多いのかな?と思い、今回改めて読み、引用をさせていただきました。SECIモデルの紹介だけでなく、良いことたくさん書いてあるんですよねえ・・・

http://theelearningcoach.com/ というサイトがあるのですが、その中の一記事。暗黙知の移転をどのような方法で行うことができるか?という戦略について述べられており、今回の発表テーマとドンピシャの内容です。

優れたリーダーは、暗黙知をうまくマネージしてるんだぜ?ということを調査した論文。リーダーシップってふわふわした概念に思われがちですが、こういった側面から理解を深めていくと、リーダーシップも科学できる範囲はたくさんあるよなあ、と。

データ、情報、知識、知恵の階層構造や、それぞれとどういう向き合い方をすべきか?を述べた書籍。情報のエキスパートとして30年国連で活躍した著者が書いただけあって、すごく骨太な内容です。自分としては、今回の発表の中で使っている「暗黙 "知" 」という言葉の定義から本当は話し始めたかったのですが、さすがに聴衆が聞きたい内容とミスマッチだよな、と思い、発表中では本書のことには触れませんでした。 これを読んだことがある方、ぜひ続きを居酒屋で。ご連絡お待ちしています。

なぜこのテーマにそんなに思い入れがあるのか

というわけで、暗黙知についての発表をしてきたのですが、なぜこのテーマにそんなに思い入れがあったのか?を最後に少しだけ。 僕は、数年前から、人間の思考の成り立ちや再現性に興味があります。世の中には天才と言われる人たちがいたり、自分も話していて「この人は天才だなー」と思う人が数名いるのですが、生まれつきそうだったという人は実はそんなに多くないのではと思っています。(もちろん中には生まれつきの天才もいるかもしれませんが、実はその人が裏でとんでもない努力をしていた場合、すぐに天才だと決めつけるのはちょっと失礼かなという気もしなくもありません。)では、何がその人を天才たらしめるかというと、色んな知識や経験についての興味を深掘りする力だったり、整理する力だったりするのではないかなーと思っています。 そこで、情報(前述したデータ、情報、知識、知恵の階層構造然り)の特性に理解を深め、天才を生むための再現性のより高い仕組みについての興味関心が湧いてきたわけです。また、それを個人に対してだけでなく、チームに適用させるにはどう応用すればよいか?にも同じく興味があります。

・・・ということへの深掘りの蓄積の一部が今回の発表だったりします。という感じでした。 このテーマについては、自分の人生のどこかで、もっと深めていきたいと思っています。またどこかでこういうことをお話できたらいいなー。

NoOps Meetup #6 に登壇してきた #NoOpsJP

先日、6/4 に NoOps Meetup #6 に登壇をしてきました。

noops.connpass.com

お越しいただいた皆さま、ありがとうございました。また、素晴らしい会場、飲食提供、そして NoOps のパーカーをいただき、スポンサー企業の皆さま本当にありがとうございました。そして運営メンバーの皆さまもあたたかく迎えていただきありがとうございました。

f:id:kths:20190607000445j:plain

話したこと

speakerdeck.com

今回登壇するにあたり NoOps の歴史的な背景についてあらためて整理しました。 NoOps という単語を見ると、どうしても No Operations を連想し、現在 Ops 寄りなお仕事をされている方は拒否反応が出てしまうかもしれません。ですが、実際はソフトウェアで自動化を推進することにより、一部の運用業務を Self-Service で開発者が実施できることを指しているのだと私は理解しています。(または、そもそもその運用業務をソフトウェアで実行したり、そもそも運用業務が発生しないようにシステムの回復性を実装したり。)

また、依頼作業ドリブンで仕事をするのではなく、 Self-Service で仕事を進めることによって、組織の経済的な無駄が取り除かれることについて、書籍『The Principles of Product Development Flow』の内容をもとにお伝えしました。

f:id:kths:20190607001503j:plain

本発表の主旨は、NoOps と SRE の交わる文脈として Eliminating Toil について、『The Site Reliability Workbook』の内容をもとにご紹介しました。発表の締めくくりとして、「嬉しくない運用業務を取り除くために、どのように SRE として推進していけばよいか?がSRE本には丁寧に書かれているので本当にオススメの本です」とお伝えしました。

いただいた感想など

いくつか私の発表中に Twitter で言及いただいた感想をピックアップしてみます。

NoOps という用語だけを見ると、運用に関わる人を減らす運動に見えてしまうかもしれないのですが、そうではないよねー、という話をしてきました。

僕も同意見です。この「同人誌」という解釈が本当に正しいよな、という気がしています。サービスの運用について考える時に、関連する業務をMECEに整理できるかと聞かれると必ずしもそういうわけではないです。だからこそSRE本は、いろんな人の小論集として構成されているのだと理解しています。

スタディストでは、 Design Document を書くことを重視しているよーという事例を共有しました。で、その背景として「障害を生まないように設計した人にちゃんと焦点を当てたいから」という価値観を持っています。ただ、誤解して欲しくないので敢えて書きますが、決して設計だけできる人がエラいという価値観は持っていないです。設計をし、設計に沿って美しい実装をし、両者は両輪の関係だと思っているからです。

すごく嬉しいお褒めの言葉をいただきました。スタディストという社名に恥じぬよう、今後もいろんなことを貪欲に学び、良いチーム、良いサービスを All Studist でつくっていきたいと改めて思いました。

印刷して家にかざろうかと。ありがとうございます。 世の中には魔法のようなものはほとんどなく、一歩ずつやるしかないとチームのミーティングでもたまに話しています。とは言え、それは自分たちの進むスピードをゆるめる言い訳にするつもりはなく、ムーンショットを打ち続けられるチームでありたいな、と思っています。

Stackdriver Error Reporting だいすきです!!!いつもお世話になっております!!!

というわけで、最後はこんな感じでお話を締めくくりました。

今回は、他にもいろんな方にお褒めの言葉をいただき、たいへん嬉しかったのですが、特にこのコメントは個人的にすごく嬉しかったです。 というのも、実はこのスライドの発表をした当時からそろそろ 1年がたちます。

speakerdeck.com

今回の発表では、この当時からさらに進化した状態をスナップショットとして残したいと思い、資料作成段階から意識をしていました。なので、実際にこちらのスライドをご存知の方がこのように言及くださるのは、自分としては本当にありがたいお気持ちでいっぱいです。ありがとうございました。

聞いてきたこと

今回は、私以外に、Google 山口さんとサイボウズ山本さんの発表がありました。Twitter などでお二人のご活躍をいつも拝見していたので、素晴らしい方といっしょに登壇させていただき、本当に嬉しかったです。

Google 山口さんの発表

docs.google.com

SLI/SLO やオブザーバビリティのお話からはじまり、Stackdriver の機能がそういった概念をどうサービスとして表現しているか?を発表くださいました。 Stackdriver ユーザーとしては、めちゃくちゃおもしろい発表でした。特に、Stackdriver IRM (Alpha)は聞いていて、すごくわくわくしました。

サイボウズ 山本さんの発表

speakerdeck.com

サイボウズさんが、データセンターのインフラ刷新プロジェクト(Neco)を進める中で、データセンターをいかに NoOps になるように構築しているか?というお話でした。しかもつくったものをほとんどすべて OSS として公開をしていると。かっこよすぎる。個人的には、 Neco の設計原則が特に刺さりました。

おわりに

当日は、他にもパネルQAなども行いました。会場の皆さんからの質問が具体的で、回答する側としてもたいへん勉強になりました。もちろん、Google 山口さん、サイボウズ山本さんの回答も非常に参考になって、おもしろかったです。

というわけで、終始たのしかった!関係者のみなさまおつかれさまでした&ありがとうございました!

2019/1 - 2019/3 OKR 振り返りと次の四半期に向けて

今年の 1/4 に OKR を設定した。

kths.hatenablog.com

当初は、今年一年かけて 設定した OKR に取り組もうと思っていた。 が、運用しながら OKR の運用期間は四半期くらいがちょうど良いだろう、という考えに変わったので、今四半期(2019/1 - 2019/3)のOKR振り返りと、次の四半期(2019/4 - 2019/6)に向けての OKR 設定をする。 ちなみに「 OKR 運用期間が四半期が良いだろう」というのは、プライベートの OKR 運用だけでなく本業の OKR 運用でも同様の感想を持った。まあ、当たり前ではあるが、内容によるとは思う。

今四半期の OKR 振り返り

総括すると、 60% 達成くらいに落ち着いたのではないかと思う。

悪い生活習慣と決別し、健康人間になる
  • [未達] 02:00までに就寝し、08:00までに起床する日が80%以上

そもそも睡眠時間の計測の継続に失敗した。AutoSleepというアプリを使用して計測していたが、AppleWatchをつけずに寝るとすぐに計測がこわれてしまった。結果、面倒になり入力をサボる→睡眠時間を翌日には忘れる、という状態だった。また、そもそも睡眠時間が不規則なことに対する課題感が自分に薄かったことに気づいたので、目標達成意欲が継続しなかった。

  • [達成] 一週間のうち6日以上10,000歩達成している週が80%以上

「正直ぜったい無理だろうなー」と自分で思っていたが、達成した。心がけていたことは、主に2つで、気軽にタクシーに乗るのをやめたことと、帰宅時に歩く時間を意識して増やしたこと。

  • [達成] 2019/12/31までに体重が12kg以上落ちている

1年で12kg減なので、 3ヶ月で3kg減に読み替える。なんと3ヶ月で 6kg も減量に成功した。10,000歩達成の継続に加え、食事の記録を継続しただけ。また、朝食を食べない生活に別れを告げてから、一気に減量が加速した。ちなみに特別な食事制限は一切行っていないし、ランニングなどの運動も一切していない。(それはそれでダメだが。)おれ12kg減量に成功したらダイエットブロガーになるんだ・・・

カンバン仕事術を実践し体得する
  • [未達] 週次でスプリントプランニングを実施し、毎週の進捗達成率80%以上を保つ

毎週の進捗達成率80%以上を保てたのは、約20%の週だけだった。だいたいの週は、進捗達成率 60% 前後を推移した。突発的なイベントによる作業時間のブレが大きく、週次ごとの進捗を安定させることが難しかった。ストイックな人であれば、「今週、飲みに行かん?」をすべて断ったり、不足分は徹夜して補うのだと思う。が、自分は面白そうなことにはわりとなんでも「OK、行く」と即答してしまうし、睡眠時間を極度に削ると本業にすぐ支障がでるので睡眠時間をゼロにすることもできなかった。

また、突発的なイベントに参加したことで得たものも多かったので、人生において何を重視するかの価値観定義が先にないとダメなんだろうな、という反省があった。もしくは、単に進捗達成率を上げたければ、作業時間のバッファーを見込めばよかっただけの話だったかもしれない。

  • [達成] 人生バックログ(?)の作成と運用を1月末までに開始する。また、自分自身のベロシティとキャパシティを2月末までに計測および運用開始できている。

達成はしたが、そもそもこの KeyResult が不要だった。理由は後述。ベロシティ(総達成ポイント数/キャパシティ)は安定していたので、見積もり自体はそれなりにうまくいっていたのだと思う。

ヒューマンスキルや、マネジメントとは何かをハラオチさせる
  • [達成] 「考える週」を年に2回開催し、ヒューマンスキルや、マネジメントのことをInputし、ドキュメントとしてOutputする

考える週については、今四半期には入れ込めていないが、読書を含め自分と対話する時間を定期的に取ることができたので達成としておく。ヒューマンスキルや、マネジメントのことをInputし、ドキュメントとしてOutputすることは続けたが、主に個人メモとして残したため世の中に公開できていないのが残念。(自分の身の回りのことと具体的に照らし合わせた読書メモを取っていたため公開しづらい内容だった。)公開してはいけない情報を削り、公開すればよかったな、と思う。

  • [達成] 1on1 で感じたこと・学んだことを一ヶ月に一度振り返る

学んだことを振り返るサイクルは、達成した。が、それによって得たものを計測するようなKeyResultになっていなかったため、達成したもののなんだかなあ・・・という感想。ちなみに1on1の振り返りは、得たものが多かったので、それはそれで良かった。

OKR 運用の振り返り

  • KeyResultのつくり方が下手だった。◯◯するは、達成のための行動指標であり、必ずしも結果指標ではない。
  • また、結果にむかうための行動は週次のPlanningで規定すればよく、予め規定する必要性はない。
  • もちろん場合によっては行動指標を守り切ること自体が結果指標として採用に値するケースもある。(今回の自分のOKRでいえば、「1週間のうち6日以上10,000歩達成している週が80%以上」というKeyResult設定は正しかったと感じる。)
  • とはいえ、私生活で自分の能力を改善していくことは、基本的に習慣ゲーだと思っているので、行動指標をOKRとして定めるのは私生活のOKR運用としてアリ、という印象を持っている。どっちやねん。
  • KeyResult はもっと少なくてよかった。人間が日々意識できる目標の数なんて、そんなに多くない。研ぎ澄まさないと価値が薄れる。
  • また、KeyResultに関連して、計測するものが多いと管理が面倒になって継続意欲が減少する。
  • 今四半期は、自分の行動を変えることに焦点をあてた目標設定を行ったが、次四半期では自分自身がどのように成長したかに焦点をあてたい。(e.g. 英語語学力の向上)
  • Planningの実施頻度は、2週間に1回がよさそう。仕事では、1週間に1回がちょうど良く感じていたので、そのままプライベートでも1週間に1回のスプリント期間を採用したが、失敗だった。作業時間が少ない週の見積もりをすると、自分が何も達成できていないような気に陥るので、モチベーションが下がったりした。
  • OKR運用を行うこと自体はめちゃくちゃ良かった。日々何も考えずに目の前のタスクを消化し、空いた時間は何も考えずに読書に全振りしていた状態から、戦略的に行動を改善するきっかけになった。

次四半期(2019/4 - 2019/6)の OKR 設定

[継続] 悪い生活習慣と決別し、健康になる
  • 2019/6/30までに体重が3kg以上落ちている
  • 週に一度、運動をする

生活習慣、特に食生活と運動習慣の改善は、年末まで継続する。今四半期との違いは、1日1万歩の行動目標を、週に1日の運動に変えたこと。1日1万歩の継続も悪くないが、ときに時間がかかりすぎることに課題意識があった。(だいたい普段の生活だけで得られる歩数に加え、1日に1時間ほど余分に歩かないといけない。)毎日1時間ウォーキングするのであれば、週に2時間ほどまとめて有酸素運動すればよいのでは?という実験をする。

執筆業の進捗を出し、今年度後半の余裕をつくる
  • 書いているSREの連載の残りの記事を予定どおり進める
  • 書いている書籍の執筆を予定どおり進める

それぞれの執筆に関して補足だが、自分の当初の宣言こそが納期であり、また、これまで自分に対する甘えを続けてしまっていた。この甘えを排除し、執筆業との向き合い方を身体に叩き込みたい。

ちなみに、「執筆を予定どおり進める」という目標は野心的でないように見えるかも知れないが、これまでの自分の筆の遅さを顧みると、当初の予定を守ることは野心的な目標であることは補足しておきたい。

気づけばほとんど日本語にしか触れていない私生活をやめる
  • 海外のポッドキャストを週に30分聞く
  • 業務時間以外で英語のニュースを毎日一本読む

ここ半年ほどで、英語に触れる機会の少なさの危機感を強く感じるようになった。もちろん英語の語学力全般に関しても課題感はあるが、日本語中心での私生活により、知らず知らずの内に自分の情報源が偏ってしまうことへの課題感もある。Matzが言うところの英語で一次情報を取れってのはきっとそういうことなんだろう、と思っている。

余談だが、私の前職は外資系だったが、仕事上の必要最低限の意思疎通をなんとかする程度の英語力しかない。日常会話とか自由度の高い会話であればあるほどダメ。他愛のない会話とか特に苦手。逆に海外旅行中とかに自分の意志を相手に伝えて、行動してもらうみたいなのはできる。(得意とは言ってない。)

おわりに

仕事のOKR運用と違い、仲間がいないから継続にいつも以上に強い意志が必要な気がする。コーチ欲しい、コーチ。

2019年の個人OKRをつくってみた

2019年は個人OKRをやってみようと思った。のでやってみる。

ちなみに2018年の振り返りを前提としてる。

 

kths.hatenablog.com

 

OKRを仕事でまだやったことがないよーって方は読んでもらえると、OKRを実践する参考になる…かもしれない。

ちなみにOKRについては、昨年になんとなく気が向いてまとめたので、ご興味ある方はどうぞ。

 

 

OBJECTIVES

  • 悪い生活習慣と決別し、健康人間になる
  • カンバン仕事術を実践し体得する
  • ヒューマンスキルや、マネジメントとは何かをハラオチさせる 

せっかくなので、それぞれに関するコメントを残しておく。

 

悪い生活習慣と決別し、健康人間になる

今に始まった話ではないが、とりあえず食生活がヤバい。一ヶ月の食事のうち、外食95%以上。朝飯は抜く。飲酒も週5以上は確実。

かと思えば、定期的な運動習慣もなくなった。今は2〜3ヶ月に一回のテニスだけ。

というわけで、2017年に一年間で5キロ太った実績がある。(2018年はなぜか奇跡的に体重をキープしていた。)

 

また、睡眠時間も不規則極まりない。夜中の3時や4時まで執筆やプログラミングをして、朝は9時30分に起きる日もそこそこ多い。

昨年、note にこんな記事を書いたが、すまんな、タイトルは嘘だ。自分の睡眠について見直していない。

note.mu

 

とりあえず健康的な習慣を取り戻さねば。

 

カンバン仕事術を実践し体得する

2018年は、とにかく大量の並行タスクが動きっぱなしになっていた。登壇資料作成、仕事のためのInput(読書やプログラミング)、執筆関連、勉強会運営の準備、副業とそれに関する諸タスクなど。これに加えて、趣味(読書、漫画、映画、アニメ、ライブ、旅行)の時間を確保すると、平均睡眠時間が3時間の時期もしばらくあった。

 

その結果、納期の決められているタスクはともかく、自分ですべてスケジュール管理しないといけないタスクがとにかく進まなかった。この状態が続くと、「緊急ではないが重要なタスク」が先延ばしにされることをこれまでの社会人生活で私は学んでいる。

 

で、年末年始に『カンバン仕事術』を読み返し感じたが、昨年後半の自分は、アジャイル開発プロセスの基本を自分の人生において、一切実践できていなかった。

 

 

業務では、「WIP制限しましょう」とか言ったりもしていたが、業務外のことになると一切なにもできていない。要するに自分をセルフマネージする能力が自分は低いのだと思った。

ので、そんな自分とも決別することを2019年の目標の1つにしてみる。

 

ヒューマンスキルや、マネジメントとは何かをハラオチさせる 

昨年、Developers Boost に登壇した際に、DMM CTO 松本さんの講演を聞いた。

 

U30の皆さんに贈る最速キャリア戦略

https://event.shoeisha.jp/devboost/20181215/session/1882/

 

この講演の中でカッツ・モデルの説明があり、「なるほど」と思った。

 

jinjibu.jp

 

マネージする人数が増えれば増えるほど、業務遂行能力よりも対人関係能力、対人関係能力よりも概念化能力が重要になるという考え方。

 

これまで自分は、こういう説明を聞くと、なぜか「自分は対人関係能力や概念化能力は高いレベルで実践できているタイプの人間だ」と勝手に思い込んでいる節があった。学生時代に周囲の人間を巻き込み、物事を推進する経験に恵まれた、つまり、「やったことがあった」ので、「自分にはできる」と思っていた。イタい。

 

が、いざ自分がマネージャー職に就き、「なるほど、マネジメントわからん」となった。

これまでの社会人生活で素晴らしいマネージャーに恵まれたおかげで、彼らと働く素晴らしさを知ったが、自分がその体験をチームに提供できているかをどう考えればよいかが分からなかった。結果、「なるほど、マネジメントわからん」と感じた。

その原因を自分なりに分析した結果、ヒューマンスキルやマネジメントを深いレベルで考えたことがなく、自分の中での言語化ができていないことに一因があると感じた。

 

というわけで、2019年は、このあたりを深掘りしてみたいと思う。

  

KEY RESULTS

前述したOBJECTIVES それぞれに対するKEY RESULTS を決める。

 

悪い生活習慣と決別し、健康人間になる
  • 02:00までに就寝し、08:00までに起床する日が80%以上
  • 一週間のうち6日以上10,000歩達成している週が80%以上
  • 2019/12/31までに体重が12kg以上落ちている
カンバン仕事術を実践し体得する
  • 週次でスプリントプランニングを実施し、毎週の進捗達成率80%以上を保つ

上記実践にあたり、人生バックログ(?)の作成と運用を1月末までに開始する。また、自分自身のベロシティとキャパシティを2月末までに計測および運用開始できている。

ヒューマンスキルや、マネジメントとは何かをハラオチさせる 
  • 「考える週」を年に2回開催し、ヒューマンスキルや、マネジメントのことをInputし、ドキュメントとしてOutputする
  • 1on1 で感じたこと・学んだことを一ヶ月に一度振り返る

「考える週」については、以下の本をどうぞ。ビル・ゲイツが実践しているやつです。

 

 

健康健全性指標

  • 人生の楽しさ

これは、自分が人生で最も重視していることの1つでもある。

 

今後の運用

運用期間は、いったん1年で考えている。

これを継続するための仕組みを導入しないと続かなさそうだなー、と。仕事ならまだしも自分一人だし。

睡眠時間は、Apple Watch を毎日つけたまま寝て「Auto Sleep」で管理して、歩数はFiNCに連携してる歩数計のデータで見る。「考える週」は近いうちに実施週を決めちゃうか。あとはリマインダを今のうちに設定しとこ。

自分バックログ(?)は、Trelloでいっか。

運動に関しては、同志が欲しい気持ち。なぜなら、去年ジム通いを挫折してしまったから。

 

会議体は、土曜日のAMにチェックイン + スプリントプランニング、金曜日の夜に1人TGIF + レトロスペクティブ にしようと思う。1人TGIFの響きむなしい。

ちなみにOKRと、スクラムの融合は自分の中で興味のあるテーマなので、1人OKR +  カンバン仕事術を実践しながら、何かヒントをつかみたい。

というわけで、明日からさっそくやってみる。