ChatGPT + Claude Codeで1行も書かずにAndroid アプリを Vibe Codingできた
前提
Vibe Codingが流行っているので、なんか作ってみたい欲が高まっていました。 そんな時ふと、日常の小さなペインである「物理の会員カードにQRコードが印字されていて、来店時にそれを提出する必要があるために財布を持ち歩かなければならない」が気になった。 会員カード系のQRコードはいわば静的データなので、スマホに保存しておけるハズ、そうすればスマホのみを持ち歩けば良いのに、とは前々から思っていた。 軽くStoreを見てもそれっぽいアプリはありそうだったが、無料でなかったりするし、要件はとてもシンプルなので「これ、AIで作れるのでは」と思って作ってみた。
思った以上に簡単にできてしまったため、驚きを以下で書き記していく
さきに成果物デモ
1. ChatGPT との要件定義
要件定義はとりあえずChatGPTに投げるところから。まぁ問題なく話が進む。当初は、スキャンした QR コードをサーバー側の S3 に保存するなど、Backend Engineer らしい発想で設計を考えていたが、「個人利用であれば、端末のローカルストレージで十分」という指摘もしてくれて、余計設計がシンプルになり、実装の複雑さも大幅に削減された。ClientとServer、なんならInfra構成含めたmonorepoでも作るかと思ってたけど、この時点でClientのみに収束した。 実装はClaude Codeにお願いするつもりでいたので、CLAUDE.md と instruction.mdを出力してもらって、ChatGPTはお役御免。
CLAUDE.md と instruction.md の作成
CLAUDE.md に記述した詳細内容は以下（らしい）
- プロジェクト概要：アプリの目的、対象プラットフォーム、主要機能
- アーキテクチャ：MVVM + Unidirectional Data Flow、マルチモジュール構成
- 技術スタック：Kotlin、Jetpack Compose、Material3、Room、Hilt、CameraX、ZXing
- 開発ルール：実装時の制約やベストプラクティス
instruction.md は、以下な感じ
- プロジェクト基盤の構築
- ドメイン・データ層の実装
- ホーム機能の実装
- 追加機能の実装（カメラによる QR コード読み取り）
- 表示機能の実装（フルスクリーン QR 表示）
- 詳細機能の実装（カード情報の編集）
- バックアップ機能の実装
- ショートカット・ディープリンクの実装
- 削除機能の実装
それまではAndroid Studio上で動作確認していたが、Step6あたりで端末にInstallしてみると、削除機能がないことがわかったｗ なのでそれだけ追加実装してもらったために、Step9だけ後付けになっている。
2. Claude Code での段階的開発
開発は非常にシンプルで「Step N を作成して」の指示を繰り返すだけで、アプリケーションが段階的に構築されていった。
AI による自動的な実装
各 Step では、以下のような成果物が自動的に生成された（らしい）
- コンパイル可能なアプリ：各ステップ終了時点でビルドが成功
- 適切なアーキテクチャ：定義した設計パターンに従ったコード
- エラーハンドリング：適切な例外処理とユーザーフィードバック
- テストコード：ユニットテストと UI テストの実装
- コード品質：Spotless + ktlint によるコードフォーマット
要件定義を超えた実装の驚き
- レイアウト：Material Design に準拠した UI
- 色味：適切なカラーパレットとアクセシビリティへの配慮
- ダークモード：システム設定に応じた自動切り替え
- 保存アイテムの sort, filter 機能：ユーザビリティを考慮した検索・ソート機能
- アイテムのメタデータ（カテゴリ分けなど）：データの整理と管理機能
できたものを見て驚いたのは、これらの機能は、要件定義の際には「QR コードをスキャンして保存・表示する」という基本的な要件しか伝えていないのに、実装されており、ChatGPT instruction.md が良かったのか、Claude Code の実装力の高さなのか、いずれにしてもユーザーにとって本当に使いやすいアプリケーションが完成した。
これも、AI Codingの凄さで、単なる指示通りの実装をするのではなく、ユーザー体験を考慮した包括的なソリューションを提供で、人間の開発者でもこれができる人はレベルが高い。。
3. GitHub Actions での APK 配信
動くものができたところで、配信のためにGitHub Actionも作ってもらった。コードの変更があるたびにActionで自動的に APK がビルドされ、GitHub のリリースページからダウンロードできるようになった。 という感じでCICDまで構築して完了。
まとめ：Vibe Coding の実践として
1 行も書かずに Android アプリを作成
結果的に絵に描いたようなVibe Coding の実践になり、1行もコードを書かずに、AI との対話だけで Android アプリを作成し、配信まで完了できた。 Google Play Store公開は、初期費用$25をケチってやってない、要件としては不要ではあるが、経験としてやっても良かったけど、まぁそれはまた次回機会があればやってみたい。
これで仮にもAndroid Engineerを名乗れてしまう訳だが、もちろん名乗るつもりはない。とはいえ、素直に恐ろしい時代だ。 ちなみにこの話、ChatGPT相談から実装完了まで数日しかかかっていないし、「数日間」の大半は「人間からの指示待ち」時間であって、機械が動いていたのはほんの一部でしかない。 各ステップでbuildなどをしながら進めていたが、そこでもエラーが出力されることもなく、最初から最後まで「なんかよくわからんけど、期待通りのものができていっている」以上に把握・観測することがなかったのが驚くべき開発体験だった。
「点を打ち、線を繋ぎ、面を作る」ことによる業務改善で成果を最大化する
概要・Introduction
業務改善の成果は段階的に達成される。まず『点を打つ』ことで各処理が効率化され、次にそれらを『線で繋ぐ』ことで一貫性が向上し、最終的に『面を作る』ことで全体の業務プロセスが一気通貫のフローとなり、最大の効果を発揮される。という考えの話。
本題
少し前の話になるが、チームで半期を振り返るMTGを実施した際「（ある領域において）最もインパクトのある取り組みは何だったか？」という議論をした。その際、メンバーそれぞれで挙げたネタが異なり、それはとても興味深かったのだが、自分の挙げたネタの根拠を、その時話せなかった部分も含めて書き記しておく。
メンバーの挙げたネタは、例えば「管理画面に表示項目を追加して、作業者の余計な確認作業を減らした」や「重要度の高い業務オペレーションを(短納期で）システム化した」というものだった。対して自分のネタは「内部管理画面に直接リンクする動線を、外部SaaSの画面に設けるためのChrome Extensionを提供した」だった。なぜこれを選んだかを解説する。
まず、背景としてそれまでのオペレーションは以下の流れだった
- ブラウザで外部SaaS画面を開き、必要となる情報（ID的なやつ）を確認する、あるいはコピーする
- 別タブの内部管理画面で、検索フォームに情報を（マニュアル、あるいはペースト）入力してsubmit
- 目的地の内部管理画面に辿り着く
これが以下のようになった
- ブラウザで外部SaaS画面を開き、Extensionによって作られたリンクアイコンをクリックする
- 別タブで目的地の内部管理画面に辿り着く
これは何らかの業務改善を行う際の「線を繋ぐ」成果である。どういうことかというと、業務改善とは、「点を打ち、線を繋ぎ、面を作る」ことでその成果が最大化されるという整理に基づいている。
点を打って、時間短縮
点を打つ、とは例えば何かしらの処理を担うためのピンポイントのソリューション提供である。例として経費精算処理ならば、領収書のPDFをuploadして申請ボタンを押すような画面を作ることだ。これによって、それまで紙で行っていた領主書管理や帳票をデジタル化できる。
線を繋いで、一貫性の向上
線を繋ぐ、とは別々に存在するピンポイントなソリューション（＝点）を結びつけ、プロセス全体を通して連続的なデータフローを生み出すことである。 同じく経費精算処理の例でいうならば、オフィスの複合機で紙の領収書をPDF化して自身のemail アドレス( 会社ドメイン) に添付送信する処理と、PDFを添付して申請する処理(=これが前述の「点を打って作った処理」）は別々に実装されている。そのため2つの処理を跨ぐところ、つまり自身のメール受信箱から添付のPDFをローカルダウンロードし、申請処理の画面にアップロードするというマニュアル作業が発生してしまう。領収書をPDFデータにする、申請をweb化する、というアプローチが分断されてしまっているのが課題であり、例えば紙の領収書がスキャンされたら、勝手に申請画面に添付反映されるような処理が「線を繋ぐ」ということだ。
面を作って、プロセス全体を自動化
面を作る、とは線をある業務の端から端（＝開始から終了）まで伸ばし切ることの繰り返しで達成できる。つまり一気通貫の処理が連続されることだ。この時には一つの線を繋ぐ作業が1つ（以下）のアクションで完結している。例えるなら、織物を織っていくイメージだ。
縦糸に沿って横糸（＝線）を通して行くことで、それがやがて面となっていくことで織物が完成する。
(別解) ボンバーマンで例える
ボンバーマンの初期の火力は弱い、この時ボンバーマンは火力の弱さをカバーするため足が必要で、動き回る必要がある。このボンバーマンの移動範囲こそが点と点、あるいは線と線の間に残っているマニュアル作業だ。
一方火力がMAX状態の時は、一発で画面の端までリーチすることが可能だ。この時ボンバーマンの動きは直線的に進むだけで目的を達成できる。一直線に進みながら各行にボムを仕掛けていった時に描かれる爆発範囲の軌跡を見てみると、面が作れているハズである。
現場において
冒頭のChrome Extensionが「線を繋ぐ」アクションであり素晴らしいと表現したのは、改善案件と称する作業で「点を打つ」ことがとても多いからだ。この理由の一つに顧客からの要望で「線を繋く」要件はほとんど来ないという事実がある。多くの顧客要望は個別機能にフォーカスしがちであるため、要望に応えるだけでは『点を打つ』改善にとどまるケースが多くなる。
例えば線を繋ぐというのの代表はSlack Integrationだ。そう考えると「Slack Integrationを開発してください」と言われることは少ないのではないか。またSlack Integration開発でも部分的な線（面を作るに至らない）の長さになってしまうケースはよくある。どこからかの通知がSlackに届いて結果として「◯◯のところで、XXXをしてください」というようなメッセージが表示されるなら、それは線を端まで伸ばしきれていないことを意味する。なんらかの業務フローの端っこにいるのがSlackでなくてはならない、それが起点でも終点でも良いし、両端であるのが理想だ。
業務改善で成果を最大化とは
「点を打つ」「線を繋ぐ」「面を作る」それぞれに挙げられる成果が異なり、点の成果は「時間短縮」、線の成果は「プロセス一貫性の向上」などが挙げられる。面の成果は「プロセス全体の可視化と追跡性の向上」と「自動化」であり、これによって生産性が最大化される。 そのために必要なのは一つの線の長さがどれだけなのかを正確に理解していることだ、これが業務理解と呼ばれる部分で、これは往々にして「ヒアリング」だけで把握できないことがある。（完全にマニュアル化されている場合は逆にヒアリングではなく、ドキュメント読み込みで可能というケースもある）
とはいえ、最初から線を端から端まで伸ばし切ることは簡単ではない。切ったり貼ったりしながら線を伸ばしていく事の方が多いようにも思える。その繰り返しをいかにスムーズに実施するかもまた必要なスキルである。 CLIにおいてUNIXの哲学に基づいて作業すると処理をパイプで繋いでいけるようなるのと同じように、点の置き方や線での繋ぎ方を意識し、インターフェース設計に取り組むことが重要であり、その積み重ねによって最終的に面を作るための一本の糸が紡がれるのが業務改善と呼ばれる作業だと考える。
まとめ
業務改善の取り組みでは、まず「点を打つ」ことで個別の作業効率が向上し、次に「線を繋ぐ」ことで業務フロー全体の一貫性が確保され、最後に「面を作る」ことでプロセス全体の可視化と自動化が実現できる。それぞれの段階における成果（時間短縮、一貫性の向上、プロセス全体の最適化）は、業務の効率化と質の向上に直接的に結びつく。
Chrome Extensionの導入は「線を繋ぐ」効果を発揮し、業務フローのシームレスな一貫性を確保する重要なステップでしたが、さらにその積み重ねによって、最終的には「面」を形成し、業務全体が見える化・自動化された理想的な状態を目指していきたい。こうした一貫した取り組みが、チームの生産性向上と業務の質的向上に繋がると考えている。
2024年イギリス旅行記
うっかり先月になってしまったが、最近イギリス旅行ができたので、大したことではないが思ったことをメモしていたら、SNSへの1エントリを超えそうだったので、ブログエントリにしてみる
観光編
決済周り
事前に調べていた遠りだったが、VISAのTouchlessが完全に浸透しきっていた。カタールW杯の時もVISA Touchだったが、あれはVISAが大会スポンサーだったのもあったし、ドーハ自体が近年作られた都市だったのもあっての普及率だったのかと思っていた。イギリスでは訪れた各都市（ロンドン・リバプール・マンチェスター）で完全にデフォルトになっており、結果として遂に一度も現金を使わないで旅を完結することができた。W杯の時は一部、寄り道のUAEで露店で使うためとかのためにキャッシングで引き出したので、旅行を通して本当にノー現金は今回が初だった。
具体的には、リバプールのバス、マンチェスターのトラム、ロンドンの地下鉄、有名な2階建バス、などの交通機関はどれもOK。2016年にロンドンに行った際にデファクトだったオイスターカードももはや不要なものになっていた。街中のお店は、いわゆる土産物屋やコンビニと駄菓子屋の中間みたいな店でも端末があった。一番懸念していたのは、サッカー関連でスタジアム周辺や街中に臨時で出ている路面店だった。こういう路面店は試合ごとのマッチデーマフラーや、オリジナルマフラーを売っていて旅の良い記念になるのだけど、さすがにこれまでは現金やりとりだった。カタールで買ったマッチデーマフラーも現金だった。ところが今回は、そんな店でもAirREGIチックなスマホ連動の小型の端末を持っていて、クレカ決済（もちろんTouchless)ができた。
これまで財布代わりに肩掛けポーチをしてクレカや現金を管理する、みたいな格好だったので、今回もこれで行ったが、途中からはポケットにカード1枚入れるだけで十分というスタイルに変更した。
本当にクレカ1枚あれば、あとは不要。しかし、そこで壁になるのがオンライン決済だ。今回、事前準備の宿や電車の予約でBooking.comや trainlineなどのサイトを使ったが、その時から普段使いのカードは不正決済の誤認されて度々エラーになって、予約が一苦労という事態があった。現地でもこれと同様で、ロンドンでミュージカルを観ようと思って予約したら、そもそも3D Secureの認証に進めずに詰んだ。これを解決したのがGoogle Payの決済で、登録してるカード自体は同じものなんだけど Goole Pay経由だとすんなりだった。
そして、決済が完了するとチケット関連はGoogle Walletで管理できるようになっている。これはサッカーでもミュージカルでも同様で、下手な独自アプリを入れる必要もないし、webを開く必要もないので大変便利。ちなみに帰りのフライトはルフトハンザだったけど、これも同様。
Google Walletにクレカ登録済みだと、そこからTouchlessで決済できるので、スマホをかざせば済む。なので、前述の物理カードをポケットに入れることすらも省くことができる。ここまでは実際に検証することができて、本当は Pixel WatchのWalletに登録して、Watch経由の決済を検証したかったのだけど、そこまではできず。普段は、SuicaとiDをPixel Watchに登録しているので、Watchがあればなんでもできる、を実現できているのだけど、多分同じことができたんじゃないかと思う。
オンライン決済に対しては不正検知が機能しているクレカだけど、物理使用で不正検知で引っかかることは良くも悪くもなかった。ので、紛失には十分気をつけましょう。
イギリス国内で長距離移動するのに、trainlineは便利。ただ、ダイナミックプライシングなので、早期に計画を立てられて、予約できるのがよりお得です。
物価
まぁ、予想通りインフレ+円安で高かった。1ポンド190円のレートを前提にしつつ具体例で言うと、
- 飲み物: 2,3ポンド
- マックのセット: 8ポンド
- バーガーキングのセット: 10ポンド
- カフェで軽食とコーヒー: 10ポンド
- Tシャツ: 20ポンド
- スタバでラテ: 4ポンド
- スーパーのお惣菜サラダ: 4ポンド
- プレミアリーグ、ウェストハムの一番安い席: 70ポンド
- ミュージカル
- ハロッズのビニールトートバッグ: 40ポンド
特にハロッズのトートバッグは他のブログでも触れられてたけど、8000円と考えると少なくとも友達へのお土産としてはかなり奮発することになるので注意。ちなみに帰りのヒースロー空港の免税エリアでも同じ値段だった。
Amazon Fresh
たまたま見つけたので、Amazon Freshの初体験ができた。入り口でクレカを通して入場したら、帰りはゲートを通るだけ。「合法的に万引きできる体験」と言って良いそれは、なかなかドキドキしたw
だいたいのスーパーでセルフレジも浸透しているので、海外あるあるの、愛想が悪く座った店員に向かってベルトコンベアで商品を送る体験のためにレジ待ちする必要もほとんどなかったけど、やはり袋に詰めてそのまま出るっていうのは食品鮮度というより体験としてFreshすぎたｗ
まとめると、VISA と Touchlessと Goole (Pay|Wallet)が最高（ Apple Payでもきっと一緒）だった。日本もこうなって欲しいと思うけど、QR決済やポイント還元もあるし、言ってもやっぱり Suicaの改札での反応力はチートなので、違う世界線なんだろうなと思う。今回の体感速度としてはこんな感じです。
気候＆観光周り
過去2回ほどイギリスを短期間旅行していて、その時は曇りか晴れくらいだったけど、それは運が良かったか時期が違うせいもあるかもだけど、今回は本当に雨が多かった。ザ・イギリスなイメージ通り。とはいえ、細かい雨なので大体みんな傘をささない。日本の雪国の人が雪で傘をささないのと多分同じ。ヒートテック、長袖、トレーナー、コートまで重ねてたけど、それくらいで十分だった。
電車は都市内、都市間どちらもそれほど遅れず。「来るか来ないかわからん」みたいなレベルでは決してない。東京のラッシュアワーくらいの振れ幅と思っておけば合ってそう。
ロンドンではSantander Cycle のシェアサイクルに乗ってみた。都内だとdocomoのBIKE SHAREとか大宮近辺はHELLO CYCLINGがあるのだけど、ポートにDockがあって、そのDockに差し込んで返さないといけないのがBIKE SHAREとの違い。HELLO CYCLINGだとアプリ上からDockの確保予約ができるのだけど、それはなさそうだった。とはいえ、Dockのキャパがかなりあるので、溢れて返せなくなることはなさそう。溢れても別のDockは例えば 都内のLuupのスポットより全然ある気がする。一番大事なポイントは、電動チャリじゃないってこと！実はこれを勘違いしていた。 1日3ポンド乗り放題を払ってしまってから気づいたという失敗。
ミュージカル＆サッカー
たまたま思い立ってミュージカルを観た。レ・ミゼラブルの劇場は歴史があり、箱が小さいので高くない席でも良く見えた。アナと雪の女王の劇場は豪華で、設備も凄く、氷の魔法の演出も再現できていた。
鑑賞体験としては、正直あまり良くなくて、飲食可なので映画館並に飲み食いする人いるし、劇中でも結構お喋りしてる。物音も立てるし、スマホで時間を確認する人もいて、集中力をかなり阻害された。ここら辺は本場のミュージカルのお作法とか全くわからないので、なんとも言えない。日本人が静かに観るとかは何においてもそうとも言えそう。
実際、サッカーで言うと、プレミアリーグでは常連さん達は、試合始まってから来たりするし、もっとすごいのは試合終了より前にとっとと帰る。大勝・大敗してたりすると尚更だ。何十年も通っている地元サポーターには、サッカーがもはや日常なので良い意味でそんなもんなんだと思う。
お花見で、桜がせっかく綺麗なのだから、と黙って愛でるのはなんか違う。綺麗な花を適当に見つつお喋り・飲み食いするのが楽しいのだと考えると、それが文化なんだろうと思う。
まとめ
たまたま年の初めの方にマイルとプレミアムポイントを貯める機会になったので、SFC修行を検討することにしました
Software EngineerがSports Businessに行ってみた話(ex-MIXI Advent Calendar 2023/12/01)
Advent Calendarとしては通算3回目、個人的に関わるのは2度目のex-MIXI Advent Calendar 2023、初日は masartz がお届けします。
ちなみに前回2017年のときの記事はこちら。
MIXIには2007年から2014年まで7年間所属しておりました。
当時もちろんSNS「mixi」を使っていた自分も時を経て、今は「みてね」に子供x2の写真・動画をアップする毎日です。
SNS「mixi」が来年に20周年、モンストが今年10周年など既存の事業が長い間継続し続けているのも素晴らしい一方、スポーツビジネスの領域などにも取り組み、今はＪリーグのFC東京の親会社という立ち位置であるのも、当時は全く想像できなかったことでした。
一方、今所属するメルカリも同じくＪリーグの鹿島アントラーズをグループ会社に迎え入れています。
Ｊリーグの試合で「自分のキャリアダービーマッチ」ができる人はなかなかいないんじゃないかと思うし、サッカーファンとしてとても幸せなことだと思っています。そしてサッカーファンであることを拗らせて、実は2021年10月から2022年3月までの半年間、Software Enginnerとして鹿島アントラーズの業務に携わっていました。
「鹿島でエンジニア？」と色々と聞かれることがあるので、せっかくなので「スポーツビジネスとSoftware Engineer」というテーマで書いてみようかと思います。
取り組んだ経緯
前提として、当時入社後5年くらい経っていて、事業やRole( Enginnering Managerをやったり、Technical Product Managerをやったり）でできることはやった一方、成果はどれもあまり出せずに行き詰まっていた。そんな時に、アントラーズを含むSportsBusiness事業のチームにjoinできる機会があった（※現行の採用プロセスは異なります）。状況としてはそれまでいなかったSoftware Engineer第一号だったので、定められたJDのようなものはなく、「自分で切り開けられれば、なんでもできる」状態だった。なので、「Software Engineerとしてスポーツビジネスにコミットできるのか」という課題の検証をするべく、飛び込んでみたというのが事の発端だ。
実際に業務を始める際に事前に想定していた事として、おそらく業務にいくつかのベクトルがあるのだろうなと思っていた。
- For Customer
- いわゆるサポーター向けのtoC施策、オンライン・オフライン含めた様々な施策がある
- For Football, Player, Team
- 根幹であるチーム運営に関わる様々なこと。チーム強化に関わること全般
- For Company
- 鹿島アントラーズ社に対して、会社運営に関わること。Corporate IT と呼ばれる分野を含む様々なこと
という分類分けをしていたけど、アントラーズの組織もまさにこのような感じで部門が分かれていて、初期のキャッチアップが思った以上にやりやすかったりした。
やってみてどうだったか
結論としては、Webサービスを提供・運用する事との違いの大きさをまじまじと感じた、というまとめになるのだが、もう少し紐解いていく。
ビジネスグロースについて
スポーツビジネスはスケールしない、と書くとかなり語弊がある。Webサービスのスケールが異常、というのが正しい。ある日を境にユーザー数が10倍になったりすることが平気であるのがWebサービスだ。
一方で、スポーツビジネスではそんな事は起きないし、ある日突然10倍の入場者にスケールする事とかはない。これはスポーツビジネスに限らず、物理プロダクト（鹿島ならサッカーチーム）を持つ事業に当てはまる。
sotarok-sanのblogを引用させてもらうと
- MAU1000万とか、CVRが2%改善したとか、流通量が100億を超えたとかを目指して作り上げていきます。インターネットを利用したスケールするビジネスと言う事は基本的にそういうことなのです。
- まず場所や広さによりMAUの最大値がほぼほぼ決定されます。利益率や顧客単価は努力で上げ得るものもありますが、それでも上限値は存在します。つまりビジネスはスケールしません。
- 一方で、ミクロなレベルでの体験の濃厚さと言うものが存在します。
上記のように書いており、まさしくこれである。
テレビ（DAZNなど含む）を含めた視聴者つまりお客さまというのは地球規模で数えられるほどのスポーツがサッカーなのだが、個々のチームかつ、その事業的な面も含めて見ていくと、スタジアムに来場するお客さまからの入場料やグッズ収入というのがスポンサー(パートナー)収益と並んで売上の大きな柱となる。そしてこの変数の一つの要素であるスタジアムのキャパシティというのはWebサービスのインスタンスのようにある日突然倍増するものではない。
一方、Webサービスを運営している事業の場合、無限のスケールからくる無限の売上によって莫大な投資をしたりする。技術投資もその一部に含まれ、Software Engineerの生産活動と生存領域はその中にある。一方で、スポーツビジネスは年間の売上・予算などの上限値が実質的に存在し、利益も必然的に導かれる中で生きていく必要がある。まして、当時はまだコロナ禍だった。
となると、Webサービスのような大きな技術投資をするよりも、技術によって業務効率化を図るのが最も合理的なアプローチになる。いわゆるDXが一番効きやすい部分だ。これは上述の分類分けでいうと「For Company」の部分に該当する。コーポーレート部門（社内IT)としての活動がイメージしやすいと思われる。具体的な業務としては「SlackのIntegrationを作成して、〇〇を効率化しましょう」とかになる。
ついでに他の領域の部分を具体に落とし込んだ説明をすると、「For Customer」は例えばサポーター向けの公式アプリを通じて、エンゲージメントを増やすための施策検討などだ。さらに補足すると「For Business Partner」もこれの隣にあたるところにあり、いわゆるスポンサーへの営業や権益に関わる部分がある。そこで技術的に検討できそうだった例として「物理の広告面に対して、各スポンサーロゴの紹介を個々の契約形態を考慮しつつ、どう最適に表示するか」みたいな課題があったりした。
最後の部分が「For Football, Player, Team」であり、チーム強化の部分。ここに対するSolutionとしてイメージしやすいものとしては「試合映像を解析して、戦略分析に役立てる」みたいなカッコ良さそうなやつだ。一見やれる余地があるように見えるが、実はこの分野は結構開拓されていて、海外を含めたベンダーがたくさんある。とても一人でゼロから事業を立ち上げて、太刀打ちできる領域ではなくて、ベンダーの技術選定をしたりする方が余程エンジニアリングの価値を出せたりする。また、ここにもスポンサー権益ビジネスという側面があり、スポンサーとのリレーションを活かしたコスパの良い技術選択というものも、事業的に見て大事なポイントだったりする。
Software EngineerとSoftwareのコアコンピタンス
要約すると、「ガリガリコード書いて、Productを作りValueを出す」ような直球勝負ではなくて、技術力を活かしたそれぞれの領域の期待成果を出すようなアプローチが導かれる。そのもう一つの前提が、Software Productが事業のコアコンピタンスではない、という事実だ。
鹿島アントラーズのコアコンピタンスはフットボールチーム、つまり主役はサッカー選手だ。
これまでのキャリアで、ありがたいことに「エンジニアさんあっての(事業|会社)ですから、ありがとうございます」みたいな事を言われる事があった。そのたびに「いやいや、みんなで作っている(事業|会社)でしょう」と思ったり返答してきたつもりだ。今でも本当にそう思っているが、一方で「エンジニアが主役」であることもまた事実なのだと感じた。それは鹿島で「主役ではない」環境を経験したからこそそう思う。
どんなに良いSoftware Productがあったとしても、また仮にそれをゼロから作ったとしても、それによって本当の意味で「直接的に」勝利に貢献するということはない。もちろん間接的には、試合環境を整えたり、サポーターの熱量を高めたり、チーム強化をしたり、などが勝利の変数にはなっているのだが、そのインパクトは決して大きくない。何と比べて大きくないか、と言えば、Webサービスを提供するためのProductのコードを書くことと比べてである。
例えばサポーターの熱量が勝利にどれだけ貢献するかで言えば、俺はサッカーは12人でやるものだと思っているし、W杯を現地で観て勝利の瞬間を経験した身として、そのインパクトの大きさを絶対的に信じている。
あくまでWebサービス運営との比較である。Webサービス運営において、エンジニアは確実に試合のピッチの上に立っている。ボールをゴールに突き刺すことができる立ち位置だと思う。かつてEngineering ManagerやTPM(Technical Product Manager)をやって、「現場からは退いてしまったか」という葛藤がずっとあったが、どのRoleもピッチの上でのポジションチェンジだったと思う。
まとめ
という訳で、Software Engineerとして出せるValueが（相対的に）少ない立ち位置で、見込める事業成果の規模に対してコミットし続けるか、という選択を改めて問うた時に、せっかくのチャンスだったが今回は離れようという決断をして、メルカリ側の事業に戻った経緯でした。悩むポイントはたくさんあり、ちょっと挙げるだけでも
- 役割が固まってない魅力、なんでもできる段階である点
- サッカーファンとして、働く環境の魅力
- 選手の練習グラウンドが窓から見える
- 業務中にうっかりジーコとすれ違う
- ゼロイチフェーズっぽい成長余地
- 本職のスポーツビジネスとしてはもちろん歴史・伝統ありなのだけど、Engineeringで改善できる余地は多分にある
- 地域密着の理念とその実践ができる
などなど、伝えきれてない魅力は他にもまだあると思いますが、例えばそんなところ。
振り返ってみれば、限られた期間の取り組みだったが、携わるときには「このままサッカービジネスに行くかもしれないな」と本気で想像しながら取り組んだし、今でもボランティアベースで関係は継続させてもらっている。 メルカリ内でなければできない挑戦だったし、言うても当たり前にSlackを導入できていて、使いこなせてるリテラシーのあるJクラブがどれだけあるのか、っていうのは環境的に恵まれていたことを強く推しておきたい（FC東京もそうであることを願いますが）
また、このチャレンジを後押ししてくれたのも、小泉さんはじめ、元MIXIかつ現メルカリの関係者のご協力と配慮があってのことだったので、改めて「mixiが築いたつながり」の強さを感じる経験でした。
という訳で、改めて「Software Engineerとは Software事業を牽引するキープレイヤーである」というありがたい事実を知ると共に、それでもやはり「事業とは様々な役割の人、様々な取り組みによって支えられ、作られていくものである」と思います。MIXI社の事業も、メルカリ社の事業もそうであったし、これからもそうあることを願ってます。
美味しいコーヒーを提供するためのDeveloper Productivity
コロナ禍とコーヒー生活
コロナ禍で自宅勤務がメインになって以降、コーヒーにハマっている。
アメトーークで紹介されていたコーヒーサーバーをふるさと納税で購入し、近所のお店で焙煎してもらった豆を、自宅で挽いて淹れている。
それまではコーヒーの味の違いなどわからなかったが、やはり日常的に飲んでいると豆の種類・焙煎度・挽き方で味が変わることに気づく。（多分厳密には、もっと他のパラメータもあるんだろうけど、そこまでわかってない）同じ豆で、同じ焙煎でも、挽き方やその他を少し変えただけで味が変わったりして「あれ、昨日と違ってイマイチだな」と思うこともあり難しさと奥深さを感じている。
という前置きがあって本題だが、最近 Developer Productivityの向上というのをメインタスクとして活動している。もう少し詳しく言うと、グループ全体の各開発組織（＝チーム / project）の開発生産性に係る指標を計測し、その計測結果から改善アクションにつなげる、という試みに取り組んでいる。
ここで目的としている Developer Productivityの向上って、「美味しいコーヒーを飲んでもらう」という顧客体験に対して、「様々な種類の良いコーヒー豆をより多く提供する」ようなものだな、と感じたという話。
コーヒーの作業工程と味への影響
前述したように、コーヒーの味を分解すると、豆の種類・焙煎・挽き方(and more)に分かれる。ここで注目すべきは、豆を製造するという工程と、製造された豆を焙煎する・挽くという加工する工程に分かれることだ。
当然それぞれの工程に別々の担当者がいて、生産者は日本から見た外国（コーヒーベルトと呼ばれている国々が主）の人たちで、加工者は地元のコーヒー屋の店員さんだったり、自分自身だったりして、全然違った人が担っている。
それらの工程を経て、最終的にエンドユーザー（つまり自分）の前にコーヒーが提供され、それが美味しいものだと幸せである、というストーリーになっている。しかし、違う領域の担当者のそれぞれのアウトプットの品質が、最終的な成果物の品質にも影響してしまうのがデリケートなところだ。特に製造者から見たら、豆の質にしかresponsibilityを持てない状況で如何ともし難い問題と言えるかもしれない。
と匂わせて書いてきたので、コーヒー豆の製造者がエンジニアで、加工者がプロダクト（ビジネス）サイドっぽいよね。というのはおそらくしっくりくるだろう。
Developer Productivityの指標
開発生産性の話をするときに「生産性（が高いこと）をどうやって測るのか」が議論になることがあり、個人的にも未だに結論は出ていないのだが、最近立てている仮説として、「Deployment Frequency(デプロイ頻度）」をKPIとできるのではないかと考えている。Deployment Frequencyは御存知の通り、Google が提唱する Four Keysと呼ばれる指標のうちの一つだ。Four Keysは Deployment Frequency , Leadtime for Change, MTTR, Failure Rate の4つがあり、それらを俯瞰してみていくことでDeveloper Productivityが可視化されるとされている。
実際、今取り組んでいるタスクにおいてもこれらの指標を可視化するのがこれまでのメインフォーカスになっている。それに対して、「KPIは Deployment Frequencyだ」と言うと、4つのうちから1つに絞りこむように誤解されがちだが、そうではなくて、
- Developer Productivityの向上という取り組みを、とあるFunctionと捉える
- Four Keysの指標を Functionに渡すためのInput パラメータと捉える
- FunctionにInputがあれば、Outputもあり、それが生産性向上の取り組み結果つまりKPIとなる。これを Deployment Frequencyと置く
つまり、Four Keysの指標を以てDeveloper Productivity改善に取り組んだ結果を Deployment Frequency向上に跳ね返ってきたことで測るべきではないか、という仮説だ。これは特に今所属する組織がFocusすべき指標として攻めの Deployment Frequency や Leadtime for Changeと守りの MTTR, Failure Rateであれば攻めの指標をKPIにする方が組織風土に合っているのではないか、という個人的な事情も含んでいる。特に、究極的な数値が「０」のLeadtime for Changeに対して、Deployment Frequencyはそれが「正の数値」なので、「向上」施策で「数値を増やす」ことが直感的にわかりやすいし、会社のカルチャー(Go Bold)にマッチしている気がする。
そして、これをKPIとする穴は、Deployment Frequency向上がDeveloper Productivity向上の最終的な目的ではないということだ。
Developer Productivity向上の最終的な目的はなにか？ずばり Business Growthである。すべては事業が成功するために取り組んでいる。これはとても重要なポイントだ。
しかし、Business Growthが目的だとしても、Business KPIと同じ数値をDeveloper Productivity向上の取り組みのKPIとすることはできない。なぜならそのKPIに対してダイレクトにリーチできないからだ。その間には Product Productivityとでも呼べるものがある。より良いProductを提供するための様々なファクターだ。
toCのProductだったらPMの企画設計力・仮説設定力、Designerのデザイン力、BIの分析力、QAの品質確保レベル、CSが握る顧客満足度、などなどどれも欠かせない要素が絡み合ってProductの成否を左右する。
Developerがどれだけコーヒー豆に風味と香りをつけても、焙煎と挽きの工程次第では顧客の望む美味しさにはならないかもしれない。
一方で、加工工程に一流のバリスタを置いていても、豆そのものの質が悪ければ期待したクオリティにならないのもまた同様だ。
そして何より、製造・加工それぞれがベストを尽くしても、「顧客にとってそれが美味しいと思うものか」はわからない。
加工工程でどう処理するかもわからないし、顧客が何を望むかもわからない。しかし「だから我々Developer はただ『質の良いコーヒー豆を提供すること』にfocusする」というのはたとえ論理的であっても、それがゴールになってはいけない。何故なら我々Developerも顧客に提供したいUXは例えば「ホッとするひととき」であり、それを達成するためのProductは豆ではなく、飲み物としてのコーヒーだからだ。
なんのためにDeveloper Productivityを向上させるのか
Developer Productivity向上という取り組みに対して、
- Business KPIは本質的には追いたいが、成果が見えない数値であること
- Technicalな数値(e.g. Deployment Frequency)だけを追いたくはないが、成果が見える数値であること
これらを理解した上ならば、それぞれの数値を扱うのも良いのではないかと思う。
これはEMFMで言われている「物的労働生産性」と「付加価値の労働生産性」の違いだと思う。
ここまで考えれば、最終的に我々が目指しているDeveloper Productivityの向上というのは、ただ「コーヒー豆を大量生産する」物量の話では決してない。コードを書いてデプロイすることそれ自体に意味はない。「多くの顧客の”それぞれ”が美味しいと感じるコーヒーを飲んでもらえるようにするために、様々な種類の良いコーヒー豆を提供する」ことを目指すべきだ。できるだけたくさんの種類で、できるだけたくさんの量を、できるだけ早く。
Sortware Engineerであるならば、高い技術力で、多くのコミットを、素早くデプロイ、とかになるのではないだろうか。それによって Productの仮説検証の回数と確率を上げて、Business Growthに至るのが理想的なストーリーである。
子育てで活きる目標設定と期待値調整
そういえば、子育て情報が育休時の生後4ヶ月くらいで止まっていた。
3歳も無事にすぎてすくすく育っており、せっかくなので、その後のメモを残しておきたい
(前置き) 子供の成長のログ
大体、1歳くらいで歩けるようになる。この頃になると、行動範囲が増えるので、それまでは家の中をうろつくだけでラクだったなぁと今にして思う。
大体、2歳くらいから言葉を喋るようになる。今振り返ると、それまでの意思疎通をどうしてたのかもう思い出せない。喋れなくてもなんとなくわかっていたのは今にして不思議。
1歳半くらいから一言くらいの言葉なら発するようになった気がする、2歳を迎えてようやく「公園、一緒、行く」みたいな文が繋がった時に感動したが、それから会話になるまでがあっという間だった気がする。
うちの子の場合、夜泣きがなくなったのは多分2歳半以降だと思われる。寝たあとに仕事をし直してから、遅れて寝る。というのができるようになったのはこれ以降。それまでは、そもそも寝るのが遅くて23時近くなることも多かった。「寝るのにも体力が必要」というのは逆に自分がこの歳になって、年々睡眠時間が減ってきて感じることでもあるが、まだ小さいこの時点では身についていないのかもしれない。
1歳半頃に夜泣きで起きてから寝かすのに散歩(AM2時）とか、2歳頃に寝かしつけのために外を1時間散歩(22時頃）とか、時期はそこまでピンポイントではないのだが、記憶にあるのはその辺。
(本題) 子育てで意識しているマネジメント方法
前置きメモはこれくらいにして本題はここから。
子育てをしていて、仕事のピープルマネジメントが役に立ったと思うのは「期待値調整と目標設定」だ。
これは普段から日常的に意識して取り入れている。
とにかく子供は、やりたいことを無限にやりたがる。散歩でも、ブロック遊びでも、お風呂でシャンプーの栓をプッシュしつづけるでも、ずーっとやる。これをいきなり制してしまうと大体ギャン泣きになる、けど、こちらとしては止めてほしい（特にシャンプーのプッシュ）。
その時には「あと1回で終わりね」と言ってから、止めるようにしている。目標を共有した上での行動を促す期待値調整だ。
多分1歳になる前くらいから取り組みはじめてたと思う。と言っても子供の期待値など不明瞭なものなので、約束したところで「まだやる！」というのは日常的にある。それでも「じゃあ、あともう1個ね」と折れることも必要で、「もう1個」がN回続くことも当然ある。それじゃ意味ないのでは、とも思われるがどこかの段階で「1個って言ったので終わり」と区切って、強制終了させる。
それで結局ギャン泣きになるんだけど、「それはお前が約束しただろう」と大人側が割り切ることができて、甘やかさずにギャン泣きを受け入れるためにも期待値調整は必要。実際に、初回の「あと1個」ですんなり終わるケースもあるから、それはそれで子供の成長を感じられる。
大人が持つ事情という子供にとって見えない目標
何かを止めさせたい時には、大抵は大人側の事情がある「ご飯を食べさせたい、お風呂に入れたい、寝かせたい」などが筆頭候補。なので、その意図を伝えることも大事なポイントだ。つまり目標設定。「お風呂に入るから、おもちゃはあと1個遊んだらおしまい」と伝える必要がある。「お風呂に入るから」を省くと、おもちゃは止められても結局別の遊びをしたがってもう一戦交えることになるだけである。
おもちゃ遊びの「あと1個」の先に、「別のおもちゃ遊び」があるのか「お風呂」があるのかは子供には想像できないし、子供の目標は往々にして「別のおもちゃ遊び」だったりする。ここで、「あと1個」をちゃんと守れたのに「じゃあ、お風呂入ろう」って言われたら、「それはイヤー！」ってなってしまう。
普段1on1でメンバーの仕事を「これをやりきりましょう」とだけ言っておいて、いざ評価の際に「この達成度だとこれくらいの評価（=実はメンバーはもっと良い評価を期待値していた）ですね」というフィードバックに「思ってたのと違うー！」という状況と似たようなものである。
形骸化しないために
「あとテレビ1話みたらお風呂入ろう」とかが日常会話になって以降、子供も成長して慣れてくる。すると今度は子供側から「1個見たらお風呂入るからテレビ見たい」とか打診するようになってくる。そういう時は大体1個で収まらなくて1個見終わったあとに「もう1個」とか平気で追加リクエストしてくる。ここまで来ると「条件提示すればテレビが見られる」と子供はわかっていて「1個」に意味がなくなっている。単純によく聞かされる「1個」をそのまま発しているだけである。
これをそのまま受け入れてしまうと「目標のための認識合わせ」にならなくなってしまい、やりとりに意味がなくなってしまう。なので、「本当は何個見たいか言いなさい」と問い直すようにしている。すると、「3個」とか真の要求が引き出せるので、キチンと目標のためのすり合わせが行われる。例えすり合わせた結果だとしても結局「あともう1個」となる時もあるけど、それも時に許容し、時に却下し、で賑やかな日常となっている。
簡単だけどまとめ
いずれにしても、「なんのために、何をしてほしいか」を話し合うことは子育てでもマネジメントでも重要である。
と、マネージャーっぽく書いているが、実は最近はマネージャー業は全然していない。ただのプレーヤーとしてやらせてもらっている。それこそ子供が産まれてからピープルマネジメントしていないが、それができている人は本当にすごいと思う。
家でも会社でもこれやってたら、自分のエゴを出すところがどこにもないので、精神的にキツいと思ってしまう。少なくとも絶対疲れる、というか家でやるだけでめっちゃ疲れている。仕事でプレーヤー側でいさせてもらえていること改めて大変感謝である。
Technical Product Managerとしての1年の振り返り
まえがき
アップデートできてませんでしたが、約1年くらいTechnical Product Manager(以降 TPM)のRoleを担当しているので、その振り返りです。 ちなみに今回はRole変更エントリではなく、まだ引続きこのRoleを続ける予定です。
What is TPM
JDが公開されているので、まずはこちらを御覧ください
Why TPM
きっかけは 「TPMの組織を作ろうと思うので来てくれませんか？」と現在 Smartnewwsで活躍する @tairoに誘われ、「TPMってどういう仕事ですか？ というかPMとの違いは？」という俺の問に対して「まさに僕みたいな人のイメージです！」と説明されて、とてもすんなり合点がいき、それならばやってみたいと思ったのがきっかけです。
When,Where TPM
いつからという意味では、冒頭にも書いた通り、現在で1年とちょっと経ったくらい。 どこの領域という点に関しては、過去に記事にもなっていたこのあたりです。
How TPM
これは社内でも話題に挙がる項目でもあり、社内向けにも説明用ドキュメントが作られたりしているが、一言で表現するとまんま「Technical knowledgeを持ち、それを用いてProductを成功させるProduct Manager」となる。 これだけ書くと、PMの上位互換のように感じるが、それはある意味正しくて、ある意味正しくない。というのも、plain なPMという定義がもはや難しいと思っているからだ。
上記記事がとても参考になるように、PMに求められるスキルが高度・多様化する中で、何かしらの専門性を持つPMというのは増えているし、今後も増えていくと思う。数あるその方向性の一つの亜種に過ぎないと思っている。エンジニア向けに説明するなら、PMというのが「Software Engineer」と同じくらいplainなものを指していると思うと良さそう。
これだけでたくさんのことが書けてしまうし、議論ができてしまうが、この記事のメインはそこではないので、細かい定義はここまでにしておく。
現状課題
という訳で、仮にもPMの端くれなので、やることはProduct Managementになる。ここが大事で、Project Managementではないということだ。 両者の違いも難しいが、ProductにはLifecyleがあり、それはProjectのように一直線のものではないのが一つ差かなと捉えている。
- Product Concept
- Product Design
- Product Development
- Product Delivery
- Product Maintenance
- Back to Concept(= Step1)
これも様々なフェーズ分けの定義があって、上記は一例だけど、要は開発して終わり、リリースして終わりではない、ということだ。
このサイクルと自身の作業との振り返り比較で言うと、ようやくサイクルを1周できそうかどうかというレベル。この 1年かけてようやく というスピード感と経験の薄さが現状の最も大きな課題と感じている。
もちろん開発やリリースするのに色々な課題がある。リソースがなかったり、逆にブロッカーがあったり、などなど。
とはいえ、その辺を解決しつつ進めることこそが仕事であり、逆に進めることで成果を出すことがProductの改善につながると思う。
本当であれば、1つのCycleとして振り返り、何をやってどうなったから、次にどうするのか、ということがここで述べられるのがベストなのだが、そこまでには至っておらず、現状における成果をこれ以上に書けないのがとても悔しい。
Technical というPrefixに関しては、メルカリにおけるEngineering経験を活かすっていうことはできている部分があると思う。具体的にはコードやアーキテクチャを知っていることでできる設計の部分などだ。一方で、それは汎用的なTechnical knowledgeではなくドメイン知識だと思っていて、他の環境で同じことができるとはまだ思えないのが正直なところ。
これも大きな課題で、 ただのEngineerがPMの真似事しているな と見られてもおかしくないようなことしかできておらず、PMとしての専門性はまだ全然だと思うのは前述のサイクルを回しきれていない点が物語っている。
Individual Contributor との違い
EngineerからPMというRole変更は以下の資料における振り子を振った状態にあると思っている。
まず、どうして振り子を振ったか、という点であるが、PMの良さとして、Productの What（何をするか） にフォーカスできる点が挙げられる。対してEngineerは How(どうやるか) についてフォーカスできる。（もちろん両方とも「フォーカス」であって、それしかやらない訳ではない。）
Backend(サーバーサイド)領域を抽象度を上げて表現すると、「RDBにデータを出し入れしてレスポンスを返す機能」という1つの大きなHowで括ることができるとして、この1括りのHowで解決しなければいけないWhatは山程ある。
おそらくこれを「1括りのHow」とするのに多くの意見があって、
- 言語の種類やその性質による開発スピード、規模、パフォーマンスなどの違い
- インフラ設備の違いによるコスト、Availability,Mutabilityなどの違い
- NetworkやSecurityなど環境によるコストや制約などの違い
など他にも挙げきれないような多くの差異要素があることはもちろん知っているつもりだ。しかし、それらの要素は全て何らかの課題を解決するための手段として存在・提供しているものだ。 それぞれの要素の特徴や差異の意味を全て詳細に把握はできなくとも理解できるのならば、それを1つの大きなHowとして、多くのWhatの解決に向き合うのは良い経験になるのではと思ったのが振り子を振った理由だ。
逆に、自分の中で勉強不足で全くピンと来ていなくて括りの外にあるのが、例えば機械学習分野。RDBからSelectする代わりにそれと同じような感覚で機械学習モデルからデータを引くようになったとして、そのシステムの当たり前さをどれだけ咀嚼できているかは今時点ではさっぱりだ。この不透明さによってWhatにフォーカスできなくなるようなら、それが振り子を戻す時かもしれない。
まぁ、でもここまで書いて、完全に逆もまた然りだなと思った。 「顧客の求めるサービスを提供する」というのを1つのWhatという括りにするなら、それを解決できるHowも山程ある。その山を自身の中に積み上げる目的で、エンジニアとして技術力を磨く、というのも全く成り立つし、とても良い経験になると思う。
EMとの違い
一応、かつてEngineering Managerをやっていたので、それとの比較も書いておく。
個人的な経験だけでもの凄い簡単に言うと、
- 人のために人にアプローチするのがEngineering Manager
- Productのために人にアプローチするのが Product Manager
だと感じている。結局どちらも人にアプローチするのは一緒、というのがまず大事なところ。
この時、アプローチに行き詰まった際に、突き詰める先としてEMの場合「あなた」というベクトルに対して突き詰める訳だけど、ここが個人的に難しかったポイントだと思う。 「あなたのことを考えに考えて、○○したいんです」というのは、恩着せがましいというか、おこがましいというか、それってなぜ自分がやらないといけないんだっけ、と思って躊躇うことが多かった。
一方PMの場合は、「Product」へのベクトルを突き詰めれば良い、具体的にはプロダクト開発をしたいためにエンジニアにアプローチして、それが合意されない場合おそらくQCDのどこかに問題があり、それぞれについて突き詰めることになる。 Qualityを上げるのか、Costを下げるのか、Deliveryを遅らせるのか、とかを検討できれば合意できるケースが多いのではないか。もちろん例外もあるだろうし、QCDのどれかがUncontrollableであることも往々にしてあるだろうが・・ それらがControllableであるならば、QCDへのアプローチがReasonableかつLogicalであればあるほどその分だけ合意に近づけやすい。またReasonableかつLogicalにやるっていうのはエンジニア脳を使えて、やりやすくて良い。
そういう意味では、今の環境がQCDがControllableなので、恵まれているのかもしれない。。より厳しい環境でPMをやった上でのEMとの比較が必要かもしれない。
・・・と、ここまで書いて思ったが、QCDというのは実は浅い課題で、深い行き詰まりだとProductのMission/Vision などへの不合意になるのではないか。これらを突き詰めてエンジニアにアプローチする際には、Logicalに、だけでは成功しない。Logicの積み上げだけでVisionには到達しないからだ。むしろある種の熱意を持ってアプローチする必要があり、それは俺のめちゃめちゃ苦手な分野に該当する。PMだからLogicalで簡単というのはおお大きな誤りということになる。
しかも、もしMission/Visionが語れるのならば、EMとしてももっとできることがあったかも、とも振り返れる。多分
- 人のために人にアプローチするのがEngineering Manager
この前提自体が違っていて、あるべきは『組織のために人にアプローチするのがEngineering Manager』だ。 思い返せば、EM時代もMission/Visionをマトモに考えられたことはなかった。どういう組織（これはEngineering Division全体もそうだし、自チームもそう）にしたい、という明確なモノは持っていなかった。当時、人に翻弄されているように感じたのは、指し示すものがない中で彷徨っていた感があったかもしれない。暗中模索という言葉がまさにしっくり来る。
つまり、結局Roleは変わっても自分の突き当たるべい苦手分野は一緒で、それは克服はできていないのでは、と思い始めてきた。
何が言いたかったか
それなりの理由を持って、TPMに取り組もうと思ったのでその背景整理をしつつ、現状課題というこの1年の整理を書き残すのが当初の目的だったが、Enginner及びEMとの違いを補足で書くつもりが、実は大して違わないし、課題は同じだった、ということを書きながら思ったのが自分自身の収穫になったというオチ。
書いてみたら、小さいもの課題として捉えてた反省が見つかった。いや、小さくはないか、基本的な事で事実自分には足りていないものだが、それよりもっと大きな根本的な課題があるのがわかったという学びか。
おまけ
再掲ですが、ちょうど最近OpenになっているJob Descriptionはこちらです。 ご興味のある方は、カジュアルにでも構わないので、ご連絡ください。
