これはただの日記

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

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

先日、「プロダクト開発における暗黙知との向き合い方」というテーマで 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 +  カンバン仕事術を実践しながら、何かヒントをつかみたい。

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

 

2018年の振り返り

2018年の振り返りを書く。いわゆるエモい風な話しか書いていないので、そういうのを読みたくない方は、戻るボタンをどうぞ。

 

仕事

力不足を感じた1年だった

2017年の振り返りで、「責任範囲が広がることで成長機会が増え、素晴らしい経験を数多く積めた一年だった」と書いたけど、2018年はその傾向がさらに加速したように感じる。

で、その結果どうなったかというと、2018年は、自分の力不足を感じる機会が以前に比べて圧倒的に増えた。

もっと素晴らしい仕事をできるはず、もっと良いプロセスにできるはず、という気持ちがずっと頭から離れず、とにかく試行錯誤を続けた気がする。で、試行錯誤の過程で、過去の偉人の残した文献に触れたり、1on1で技術顧問の方々に相談し、自分がやっていることとの照らし合わせを繰り返した結果、自分の未熟さに否が応でも向き合わざるを得なかった。

2019年も引き続き、2018年取り組んでいた以下のようなテーマに向き合っていく。もちろん向き合うだけでなく、自分の中での first release の完了条件をそれぞれ定義、チームで共有し、実践できている状態をつくりあげたい。

これ以上は詳しく触れないが、今のように自分が力不足を感じる状況でも、日々チームが素晴らしくなっていく様子を実感できているのは、いつも周囲にいる人たち、特に自チームの仲間のおかげだと心の底から思う。

 

ソフトウェアエンジニアは中毒性のある仕事

ちなみにマネージャーになった今年も去年と同じだけのコミット数を継続した・・・というものの、実態としては、マネージャーになってから明らかにコードを書く時間は減った。

去年と同じコミット数を継続できたのは、以下理由。

  • コードで取り扱っていなかった領域を、コードで取り扱えるように取り組んできたから
  • また、マネージャーになる前の時期に、集中してつくりきったものがたまたま数個あった

で、今年1年を通じて改めて思ったのが、ソフトウェアエンジニアは本当に中毒性のある仕事だということ。自分が考えていることを書いて、なにかの問題が解決されていく様子は、何歳になっても本当に楽しい。

個人的には、それと同じくらい チームで問題解決をするプロセスづくり や チームづくり に取り組むのもおもしろい と感じるので、おそらくマネージャー職には向いているのだと思う。

 

今後、自分がコードを書く時間とマネージャー業をする時間のバランスにどう向き合っていくかは未だに確固たる正解を持っていない。エンジニアリングマネージャー業やっている皆さんはどうやって乗り越えてきたのか…

百人百様な気がしているので、まずは都度ケースバイケースでどうするか考えようと思っている。その結果、自分なりの乗り越え方を見つけられればいいかな。

 

仕事関連で発表したもの(一部)

 Developers Summit 2018

 SRE Lounge #2

 MANABIYA

 Geeks Who Drink

 Ansible Night in Tokyo 2018.04

 サポーターズCoLab勉強会

 July Tech Festa 2018

 JDDStudy #3

 AWS Startup Tech Meetup #013

 SRE大全

 

 Developers Boost

 (おまけ)9月の三連休にOKRのことばかり考えてた時のまとめ

 

どちらかと言えば、施策的な内容だったり、思想的なことを外で話す機会が多いので、業務で書いているコードだったり、つくっているものについて話す機会を2019年は増やせればいいかなあ、とぼんやり思っている。

私事

印象に残ったライブ

  • サマソニでThe Bloody Beetroots のライブを見た。あんなにテンションが上がったライブは久しぶりで興奮した。
  • 同じくサマソニでBiSHのライブを見た。サマソニナイズ?されていて、事前に予習していたよりもかっこよかった。
  • Sweet Love Showerサカナクションのライブを1年半ぶりくらいに見た。見る度に進化していて、本当にすごいバンド。
  • OKAMOTO’S 90’S TOKYO BOYS IN HALL "Studio" も印象に残っている。メンバー同士の仲が良さそうなバンドは見ていて幸せな気持ちになる。
  • はじめてNothing's Carved In Stone のワンマンにいった。やっぱすきなバンドはフェスだけでなくワンマン行かなあかんな、とオモタ。最高でした。
  • 久しぶりにBlue Note に行って見たBrenna Whitaker も相変わらずよかった。Blue Note 自体が約2年ぶり。Blue Noteといえば、6月のfox capture planのライブに行かなかったのは地味に後悔してる。

来年は、Awesome City ClubとFIVE NEW OLD のライブに行きたい。ちなみに2月のMaroon 5 のチケットを取っているので、今から楽しみにしている。

印象に残った映画

  • キングスマン ゴールデン・サークル』よかった。前作を見ずに映画館に見に行ってしまったのだけど、アクションシーンがめちゃくちゃかっこよくてしびれた。このシリーズのファンになってしまった。
  • 『レディ・プレイヤーワン』過去と未来をつなぐような作品だったというか、そんな感じ。スピルバーグすげえ。
  • オリエント急行殺人事件』この映画も印象に残っている。人間ドラマとしての完成度が高く、自分が30歳になった時に見たらまた違った感想を持つんだろうな、と思った。
  • 『アリー \ スター誕生』アカデミー賞にノミネート確実では。レディー・ガガといえば、ダンサブルな曲の印象が強かったけど、この映画を見て印象が変わった。まだやっているので、見ていない方は年末年始にどうぞ。
  • シュガー・ラッシュ:オンライン』いやー、これはズルいわ。こんなんおもしろくないわけがない。エンジニア視点だと、エンドロールを眺めているだけでも楽しい作品。

旅行

  • 東北旅行で桜の絨毯なるものをはじめて見た。きれいだった。
  • 前職同期のみんなと恒例で行ってるキャンプは今年も最高に楽しかった
  •  バンコクに出張で行った&延泊してアユタヤを見て回った。アユタヤから空港に戻る時間がぎりぎりだったので、現地のドライバーの人と交渉してなんとかしてもらったのが思い出に残っている。空港泊を逃れてよかった。

2018年は毎月1回はどこかに旅行していた気がする。出費氏〜〜。

 

 その他

2019年もよろしくおねがいします!

[SRE Advent Calendar] SRE Advent Calendar 2018 を終えて

SRE Advent Calendar 25日目の記事です。

 

SRE Advent Calendar 2018 - Qiita

SRE 2 Advent Calendar 2018 - Qiita

 

SRE Advent Calendar を振り返ります。

 

全記事の振り返り

Day1

 

Day2

 

Day3

 

Day4

 

 

Day5

 

 

Day6

 

Day7

 

Day8

 

Day9

 

Day10

 

Day11

 

 

Day12 

 

Day13

 

Day14

 

Day15

 

 

Day16

 

Day17

 

 

Day18

 

Day19

 

Day20

 

Day21

 

 

Day22

 

 

Day23

 

 

Day24

 

Day25

 

@katsuhisa__的ベスト3

 さいごに、個人的に印象に残った記事のベスト3をがんばって選んでみます!

 

3位. 割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話

 

ゴミが散らかると、いやな気持ちになるので、それをみんなで解消していくための時間を設けている話。

リリースから時間が経つと、はじめはこれでいいや、と思っていたものがどんどんなおしたい気持ちになっていくものなので、この記事の内容にはすごく共感できたし、うちも真似したいなー、と思いました。

はてなさん、ぜひSRE Lounge にもご登壇いただきたい・・・!(とツイートしたところ、この記事の作者の方に拾っていただきました。いつかご登壇依頼をします!ありがとうございます!)

 

2位. SLO設定/超過監視にまつわる活動の振り返り

 

「SLO を設定しよう」とは言っても、いろんな会社の人と会話をする中で、なかなか超過時のポリシー運用にまで落とし込めている会社さんは少ないなー、というのが私の印象でした。

この記事では、具体的に超過時のポリシーについて詳しく触れられており、非常に参考になる内容です。

エムスリーさん、ぜひSRE Lounge にもご登壇いただきたい・・・!

 

1位. サービス品質向上のためにBacklogのSREが行ってきたサービスレベル管理の取り組み

 

ヌーラボSREの吉澤さんのこちらの記事が、SRE Advent Calendar 2018 の@katsuhisa__ 的1位でした。 

SREの文脈では、一般的に、SLI といえば、レイテンシやエラーレートを指すことが多いですが、この記事では、自社のチームの課題に焦点を当て、社内向けSLI を整備した話が書かれています。

私が登壇する資料では、度々「ウェブオペレーションは、技芸であり、科学ではない」( by 『ウェブオペレーション ―サイト運用管理の実践テクニック』 )という言葉を引用しますが、まさにこの記事の事例には、一種の技芸を感じました。

また、それ以外にもSREと組織構造にも詳しく触れられていて、今後も何回も読み返したくなるような内容でした。 

 

さいごに

SRE Advent Calendar 2018 は、総勢33名の方にご参加いただきました。ご参加いただいた皆さん、本当にありがとうございました。

上記で、私がベスト3に選出しなかった記事の中にも、素晴らしい記事が本当にたくさんあるので、みなさん年末年始の帰省時にでも、ぜひお読みください!

 

来年もぜひつくろうと思いますので、その際は、またよろしくおねがいします!次は、ぜったいにハッシュタグつけるぞ・・・!

 

本当にみなさんありがとうございました!!!少し早いですが、良いお年を。

[SRE Advent Calendar] 監視システムの特徴から考える監視設計のポイント

SRE Advent Calaendar 1日目の記事です。

 

qiita.com

 

SRE Advent Calaendar 1 がすぐ埋まってしまったので、SRE Advent Calaendar 2 もあります。

 

qiita.com

 

本記事では、SREのみなさんに向けて、監視システムの特徴から考える監視設計のポイントをお伝えします。

 

SREと監視

SREのみなさんにとっては当たり前すぎると思いますが、SREと監視は切っても切り離せない関係にあります。

SREのお仕事は、サービスの信頼性を維持・向上させることであり、そのためには信頼性を計測しなければなりません。

 

モニタリング?監視?

さて、SREの文脈では、度々、「モニタリング」というキーワードが登場します。

モニタリングと監視は、どのような関係性にあるのでしょうか。

 

私の解釈は、以下です。

- 監視: 状態を見張ること

- モニタリング: 状態を観測・分析する行為全般(監視を含む)

 

今回のブログでは、主に監視について扱います。

 

監視とは網である

私は、「監視とは網である」と考えています。そして、網に問題が引っかかったら対応(問題を取り除くこと)をします。

 

監視を網と考えることで、監視システムの特徴が分かる

監視を網と捉えると、監視システムのいくつかの特徴をうまく認識できます。

 

1. 網目なので、完璧に防ぐことはできない

2. 網目をこまかくすれば、より多く引っかかる

3. 網なので、破れる

4. 問題の大きさが変われば網目も変えなければならない

 

順を追って説明します。

 

1. 網目なので、完璧に防ぐことはできない

監視を作るときに陥りがちなのが、すべての問題を検知できる監視システムを設計しようとしてしまうことです。

しかし、監視を網と捉えると、これは不可能であることが分かります。なぜなら、網には網目が存在するので、完全に穴を防ぐことはできないからです。

 

 

また、問題をできるだけ多く検知するために、網を複数枚用意することにはお金がかかりますし、網目をより細かくしたり、網を新しく設置するには時間も必要です。

ですので、「どれだけの網があればよいのか」「また、網目の細かさはどれくらいが適切か」「いつまでに網を設置すればよいのか」をはじめに考えておく必要があります。

 

すべての問題を検知する監視システムは実現できないので、はじめから妥協点を決めなければならない。これが監視システムの特徴の1つ目です。

 

2. 網目をこまかくすれば、より多く引っかかる

次に、網目をこまかくすれば、より多くの問題を引っかけることができます。これは、監視システムに時間とお金をかければ、問題をより多く検知できるようになることを示します。当然ですね。

 

あわせて考えなければならないのが、引っかかった問題は、取り除かないといけないということです。つまり、網目を細かくし、より多くの問題が引っかかるようになればなるほど、問題に対応するコストが増大することを示します。

 

時間とお金をかけて監視の網目を細かくしたのに、網を管理する人の仕事は増えるわけです。(一方、サービスを利用している人にとっては、問題に直面する確率が減るのでサービスの信頼性は向上しますが。)

これも意外と見落としがちな監視システムの特徴です。

 

3. 網なので、破れる

監視は網なので、破れます。これは、監視システム自体のダウンタイムの発生や、一部の監視項目の動作が不安定になる可能性を指します。

 

監視システムは常に動き続けるものを想像しがちですが、網と考えれば、たまに破れる可能性があることをより認識しやすくなるでしょう。

また、網が破れる可能性があるのであれば、複数の網を活用することも視野に入れるべきかもしれません。(もちろん、網の設置コストも増大します。)

 

4. 問題の大きさが変われば網目も変えなければならない

 最後に大事なポイントは、問題の大きさが変われば網目を変えたり、新しく網を設置する必要があることです。

 

これは、求めるサービスレベルが向上すれば、これまで検知せずとも許されていた問題も検知しなければならないことを示します。

逆に言うと、現在利用している網で、求めるサービスレベルを実現できているのであれば、無理に網目を変える必要はないということです。

 

監視は、サービスレベルとセットで考える必要があることも監視システムの大事な特徴です。

 

まとめ

本記事では、監視を網に例え、監視システムの特徴を解説しました。以上から分かる監視設計のポイントを最後にまとめます。

 

  • すべての問題を検知できる監視は、はじめから目指さない
  • 監視項目の追加は、OnCall対応(障害対応)コスト増大とセットで考える
  • 監視システムは停止する前提で監視設計すべし
  • 監視は、サービスレベルを意識して 設計する

 

以上です。

 

さいごに

本記事では、網のかけ方(監視対象)や網の種類(監視方法やツール)については解説しませんでした。

そのあたりにご興味ある方は、私が過去に発表した以下資料をご参考ください。

(いま改めて読んでみると、修正したいポイントもいくつか見つかりました。いつか資料を修正したいと思います。)

 

speakerdeck.com

 

 

また、私の師匠が書いた以下記事も、監視システムとは何かを考える上でたいへん素晴らしい記事なので、こちらもあわせてどうぞ。

 

blog.cybozu.io

 

何か疑問点やご意見あれば、 @katsuhisa__ までご意見いただけると嬉しいです!