アジャイルな見積もりを理解する「コース定数」という概念

アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。

特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。

そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。

「コース定数」でアジャイルな見積もりを考えてみる

国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。

山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。

交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべてです。仮に山行の半分の地点で体力切れをおこし、行くことも戻ることもできなくなれば、それは遭難となります。そのため、このコースは完走可能かどうかを事前の計画で見極める必要があります。 計画が重要でありつつも、実際の難易度や体力度は行ってみないとわからないという経験主義的な分野として、山行計画とソフトウェア開発の見積もりはよく似ています。

たとえば、わたしは近々、立山という山の縦走をしたいと考えているのですが、これが自分にとって完走可能かどうかがいまいちわかりません。インターネットでの山行記録を見ていても、「体力的にきつかったです」と書いている人もいれば「地元の小学生が遠足で登る山なので、初心者でも大丈夫です」と書かれていたりします。体力は人によってまちまちなので、各人の主観はあまり参考にならないのです。

そこで登山計画を判断する際には、客観的な「コース定数」という指標を用います。

「コース定数」とは、鹿屋体育大学・山本正嘉教授によって定義された、登山ルートの難易度を示す指標のひとつです。以下の計算式によって求められます。

1.8×行動時間(h) + 0.3×歩行距離(km) + 10.0×登りの累積標高(km) + 0.6×下りの累積標高(km)

わたしが計画を練っている立山の縦走のデータは以下です。

  • 標準コースタイム (行動時間): 7h
  • 歩行距離: 8.6km
  • 登りの累積標高差: 0.910km
  • 下りの累積標高差: 0.911km

これを計算式にあてはめると、24.8 という値になります。

この24.8というのが、コース定数になります。定数と表現されているのは、実際の山行ではこれに自分の体重や、荷物の重量なども加わるからです。日帰りの軽い荷物と、テント泊を想定した重い装備では同じルートでも体力度は異なります。なので、コース定数はそれらを除いたベースとなります。

さて、唐突に24.8 と言われてもなんのことかさっぱりわかりません。 ソフトウェア開発における相対見積もりで、基準タスクが5ポイント。今目の前にあるタスクは基準ポイントから相対的に考えて3ポイントと8ポイントなので、あわせて11ポイントです。と言われても最初はあまり意味がないのと同じことです。

ここで、実際の自分の経験が必要になります。 以下の表は、わたしが過去に経験したルートと、実際の山行記録をコース定数の算出式にあてはめたものです。

f:id:daiksy:20210817191826p:plain
山行実績

自分の今までの経験でいちばんしんどかった山は「荒島岳」という認識がありますが、それとこの表の結果は一致しています。 自分の経験からすると、30までいくとかなりきつく、20~25くらいであればほどよい疲れの山行、という認識です。

日常的にハードな山に良く行く人であれば、30くらいの山はひょいと登ってしまわれるでしょう。なので他人の情報にはあまり意味がありません。

さて、この表にあてはめると、わたしが計画している立山の24.8という値は、過去の摩耶山(黒岩尾根)のルートや摩耶山(天狗道)のルートに近いということがわかります。これらのルートを歩いた記憶を遡ると、ほどほどにきつくはあったけど、まだ余力を残した状態で山行を終えることができていました。なので、立山もおそらく無理なく走破できそうである、という見通しが立ちます。

この考え方は、アジャイルな見積もりにおけるベロシティの考え方と一致します。

ベロシティとは、チームがスプリント期間に消化することができるポイントの実績をあらわします。過去に1スプリントでチームが消化したポイントの実績値を積み重ね、直近数回分の平均などをとって算出します。 「3ポイントと8ポイントなので、あわせて11ポイントです」という見積もりの謎の数字は、このベロシティと組み合わせてはじめて意味を持ちます。

つまり、見積もりのポイントと、チームの過去の実績から算出した処理能力を照らし合わせて将来の見通しを立てていきます。

ベロシティが8ポイントのチームであれば、前述の2つタスクを終えるのに2スプリントかかります。ベロシティが13ポイントのチームであれば、1スプリントで終わらせることができます。隣のチームのベロシティが11とか20とか、そのような値に意味はありません。他人が有している登山に必要な体力が、自分の山行にとって無意味であるのと同じです。

これが、アジャイルな見積もりとベロシティの考え方です。このように身近な例で考えると、とてもわかりやすいですね。

専門的に学びたい方は以下の書籍がおすすめです。

デイリースクラムでの掛け声

会社でひとつのチームのスクラムマスターをやっていて、デイリースクラムがオンラインということもあってか、なんとなくだらだらと終わっていくのが気になっていた。

前職では、いつのころからかデイリースクラムの終わりに掛け声をやって終わるという流れだったので、それを今のチームでもやってみることにした。

具体的には、デイリースクラムの最後に、ぼくが「今日も1日がんばるぞー」と声をかけるので、メンバー全員がそれにあわせて両手をあげながら「オーッ!」と発声するというやつ。 こういうノリが苦手な人もいるだろうから、嫌なら反対してもいいよ、という感じで伝えると、とくに反対意見がなかったので続けることにした。

やってみると、やはりなんとなくメリハリが生まれて、元気になる気がする。

Twitterでそんな話をしているとこんなリプがあった。

なるほどボーイスカウト。スポーツの円陣なども同様であろうか。

「やる気」のメカニズムなども、ドーパミンによって人間はやる気を喚起されるが、このドーパミンは行動をしないと分泌されないので、ぼーっと待っててもやる気は出ない、という話を聞いたことがある。体を動かしたり、気持ちを無理やり奮い立たせて「やる気のようなもの」を生じさせるには効能があるのかもしれない。

こんな感じのチームで一緒に働きたい人は👇ここ👇をクリック(突然の採用活動)!

recruit.chatwork.com

エンジニアリングマネージャとして会社にジョインするのは難しい

新しい会社に入社して1ヶ月半経った。

今回はエンジニアリングマネージャとしてのポジションでの採用で、過去4回の転職はすべてアプリケーションエンジニアとしての採用だったので、その差分に若干戸惑っている。時勢的にフルリモートワークというのも大きい...。

"成果"が見えにくい仕事に対する実感をどのように得るか

まずひとつは、"成果"に対する手応えが異なること。エンジニア採用であれば、「入社最速RTA!!」などと言いながら、とりあえず小さなタスクを拾って入社後1週間以内くらいに自分の出した最初のプルリクエストがマージされれば、「最初のステップは超えた」という実感を得ることができた。

マネージメント職では、そのようなわかりやすい成果が見えづらい。そもそも、自分の打ち手が効果を発揮するのが翌月、みたいなリードタイムも珍しくないので、自分はちゃんと給料分働けているのだろうか、とまぁまぁ不安になる。そこで、上役の人やメンバーと1on1などで期待値コントロールを丁寧にやる、ということをして心の平穏を保っている。

また、入社後1ヶ月のタイミングで社内のグループウェアにふりかえりを書いた。これを読んでくれた人からも概ね好評だったので、続けていこうと思う。なんとなく自分のやった仕事を書き出してみると、「なんやかんやで結構仕事してるな」という認識が得られるので、これも心の平穏につながる。

観察と干渉のバランス

自分がメンバーだった時代、新しく採用されて就任したマネージャーの過干渉により、ハレーションが起きて大きなストレスとなったことは何度もある。チームの課題を解決するのが仕事なので、必要であればある程度意図的にチームにストレスをもたらす手法はないこともないが、昨今のサーバントリーダーシップの考え方とはそぐわないし、自分の好みでもない。

自分のチームに対する干渉が、チームとってストレスになっていないか、というのがとても気になる。逆に、それを恐れるあまり「あの人、何をするために雇われたの?」と思われてしまっても困る...。このバランスが難しい。

スクラムマスターとしてのトレーニングで身につけた考え方を活かして、当面は「観察」を重視している。このあたりのさじ加減は、いかんせん自分としても経験の少ないことなので、小さく失敗しながらやっていきたい...。(あまり失敗して良い分野でもないんだけど)

表に言える仕事内容

会社のイベントで登壇させてもらったり、ブログエントリを書いたりした。

lp.chatwork.com

creators-note.chatwork.com

こんな感じで、今の所元気に暮らしています。

登山のド素人が1ヶ月でテント泊をやるまでの道のり

コロナ前にたびたび集まって酒を飲んでいた友人たちと、このご時勢で集まれなくなったのだが、彼らはなにやら最近登山に熱中しているらしい。そんな様子をしばらく対岸から眺めていた。

事の起こりは3月の末。その友人たちと琵琶湖疏水を大津から蹴上まで歩くハイキングが計画された。長らくの在宅勤務の運動不足解消に、近頃は自宅の近所を1~2時間歩くなどをしていたのだが、毎回同じようなコースを歩き続けて飽きていたので、気分転換にとても楽しみにしていた。

そのうち、友人たちは疎水歩きの前座として2, 3時間ほど登山をするのだという。京都から大文字山を越えて大津まで行き、そこで自分と合流するのだとか。いったい登山とはそれほど楽しいものなのか。物は試しに、自分もその行程に混ぜてもらうことにした。

どうせやるならと登山靴とハイキング用ザックを買い、参加したその様子がこれである。

大文字山・如意ヶ岳・長等山 / だいくしーさんの大文字山(京都府京都市左京区)如意ヶ岳長等山の活動データ | YAMAP / ヤマップ

この登山のあと、さらに3時間ほど疎水沿いを歩き、当日はクタクタになったのだが、思いの外楽しかった。

さて、実はこのとき、自分はこれまで勤めていた会社を退職し、1ヶ月ほどの有給消化に突入するというタイミングだった。本当は思い切って日本縦断旅行などしたかったのだが、コロナの感染者数の傾向がどうにもきな臭い。そこで方針を変更し、この長期休暇で何度か登山をしてみようと思い立った。

最初に登ったのは摩耶山である。友人が公開している山行計画を頼りにルートを決め、その友人にルートをレビューしてもらいつつ行ってきた。

摩耶山 / だいくしーさんの活動データ | YAMAP / ヤマップ

これがとても天気がよく、歩いたコースもトゥエンティクロスという沢沿いを何度か渡渉しながら歩く楽しいコースで、また山頂で食べたカレーと生ビールが最高で、完全に登山のおもしろさにハマってしまった。

しかしこの摩耶山の山行は同時に課題の残るものでもあった。後半、バテてしまって、登山とはこんなにしんどいのか、という思いもしていたのである。どうやら、自分は街中を歩くのと同じ感覚で山道を歩き、余計な消耗をしていたらしいということがその後調べてわかった。

登山はいかにペースを保ちながら、長時間動き続けるか、という運動である。登りの際は歩幅を小さく、定期的に休憩しながら自分の筋力やスタミナの消耗を最小に保ちながら行動していく。

そうとわかれば、今度は「山の歩き方」を試してみたい。もう次の山に行きたくて仕方がなかった。

また、やるならせっかくの休暇だしとことんやってやろう、と1ヶ月の登山ロードマップを考えた。ゴールは、4月後半にテント泊をやること、である。

この日から、2, 3日おきに山に登り、山に登っていない日は梅田の石井スポーツでテント泊に向けたギアを買い集める、という暮らしがはじまった。

摩耶山に次いで須磨アルプスに行ってきた。

鉢伏山・旗振山・鉄拐山・高倉山・栂尾山・横尾山・東山 / だいくしーさんの活動データ | YAMAP / ヤマップ

前述の「山の歩き方」を練習する目的も兼ねている。 たしかに、歩き方に気を配るだけで疲労度が全然違うことがわかった。

これなら、六甲から有馬へ抜けるルートも歩けそうである。

この「六甲から有馬」というのは、六甲山を登る定番のコースである。阪急の芦屋川駅からロックガーデンを通り、六甲最高峰を登頂した後、有馬温泉へ降りる。距離にして14kmほど。コースタイムは約7時間という長丁場だ。

こんな長い距離を本当に歩けるのか不安だったが、須磨アルプスの様子だと行けるような気がしてきた。

飲料水や行動食、途中の食事のためにクッカーやバーナーといった調理器具など念入りに準備していざ決行。

なかみ山・六甲山 / だいくしーさんの六甲山なかみ山の活動データ | YAMAP / ヤマップ

これまで何度か旅行に行ったことのある有馬温泉へ徒歩でたどり着いた、というのが感動的で、大きな達成感を得られる山行だった。

こうなったらいよいよテント泊である。

ぼくが利用しているYAMAPというアプリには、いくつかの条件を達成すると獲得できる「バッジ」という機能がある。Playstationのトロフィー、Xboxの実績解除、みたいな遊びである。 その中に「六甲ハイカー」というバッジがある。これは六甲山系の決められた7つの山を登頂すると獲得できる。この六甲ハイカー獲得の登山を重ねながら、テント泊の準備を進めていく。

最初、金剛山の山頂近くのキャンプ場を目指した登山を考えていたが、金剛山は近畿では珍しい標高1,000mを超える山である。自分が実行を考えていた4月中旬は、天気予報によると気温が低めで、金剛山山頂付近は夜になると0℃近い気温になる日もあるという。

最初のテント泊でこの条件はすこし不安が大きいので、別の場所を探していると、金剛山より標高の低い生駒にも山上にキャンプ場があるらしい。そこを予約することにした。

テント泊は荷物が多い。テント、マット、寝袋、衣類、調理器具、食料などなどを60Lを超えるサイズのザックに詰める。衣食住すべてを背負って山を登るわけだ。自分の荷物をザックに詰めたところ、20kg近くになった。これには焚き火台やビールなど、登山には必須ではないものもたくさん含まれた結果こうなるわけだが...。必須装備だけに絞っても15kgくらいにはなる。

生駒山には石切から登る3時間ほどのルートを当初計画していたが、この重さを背負っての登山はどうなるか想像もつかないので、生駒駅から2時間ほどでキャンプ場に着く短いルートに変更した。結果的には、この重さを背負っての行動時間は、今の自分の体力では4時間くらいが限界、ということが実際歩いてみてわかった(キャンプ場からの帰りのルートでは山頂を経由する3時間のコースをとったことで感覚を得た)。

生駒山麓公園でテント泊登山(の練習)! - 鐃速日山・生駒山 / だいくしーさんの活動データ | YAMAP / ヤマップ

キャンプそのものはこれまでに何度か経験があるが、一人のテント泊登山はそれとは完全に別物だった。 自身の体力も含む、すべてのリソース配分は自分の責任で、なにかそこで致命的なエラーが生じると最悪下山もままならないことになるという緊張感がとても大きい。テントで寝るときにも、自分ひとりというのはとても心細く、ほとんどまともに眠れなかった。

このようにまぁまぁ過酷な体験ではあるのだが、それを凌駕する楽しさもあった。

キャンプそのものは普通に楽しいし、やりきった達成感も格別である。あの重量を背負っての山行の記憶を思い出すと今でも「二度とやりたくない...」という気持ちになるが、おそらく近いうちにまたやってるだろう。

その後、無事に「六甲ハイカー」バッジも獲得することができ、長期休暇の登山ロードマップは無事完走できたのである。

f:id:daiksy:20210428191948p:plain
1ヶ月で歩いた様子

なぜスクラムチームをスケールしたくなるのか

Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。

しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか?」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。

なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか?

そういうことを考えてみた。

最初から人がたくさん必要な場合

そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理想だが、世の中にはそんなわけにもいかないシステムはいくつかある。

大企業の基幹システムなどは、最初からそれなりのサイズでリリースしなければいけないものもあるだろう。当然リリースしながら育てていく漸進的なやり方はこういった場合でも有効ではあるが、いかんせん規模がとてつもなく巨大であるならば、それを現実的な工期で収めるにはどうしてもマンパワーがいる。このような開発現場でスクラムを採用する場合、スケーリングスクラムの手法は有効だろう。

しかしこれは楽な部類ではある。

最初から人がたくさん必要ならば、そのように組織設計をすればよいし、複数のフィーチャーチームを維持する前提でアーキテクチャを含めた全体設計が可能だからだ。 最初からわかっているのなら、そういう準備をしてから導入すれば良い。やればできる。

あとから人を増やしたくなる場合

厄介なのはこちら。

最初は1つのスクラムチームで開発を開始し、ローンチし、そこからさらに継続的に開発する。そのようなチームをスケールしたくなる場合。 「我慢しろ。スケールするな」が1つの答えではあるのだが、なかなか現実はそのようにうまくいかない。

6人のスクラムチームが8人になる。さらに人が増えて10人になる。このあたりからスクラムチームの維持は難しくなる。では5人のチーム2つに分割するか? しかしこの段階ではチームを分けたことによって生じるコミュニケーションパスの増加による負担が、チームのスケールメリットに見合わない。システムのアーキテクチャも、チーム分割に耐えられるようなスケーラブルに設計になっていない。

こういう感じでどんどんチームは追い詰められていく。

ではそもそもなぜチームは人を増やしたくなるのだろうか。作業の優先順位を適切にコントロールして、やるべきことを厳選すれば1つのスクラムチームでの開発を維持できるのではないのか。

やりたいことではなく、やらないといけないこと、が増えてくる

長期間ソフトウェアを運用し、そして幸運にもその事業が成長した場合、チームとしてやりたいことよりも、「やらないといけないこと」が少しずつ増えていく。

たとえば、ユーザーの増加に伴ってカスタマーサポートの負荷は少しずつ増えていく。ソフトウェアのサポートには、当然場合によってはエンジニア稼働も必要であるから、そのような仕事がちょっとずつ増える。

技術的負債も積み上がる。もちろん、定期的に返済したり、そもそも負債が生じにくいように注意深く開発はするのだが、それでもシステムのスケールに伴ってこれらへの対処は増えていく。5年以上稼働しているシステムであれば、スプリントバックログには常時なにかしらの負債返済のタスクが入っているだろう。

こういう「やらなければならないこと」に少しずつ圧迫され、「やりたいこと」に振り分けるリソースはちょっとずつ減っていく。なので、ちょっとずつ人を増やしたくなる。

急激に事業が成長して、一気に人を増やさなければならない、という状況ならまだ幸運かもしれない。諦めもつくし、一気にスケールすればスケールメリットがデメリットを上回ることもあるだろう(それはそれでカルチャーの維持とか、組織づくりとか別の厄介事はたくさん生じるが、これはスクラムチームの話なのでそういうのは今は忘れておく)。

このような事態において、歯を食いしばって「1つのスクラムチームを維持する」良い方法はあるだろうか。 そもそも事業が成功しているなら、人(雇用)を増やして幸せを大勢の人と分かち合いたい、という動機もあるんじゃない?

こうして、ぼくは今日も出会うアジャイルコーチに質問するのである。「スクラムチームをスケールするにはどうしたらいいですか?」

なにかいい方法があったら教えて下さい。

2020年のふりかえり

今年でいよいよ後厄が終わります。コロナなどでたいへんな一年でしたが、公私ともに充実した良い一年でもありました。

去年はこんな感じでした。

daiksy.hatenablog.jp

買ってよかったもの

例年はあまり「買ってよかったもの」と言われてもピンとこない生活を送っていますが、今年は就業環境をリモートに本格的にシフトさせ、そのために身の回りを整えました。

その1. 昇降デスク

緊急事態宣言以降ずっとリビングで仕事をしていたのですが、メンタル的にも限界を感じたので意を決して買いました。

気分によって、スタンディング、バランスボール、椅子など仕事のスタイルを切り替えられます。

個人的にはふりかえりなどのファシリテーションをするときは、立ってやるとなんとなく気合が入ってやりやすいです。

その2. セイルチェア

昇降デスク購入後、一月くらい立って仕事をしていたのですが、やはり疲れるので椅子を買いました。なにげに今年最も高額な買い物かもしれません。

家にオフィスチェアを置くと、なんとなく見た目のバランスが悪い気がしていて躊躇していたのですが、知人のデザイナーさんが家に置いても違和感がない、とツイートされているのを見て買いました。

次の写真が在宅ワーク環境完成形です。

f:id:daiksy:20201229124838j:plain
こういう環境で仕事してます

その3. PS5

すべての抽選に外れまくって当分入手は無理かと諦めていたのですが、縁があって正規価格で入手できました。 開封した瞬間、目の前にある製品の実在が信じられないやら嬉しいやらで膝がガクガク震える、というこれまでの人生になかった反応を身体がしめし、不思議な感じでした。宝くじに高額当選した人とかもこういう気持ちになるのかもしれません。

月別のふりかえり

さて、月別の活動のふりかえりです。

1月

コロナ禍以前の生活がどうだったか、もうあまり思い出せませんね...。ほとんど記憶がありません。カレンダーを見ても別に特別なことはしていなさそうでした。

2月

デブサミに登壇しました。もともと公募セッションに申し込んだのですが、セッション内容が先方のもともとのタイムテーブルの構想とマッチしたということで、招待講演枠に移動するという特殊な感じでした。

今年はこれをきっかけにさまざまな執筆やオンラインイベントのお誘いがありました。特に今年は、その後の執筆活動によって、自粛生活の中でも一つやりがいのある仕事が得られてメンタル的にもずいぶん助けられることになります。この機会がなければ今年1年の生活はずいぶん違ったものになっていたかと思うと、少しぞっとします。

event.shoeisha.jp

speakerdeck.com

このデブサミが今年自分が参加したリアルに人が集まる形式の最後の登壇になりました。

この数日後、PIXIV TECH FES. に招待いただいていたので参加してきました。

conference.pixiv.co.jp

デブサミ -> PIXIV TECH FES 参加ため、土日を挟んで数日間東京に滞在していました。ちょうどコロナウィルスの市中感染が広まりはじめたころで、せっかく土日を東京で過ごしていたのに、なにやらおそろしくて1日中ホテルに篭もっていました。

PIXIV TECH FES. も懇親会が中止になり、その翌週からは他のイベントも次々と中止。今思えばギリギリのタイミングでした。

3月

デブサミの講演をご覧になった技術評論社の方からコンタクトがあり、編集者さんと一緒に目次を作り始めました。最初はデブサミの講演内容をそのまま記事化する予定でしたが、何度か編集会議でフィードバックをもらい、最終的に「障害対応演習」に絞った記事になっていきます。

このあたりの時期から会社にはほとんど行かずに、それ以降ずっと在宅勤務が続いています。

4月

オンライン飲み会をやりはじめたり、それに高速に飽きている様子がカレンダーから伺えました。

5月

EM.FMに出演しました。Podcastの出演はなにげにはじめてかもしれない?? 激変する周辺環境をどうマネージメントするか、みたいな話をしていました。

anchor.fm

こちらもデブサミの記事がきっかけで、ProductZineというCodeZine内に新設されたメディアの記事を書かせてもらいました。 編集者さんとのMTGの末、会社として連載枠をいただき社内でのキュレーション活動などもやっていました。

codezine.jp

Findyのメディアにお声がけいただき、自分のキャリアについての記事を書かせていただきました。

engineer-lab.findy-code.io

ちなみに、これまで原稿料をいただいて書いたWeb記事で、100ブックマークを下回ったことはまだないのが密かな自慢です。

6月

認定スクラムプロダクトオーナーを取得しました。

f:id:daiksy:20201228111327p:plain

スクラムフェス大阪で登壇しました。 オンライン登壇なので少し変わったことがしたいと思い、チャットに寄せられる質問やリアクションにリアルタイムに反応しながら講演する、というのをやってみました。まぁまぁうまくいった手応えがありました。

www.scrumosaka.org

speakerdeck.com

7月

冬に続いて、夏のデブサミにもお声がけいただきました。前述のProductZineのつながりで、3人のリレーセッションでした。

event.shoeisha.jp

speakerdeck.com

8月

デブサミ関西にもお声がけいただき、1年で3回デブサミに登壇するという光栄な経験をさせてもらいました。 一般参加者として講演を仰ぎ見ていたあの頃の自分にこれを教えたら、たぶん信じてもらえないでしょう。

関西在住のエンジニアのキャリアについてのパネルディスカッションでした。 コロナによって奇しくもリモートワークが浸透し、それによって地方からでもさまざまなキャリアのチャンスに巡り会えるのではないかと期待しています。 自分自身、関西にこだわって暮らしているのですが、もしあのときに東京に行っていたら、今よりも高い年収になっていたのかもなー、などと妄想することは今でもあります。

将来、人々がまた自由に行き来できるようになったとしても、地方に住みながらにして良いキャリアが選び取れるような世の中は進んでほしいです。

event.shoeisha.jp

9月

夏のデブサミのセッションが好評で、それの再演ウェビナーがありました。

codezine.jp

去年に引き続き、文科省のenPiTという事業のお手伝いをしました。

aibic.enpit.jp

10月

3月から準備していた特集記事がついにお目見えしました。 おかげさまでたいへん好評のようで嬉しいです。

WEB+DB PRESS Vol.119

WEB+DB PRESS Vol.119

  • 発売日: 2020/10/24
  • メディア: Kindle

daiksy.hatenablog.jp

11月

あまり記憶がない...。

12月

去年からお手伝いしていた仕事がようやくお目見えしました。

daiksy.hatenablog.jp

来年のこと

1月発売の某雑誌にむけて実は記事を書いており、先日入校されました。また、春頃に発売される予定のとある書籍のお手伝いもしています。 このように今年はコロナの影響もあって例年より登壇やイベント参加は少なかったのですが、執筆関連の仕事が多くて家で自粛生活を続けつつもおかげで充実して過ごせていました。

これらの仕事が無かったら、たぶんめちゃくちゃ気が滅入っていたと思うと自分はとても幸運だったなと思います。

これらは2月のデブサミの講演がひとつのきっかけだったり、2019年からの仕込みだったりします。それらの仕込みはすべて使い切ってしまったので、来年は特に大きな予定もなくすこし不安な気持ちを抱えているのも事実です。

そのようなこともあり、自分のキャリアを落ち着いて見つめつつ、また大きめのチャレンジなどしていけたらなと思っています。

『わかばちゃんと学ぶサーバ監視』監修の裏話

12/22(火)に発売の書籍、『わかばちゃんと学ぶサーバー監視』と、それに先駆けて本の前半部分を技術書典で頒布した『マンガでわかるサーバー監視入門』を監修させていただきました。

わかばちゃんと学ぶ サーバー監視

わかばちゃんと学ぶ サーバー監視

  • 作者:湊川あい
  • 発売日: 2020/12/22
  • メディア: 単行本(ソフトカバー)

ここでは本の宣伝をかねて、監修って何をやったの? みたいな裏話を書こうと思います。

きっかけは?

ぼくは普段Mackerelというサーバー監視SaaSの開発チームのディレクターをしています。あるとき、著者の湊川さんと出版社の編集者さんから監修のご相談をいただき、お引き受けすることになりました。扱っているプロダクトの性質上、半分仕事みたいなものなのですが、仕事自体は個人でお請けした仕事という形です。

湊川さんからいただいたお話は、当初からMackerelを中心に据えてサーバー監視を説明する本にしたい、ということでした。しかしながら、これはMackerelの宣伝本ではなく、あくまでもサーバー監視についてわかりやすく説明する本にしたいという意向をお持ちで、その点についてはぼくも大いに共感しました。なので、Mackerelを取り上げている本をMackerelのディレクターが監修するという難しい立場ではあるものの、できる限り他のツールの紹介なども含めたフラットな視点になるように心がけました。

監修ってなにをするの?

基本的に構成や執筆は著者の湊川さんが進められていました。ぼくは湊川さんが作られた構成や原稿を確認し、誤りや気になる部分があれば指摘をしたり、湊川さんから質問が寄せられた場合はそれについて調査したり回答をする、という感じでした。

実はほんのちょっとだけですが、原稿の執筆もやらせてもらっています。特にどこがぼくの担当かは明記していないので、探してみて、ここかな、という箇所が見つかったらこっそり教えて下さい。あってるかどうかお答えしますw

あと、マンガの中に一瞬だけ登場したりもします。

f:id:daiksy:20201221175719p:plain

執筆前の事前の打ち合わせで湊川さんにお話したエピソードをマンガにしてもらいました。そういう意味では広義の意味では漫画原作者と名乗ってもいいかもしれません(名乗りません)。

難しかったポイント

今回、監修という立場で本の制作に携わるのははじめてのことだったのですが、やってみるとけっこう難しかったです。

単に内容のファクトチェックだけであるなら、そんなに悩むことはないのですが、ファクト的には正しいが、自分だったらこうは書かないな、という箇所を指摘するべきかどうかで悩むことが多かったです。

とくにこの本はマンガがベースになっていることもあって、湊川さんの解釈や表現をできる限り尊重したいというのを常に考えていました。湊川さんから見れば自分は専門家であるので、自分が指摘してしまった箇所について、著者さんの立場としてはそこは修正しようという向きに強くベクトルが働くだろうと考えました。なので、あまり細かく指摘しすぎてしまうとせっかく著者さんが自ら勉強されて得られた解釈を損ないかねません。ですので、ファクト的に正しい場合はあまり細かいことは指摘せずに、なるべく著者さんが書かれたテイストを守ることを優先しました。マンガはそのほうが絶対に楽しいものになると思ったからです。

ただ、マンガである前に技術書でもありますので、この件を言い訳にするつもりはもちろんなく、監修した自分にも当然責任はあると思っていますので、厳しいご意見などあればぼくの方に伝えていただけたらと思います。

とはいえ、技術書典で公開いただいた前半部分はたいへん評判がよく、そのテイストは後半部分にも続いていますので、最近のサービス監視について概観を得られる充分な読み応えのある内容になっているという自負はあります。

間違いなく読んで楽しい本になっていますので、ぜひお手にとっていただけたらと思います!

わかばちゃんと学ぶ サーバー監視

わかばちゃんと学ぶ サーバー監視

  • 作者:湊川あい
  • 発売日: 2020/12/22
  • メディア: 単行本(ソフトカバー)