少し寝ようかと思って横になった時間はあったものの、寝過ごすのが怖くて結局は新幹線の始発まで起きていた。この時期は4時を回り始めると徐々に外が明るくなっていき、5時は普通に明るくなっている。夏至も近い。

テックブログ公開

先日書いてレビューを終えた テックブログを公開した。

• Docker とは何か？

コンテンツは狙ってバズらない

私の言葉だ。多くの開発者が関心をもつ話題ではないけれど、仲間内では評判がよかったので拡散されると嬉しい、、、。と淡い期待を寄せていたが、そうでもなかった。工数をかけて丁寧に書いても関心をもたれないことはよくある。個々のコンテンツがバズらなくてもコンテンツは積み重ねることも大事なので私がよいと思う記事を今後も書いていく。

半年間の開発のふりかえり

2時間をとって半年間の開発のふりかえりをやった。課題管理システムから定量的な数字をみたり、定性的なのは、過去のマイルストーンのふりかえりのふりかえりをしたり、課題管理システムから特定の issue を取り上げて改善するにはどうしたらよいかなどを議論したりしてみた。

私もチームのファシリテーションに慣れてきて、自由に意見を求めるよりも、個人個人を指してどうですか？と尋ねる方が意見がわーっと出てきて議論が活発になることに気付いた。なにか議題があったら必ず当てられて意見を言わないといけないとメンバーも察してくれるようになっていると思う。そういう空気になってきた。そして、ちゃんと答えてくれるのでそれで問題ないと思う。大人しいというのか、消極的というのか、うちのチームのメンバーには意見を求められなければ言わないという姿勢が垣間みえる。これは開発の自律性とは反対にある価値観なのでなるべくそこから脱却して自分から議題に意見を言うようになってほしい。もしかしたら私が喋り過ぎなのかもしれない？

ふりかえりをしないチームは多いので何もしないよりはなにかしら 示唆は与えられた のではないかと思いたい。

今週は19時に帰ってきてそれから晩ご飯を食べて家でくつろぐという生活に戻ってきた。生活に余裕をもてるようになってきた。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。先週はリリース前の余裕の無さからお休みしたので1ヶ月ぶり。今日の議題はこれら。

• 第4期のふりかえり
• デザイナーさん向けの発注や契約の話し

先週末にふりかえり資料の叩き台を作って洗練させた資料を説明していたら1時間ほどかかった。もう3年会社を経営したので財務や経営についてわかったことがたくさんある。会社の貯金もある程度貯まって財務が安定してきた。無知の無知が怖かったので創業以来、財務に注意を払ってきた。しかし、これから業務がプロダクト開発へ移行していくに当たって財務のことを気にかける必要はないと私は考えている。そんな油断をしていると足元をすくわれるのかもしれないが。

業務委託の契約の話をしていて、請負契約と準委任契約の違いについて話題になった。うちは創業以来、準委任契約でしか働いてきていない。ipa が公開している 情報システム・モデル取引・契約書（アジャイル開発版） でもアジャイル開発は準委任契約を推奨している。私も開発プロジェクトに入って柔軟に開発するスタイルを好むことから相性がよかった。うちの会社は準委任契約のメリットを十分に理解できている。

準委任契約のメリット

• 成果物の取り決めがないので納期へのストレスや開発遅れに対するリスクが小さい
• がんばって働けば人月単価の金額が毎月売上としてあがる

準委任契約のデメリット

• 普通のサラリーマンと働き方がほぼ変わらない

はらさんと話していてとして請負契約の特徴として次のようなことが上がった。

請負契約のメリット

• 請負契約の方が儲かる可能性がある
• 自分たちが実際に作業しなくても協力会社に発注できる

請負契約のデメリット

• 成果物ができないと売上が上がらず利益率が悪化したり、赤字になるリスクがある
• 納品しないと売上が立たないので資金繰りが難しい

私の基本的な姿勢として協力会社に開発の業務を発注したくない。とくに品質レベルを知らない協力会社に発注することは100%ない。それは私が sier 出身なので他社へ開発を発注するときの難しさや管理のしんどさをよく知っているからだ。私が sier を辞めた理由の1つに自分がミスしたわけでもないのにお客さんに謝り続けるのが嫌になった。開発を他社へ依頼するとそこで発生した不具合やトラブルのすべての責任をもたないといけない。自分がミスして迷惑をかけて謝るのはなにも苦にならないが、他人がミスしたものを自分の責任として謝るのが当たり前の生活をやっていると、私の方がもっとうまくやれんじゃないかと考えてしまったりした。1人だと開発はスケールしないが、他人が品質の低いもの作ってしまうのと比べて開発の満足感が違う。

いずれにしても請負契約は双方に体力がないと資金繰りが厳しくなってお互いにリスクがある。

また資金調達の手段としてのクラウドファンディングは複数の側面があっていいんじゃないかという話題も少し盛り上がった。少し前に私もいとうさんのプロジェクトの応援のために支援した。800,000円という目標金額に対して残念ながら665,540円と未達ではあったものの、76人もの支援者がいることがわかる。私がクラウドファンディングのプロジェクトを作ってもおそらく支援者はよくて数人といったところだろう。いとうさんのメディア力であったり信用のすごさがわかる。クラウドファンディングやってますというのが支援することに関心がなくてもシェアするだけで開始前からマーケティングメッセージになる。そんなプロジェクトがあるんだというのを知ってもらうだけでも大きなことだと思う。

• 全国のコワーキングをネットワーク化しイベント情報の共有と収益の分配を実現したい！

開発合宿の計画づくり

昨年度に workcation と称して行ってきたイベントを今年度も行う。いとうさんから2泊3日のようなちゃっちいイベントをワーケーションと呼んだりしないと教えてもらったので今年は開発合宿と呼ぶことにする。タグも新規に camp に付け替える。前回は6月という閑散期に行って空いててよかったのだけど、今年は最も賑わうという冬の繁忙期に行ってみたい。夏と冬だと情緒も変わるはずなので私にとってどちらがよいかも判断してみたい。身近な人たちから声をかけて、昨年は4人だったが、最大13名泊まれるそうなのでもう2-3人ほど増えてもいいんじゃないかと思ったりしている。まずは日程調整からしていかないといけない。

• 冬の城崎温泉へようこそ！

18時から20時半ぐらいまで寝て、それから晩ご飯を食べに出掛けて、23時頃に戻ってきてまた寝て、4時に起きて、6時に起きた。出張の初日は不規則な寝方になる。

定例会議とふりかえり

リリースまであと3週間。一部の開発がまだ完了していないことに大きなストレスと懸念を感じつつ、進捗はしているそうなのでその対応が完了するのを待つ。いまは日々の進捗や発生する事象に注意を配りつつ、メンバーは QA レベルのテストを、私は淡々とリリースの準備をしている。外部からアクセスできるプライベートなコンテナレジストリを docker hub でお金を払うか、自社で運用するかの決めの問題や外部向けにドキュメントを公開するための決めごとなどを確認したりしていた。

毎月のマイルストーン終了後にふりかえりをしている。今月は対応した issue のうち、70%超を私が fix しているのであまり話題がないかなぁとか思っていたけど、全然そんなことはなく、活発にふりかえりのコメント (付箋に書く) が出てよかった。当初は付箋に書いた内容に対して関心のあるものをメンバーに投票してもらっていた。そして、メンバーの関心の高いマークがたくさん付いたものから掘り下げて聞くようにしていた。最近は3人でふりかえりをやっているため、すべての付箋をみていっても10個未満程度、すべてヒアリングしても時間がちょうどよいので投票をやめた。そうすると、メンバーが自分のやったことや思ったことを他者へ話す機会になっていて、これは内省を促す意図でとてもよいことじゃないかと思うようになってきた。

ふりかえりをしない人やチームは成長しない

これは私の持論だ。うまくいかなかったときにふりかえりすると、当事者が嫌な気持ちになったりしんどかったり、責任を感じたりとネガティブなイメージから、私の経験則ではふりかえりを行わないチームの方がずっと多かった。こういう小さい積み重ねを継続的にやるのは後になってその人の価値観や成長に影響を与えるのではないかと最近は思う。うちのチームでは厳しく責任追及はしないのでメンバーが率直的にこれができなかったとふりかえることはできるようになっているとは思う。

ふとふりかえりをしていてこんな言葉が私の口から出た。

作業の進捗をストリームとして確認できると嬉しい、ストリームを眺めているとメンバーが考えているのかどうかが分かる

エンジニアリング組織論への招待 に次のような節がある。

「悩む」と「考える」の違い

「考える」は行動であり、「悩む」は状態なのです。考えているのであれば、それはメンターがその行動を見ることができます。しかし、「悩む」であれば、メンターは心の状態を観察することはできません。

悩んでいる状態は手が止まっていて、頭の中で思考がぐるぐる巡っていて、もやもやしている状態。考えているとは、課題を書き出したり、分解したり、調査したりと忙しく行動していると言える。当然、考えないと優れた品質のアウトプットは出せない。正に私がやっている課題管理も、そのための課題管理システムも考えていることを確認・監視するために有効な手法とシステムであることが伺える。チームのふりかえりをしながら、そういった話しをメンバーに共有したりしていた。

1時に寝て5時に起きた。ホテルのテレビを付けっぱなしで寝たら朝のニュースで起きた。なんとなくニュースをみながら7時ぐらいまでのんびりしてた。

1週間のイテレーションはナンセンス？

毎月行っているマイルストーンのふりかえり。今回で3回目なのでメンバーもだいぶ慣れてきた。11, 12, 1月と3ヶ月に渡って課題管理をメンバーに実践してもらいながら開発してきた。当初、開発のイテレーションを1週間で行うか、2週間で行うかの話し合いで短い方がいいんじゃないかとなり、あまり深く考えずに1週間のイテレーションで開発をまわしてきた。しかし、いまとなってはこれは開発のイテレーションとは違うものになっている。

最初の1ヶ月はメンバーにとって慣れないワークフローだから、1週間のイテレーションでこの issue をやる・やらないといった厳密な取り決めはしなかった。その後、徐々に慣れてきたのを見越して、定例会議のときに issue 一覧をみながら、メンバーに2-3個ぐらいの issue をアサインしたり、issue の優先順位付けを明確にしたりしてきた。必ず issue を完了させるという強い制約を課していないものの、だいたい毎週アサインしたものをメンバーは対応してくれていたので、マネージャーとしての私の視点からもとくに問題はないようにみえた。要はうまくまわっているのでそれ以上の管理をしなくてもいい状態だったと言える。

一方で、本来の課題管理のイテレーションとは異なる開発のワークフローになっていて、それがよいことなのかどうか、私自身にも明確な答えがなかった。それでメンバーに尋ねてみた。いまの1週間単位のイテレーション (開発のワークフロー) をどう思いますか？

メンバーからは、1週間の作業内容を厳密に決めなくてもいいんじゃないかという意見が出た。それは私の考えとも一致していたものの、開発のイテレーションを2週間に伸ばすことについて話しているときに、そうしたとしても、定例会議は毎週やりたいという意見が出た。要件確認や仕様共有のために重要だという。通常、イテレーションの成果共有のために定例会議とイテレーションの長さは一致している。仮にイテレーションを2週間にしたら定例会議は2週間に1回となる。しかし、メンバーの視点からはイテレーションを1週間にするか2週間にするかについて関心はないものの、毎週の定例会議で行っている情報共有は重要だという認識があった。

ここで開発のイテレーションと定例会議の頻度は別にあわせなくてもいいんじゃないかと考えるきっかけを私は得られた。スクラムもスプリントと会議体の頻度はセットになっているのでこの発想はなかった。ちなみにアリエル時代は1つのイテレーションが3ヶ月で定例会議もなかった。そして、うちのチームは1ヶ月のマイルストーンに対してふりかえりをセットにしている。これはもはやイテレーション開発の文脈でいえば、実質うちのチームはマイルストーンと呼んでいる1ヶ月が1つのイテレーションになっていて、1つのイテレーション内に4回の定例会議があるというイテレーション開発のワークフローになっていることに気付いた。課題管理の考え方やワークフローがもっと洗練されていくと、毎週の定例会議をやらなくてもよいようになっていくのが私の経験から自明である。しかし、うちの開発は私も含めて8割以上がフルリモートワークなので、メンバー全員の顔を合わせる機会を作るという観点から毎週の定例会議は大事な場にもなっている。

実際の開発のマネジメントをしてみると、私自身、分かっていなかったことや新たな発見があって、まだまだ自分自身も修行の身であることを実感する。ここでの結論としてわかったことは次の通りで、ロードマップにおける最初のフェーズが完了する3月末までは現状のワークフローを継続してみることに決めた。

• 開発のイテレーションとして1週間は短過ぎて管理対象としてあわない
• 開発のイテレーションと定例会議の頻度をあわせなくてもよい
• フルリモートワークの場合、メンバー全員を集める目的は情報共有だけではない

0時に寝て何度か起きつつ5時に起きた。慣れないホテルでの就寝なのに昨日はバテバテだったから割と眠れた方だと思う。

ふりかえり

1ヶ月 (厳密には4イテレーション) をマイルストーンとし、マイルストーンを終えたらふりかえりを行う。前にスクラム開発で行っていたふりかえり手法をベースにしながらやってみる。ポジティブなふりかえり向けに fun/done/learn という手法がよさそうだったので採用してみた。ツールは jamboard を使った。

• ファン・ダン・ラーン(FDL)ふりかえりボード
• ふりかえりでFun! Done! Learn!

初めてやってみたので進め方そのものにいくつか反省があった。オフィスで大きいスクリーンに映してみんながみえるようにしながら jamboard にコメントを書き込んでいく同時作業が割と忙しかった。jamboard で付箋を書くときの操作性が微妙によくない。慣れの問題かもしれないけど、なにかあとひと押しの操作性が足りない気がする。

最初なのでやり方の例として私も付箋にコメントを書きながらやっていた。私が参加者の1人として振る舞うと進行が止まってしまって忙しくなることに気付いた。あとで付箋に対して「いいね」をつけて共有してもらうときに、私の役割が開発者としての振る舞いとファシリテーターとしての振る舞いが混ざってしまって、他の参加者がどう感じたかはわからないが、私自身がいま何をやろうとしているのか分からなくなるといった混乱をきたすことがわかった。ファシリテーターとしての私はメンバーの意見を聞いてまとめ役をしないといけない。しかし、開発者としての私が意見を発してしまうと、私の意見を私がまとめることになってしまい、その客観性を担保しているのかどうかが分からなくなってしまう。要は簡潔なまとめなのか、個人の意見なのかの見分けがつかない。ファシリテーターとして振る舞うときはメンバーとしての意見を言わない方が進行がやりやすくなることに気付いた。初めてやったときはこんなもんか。次回への反省につなげる。

やったことは、課題管理システムから自分が担当者の issue をフィルターして眺めればすぐに把握できるが、ネガティブなふりかえりの気付いたことや改善したいことを掘り返す方法がないことにも気付いた。マイルストーンが1ヶ月なのでどこかに記録しておかないと忘れてしまう。go のプログラミングにまだ慣れていないといった付箋がたくさんあったが、それ以外はもう覚えていないというのもあったと思う。忘れないための一時記録の仕組みを考えないといけないことに私自身が気付いた。

早めに帰ってきて晩ご飯を食べてからまたオフィスに戻って作業して2時に寝て7時半に起きた。

ストレッチ

今日の開脚幅は開始前153cmで、ストレッチ後155cmだった。先週よりは体力的に回復しているものの、今週も多忙で椅子に座っている時間が長かったので数値が悪くなっているのかもしれない。基本的には、お仕事が忙しい = 座っている時間が長い = 同じ姿勢の状態を維持する = 筋肉が固まったり運動不足に陥るという理屈で体調が悪化する。今週はなぜか右太ももの前あたりの張りが強かった。逆に腰や全身の負担は軽減したように感じた。開脚幅の数値はよくないものの、先週よりは復調しているような感触。実際のところはまだよくわからない。

ふりかえりとワークショップの定義からコミュニティ作りのなにか

書籍同様、タイムラインなどでみかけた記事を後で読もうと積ん読しておくときがある。次の記事もおそらく公開時期にみかけて気付いたら積ん読のまま1ヶ月が経過していたのを精読してみた。

• 価値発見に焦点化した振り返りワークショップの意義と、その教育学的分析

読み始めて、いくつかもの思いにふけりつつ、そこから派生して他の作業もしながら戻ってまた読み進めて、この記事を読むのに5時間かかった。そのぐらい私にとっては示唆のある読み応えのある記事だった。書いてあることのいくつかの点が他の事柄に繋がっていて、その点と線を確認しながら読み進めたので時間がかかってしまった。よくぞこの記事をブックマークしただけで流さなかったと過去の自分に感心したぐらいにはよい記事だった。ワークショップという言葉はよく聞く言葉ではないし、グループワークをする小さいセミナーのイメージを私はもっていた。教育学の分野の研究者によると次のような定義があるらしい。

ワークショップとは

• 講義など一方的な知識伝達のスタイルではなく、参加者が自ら参加・体験して共同で何かを学びあったり創り出したりする学びと創造のスタイル (中野民夫, 2001)
• コミュニティ形成 (仲間づくり) のための他者理解と合意形成のエクササイズ (練習) (仮宿俊文, 2017)

ちょうど課題管理の文脈でふりかえりをどう設計しようかを考えていたときにこの記事を読んだ。ふりかえりの目的を多義的に捉えるという発想そのものが私にはなかったのでそういった目的も含め、ふりかえりを実践していければよいのではないかと、自分の中にももともと燻っていた火種を見事に言語化してくれて示唆に富む記事だと感じた。

• 既存の業務に対する課題や改善の洗い出し (一般的なふりかえりの目的)
• チームのメンバーとコラボレーションする上で他者の考え方や意見を理解するきっかけの1つにする
• エージェンシーは自分一人では育まれず、同僚や上司、チームや組織との関係性の中で育まれる

ストレッチ

今日の開脚幅は開始前155cmで、ストレッチ後161cmだった。開始前の数値が悪いけど、とくに調子が悪いというわけでもなかったので計測の仕方がよくなかったか、たまたま足の開き方が悪かったかといったところだろう。昨日、高級時計と投資の話しを聞いたのでトレーナーさんとお金があったら何に使う話しが盛り上がった。トレーナーさんも庶民的な方でとくにお金があっても贅沢をしたいというものでもないらしい。私も改めてお金があったら何がしたいかを考えてみてもお金を使ってやりたいことはとくにないなというのが率直な思いでもある。私には自分がやったことのないことをやってみたいという思いしかなく、そのためにお金を使ってきた側面も多々あるけれど、お金を直接的に使って何かをやるというよりも、生活できるだけのお金があれば、その時間に自分がやったことのないことに挑戦して人生を楽しむということぐらいしかやることはないんだなと、トレーナーさんと話していて考えたりしていた。

os 雑談

午後から昨日の障害のふりかえりといくつか調査をして、夕方におがわさんに声をかけたら話し相手になってくれると返ってきた。障害のふりかえりをした後に課題管理の雑談もしていて4時間弱ぐらい話してた。私自身、反省しないといけないとは思っていたのでおがわさんはちゃんと指摘をしてくれた。この歳になると私を叱ってくれる人はいない。たまに失敗したときにおがわさんに話して然るべき指摘をしてもらえるのは本当にありがたい。

kubernetes がどうやって動いているのかを理解して運用しているのか？

コンピューターがどうやって動いているのかを理解しているのか？

私が未熟で理解できていなかったからこんな障害を見過ごしていた。システム障害が発生しても人生は終わりじゃない。反省してから次につなげる。おがわさんと話していて、os の仕組みや機能についていくつか教えてもらった。

• 制限対象の違い
  • ulimit はユーザーに対する制限
  • /proc ファイルシステムはシステムに対する制限
• /proc/sys/kernel/pid_max は kernel のデフォルト値として 32768 が設定されているが、systemd を使っていれば値を変更している場合がある
  • 私の ubuntu マシンだと 4194304 が設定されていた
• コンテナ内から /sys/fs/cgroup/memory/memory.usage_in_bytes をみると、コンテナが使っているメモリ量なのか？
  • cgroup の使い方次第で変わる、システムの値かもしれないしコンテナの値かもしれない
• ゾンビプロセスに残っている情報は親プロセスが子プロセスの統計情報を取得するために必要なもの
  • どんな子プロセスも一時的にはゾンビプロセスになる
  • kernel の task_struct 構造体やその他の構造体、リンクしている情報などをすべて足すと1つのゾンビプロセスが10数 KiB 程度ではないか
    • 仮に 15 KiB として 32000 個のゾンビプロセスがあると約 469 MiB のメモリ量になるのでだいたい数字があう
• ユーザー空間とカーネル空間の違いを理解できるようになった方がよい
  • システムコールの fork がエラーになるのはシステムがおかしいとすぐに気付けるはず
    • fork がエラーになる原因として考えられるのはメモリを確保できないか、pid_max に達したか、いずれにしてもエラーコードをみれば推測がつくのではないか
• 環境にログインできるのであれば strace を使えば障害調査に役立つ
  • 私が普段使っていないツールなので障害のときにとっさに扱えるよう練習しておく