Coderetreatに齢45にして初参加

2020年11月7日（土）に、こちらのイベントに参加させていただきました〜

ここ最近の週末は、GolangでLeetCodeの問題を解くか、Kubernetesのclient-goのソースリーディング・動作確認を続けています。一方で、ずっとひとりで学習を続けているので、たまには違った視点が欲しいなと思い、腕試しを兼ねて同イベントに参加してみました。

イベント概要

平たくいうと、ライフゲームというお題をみんなで実装してみましょうというものです。
但し、以下のようなルール・制約があります。

• 実装45分、振り返り15分の計60分のサイクルを、6回繰り返す
• 使用する言語・開発環境は自由
• 基本はペアプロ、慣れたり気分転換したくなったらモブプログラミングで！
• 45分経ったら、そのコードは破棄！

45分ごとに頭も気持ちもコードもリセットするため、いろいろなチャレンジができるチャンスでもあります。

自身の行動記録

覚えている範囲でメモ。ちなみに開発環境は、TDDのトレーニングで有名なcyber-dojoを主に使用しました。

Iteration 1 : まず慣れる

まずはTDDを忠実に実施することで、ライフゲームの仕様の理解とイベントのルールへの慣れを優先しました。ちなみに、言語・テストツールはJavaScript + Jestでした。

Iteration 2 : 設計を考える

次はJava + JUnitで、オブジェクト指向の観点から設計を意識して進めました。このあたりでライフゲームの実装イメージが掴めた感じ。

Iteration 3 : Golangでやけど

配列操作の都合と、自身が最近学んでいることを試してみたいことから、Golang + testingをチョイス。しかしながら、人数の都合でトリオを組んだメンバーが初Golangだったため、言語の勝手で詰まってしまい、私が言語仕様を説明している間にタイムアップ (´・ω・)

Iteration 4 : Golangおかわり

Iteration 3を受けて、Golangを試したい！という方が他にもいたため、再度チャレンジ。
最初の5分は、時間の節約と言語仕様の説明を兼ねて、私がIteration 3での実装内容を復元し、残りの時間でみんなでワイワイする形に。完了のイメージがはっきりと見えてきたところでタイムアップ。45分はかなり短い。

Iteration 5 : Clojureに散る

なぜかClojureをやろうということになって、モブプログラミングで試したものの…　そもそも書き方が分からない、知りたいことがまるで検索で引っかからない（ググラビリティの低さ）、説明を読んでも意味が分からないと、文字通りの完敗。

Iteration 6 : Pythonで完成

最後は全員でモブプログラミング。リスト内包実装など様々なテクニックを皆さんから教えてもらい、時間内についに完成！
ちなみに私は、純粋に体力が尽きてしまい、このiteration途中でコーディングから離脱してアイデア出し係に。6 iterationはかなりハード。

感想

• 参加者と運営の皆さんのホスピタリティのおかげで、45歳でも多くのことを学べました。感謝。
• Golangの独習内容は、他者に説明できるレベルになっていたことを確認できました。
• 久々に会社以外のIT系の人と直に話せたため、かなりのリフレッシュになりました。
  
  

おまけ

株式会社アトラクタ様のおかげで、美味しいハンバーガーをいただきました。本当に感謝です。

お店はこちら。

Kubernetes Novice Tokyo #5でLTをさせていただきました

自身のKubernetes力を磨こうと、9/29（火）に「Kubernetes Novice Tokyo #5」というイベントでLTをさせていただきました。

Kubernetes関連のコミュニティ・イベントでは、初の登壇になります。
発表資料は、コチラになります。

私たちのチームが現在絶賛構築・運用しているKubernetesベースのテスト用インフラである「Testable Infra」について、自身の情報整理とコミュニティからのフィードバックを得ることを目的にお話させていただきました。

ちなみに、10分という発表時間と、CNCF系OSSのコミッターから「Kubernetesをそういう目的で使うという発想はなかった」と以前言われたことがあったことから、今回は概要レベルの説明にとどめています。

このイベントで得たもの

1) 大将さんから教えていただいた、1つのLoadBalancerを用意して配下のクラスタ群を切り替え可能にするアイデアを早速活用して、Kubernetesリソースの削減とTestable Infra自体のパフォーマンス向上につなげられています。

2) mikiさんの発表を参考に、私もKubernetesのclient-goのソースリーディングを始めました。

さいごに

別イベントから登壇依頼が届きまして、Testable Infraの技術詳細や構築・運用時のTipsなどを現在絶賛整理中です。近々みなさまにも共有できると思います。

RSGT2021に登壇できます！

多くの方の応援をいただき、Regional Scrum Gathering℠ Tokyo 2021（以下「RSGT2021」）のプロポーザルが通りました〜！

ちなみに、私のプロポーザルは↓コチラ↓になります。
Regional Scrum Gathering Tokyo 2021 - Tips of Product Management for Internal Tools／社内ツール・サービス・プラットフォームにおけるプロダクトマネジメントの勘所 | ConfEngine - Conference Platform

さて今回は、このプロポーザルの狙いを、簡潔に5分以内で読めるようにまとめてみました。

1. 自身のプロダクトマネジメントの知見を整理しフィードバックを得たい

ここ1年ほど、特に社内ツール・インフラの設計・開発に加えて、プロダクトマネジメントもやる必要が出てきました。 その際にぶつかった課題、試行錯誤して失敗した点／うまくいった点を整理し、みなさまからのフィードバックをいただいて洗練していきたいと思っています。 もちろんその結果として、現在担当している社内ツール・インフラをより確かなものに育てていく所存です。

2. 世界的な知見不足を埋めたい

今年5月に公開された、ThoughtWorks社のIT業界トレンドレポート『Technology Radar (Vol.22)』を読んだところ、以下の記述に特に目が止まりました。

要点としては、

1. 社内ツール・インフラにプロダクトマネジメントの考え方を適用するトレンドが世界的にみられること
2. 一方で、社内ツール・インフラならではの知見・方法論などの整理はこれから

というものです。

私は基本、スペースを見つけて走り込むタイプ（ゴールを決められるかはまた別）なので、これはチャンスだと思い、このレポートを読んだ直後からこのプロポーザルを書き始めていました。

3. Agile2021の公募にも挑戦したい

今年のRSGT2020で試したところ「行けた」ので、今回も狙ってみようと思います。

昨年は、Regional Scrum Gathering Tokyo 2020 - 特殊部隊SETチームの日常 - 技術と実験を融合した実践アジャイル術 - | ConfEngine - Conference Platformと題してお話させていただきました。

そこで皆様からいただいたフィードバックを活かして、Agile2020にプロポーザルを出したところ、なんとかacceptされました。

• 倍率は、7-8倍ほどでした。
• ちなみにイベントは、新型コロナの影響で中止となりました。結果として幻のスピーカー扱いに。

発表資料はコチラです。

せっかく資料を作ったので、日本国内で発表をした際の内容を、ログミーさんにまとめていただきました。

ちなみに、Agile2020の公募の経緯については、コチラもご覧ください〜

さいごに

新型コロナで鬱屈した気持ちを、少しでもみなさまとともにカンファレンスの場で発散できれば！

ウィズコロナ＆ニューノーマルな生活の過ぎたるイチ事例

在宅勤務とストイックな生活をしすぎて体調を崩していると、先日医師に診断されました。
ただ、症状的に何が原因でどう対処すれば良かったのかが分かりづらいものだったので、似たような症状で困っている方のプラスになればと思い、症状・原因・対応策をまとめてみました。

症状

• 7月頃から、左手の人差し指・中指に痛み・違和感が出てきました。
• 7-8月頃から、肩こりが慢性的になり、どんなにストレッチをしても効かない状況になりました。
• 8月中旬頃から、両耳、特に右耳が聴こえなくなってきました。
  • 特に右耳は、カパカパするような違和感に悩まされています。
  • ギターなどの弦を弾いたような、謎の異音が聴こえるようになっていました。
• 9月以降、めまいと吐き気も出てきています。

めまいと吐き気の段階で「何かマズイ」と判断し、急ぎ鍼灸院と耳鼻咽喉科を受診しました。

原因と対策

• 背骨がねじれた状態になっていて、全身、特に首回りに大きな負荷が掛かり、結果肩や指を含む全身の痛みにつながっていることが分かりました。
  • 生まれつき猫背だったことに加え、在宅勤務の長期化で、負担のかかる姿勢で長時間PCに向かい過ぎたことが原因とのことでした。
  • 背骨を整体的に矯正し、現在も継続的に鍼・マッサージを続けています。
• 「耳管」という器官に障害が起きていて、めまい・吐き気につながっていると思われるとのことでした。
  • これは、急激に体重を減らしたりすると、たまに起きる症状とのことです。（確かに今年に入ってから10kg以上減量している最中でした）
  • ちなみに、脳は健康とのことでした。
• 右耳に1cm強の髪の毛が刺さっていて、これが異音につながっていました。（すぐに除去してもらいました）
• 在宅勤務で外出を避け続けたこと、また仕事に集中し過ぎてしまったため、メンタルが気付かぬ間にダメージを受けていたとのことでした。
  • 確かに半年ほど、新型コロナ対策を忠実に守って、自宅近辺以外の外出を一切していませんでした。結果的に、仕事だけを突き詰めるライフスタイルになり、思考・メンタルの幅を狭めてしまっていました。
  • 早速今日、無理やり外出をして、気分転換を始めています。

さいごに

ウィズコロナ＆ニューノーマルな生活には、新しいメリットもたくさんある一方で、未知というか気付きづらい心身のダメージもあるようです。それらの原因と対策を見つけて集めて共有し合うことは必要だと、文字通り痛い目にあって痛感した次第です。

参考情報

鍼灸院で使っているストレッチポールです。背骨・首回りの痛みを、以前よりも軽減できています。

LPN ストレッチポール(R)EX ネイビー 0001

気分転換を意識して行うことの重要性とそのテクニックが、詳細にまとめられている一冊です。

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

怒りやストレスの原因を見つけて解消するための技術が、簡潔にまとめられています。

アンガーマネジメント入門 (朝日文庫)

おまけ：半年ぶりの外出

虎ノ門ヒルズ駅。まだ絶賛工事中。

虎ノ門ヒルズ本体。発展はこれからな模様。

虎ノ門ヒルズの近くにある愛宕神社。出世階段が有名。

愛宕神社にあった龍の像の出来栄えが見事

"Kubernetes the Hard Way"を完走しました

同僚に勧められて、GW早々"Kubernetes the Hard Way"を全てやりきりました！

"Kubernetes the Hard Way"とは

Dockerなどのコンテナの管理ツールとしてデファクトスタンダードになりつつあるKubernetesを、インストーラー任せにせずに、自力で必要なコンポーネントやクラスタ全てをセットアップして動作させるようにするという、一種の学習ツールです。

Google Cloud Platform (GCP)とGoogle Cloud SDKを使用して、インスタンス作成やネットワーク設定などを行う必要があるため、これらの学習教材としても有用です。

動機

大きく3つあります。

1. 実務でのKubernetesの利用が普通になってきた

ここ数年、社内でDockerの普及が進み、これらの管理のためにKubernetesの利用が普通になってきたことがあります。であれば、詳しく知りたくなりますよね〜

2. 書籍や公式ドキュメントだけでは理解しきれないところがあった

これは私だけの可能性がありますが、Kubernetesの書籍や公式ドキュメントを読んで動かし続けていたのですが、いまいちピンとこないところが多々ありました。 例えば、KubernetesのControl Planeは

• kube-apiserver
• kube-controller-manager
• kube-scheduler

で構成されていると公式ドキュメントにはありますが、これらには具体的にどのような設定が必要なのか？どのように連携し合って全体としての機能を提供できるのか？といったレベルまで理解しきれず、悶々としていました。

3. 以前から試してみたいことがあった

加えて、以前からDockerとKubernetesとを活用して、既存のテスト環境を（テストデータ込みで）必要な時に複製・破棄できる仕組み（チーム内では「Testable Infra」または「Testable and Disposable Infrastructure」と呼称しています）を作ろうと画策していまして、その実装やトラブルシューティングに、Kubernetesの内部構造の詳細な知識が必要だったこともあります。

やってみて分かったこと

1. 内部の詳細を体得できた

実際に手を動かすことで、以下のことを理解もとい「体得」することができました。（個人的な動機に叶うものでした）

• 各コンポーネントを動かすために、どのような設定ファイルが必要で、どのクラスタのどのディレクトリに置けば良いか？
• 各コンポーネントをLinuxのサービスとして動かすために、それぞれどのような設定が必要か？
• 各コンポーネント・クラスタ間の通信で、認証や暗号化がどう関わっているのか？またそのためにどのような設定が必要か？
  
  

2. トラブルシューティングができた

指示通りに設定したにも関わらず、kube-apiserverの起動に失敗するトラブルに遭遇し、原因究明およびトラブルを解決するという経験ができました。

トラブルシューティングの詳細は、下記GitHub Issueとしてまとめておきました。

「ツール系の学習にはトラブルシューティングが最適だ」と、昔会社の先輩に言われたことがありましたが、まさにそうでした。トラブルシューティングは、課題発見・解決力を磨く強力なツールです。

3. GCPの費用と節約方法が分かった

"Kubernetes the Hard Way"のREADMEには、GCPの費用の目安として

$0.23 per hour ($5.46 per day)

とありますが、必要時以外にGCPの各種リソースを停止・削除しておけば、1日あたり200-300円程度に抑えられました。

（インスタンスやネットワーク設定は、停止しているだけでは課金されるんですね〜）

まとめ

完走した感想ですが、Kubernetesのドキュメントやコードを追うことや、日々の業務で活用することももちろん有益ですが、より理解を深めるためにこれを試すのは、大いにありだと思います。 GW & Stay Homeなこのタイミング、実はこうしたことを試す／学ぶ良い機会かもしれません。

Agile2020公募採択とその歩み

世界最大規模のアジャイルのグローバルカンファレンス「Agile2020」に提出していた公募が採択され、登壇させていただくことになりました。2014年以来、2度目の栄誉です。

新型コロナウィルスの影響で、予定通り登壇できるかは正直不透明ですが、主催者によると、本稿執筆時点では予定通り開催するとのことです。

ちなみに、私のセッションの情報はこちらになります。提出した論文などは、こちらからご覧いただけます。

さて今回は、公募採択までの歩みについてまとめてみます。

動機と準備

Agile2014で採択された論文が、現在でも私たちの業務やチームの指針策定にプラスに作用していることが大きいです。個人・チームとして何か問題にぶつかった時に、考え方や解決策の引き出しとして活用できているのです。

一方で、前回の登壇から5年以上経過し、その間私もチームも多くのスキル・経験を蓄積してきました。そろそろ、蓄積してきたスキル・経験を整理して活用できるようにする時期だと判断し、昨年2019年の4月から行動を開始しました。

具体的には、以下のアクションを行いました。

• 業務上の気付き・考えたこと・取った施策・その効果などを、毎日メモとして書き溜める
  • 業務中に書くことがポイントです
  • 常に発信することを前提に、日々の業務を観察し実行していました
• 1週間おきに、書き溜めたメモを文章としてまとめる
  • 1週間スプリント・ウィークリーリリースと書くと、イメージしやすいかもしれません
• 文章の通りが良くなったところで、実際に論文フォーマットを当てはめる
  • 前回すでに論文のフォーマットを入手し、書き方を熟知しているため、早期からリリースできる状態で作りこみました
  • 実際に提出前提のフォーマットで書き出してみると、記述の過不足などがよりクリアになります
• 同僚に定期的にチェックしてもらい、フィードバックを取り込む

上記の結果、昨年11月はじめの時点で、いつでも論文を提出できる状態にできていました。 そして、11/14に公募が開始されたので、早速論文を提出しました。

渋い反応

しかしながら、実際に論文を提出してみると、ネガティブなフィードバックばかりが返ってきました。

いずれにも共通するのは、「too general」というもの。

私はこれを、「記述範囲が広く一般論的な内容になってしまっているので、もっと具体的で踏み込んだ内容にして欲しい」という意味に捉え、年末年始の休みを使って、徹底的に詳細な内容に書き換え、再度提出しました。

しかしながら、以前よりはポジティブなフィードバックになったものの、やはり「too general」とのこと。

この時点で、何かがおかしいと気付きました。

ピボット

私が選択したトラック（＝セッションカテゴリー）は、前回のAgile2014と同じ「Experience Report」でした。 このトラックは、アジャイルを試してみた経験談を深掘りするもので、具体的には「テスト自動化による想定外の学習効果」や「モブプログラミングのon-boardingへのプラスの効果と改善すべき点」といったものが求められます。

一方で私の論文は、SET（Software Engineer in Test）としての戦略策定方針やそのためのステークホルダーからの支持の得方、問題プロジェクトの課題発見とその解決方法、我々が構築した新しいコンセプトのテストツールなど、ここ数年の活動全体を整理・総括したもの。

どうやら、「Experience Report」トラックで求めているものよりも、はるかに広範で多岐にわたる情報をまとめすぎたようです。端的にいうと「書きすぎ」でした。それを「too general」と指摘され続けていました。

一方で私としては、論文でまとめたレベルの全体的な話をしたい、そのレベルの知見をまとめて今後の自身とチームの活動に活かしたい。登壇はしたいけれども、そこは譲歩したくない。

そこで、締め切りまで1ヶ月を切った1月の中旬、私は「ピボット」を選択しました。

改めてトラック一覧を確認し、自分の話したい事に近しいものを探してみたところ、「Development & Testing Practices」を発見。こちらは、30分だけ話せる「Experience Report」とは異なり75分も話せる、論文以外の過去の発表資料も評価対象にしてもらえる、そして何より、自分の話したいこととトラックの求めているものとが一致している！

そこで、ピボットを決意した次の日に、早速「Development & Testing Practices」に公募を提出し直しました。

ちなみにAgile20xxはこのように、トラックごとに応募方法や基準が異なります。

著名人からのフィードバックとサポート

ピボットを決意し公募を提出した次の日、早速ポジティブな反応が返ってきました。

まず、私にTDDを叩き込んでくださったJames Grenningさん。久々の再会です。

テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計

次に、Agile Testingの考え方で日々お世話になっているLisa Crispinさん。まじか！

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

他の方たちからもフィードバックをいただきましたが、いずれにも共通したのは、「方向性は合っている」「より多くの人にアピールできるようにここをこう直そう」という、公募採択とその後を想定した具体的なものでした。

それらのフィードバックをもとに、公募内容の改善のやり取りを続けた結果、採択となりました。勇気を持って選択したピボットに成功したと言えます。

まとめ

公募を出す際も、アジャイルの考え方や方法論は役に立つぞというのが、個人的な所感です。

• 小さく準備しておく
• いつでもリリースできる状態にしておく
• フィードバックをすぐに取り込めるようにしておく／取り込む
• 必要であればすぐにピボットできるようにしておく／する

【Appendix】RSGT2020での発表の補足

Regional Scrum Gathering Tokyo 2020、個人的には3年ぶりに参加＆登壇させていただきました。

久々のRSGTは、私にとっては本当にキラキラした、極上の知的エンターテインメント空間でした。そのような空間を作ってくださった、運営委員・ボランティアスタッフの皆さま、参加していただいた皆さま、そして協力してくださった多くの皆さまに、心から感謝です。

さて、イベントを終えておよべさんと振り返り的な雑談をしていたところ、

初参加や初心者にとっては、上手くいった成果よりも、上手くいかない状況下をどのように考えて乗り越えていったのかの方をより聴きたいかも

という話題になりました。

確かにそれは一理あるなと思いまして、我々の発表での「上手くいかない状況下をどのように考えて乗り越えていったのか」について、補足資料的にまとめてみました。

（参考）発表資料＆発表内容

プロポーザルと発表概要は、コチラになります。

発表資料はコチラです。

発表時のTwitterのタイムラインをまとめてみました。

上手くいかない状況とそれを乗り越えた例

1. 失礼なことを言われた時

正直いまでも、アジャイルやテスト自動化などに理解・関心のない人たちから、「あなた方の施策にメリットがあるようには思えない」「スキル不足をアジャイルという言葉で誤魔化しているだけでしょ？」などと言われることは、社内外関係なくあります。私は聖人君子からは程遠い人格なので、そうした言動に対しては、当然怒りやストレスは感じます。むしろ感じやすいタイプです。

しかし、怒りの感情に任せてこちらが暴れたりしたら、私たちを信頼してくれている上司・仲間を裏切ることになります。なので、怒りの感情をコントロールする必要が出てきます。

私の場合は、怒りを感じた場合は、すぐにその場を離れ、マインドフルネス呼吸で心を鎮めるようにしています。そして、心が鎮まってから、冷静な行動をするようにしています。ちなみにマインドフルネスは、継続していくと、ストレスへの対処能力・速度を高められます。ストレスへの対処は、スキルで伸ばせます。

私は下記書籍でマインドフルネスのスキルを日々高めています。

サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法

たった一呼吸から幸せになるマインドフルネス JOY ON DEMAND

2. SNSで愚痴りたくなった時

上記の例とも関連しますが、時には怒りをぶちまけたくなることは、人間ならばどうしてもあります。特にSNSが普及した昨今は、怒りをSNSにぶつけることも容易です。

しかし、SNSでの愚痴は、自身の経験から、却ってストレスを増やしがちです。

そもそもネガティブな感情を持っていることが友人・知人など不特定多数に伝わるため、彼らを心配させたり、場合によっては不快感を与える可能性が高いです。さらに、会社の仲間・上司との繋がりがある場合は、信頼を失い、より辛い出来事を招きかねません。

なので、そもそも愚痴りたい状況が出てきたら、SNSを止めましょう。「SNSデトックス」は、今の時代だからこそ必要です。

3. 勉強不足を感じたり指摘された時

特に私の場合は、技術力の高いエンジニアに囲まれて日々仕事をしているため、「自分が彼らの役に立つことができるのか」という自問自答は日々あります。また、技術的に分からないことが多いと、そもそも話をさせてもらえない人もいます。

したがって、勉強は常に続ける必要があります。私の場合はComputer Scienceの知識が足りなかったため、オンラインで大学の授業を受講できるCourseraを活用して、エンジニアと話せる知識を貯め続けています。

また、技術の世界的トレンドを追う一環で、私はInfoQの記事をなるべく読むようにしています。

4. 提案に理解を示してもらえない時

「Scrumの採用を提案したけれども、上司から却下されました」という話は、世の中に溢れていますよね。当然私たちも、似たような経験をたくさんしてきています。

この点については、私は明確な解を持っています。やったこともないことやろうを提案するのではなく、成果を先に出して追認してもらうのです。勝手に施策をやることを咎められることは確かにたまにありますが、成果が出るかどうか分からないものにゴーサインを出してもらうよりは、よほどスムーズです。

また、提案・説得を試みるエネルギーを、「サクッと見せられる成果」を出すことに転用することで、「何を見せたら納得できるのか」「どうやれば短期間で見せられるものを作れるか」という発想ができます。実はこれ、Scrumやアジャイルの練習と言えますよね。なので、練習を兼ねて成果を見せて上長らをびっくりさせて喜ばせた方が、仮に失敗しても、チームとして得られるものは大きいですよ。

他にも色々と工夫・アイデアはあるのですが、長年の積み重ねで習慣化してしまっていて、すぐパッと言語化できない状況です。言語化でき次第、また追記します。