2021年振り返り

サマリ

  • 体重が100kg から 79kgに減量成功。目標BMI値の人と同じ食事を取り続けるとそこにBMIは収束するらしい。
  • youtubeはじめた。チャンネル登録よろしくね!!
  • バイクを趣味にした。バイク免許を小型自動二輪(8月卒業)、普通自動二輪(10月卒業)、大型自動二輪(12月入校)
  • 納車を1年で3回経験し、納車中毒に。納車のUX最高。好きな単語は納車。今年の1年を表す単語は納車。

仕事

1月にRegional Scrum Gathering Tokyo 2021にてカネとAgileという登壇をしました。

5月に新入社員向けの研修資料公開。新人のとき聞きたかったといわれた話を新人向けにしました。

事業価値とエンジニアリング。

会社のアドベントカレンダーに以下を投稿しました。

大事ではないことを大事だと錯覚した結果、オーバーエンジニアリングになる i2key.hateblo.jp

健康

6月に緊急入院。健康診断で血糖値が異常値を叩き出す。食生活の改善と運動を始める。

食事はBMI22の人の食事を朝昼晩徹底することで、I/Oのバランスがとられるところまで収束させていく設計で摂取(開始時BMI30)。目標BMI値の人の食事をとっているとそこに収束するらしい。半信半疑であったが。とりあえず、栄養士に言われたとおり食品群は全てをバランスよく食べることを徹底。1日1900kcal。米は1日160g×3。魚類1日120g。肉類1日90g。卵1日50g、大豆豆腐系1日200g。乳製品1日180g。野菜1日360g。油脂類1日20g。塩分は1食2g。などなど。運動は食後の血糖値上昇を緩和させるために食後15分後に30分実施。また、会議中もひたすら自転車をこぐことを徹底。fitboxを購入。テレワークに最適。

結果的に、BMI22の人の食事を取り続けて、ひたすら自転車こいでいたら、本当にBMI30→BMI22まで減った。今食べているものから何かを削るという思考ではなく、目標のBMIの人の食べている食事を取り続けるほうがゴールからプルしている状態になり、理に適っているという知見を得た。そして、20キロの脂肪を纏っていた体から卒業し、冬が寒いということを知った。 f:id:i2key:20211231175334j:plain

youtube

友人とyoutubeはじめました。プロダクト開発をしていると良く聞いたり使う言葉。でも、よく考えると意味が分からない。そんな言葉を、自分たちで勝手に定義してみようとはじめました。 あくまで、勝手に定義しているだけなので、本当に正しい定義かどうかは分かりません。でも、定義する途中でプロダクト開発の奥深さや楽しさを少しでも共有できたらなと思っております。

オーバーエンジニアリングついて。

PIMBOK第7版について

技術的負債について

システムってなんだ?

生産性とは

俺のプロダクト開発用語辞典 www.youtube.com

1月に人生初の車購入。見に行って翌日契約。BMW MINI F56 cooper。かわいい。おしゃれ。なお、運転の感覚がゴーカートフィーリングと言われているらしいが、そのフィーリングを感じるほどの感度はもっていない。

バイク

趣味が海外旅行(30カ国以上行っている)とゲームだったため、海外旅行がコロナで封じられ外に出る理由がなくなってしまった。なんとなく見ていたTOKYO BB / TOKYO BB returnsというyoutubeに触発されバイク買ってみようかなと。強制的に外出することになる趣味を作るのよいかもなーと。で、なんか、今ハンターカブってのが流行っているらしい。youtubeでいろんな芸能人がこぞって買い始めているようだ。ということで、7月、免許取得前にHONDA ハンターカブ購入(youtubeが購買活動へ作用するというマーケ効果を肌で感じた)。8月に二日間で小型自動二輪(AT)教習&免許取得。排気量125cc。

試しに秩父にいってみたところ、公道60km/hでエンジンが悲鳴を上げており、更には秩父の山の坂道も相当キツく、排気量に物足りなさを最初のツーリングで味わい翌日には普通自動二輪(MT)の教習所に入校。排気量400cc。

9月(普通自動二輪の免許取得前に)BMW G310GS購入。10月にハンターカブ売却(ほぼ買値で売れた)。普通自動二輪(MT)教習。免許取得。排気量400ccにランクアップ。11月、BMW G310GS納車。

これで、高速道路にのれる。ということで、高速道路走行をしてみたら、80km/h巡航はまったく問題ないのだけど、それ以上の速度になるとエンジンが悲鳴を上げ始める。エンジンが頑張ってる感すごく出てくる。なんかすごく心理的なストレスがかかる。ということで、帰宅後に大型自動二輪(MT)教習所入校。2022年1月から教習開始。

一年で納車を3回やってると納車中毒みたいになる。好きな単語は納車。好きなUXは納車。引き続き来年も納車していくために頑張っていきたい。

大事ではないことを大事だと錯覚した結果、オーバーエンジニアリングになる

本ブログは Recruit Advent Calendar 2021 - Adventarの25日の記事になります。

ITビジネスやサービスにおけるプロダクト開発で良くある、作りすぎ。やりすぎ。

無駄なく、効率的にと思っても、ついつい発生しちゃう。

こういうの、オーバーエンジニアリングって言うらしいよ!?

でも、どこからオーバーで、どこまではオーバーじゃないんだ!!

ということで、勝手にオーバーエンジニアリングを定義してみようと思います。

作り過ぎて、時間や金を無駄にすること????

とっかかりとして・・・まずは一般用語としてのオーバーエンジニアリングの意味をwikiで調べてみると以下のように記述されています。

wikipedia(英語版) Overengineering - Wikipedia 一部抜粋。

Overengineering (or over-engineering,[1] or over-kill) is the act of designing a product or providing a solution to a problem in an overly complicated manner, where a simpler solution can be demonstrated to exist with the same efficiency and effectiveness as that of the original design.[2] Overengineering differs from Planned Obsolescence which seeks to alter a design to produce an artificial limit on a product's lifespan or otherwise make it unfashionable. Overengineering is often identified with design changes that increase a factor of safety, add functionality, or overcome perceived design flaws that most users would accept. Overengineering can be desirable when safety or performance is critical (e.g. in aerospace vehicles and luxury road vehicles), or when extremely broad functionality is required (e.g. diagnostic and medical tools, power users of products), but it is generally criticized in terms of value engineering as wasteful of resources such as materials, time and money.

wikipedia(英語版) → DeepL

オーバーエンジニアリング(またはオーバーエンジニアリング[1]、オーバーキル)とは、製品を設計したり、問題の解決策を提供したりする際に、元の設計と同等の効率や効果を持つ、よりシンプルな解決策が存在することを証明できるのにもかかわらず、過度に複雑な方法で設計することである[2]。 オーバーエンジニアリングは、製品の寿命を人為的に制限したり、流行遅れにしたりするために設計を変更しようとする計画的陳腐化とは異なります。オーバーエンジニアリングは、安全率を高めたり、機能を追加したり、ほとんどのユーザーが受け入れるであろう設計上の欠陥を克服するような設計変更と同一視されることが多い。 オーバーエンジニアリングは、安全性や性能が極めて重要な場合(航空宇宙用車両や高級ロードカーなど)や、極めて広範な機能性が要求される場合(診断ツールや医療機器、製品のパワーユーザーなど)には望ましいが、バリューエンジニアリングの観点からは、材料や時間、お金などの資源を無駄にしていると一般的に批判されている。

大事そうなものを赤字にしましたが、つまりは、やりすぎてしまった結果、リソースや時間、お金などの資源を無駄にしているって読み取れます。 また、青字の部分は、逆に性能オリンピックになっても問題ないというか逆にそれが望ましいケースもあるよ。といってます。 とはいえ、私が携わっているITビジネスにおいては、どちらかというと赤字側の文脈が強いですが、全体的には良いことなのか悪いことなのかよくわからないですね。

ただ、どうやら本当に必要だったものに対して、なにかオーバーなやりすぎが発生してしまい、全体として当初想定していたものよりはブクブク膨れ上がる感じ。 そんなイメージ。

いろいろなことがあって膨れ上がる

膨れ上がるといっても、いきなりドカンと倍になるとかそういう話ではない気がしていて、徐々に・・・、何かいろいろなことがあって、本当に必要だったものよりも大きくなってしまうんだろうなと。 こんなイメージです。

f:id:i2key:20211221142811p:plain

いろいろなことがあるんだけど、そのいろいろなことが発生するタイミングはシステム開発のケースでいうと各開発工程において発生している気がする。なお、多くのことをまとめて一括でやるようなウォーターフォールと言われているようなケースや小さく1つずつクルクル回してやっていくアジャイルと言われているようなケース、いろいろあると思うけど、一般的にV字の工程はどれもやることは同じであるため、便宜上ひとくくりにして表現しています。

f:id:i2key:20211221143338p:plain

では、いろいろなことがある、色々ってなんだろう?を列挙してみる。あくまで全てではないけど、開発の現場にいるとよく遭遇しそうなあれこれ。

f:id:i2key:20211221143956p:plain

例えば・・・・・

  • 要求定義

存在しないユーザを想定して、仕様を増やしちゃう。そもそもそんなユーザーはいないかもしれないのに、脳内に存在する実在しないペルソナに対して仕様を増やしにいってしまう。

  • 要件定義

大事な気がする仕様が問題になって、更なる解決が必要になっちゃう

  • 設計

将来に備えようとして、備え過ぎちゃう。拡張性とか柔軟性とかを過度に必要だと思い盛り込んでしまう。備えること自体は良いのだけど、、、、備え過ぎてしまう。

必要以上のレビューや文書化といったプロセスを行ってしまう。誰が見るんだっけ?それ今後も使うんだっけ?みたいな。

  • コード

全体の性能ネックではないところが、大事な気がして高性能にしちゃう。別にそこシステム全体からみたらボトルネックじゃなくない?とか。

  • テスト

直さなくて良いバグを直しちゃう。リスクに対する考え方や事業のコンテキストにもよるけど、目についたバグを全て確実になおしてしまう。とか。

大事だと錯覚してしまう

もういちだん、解像度を高めるために要件定義を例に深ぼってみます。

大事な気がする仕様が問題になって、更なる解決が必要になっちゃう の深堀り

f:id:i2key:20211221151835p:plain

例えば、「ボタンAを押したらベローンとなる。」という要求があったとして、、、このときの要件は「(システムは)ボタンAが押されたらベローンとする。」と定義されたとする。ただ、このときにベローンとするとボタンBが隠れてしまうという問題が起きる。こういうことありますよね。要件を実現するのに障壁となる問題が発生するケース。現実世界では、こんなベローンとしたら隠れちゃいましたーみたいなしょぼい話ではないと思うのだけど、あくまでわかりやすくという意味での極端な話として。

f:id:i2key:20211221153306p:plain

こうなると要件実現のためにこの問題を解決しないといけない。ということで新たな要求がここで発生する。「ベローンってなってもボタンBを押せるようにしたい」って。これがすごく現場で発生してる気がする。で、その新たら要求に対して、新たな要件がうまれる。「ベローンのときはボタンBを右へずらす」。そして、ベローンのときにボタンBを右にずらすと・・・・・「ボタンBが画面からはみでちゃう」という新たな問題が発生・・・・。

f:id:i2key:20211221153912p:plain

同じようにこの地獄の構造は続いていく・・・・。何かを作ろうとしたら、それを作るために何か問題が発生して、それを解決するために新しい要求が生まれて・・・・の連鎖。もりもりやることが膨れ上がっていく。やりすぎてる感ある。

これを発生させないためにはどうすればよかったのだろうか???

「ボタンAを押したらベローンとなる。」という要求定義の時点で、「ただし、ボタンBは隠れないようにする。」とまで定義しなければならなかったのか。しかし、そうなると、起こりうる問題を事前に全て想定しきらないとならないというなかなかの無理ゲー感がでてくる。ベローンくらいなら想定可能だと思うけど、実際は、影響範囲を全て把握した上での最強の要求定義要件定義をすることになるのは、あまり現実的ではない気もする。

では、これはなるべくしてなるオーバーエンジニアリングなのだろうか・・・・。

そうではない気がする。 そもそも要求に立ち返って考えたときに、「ボタンAを押したらベローンとなる」は、本当にベローンとしたかったのか。何かの得たい情報がベローンと表示されていればよかったのかもしれない。仮に「ボタンAを押したら画面上にホニャララって情報が表示される」みたいな要求であれば、この問題は起きなかったのかもしれない。要求の段階で「ベローン」(HOW)を指定してしまったがために、それ以降の工程では、「ベローン」は大事なものに見えてしまい、要求を受けた側はそれをどうしても実現せねば。となってしまっているように見える。要求を出した本人は、なんとなく「ホニャララ情報をさ、ベローンって感じでもいいから、なんかだしてよ」という温度感であって、ベローンにこだわりはなかったのだけど。みたいな。

f:id:i2key:20211221160217p:plain

これをシャープに言語化すると、要求に手段が混じってしまっているが故に、その手段が重要だと思ってしまった。と言える。

そして、最初の問題以降の淡い青色の部分は全てそんなに重要ではないベローンに向き合ってしまったことになる。そこの問題をどんなに解決してもそもそも重要ではないというか。意味がないというか、、、、つまり、、、、無駄。問題発生時に、要件に対して、「じゃあ、ベローンじゃなくて、ペロンでよくね?」で発生しなかった話であり、ベローンが重要だと錯覚してしまったことが全てのはじまりなのかもしれない。 要求の段階で「ボタンAを押したらベローンとなる。(けど、ベローンは実はそんな重要じゃないです。こだわりも1ミリもありません。)」ってなっていたら「あ、これそんな大事じゃないだwww」ってなりこれは錯覚を防げたのかもしれない。濃淡の話。

つまり、・・・・本来は大事じゃないものを大事だと錯覚した結果、作りすぎて(やりすぎて)、時間や金を無駄にしてしまう。ということなのかもしれない。

無駄は錯覚によってうまれる

上記での錯覚がオーバーエンジニアリングを引き起こしているのでは?という気づきをもとに、前述の各工程毎に出した「いろいろあって」もりもりやることが膨れ上がる例に対して、「ほにゃららだと錯覚してしまう」という表記にしてみると・・・・。

f:id:i2key:20211221161725p:plain

  • 要求定義

存在しないユーザを想定して、仕様を増やしちゃう。そもそもそんなユーザーはいないかもしれないのに、脳内に存在する実在しないペルソナに対して仕様を増やしにいってしまう。

→ 大きな少数の声が、全体であるかの様に錯覚してしまう。

  • 要件定義

大事な気がする仕様が問題になって、更なる解決が必要になっちゃう

→ HOWが大事であると錯覚してしまう。 (さっきのベローン)

  • 設計

将来に備えようとして、備え過ぎちゃう。拡張性とか柔軟性とかを過度に必要だと思い盛り込んでしまう。備えること自体は良いのだけど、、、、備え過ぎてしまう。

→ 数年後の状態が、明日くらいに錯覚してしまう。 (5年後には1億ユーザーなんだけど、なぜかそれが明日だと思ってしまった。みたいな。流行ってから悩めばいい系。)

必要以上のレビューや文書化といったプロセスを行ってしまう。誰が見るんだっけ?それ今後も使うんだっけ?みたいな。

→ 取捨選択が重要なのに、教科書に書いてあることは、全部やるのが正しいと錯覚してしまう。 (文脈を意識してない型に当てはめるタイプのやりかただと起こる感じ。目的意識不在のプラクティス全部盛り的な。)

  • コード

全体の性能ネックではないところが、大事な気がして高性能にしちゃう。別にそこシステム全体からみたらボトルネックじゃなくない?とか。

→ 起こるかもしれないことは、全部起きると錯覚してしまう。

  • テスト

直さなくて良いバグを直しちゃう。リスクに対する考え方や事業のコンテキストにもよるけど、目についたバグを全て確実になおしてしまう。とか。

→ 目の前で起こった問題は、全部大問題と錯覚してしまう。 (冷静になって考えると大した問題じゃないのに目の前でおこるとまあまあバイアス発生するよね。)

まとめ

つまり、オーバーエンジニアリングとは・・・・本来は大事じゃないものを大事だと錯覚した結果、作りすぎて(やりすぎて)、時間や金を無駄にしてしまう。ということであり、それを引き起こすトリガーとなる錯覚は例えば以下のようなものがある。と言えそうである。

  • 要求にHOWが入ってる(HOWが大事であると錯覚してしまう)
  • 少数ユーザの意見(少数の意見が、全体の意見であると錯覚してしまう)
  • とてつもなくグロースするサービス(数年後の状態が、明日のことのように錯覚してしまう)
  • リスクを取らない(目の前で起きた問題が、すべて大問題であると錯覚してしまう)
  • リスクを取らない(起きるかもしれないことは、大抵起きると錯覚してしまう)
  • 教科書をなぞる(取捨選択こそが大事なのに、全部やらないとダメだと錯覚してしまう)

という、勝手にオーバーエンジニアリングを定義してみた!でした。

余談

開発における文脈と時間軸を正しく理解していないと、錯覚によりオーバーエンジニアリングが発生する。
全ての可能性が全て発生した世界が多分オーバーエンジニアリングの理論上最大拡張幅。前述の図のブクブク膨れ上がったやつ。
つまり、リスクテイクできていない世界。
例えば、この機能は事業的に致命的ではないためバグってもよくない?がいえると縮小する。
このプロダクトが流行ってから悩めばよくない?がいえると縮小する。
このコードは1年に一度くらいしか触った実績ないから、工数かけてまでキレイにしなくてもよくない?がいえると縮小する。1年に1度あるかないかみたいな時間軸が抜け落ちると、目についた汚らわしいものすべてがキレイにする対象になってしまう。無限にお金と時間があるなら良いのだけど、基本的には限られた資源で日々活動をしているため、そんな状況にはなりにくい。

そのためこれらのリスクを取れない、つまり、「事業理解のない提案」になるとどうしてもコストが最大化する。
全部のリスクをヘッジする実装をするから。

リスクをマネジメント対象にすることってこういうことなんだろうな。(感想)

おまけ

このような勝手な定義を毎週youtubeでスライド作りながらしております。

今回のオーバーエンジニアリングついて。

PIMBOK第7版について

技術的負債について

俺のプロダクト開発用語辞典 www.youtube.com

2019年振り返り

2019年皆様たいへんお世話になりました。2019年は会社のほうでは執行役員になり、今までとまた全く違った景色の中であっという間に年末を迎えることになりました。そのため、振り返ってみると登壇2本しか社外へのアウトプットはしておらず、ブログはまさかのゼロ。なので、あとづけになりますが、インプットの1年だったのだと思います。そうします。

外部登壇

[DevLoveX] 大企業アジャイルの勘所 #devlovex

テーマ感として「自分の頭で考える」ことが大事だと伝えたかったスライドになります。制約の限りなくない世界ではなく、我々が日々対峙している現実世界の現場において、どうやっていくかを自分の中で暗黙化してしまっていることを言語化してみました。

[Developers Summit 2019 Summer] 大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi

コミュニティ活動

ことしも、デブサミ2020コンテンツ委員として活動させていただいております。なお、2020年の2月のデブサミも登壇予定です。 event.shoeisha.jp

印象に残った本

本は好きなのでいろんな本を読んでいます。たいてい流し読みで瞬間的に読み終えます。そんな中で印象に残った本は以下。

技術の創造と設計

心理学経営

買ってよかったもの

スカフコントローラー

FPSをやったりしているときに、親指を右スティックに載せたまま、○や✗ボタンを押したいシーンが発生。そのときに、親指を右スティックから離して○ボタンに指を移す間にキルされることが結構あり、その1秒程度の空白の時間をどうしても埋めたくなり背面にボタン(親指以外のボタンで押下可能になる)があるスカフを購入。最高。次はAstroのC40がほしい。 scufgaming.com

ダイニングテーブル(PC机用)

ダイニングテーブルをPC机用に購入。カフェ感のある木目そのままな感じのテイストで意識高いPCデスクにぴったり。この「かなでもの」おすすめ。 kanademono.design

SONY ワイヤレス ノイキャン イヤホン

もともとBOSEユーザーでヘッドフォンやイヤフォンはすべてBOSEだったのだけど、ノイズキャンセルのワイヤレスイヤホンがまずはソニーが出してきたので試しに購入。これはこれで良かった。(その2ヶ月後くらい?にAppleがAirpod proだしてしまい、それが未だに買えずじまい)。2020年はBOSEも同様のワイヤレスノイキャンイアホンだすぽいので、それに期待。 www.sony.jp

Razer Blade Pro

RazerのゲーミングノートPC。FF14等のゲームをPC環境で行いたく購入。デスクトップのBTOとかが最もコスパがよいと思うが、どちらかというと見た目と軽さとリビングにおける景観を意識しこれに。エアフローとかそういうのは無視。ゲーミングPC特有のへんな蛍光色に光るアレが我が家のリビングの景観を損ねるとのことでNGが出ておりもっともシンプルなRazerに。 www2.razer.com

ゲーム

仕事が忙しくなればなるほど、また、抱える課題や悩みが深く、複雑になればなるほど、家では仕事のことを1ミリも考えない時間として過ごすのがすごく重要に感じるようになってきました。その点、ゲームはやりだすと夢中になり仕事のことは一切考える余地がなくなるので、ゲームをしている時間は自分のMPを回復する上での必要不可欠な時間としています。

League of Legends

今更だけど、今更はまりました。会社のひとたちとやってます。世界大会が10月にあり、Discordでボイスチャットつなぎながら世界大会を観戦したりと楽しかったです。e-sports最高。 jp.leagueoflegends.com

Monster Hunter World Iceborn

マスターランク276、ハンターランク604。MHWからの合計で1200時間溶かした模様。 www.capcom.co.jp

Death Stranding

デススト。荷物を届けるだけのゲームなのだけど、最高に楽しかった。同じ届け先や同じ経路をN回通るため、どうしても効率化したくなり、効率化作業が生まれ、ひたすら効率化に時間を溶かすゲーム。ただし、本来の目的はストーリーをクリアすることであり、それだけを純粋にこなすのであれば30時間あればおわるものの、今後発生するN回のお届け作業を見越したオーバーエンジニアリングな自動化作業により、なぜかプレイ時間が100時間を超えるという本末転倒は手段の目的化。ただ、手段の目的化こそが指向であり、そのたかがHOWを突き詰めていくところがこのゲームの神槌であり、面白いところでもありました。 www.playstation.com

Dead by Daylight

去年から引き続き楽しい。会社のひとたちとやるとなお楽しい。鬼ごっこゲー。 www.jp.playstation.com

ファイアーエムブレム 風花雪月

王道。 www.nintendo.co.jp

2018年振り返り

2018年みなさま大変お世話になりました。2018年は、マネジメントする組織のメンバ数が20人から100人へと拡大したことがあり、はじめてずくしの1年でした。そのため、基本的にはインプットの年で、社外登壇やアウトプット活動はほとんどしておりません。そんなのする暇がなかった・・・・。でも、ゲームはかなりしました。ゲームの話と、数少ないアウトプットをまとめておきます。

Regional Scrum Gathering Tokyo 2018

Panel - 実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。

川口さんから恐怖のパネルセッションのオファーを頂き、前回のPO祭りの当日丸投げ対策として事前に仕込んだ資料になります。

confengine.com

DevLove関西

”効率が良い”を考えてみる〜フロー効率性とリソース効率性のお話〜

と言ったら、@daiksyさんと @yohhatu さんが以下のイベントを企画してくださり、大阪にたこ焼きたべにいきました。 devlove-kansai.doorkeeper.jp

書籍

日経システムズ6月号

「ここだけアジャイル」という特集に掲載いただきました。

日経システムズ7月号

「テスト特集」に掲載いただきました。

ブログ

今年はブログをまさかの2本しか書いていないのですが、両方とも普段からメンバーと1on1で話しているようなことで、それをそのままブログにするとはてブ数がそこそこつくのが意外でした。こういう話を日々、@Poohsunny とよくしています。

「再発防止策はチェックリストによる目視確認」から考えるアウトカムフォーカス

システム障害の対応から個別の対策ではなくどう組織知として還元していくかを考えたときに、この手のものは汎化して教訓化すると一気にスケーラブルになるので、そういうふうに捉えて振り返りをしています。同時に、それをパターンとして自分の引き出しとしています。 i2key.hateblo.jp

組織に流れるフォースを間接的にコントロールする仕事

フォースという単語からはてなブックマークのコメントにスターウォーズ感がすごく出てるのですが、イメージでいうとパターンランゲージの文脈におけるフォースを意図していました。日本語に置き換えると、コンテキスト上に流れるニーズや力なのですが汎化させると傾向と言うとすんなり入るかもしれません。 i2key.hateblo.jp

コミュニティ活動

デベロッパーズサミット 2018と2019のコンテンツ委員をやりました(2019は継続中)。

ゲーム

今年の個人的にベストゲームオブザイヤーは圧倒的にDead by Daylightでした。基本的にはホラーゲームのカテゴリで、殺人鬼(1人)とサバイバー(4人)で鬼ごっこして、脱出するゲームになります。鬼ごっこ&缶蹴り&けいどろ(どろけい)の悪魔合体のようなルールなので、幼少期にみながやったリアルな遊びをオンラインでやっているイメージです。なので、つまらないわけがない。 store.playstation.com これを、会社で部活化し、みんなでやっております。DeadbyDaylight部、部長の @yuriettys がブログを書いてくれているのでそっちもどうぞ。 yresy.hatenablog.com

年明けはずっと家でDead by Daylightやってる予定です。

ボクササイズ

会社のひとたちとb-monsterというボクササイズに通い出しました。2018年2月から開始して、未だに続いています。45分間ノンストップでのボクササイズは脳内がスッキリするし、汗びっしょりだし、結構いろいろな考え事できるし自分のルーチーンになりました。

www.b-monster.jp

ドイツ行った

クロアチア行った

トルコ行った

タイ行った(今)

海外カンファレンス

Agile 2018

去年に引き続きAgile2018に参加しました。新しい発見というよりは、自分の中での経験を抽象化して定着をはかるための場としてとても有用でした。

組織に流れるフォースを間接的にコントロールする仕事

Recruit Engineers Advent Calendar 2018 - Adventar ということで、エンジニアリングマネージャー的なことを書いてみます。1on1とか採用とか評価制度とかではなく、組織力学のような話を。

フォースを感じる

自分は普段からエンジニア組織をマネジメントする際に「構造によって発生する力学」をすごく意識しています。いま、大体100人弱の社員エンジニア組織をマネジメントしているなかで、役割上、判断する仕事がかなりの割合をしめます。その判断でどんな力学が発生して最終的に現場で何が起こるかまで可能な限り想像力を張り巡らさないとならないです。そして、この想像力において、どれだけ解像度を高くできるかこそが現場感だと思います。経験がないと何がおこるか想像すら出来ないと思うので。

ビジネスにおける意思決定で発生したフォースは徐々に伝搬し、最終的にエンジニアの現場に流れ込んできます。このフォースがどのように伝搬してくるかを見る能力がとても大事であり、これが無いと、本来、事業を加速させようとした意思決定も現場に伝わるころには、まったく逆のフォースを発生させてしまい、スピード感を失ったディフェンシブなものにすり替わってしまったりします。

具体的な例で話したほうがイメージ付きやすいと思うので以下に想像ベースで書いてみます。

スタートアップや社内新規事業のアーリーステージにおいて過度な売上目標をチームに持たせようとした場合

例えば、スタートアップや社内新規事業のアーリーステージにおいて、さらなる成長の加速を願い、過度な売上目標をチームに持たせようとした場合なにが起こるのか。

サービス初期のプロダクトの価値が実証されていない状態(バケツに穴が空いた状態)においては、例えば売り方(売上)ではなく売り物(プロダクト)の力のみで結果をコントロールできる数値(継続率や成長率)を目標にすべきなのですが、ここで強い売上目標を組織に持たせると、チームは売上の単価やグロスをあげるために、売り物(プロダクト)ではなく売り方側をチューニングしアップセルやクロスセルをどうしてもしたくなります。そのほうが短期的に数字を作りやすいから。くどいですが、本来であればこのフェーズは売り方ではなく売り物をチューニングし、顧客の課題を確実に解決できるプロダクト(バケツの穴を塞いだ状態)に仕上げたほうが全体的には手戻りが減り事業成長の点で効率が良いです。売り方(水の流し方)のチューニングはそのあとの話。

しかしながら、売上を目標に持ってしまっているので、そうもいかず。仮にtoC向けサービス(薄利多売)であった場合は、急速にtoB(顧客単価高)へと販売戦略を変えたりすることもあります。ここで現場で発生することは、プロダクトのフェーズ(バケツに穴あいているtoC向けサービス)と、ビジネスの強いられているフェーズ(アップセルクロスセルによる売上最大化)にミスマッチを起こします。どんなに送客しても、toCプロダクトをtoBに売ったところでチャーンレートが高い状態(バケツに穴あいたまま)なので顧客は継続せず漏れていきます。また、それを防ぐために焦って、toBむけエンタープライズな仕様や機能がどんどん追加されていきます。ベースがtoCであったシンプルなサービスはあとから十徳ナイフのように機能がもりもりにされていき、コードベースは肥大化していき、開発のフットワークはどんどん悪くなっていきます。そして悲しいことにこの肥大化したコードベースの6割は使われない機能だったりします。P/L上もシステム投資における資産が積み上がり残存簿価まみれになり、減価償却費が根雪構造的に積み上がり自分たちのできることが徐々に制限されていきます。この最初の力学を発生させたポイントは、「アーリーステージの組織にフェーズに見合わない売上目標を課したこと」になります。

そのため、最初の組織の目標設定のタイミングで、どのような力学が発生するかを解像度高く想像を巡らせる必要がありますし、わかる限りその段階で正すことが求められます。まさにエンジニアリングマネージャーの嗅覚が必要とされる部分だと思います。

サービスの能力以上の資金調達する場合

同様なものに、例えば次の例もあります。 サービスの能力以上の資金調達(社内|社外)するというケースです。基本的には前述と同じ構造ではありますが、調達額(投資家からしたら投資額)に対して、どうしても期待が高くなります。すると、期待値に見合うように目標を高く設定するバイアスが発生します。「こんなに投資してそのリターン?」となってしまうので。そして、チームはそのゴールに向けた数値の積み上げが始まります。そこから逆算した無理なエクセル上の計画が立てられ、プロダクトはそれにそった計画駆動型の開発モデルになっていきます。

開発「側」は計画通り作り上げることが目標になり、柔軟な変更を弾き返すようになります。プランニング「側」と開発「側」の壁が強くなっていきます。どうしても、プランニング「側」は目標に向けた計画を遂行したいがために、仕様を押し込みたくなるし、開発「側」はそれをディフェンスしたくなる。ギスギスしだす。開発「側」は「仕様が決まってないので作れません」となる。更に開発「側」は計画を守るために、バッファを計画上にたくさん盛り込みだす。つまりは、やれることをバッファ分だけ自ら減らしていく構造を作り上げる。そして、基本的にバッファは使い切ってリリースを迎えることになる。結果的に自分たちのできる総量を、自ら低下させ成長をスローダウンさせていくことになる。仮にスタートアップだったら、最終的にダウンラウンドを招くことにもなります。 これも、最初の力学を発生させたポイントは「サービスの能力以上の資金調達」するという決定によって発生する組織力学です。起点は、ちょっと背伸びしたかっただけなのかもしれないのですが、巡り巡ってこんなはずじゃなかったという結果につながるかもしれません。

スクラム開発において個人のベロシティをモニタリングする場合

若干上記の例が、ビジネスビジネスしてたので、もう少し開発現場よりの例も上げてみます。 より開発現場の生産性をあげるために、チームのベロシティだけでなく個人のベロシティも日々モニタリングするようにしようという提案があった場合。 例えば、エンジニアは自身のベロシティが自身の業績評価につながると思ってしまうかもしれない。そうなると、多めに見積もったほうが生産性は高く見えるようになる。もしくは、見積もりよりも時間が掛かりそうな場合に、低品質でもおわりにしてしまえという考えが出てくることもある。さらに、相互のメンバ間の助け合いもおきなくなっていく。人のこと助けても自分のベロシティあがりませんし。と。流石にこれらは極端な例だとは思いますが、正しく合意形成や目的の共有がなされていない状態でこの決定を下すと、現場には少なからず間違った力学が発生してしまうことがあります。

エンジニアリングマネージャーとしてフォースを間接的にコントロールする

最初から上記にあげているような構造のパターンを知っていたわけではないので、実際にはシステム思考をベースに複数の類似した経験から因果のパターンを抽出して自分の引き出しとしています。(無意識的にやっていて、同じような事象に遭遇したときにひらめく感じ。) なんでも構造として捉えるのがもともと好きなので、その思考方法が癖になっていて、iPadで日々お絵かきをしています。ただ、自分は別にパターン・ランゲージの熟練者でもなんでもないので、なんとなくやってます。

エンジニアリングマネージャーとしては、ビジネス上の判断が力学としてエンジニアリングの現場にどのような形で伝搬するのか、逆に伝搬させないようにするのかを見極め、ビジネス上もっともアウトカムへのスループットを最大化させるように対策を講じる必要があると思います。 基本的に構造によって発生する力学なので、その流れるフォース自体はコントロールしにくいですが、力学を発生・加速・減衰させる構造側はコントロール可能なので、構造をコントロールしてマネジメントしていくことになると思います。例えば、ビジネスモデル、目標の構造(KGI-KPIs)、予算の構造(ポートフォリオ)、それに紐付いて作られる組織構造、それに紐づくシステムアーキテクチャ開発プロセスなどです。 例えば、経営層が経営指標をEBITDAにするとメッセージングしたときに、開発の現場では何がおこるかとか考えてみると面白いかもしれません。

また、自分が大切にしているのがこの力学を逆手にハックして利用していくことです。その力学を逆にうまく使って自分のやりたいこと、都合のよいことをフォースの流れに混ぜ込んでのせてしまう。そうすると施策が一気に進んだりします。デメリットがない場合、コトを前進させるのにはフォースの流れを利用してしまえと思っています。

こんなことを考えながら日々、エンジニア組織をマネージメントしています。

「再発防止策はチェックリストによる目視確認」から考えるアウトカムフォーカス

「再発防止策はチェックリストによる目視確認」

開発の現場において、大きなシステム障害が発生したような場合に原因究明から今後の再発防止策を検討することがよくあるかと思います。

そこでよくある議論として、

とあるエンジニア「エクセルでチェックリスト作って今回の確認観点を追加します!今後はリリース前確認でかならず目視でチェックリスト確認を実施します」
ベテランエンジニア「んなことやってたら、チェックリストが永遠に増えていくからやること増えるだけだろ。もっと工夫なさい。チェックの自動化をしなさい。」

みたいな光景です。

ただ、これ実際に再発防止の効果が出るまでのリードタイムというポイントで見ると一般的にスジが悪いとされているチェックリスト的なやつですが、とあるエンジニアの案ほうが今すぐ対策を講じることができるので良かったりするなあと最近思うようになってきました。あくまで暫定的な再発防止対処としてですが。 目的は、「同じことが今後も発生しないこと」「それを事前に食い止めること」、であり、「自動化して確認が楽になること」ではないのですが、どうしても技術的な正しさやエンジニアとしての美学が目的ベースの判断を歪めることがあります。

再発防止に求める効果効能と時間軸による変化

さくっとチェックを自動化できるような場合は最初から自動化すればよいのですが、例えば、それが難しいような場合、エンジニアの美学としてのコードで解決することに時間を溶かすよりも、まずは原始的であろうが実利を即得られる方法を選択するほうが良いです。その対策を実装している間にまた類似システム障害が発生したら意味が本末転倒なので。

STEP1 まずは実利の即効性(フロー効率的)

まずは即効性が重要なので、一番早いやりかたを選択したほうがよいと思います。今すぐできることが重要なので。それがエクセルチェックリストならそれでもいいですし。そして、本来の目的を達成してから、あとはそれを今後N回繰り返していくときの効率面の問題に対処していくのが良いと思います。(Lintに定義追加する程度とかの問題ならSTEP2からでいいです。) よくありがちなのがテストを自動化すればいい!という対策で、これ事態は別に悪くなくむしろ自分もそうしたいのですが、開発の文脈を無視したこの手の解決策をうつと問題がおきます。本来すぐ防止策を打ちたいだけなのに、いざテストコード書こうとすると、おやおや、クラスが大きいな・・・、メソッドも細かく切られていないしテストコード自体が複雑になるなあ。。。これなら、まずはリファクタリングしないとなあ、、、さあ、どこからなおしていくかな。みたいなことが起こりがち。リードタイムが長くなる一方。それは後述のSTEP2でやりたい。まずは目的を今すぐ果たしたい。フロー効率性重視でやりたい。

※ フロー効率性やリソース効率性の考え方はこちらを参照ください。 i2key.hateblo.jp

STEP2 今後の作業量の効率性(リソース効率的)

一旦、イケてない方法にしろ再発防止という目的を達成したのであれば、次にN回繰り返すときのことや、人力作業による手戻り発生等の物理的な無駄を排除していくことになります。やりかたはコードによる自動化とかがメジャーだとは思います。もしくは、そもそも仕組みを組み直して、そもそも問題が発生しない構造にしてしまうとか。とはいえ、それなりのリードタイムを要する行為かと思います。もしくは、カネで解決するためにアウトソースで実施することもあるかもしれません。こちらはリソースの効率性の文脈が強いと思います。カイゼンは最終的には実利を得つつもやることが減っている状態だと思っているので、ここまできてカイゼンはDONEではあります。また、この場合は、恒久対応までDONEすることをマネジメントすることは言わずもがな必須です。運用がゴミまみれになり負債化するので。

今回の件はイメージにすると以下です。 まずは実利をリードタイム最短で取りに行き、その後、スケールしやすいように作業の効率化をしていくイメージです。 f:id:i2key:20181027151432p:plain

普段の何気ない意思決定に介在するアウトカムフォーカス

ポイントは目的を意識した上で、STEP1とSTEP2双方を意図的に実施することです。何度もいいますが、STEP1を絶対非効率なやりかたでやれと言っているわけではなく、即効性のある方法をとるとよいという意味なので、手動目視チェックリストで絶対やれという意図ではないです。そして、この何気ない意思決定および行動の積み重ねが開発組織の文化につながっていくと思います。チェックリスト文化だけも良くないですし、文脈を無視した自動化文化も良くないと思います。まずは最短のリードタイムで実利をとり、そのあと効率化していけると良いのではないでしょうか。本件の障害対応においては、まあ、普通に暫定対応と恒久対応なだけの話なのですが、このパターンって結構あるなあと感じたのでブログにしました。例えば次の類似ケース。

類似ケース

例えば、開発における案件のリリースまでのリードタイムを改善のために計測しようとしたときに、目的でいうと「リードタイムの可視化」なので、メンバ全員に聞いて回って模造紙にまとめるでも即効性があればなんでもいいのですが、自分も含めてですがどうしてもタスク管理ツールのAPIリファレンスを覗きだし、自動でチケットの日付とステータスの推移を抽出できないかとか悩みだすんですんですよね。で、運用がうまくされていなくてチケット管理ツールから自動抽出できないとなると、うーん・・・・、となってまた別の技術的解決方法を探しに行ってしまう。で、本来の目的からどんどんそれていきなかなか可視化されないという事態に陥る。全員で集まって人力で計測した時間を模造紙に書き出すだけで一旦は解決するのに。 また、別のケースでいうとリーンスタートアップなどででてくるMVPとかもそれに近いかもしれないですね。

さいごに

サービス開発の現場では結構この手のことが多い気がしていて、また、本件の例のベテランエンジニアのようにHOWの指摘をしたくなるのもわかるのですが、そこは本質を意識しアウトカムにフォーカスし、得たい実利とHOWとリードタイムを天秤にかけながら判断をすべきだと思います。どんなにHOWが秀逸でも実利に繋がっていないとやっていないことと変わりないので。つまり、プラクティスの使い方がどうこうとかそういう話ではなく、本質的にはこういうことこそがアジャイルをしようとせずに、結果的にアジャイルであることなのではないかなと思ったりします。(高い技術力で高速に打ち手が打てる状態が最高ではありますが自分はそんな才能はないので。)

2017年のアウトプットまとめ

今年の振り返りがてら、オフィシャルな社外発表ベースの今年のアウトプットの雑なまとめ。大体0.5回/月の社外登壇らしい。

2017/02/16

Developers summit 2017

www.slideshare.net i2key.hateblo.jp

2017/03/18

DevLove関西リンスタ関ヶ原(新大阪の変)

www.slideshare.net

2017/06/18

DevLOVE200 Bridge 上記デブサミの以下の焼き直し

www.slideshare.net

2017/09/16

XP祭り2017

www.slideshare.net i2key.hateblo.jp i2key.hateblo.jp

2017/11/01

NTTデータAgile Forum講演資料

www.slideshare.net

2017/12/14

Lean Startup Update! 2018 〜3年間のリーンスタートアップのアップデート会〜

www.slideshare.net

スライドが潰れて見にくい画像を補足。(これが正解とかではなく目的や文脈にあわせてこういう構造でいつも考えている感じ。) f:id:i2key:20171229112024p:plain

THE STARTUP WAY翻訳 i2key.hateblo.jp

番外編

i2key.hateblo.jp

まとめ

みなさま今年もお世話になりました。来年もよろしくおねがいします。 告知としまして、来年は年始早々、Regional Scrum Gathering Tokyo 2018 のパネルディスカッションに機会がありまして出演させていただきます。

confengine.com