ビッグバンドで初出演してきた

昨年入団したビッグバンドの本番を先日無事に終えた。

入団した時は、本番が1年後なんて気が遠いなーと思っていたのだけど、振り返るとあっという間だったし、ビッグバンド初体験の自分にとっては1年間という練習期間が必要十分だった。

本番前2週間は、毎朝1時間スタジオを取って練習していたのだが、この練習を裏切らない成果を出せたと思っている。

ビッグバンドに入団した動機は、上のブログにも綴ったのだが、セッションだけだと演奏やり流して曲にじっくりと向き合えず、音楽的な反省も成長も積み上げられていない、という悩みがあり、本番に向けてバンドと楽譜に向き合うビッグバンドであればそのコンプレックスを埋められるのではないか?(何よりビバップの元であるビッグバンドを経験することで、コンボジャズで演奏する曲への理解も深まるのでは)という狙いがあった。

これは成し遂げられたのか?答えは確実にYESだ。入団当初は勝手が何も分からずリズムを刻むことしかできなかったが、楽譜の読み方を覚え、ビッグバンドの音楽的な作法をなんとなく感じ取り始め、勇気を持ってフィルインを入れられるようになった。管楽器がドラムの何を頼りにしているのか?の存在意義も演奏の上で意識し始めるようになった。それまで全然知らなかったビッグバンドの曲も好きになったし、次の本番に向けての課題もいくつか浮き彫りになった。

そして、こうした経験で培った手数やフレージングは普段のセッションにも大いに生かされている。

というわけで、1年間あっという間だったが、飛び込んで良かったという記録。

聴講メモ:EMConf JP 2026

はじめてEMConfに参加してきた。マネジメントから離れて今はいちメンバー(IC)として業務している。マネジメントへのやりがいを感じ始めつつも、ICに戻る(そのための転職)決断をしたのは、筆者の経歴が、超少人数チームでの開発経験か、超上流〜上流の業務あるいはマネジメント(それも受託開発事業で営業寄りの業務が中心)と偏っていることが悩みで、まともなチーム開発の業務・現場を知らないことには、今後どちらのキャリアにも立てないと思ったからだった。なので、いずれまたマネジメント業務に携わりたい意欲もあるし、その時は「エンジニアリング・マネージャー」を名乗れる経験・知見を積みたいと思っていた。

その背景もあって、EMConf にはいつか参加したいと思っていたが、去年はチケット完売していて参加できず、ようやく今年その願いが叶った。

普段参加しているカンファレンスや勉強会とは一味も二味も違うテーマ主体のカンファレンスで非常に学び甲斐があった。特にキーノートセッションの「冒険する組織のつくりかた」は、SMARTでなくALIVE、というまさに筆者自身も感じていた当たり前とされていた目標設定のありかたへの違和感が言語化されていて目から鱗だった。内発的動機を引き出すための対話のヒントも得られた。

他のセッションでは、マネージャーとしての「しくじり」のシェアが多くて、過去の経験や今の行動を振り返っては、自分だけでなかったんだと背中を押された感覚があった。開発の失敗談は勉強会やソーシャルメディア上で頻繁に共有されているものの、組織やピープルマネジメント、経営層とのコミュニケーションに関する失敗談に触れられる貴重な機会だった。

また他にも共通して感じたことは、事業目線の築き方としての数字との向き合い方、ROICの話が非常に面白かったのだが、「数字は結果」としてその裏にある顧客・組織・人にどう自ら接続していくかというヒントがたくさん転がっていて、自分は全然ここが足りていないなと反省した。

イベントページ:https://2026.emconf.jp


冒険する組織のつくりかた

株式会社MIMIGURI 安斎 勇樹 さん

  • 問いのクオリティが「3人寄れば文殊の知恵」に影響を与える
  • 20世紀ビジネス経営論の課題:ビジネスとは「戦争」
    • 軍事的世界観に基づいて構築されてきた(戦略、戦術、顧客を「刈り取る」、マーケットを「制圧する」、研修、フィードバック)
  • この20-30年での価値観の変化:会社中心から人生中心、中心地の変化
    • 会社に隷属↑自己実現の探求
  • 冒険的世界観にシフトしている過渡期(不確実の中で自分の好奇心を資源にしながら)
    • マネジメントの世界観も変化:
      • 軍事的:戦略、計画の遂行と管理
        • 不確実な時代では価値観の定義が難しい(数字を追う→なぜ売るのか?探究し続ける必要性)
        • 学校教育にも変化(ソルジャーを育てる世界観)
      • 冒険的:社会的ミッションの探究と個々の自己実現との共鳴両立
  • 組織のカルチャーの4象限
    • 外向き・内向き、合理・感情(軍事的官僚的、冒険的、家族的)
    • 軍事的文化が、大企業病で官僚的になり、(メガベンチャーが陥りやすい官僚的文化による硬直化)
    • 上に戻そうと、外向きだが感情的な冒険的文化に向かう
  • 半径5mから出来る手触りのあるマネジメントの突破口
    • 目標、会議、興味、文化
  • 目標のマネジメント
    • 目標にテンションが上がってない、形骸化している、目標がない、覚えてない(機能していないってどういうこと?)
    • 人と組織の創造性に最も影響を与えるのは結局、目標(個人チームに設定されているもの、それをメンバーがどう受け止めているか?)
      • 納得していない、内発的動機がない、みんなでやる意味を感じていない、であれば、組織作りは無理ゲー
      • なぜ疎かになる?:旧来の軍事的なマネジメントにより、目標への視野狭窄を作ることが背景にあった(目の前のことだけをやって全体を回す仕組みづくり)
      • これまでの目標設定の基本原則「SMART」→それがないままマネジメントすると言い訳するからあったほうがいい、という管理側の論理(やる側はSMARTだからといってテンション上がらない→BOTになる)
    • 対抗策として、ALIVEの法則
      • Adaptive/Learningful/Interesting/Visionary/Experimental
        • Adaptiveが一番重要:外部環境、未来がどう変わろうが「潰しが効く」意味のある手段(e.g. サッカー選手 vs TikTok)これできるようになると、こんな/あんなキャリアにも効くよね
        • 誰がやっても同じ、でなく、どうやろうか?実験要素の余白があること
      • 目標がALIVEであるかでなく、みんなが「ALIVE」に受け止めているか、意味付け出来ているかが重要
    • テンション上がる目標を立てるだけでなく目標を立てる前後のコミュニケーションが重要→ヒアリングと参加型デザインでALIVEにしていく
      • 設定前に動機の芽生えを収集しておく→どう伝えると前向きに接続するか?ストーリーテリングで、メンバーの内発的動機と達成すべき目標をうまくミートさせる(ヒアリング)
      • チームの中でも、対話しながら一緒に考えつつ、上から降ってくる目標もうまく溶け込ませる(参加型デザイン)
      • ALIVEの点数付、どこを上げていきたいかは人によって違う(Learning? Interesting? を1on1で相談したり、チーム定例で話したりするとうまくいったケースも)
  • 興味のマネジメント
    • 生成AI時代に大事なキーワード:興味拡散
      • 興味を深く持っているか?興味の深掘りは「技術的」に行える
      • 好奇心と興味の違い:好奇心は好き嫌い含むが、ある好奇心が一定期間特定のものに当たり続けている→好きに定着する状態
      • 散漫なまま集中させられない、興味拡散する状態は、生成AI時代にマッチしない
    • 人には興味のツボがある、ここに刺さることで目標がALIVEになる:ツボは人によって驚くほど違う
      • 内発的動機の多様性を活かすのがマネジメントのカギ
      • 旧来のキャリア支援の定石が機能しなくなってきている:やりたいことは?将来のビジョンがわからない(X年後の目標を起点にした目標逆算できない、WILLハラスメント)
    • 今何を面白いと思っている、何に興味が向きがちなのか?を育成の手がかりにする
      • 結構これをメタ認知、言語化できていないケースが多い
      • 「生成AIに興味がある」は一緒でも、なぜ?はそれぞれ違う
      • ヒト or コト で別れる、このグラデーション(ヒトがどうなる?どんなビジネスが生み出される?)
      • 興味の活動スタイルの8タイプ(想像、解明、介入、運用とのマトリックス)で、チームメンバーの興味傾向を把握しておくことで、マネジメントコストを下げられる
      • マネジメントは罰ゲーム?従来はコト寄りが多かったが、現代はヒト寄り
        • 「人間の心理的なメカニズム」もコト寄り
      • メンバーの興味のレンズがわかるとマネジメントが楽になる(興味=レンズx対象)
  • 会議のマネジメント
    • 何かアイデアないですか?遠慮なく意見ください→「全然リアクションがない」画面オフ、ミュート状態
      • 問いが悪い、オープンクエスチョン:ひとつだけ変えるとしたら?もし客だったら難点をつける?あとXX点上げるとしたら?今パッと頭に浮かんだことがあれば、など
      • 「特にないですね」を誘発する問いかけ→人間はゼロイチは難しい
        • → 3年後やりたいこと?
      • 具体的な回答が得られやすい問いかけにする:選択肢や点数は疲れていてもやる気がなくてもできる最小単位の主体性
        • この1年の仕事を振り返って、どれがおもしろかった?
  • 文化のマネジメント
    • 目標設定をどうするか、受け止め方をどうするか
    • 半径5mを飛び出しているように見えるが、カルチャーを作ったほうが良い
    • 風土(climate)と文化(culture)の違い
      • 風土:その集団の雰囲気やイメージ、メンバーがどう感じているか(オープン、風通し、仲良し、雑談の多さ)
      • 文化:秋葉原や渋谷のように、他の組織には見られない固有の価値基準、効率よりも遊び重視、打ち上げたくさんやる
    • 良い組織:風土改善だけでなく、文化を耕すこと(刷り込み続ける)ことでマネジメントコストを下げて良いチームづくりができる
      • ハレ(キックオフや打ち上げ)の場での投資、習慣、ルールに組み込み、価値規範を繰り返し伝える、体現したメンバーを称賛

「事業目線」の正体 〜3つのフェーズのCTO経験から見えてきた、EMが持つべき視点

sotarok さん

  • 「もっと事業目線を持って」
    • 言った、言われた
    • 「事業目線」を体系化、言語化した
  • なぜEMが事業を知る必要があるのか
    • 書籍:エンジニアリングマネージャーお悩み相談室
    • そもそもマネジメントとは?
      • ピープルマネジメント(評価、採用)、承認とかではなく、
      • 事業活動を成功に導くために、自組織のアウトプットを最大化する
    • EMは、これにエンジニアリングの専門性の掛け合わせ:専門領域を用いて事業を成功に導く(支えになる)マネージャー=事業を知ることが必然
  • 事業目線とは
    • 事業は、関連部署が取り巻き、経営目線とお客様目線に挟まれている
    • EM初期は、プロダクト以外は見えていない:お客様目線、経営目線、他部署が見えていない
    • 事業目線を持つと、、:自分の立場と経営目線、顧客目線、関連部署とが接続できていて、関係性が構築、理解できている
  • これを獲得するためのステップ3段階
  • Lv.1 数字を知る
    • 自組織に関わる数字を自信を持って言えるか(トラフィック、売上、ユーザー数、登録数、、事業KPI/KGIから一歩ブレイクダウンする)
      • e.g. 決済に関わるチームなら、カード登録リクエスト数、一人当たり決済額、頻度、失敗数
      • 見える状態にする:見えないものは考えられない
      • 具体的なアクション:クエリを叩く、ダッシュボードを作る、定例会議をする
      • 副次効果の実例、SMS認証のスパイク、クレカ登録リクエストのスパイク
        • こうしたセキュリティ施策のための工数確保
        • プロダクトロードマップに影響、リスクをエンジニア目線から説明し工数の捻出戦略
    • 事業予算の構造を知る
      • 売上目標→実現するための施策→各部門の役割分担(自分の部門がこの構造のどこに作用しているのか)
      • 具体的なアクション:数字の因数分解、売上を要素に分解、どこかのポイントに自組織に接続する部分が出てくる(e.g. 売上=決済額xMAU→MAU=前月MAUx継続率→継続率=…、画面UI/UXなど、活動の意味付)
    • 今日のギャップは過去の計画の失敗:今日のギャップを知ること
  • Lv 2. 顧客との隣接組織を知る/顧客を知る
    • 数字:過去の結果の積み上げ
    • 数字の裏にある人と仕組みを見る必要がある
      • 数字:何が起きたか
      • 顧客:なぜそうなっているか? エンジニア視点でCS, PdMと違う気づき
    • CSがマニュアル通りに返答(CSの正解)→これだけの問い合わせがあるならプロダクトをこう改善するべき
      • 自組織や他部署がその解決法を取らないのはなぜか?
    • 具体的なアクション:ユーザーインタビュー、営業動向、展示会イベントのブース対応、CS対応、レビューを読む、NPS
    • なぜ隣接組織を知る?組織によって、それぞれの業務フローや力学があるから
      • e.g. CS、営業、法務、経理、、
      • e.g. 他部署の日報を読む、Slackチャンネルを見る、定例をオブザーブ、自チームの影響範囲をマッピング、他部署マネージャーと1on1
  • Lv 3 戦略に反映する
    • 数字、顧客、隣接部門の構造と力学を知る
    • ソフトウェアが事業に与える影響を理解し、何を作っているのか?を理解した上で体制づくりをする
    • 戦略に反映する:予算策定、事業ロードマップ、組織ロードマップ、採用計画
    • マネージャーのアウトプット=自組織のアウトプット+隣接組織のアウトプット
      • 自分だけが事業目線を持っても、自組織のアウトプットにつながりにくい:仕組み化してチームの活動に組み込んでいく
        • e.g. チーム全員が見れるところにダッシュボード、仕組みで違和感に気づける
        • e.g. エンジニアオンボーディングにCS研修を組み込む
  • 全部やるとCTOでは?全体像を把握した上で、自チームに重要なところから
  • 数字の見える化はすぐ効果が出る:頑張って作ったXXXの機能が使われているか、、

提案のレベルを上げる

こにふぁー さん

  • ブログがベース
  • 叩き台を作ると提案のスピード上がるが、誰でもできるわけではない、そこをレベルで分けてみた
  • 指摘→整理→意見→意思決定の促し
  • こうしたコミュニケーションは意識的無意識的にやってると思うが、マネージャーになった後はどうか?
  • マネージャーになったら、何を整理、提案したら良いかわからない状態
  • リセットされてしまった感覚
  • なぜ難しく感じるのか?
    • 広がりの変化が起きる:関わる範囲、考える時間軸、取りうる選択肢
  • どう適応していくか?
    • 理解と覚悟、理解してやり切る
    • 理解:役割と意思決定プロセス、自チームと他チームの役割、目標、価値観を説明できるか?
      • 組織図、目標、会議体、予算を抑えると理解しやすい
      • 予算権限がないからコントロールできない、ではなく、予算の全体感と予算の決定プロセスを知っておくと、そこに介入できる
    • どう把握するのか:話して把握するのが早い(組織図を眺める、マネージャーと飯、1on1、冗長に聞く、隣接マネージャーに目標を聞く、、)
    • 理解ない状態での失敗例
      • 開発組織の立て直しの経営コミットメントの提案:経営目標とのアラインや意思決定プロセスを理解せず、ただ意見をぶつけただけ状態
        • 経営目標を確認し、そこに行き着くにはという視点で、今なら、協議相談の会議体を移管して、意思決定をリードする
      • インフラコストの削減:自チームの固定費変動費を意識していなかった、
        • 継続的にコストを見直すべきだった
      • AIコーディング予算確保
        • 予算への考え方が足りなかった、必要だからという説明。時間がかかったのは、経営への説明のための説明準備、脇を固めまくったが、拍子抜けするくらいポジティブに捉えられた、もっと早く言ってよ。予算に対する考え方の理解が足りなかった(お試し、レポーティングすれば予算出すと言われた)
    • 覚悟
      • 一発でスマートに提案できることばかりではない、いきなりLv2, 3 で持っていけることの方が少なく、不確実で不明確な課題である事実を認識し、Lv0で持っていく、誰と話すか、初手で持っていくレベルの引き出しを増やすのが重要
      • 提案時、未来永劫これで行く、と捉えられることがあるが、
        • 振り返りと軌道修正のプロセスを前提とするのが大事:提案Lv2
  • 提案レベルを上げるには?
    • 一人でいきなり高いレベルを目指さず、周囲を巻き込んで意思決定するためにレベルを使い分ける
    • 自分で何度も繰り返す自己体験、他者の提案を観察する擬似体験の数を重ねる

トップマネジメントとコンピテンシーから考えるエンジニアマネジメント

zigorou さん

  • EM向けドラッカー入門
    • 企業とは何か?利益ではなく、顧客の創造
      • 顧客が価値を認めて初めて事業が成立する
    • 顧客を作る基本機能:マーケティングとイノベーション
      • 顧客の要求から出発し提供を合わせて自然に売れる
      • 顧客の創造には資源が必要、それが投資、投資効率を上げるにはコスト削減ではなく生産性に注目
      • 利益は原因ではなく結果、次の再成長への原資
      • 事業とは
        • 会社の内側からではなく、顧客と市場から始める
        • 顧客が満たそうとする欲求は何か?
      • 顧客とは?一種類とは限らない、支払う人、使う人、選ぶ人
      • 顧客が買っているのは製品ではなく効用、感じる成果や体験は何か?
      • イノベーションとは
        • 変化を踏まえて次の価値を設計、過去の延長ではなく新しい機会を創造
    • 8つの目標
      • マーケティングの目標:最適なマーケットポジションを担う(最大ではなく)
      • イノベーションの目標:失敗を前提として、成功が全体を回収するつもりで設計
      • 人的資源、資金、物的資源、生産性、社会的責任の目標、、
      • 利益の目標:利益は目的ではなく条件、再投資への原資
    • マネジメントとは?
      • 使命の達成、人の活用、社会的責任
      • 時間の統合:現在(マーケティング)と未来(イノベーション)
      • 管理的活動(マーケ)と起業家活動(イノベ)
      • マネージャーとは、命令する権限ではなく、組織の成果に対して貢献する責任
        • 部分ではなく大きな全体を作る
        • 5つの基本作業
  • マネジメントをEMに落とし込む
    • 顧客は誰?開発チームのリーダー、開発チーム、エンジニア、事業部門、エンドユーザー
    • EMによる価値提供、提供するソリューションと創出されるアウトカムのテーブル
    • マーケティングの目標とEM
      • マーケの目標における問いを翻訳する
        • どこに集中するか→どの顧客価値に寄せるか
          • 戦略的意図を開発の言葉に翻訳し、投資配分を運用可能にする
        • どのポジションを狙うか→選ばれる理由を成立させる運営能力をどう作るか?
          • マーケットポジションをサービスレベルに落とす
    • イノベーションとEM
      • 次の顧客価値を定義、事業は何であるか
      • 新しい満足を作り、古いものを捨てる
      • 仮説実装計測学習のループを短く、意思決定の精度を上げる、その基盤
      • 失敗を前提に、探索投資の枠を確保、主要な賭けに十分な厚み
      • 活動量で評価
    • 生産性の目標
      • 人の頑張りでなく、投入資源を成果に繋げる仕組み
      • 価値提供への変換効率
      • DORA capability
      • ソーシャルダイナミズムが高い状態だと生産性が高い
  • Engineering Ladders
    • EMがメンバーと期待値をすり合わせ、キャリアプランを検討するためのフレームワーク
    • 4つのロール:Developer/Tech Lead/Tech Program Manager/Engineering Manager
    • 5つの軸:Tech, System, People, Process, Influence
    • 各軸ごとに5段階の要求水準がある(ルールを決める側かリードする側か)
    • EMのラダー
      • 一貫したデリバリー、メンバーのキャリア成長や幸福度に責任を持つ(ソーシャルダイナミズム)
      • Tech LeadがSystemを主に担い、EMはPeopleを主に担う
    • 他職種との対比
      • 影響範囲(Influence)を固定して役割差分を見てみる:
        • Team Lv2 で固定すると、他の部分で上回っている必要がある。Tech Leadがいない場合は、TLの役割に介入する必要がある
        • Multiple Teams Lv 3で固定すると、ほぼ下回っている、
  • EMのアウトカム
    • 組織ニーズと個人のキャリアがマッチするアサインを意図的に
    • 自律的なチーム構築
    • 多角的なステークホルダーマネジメント
  • 評価は、うまく管理できているか、ではなく、出せているアウトカムで決まる

守る「だけ」の優しいEMを抜けて、事業とチームを両方見る視点を身につけた話

mitsui さん

  • 崩壊寸前のチームを生存させるまで
    • 退職異動でチーム崩壊寸前
      • 組織コンテクスト、ナレッジの断絶
      • 対象ドメインが複雑かつ膨大→インシデント
    • 守り、盾の戦略:外部からの依頼を徹底的に整理、チーム内でも同時進行を減らし、一つずつやり切りスイッチングコストを排除、そこにモブプロや対話で知識共有(4人全員で動ける状態)
    • 採用異動でチーム体制の回復とデリバリー安定
  • 新規プロジェクトで前に進める振り切った話
    • 転換点、槍の時代
    • 別プロジェクトでロードマップ的にも体制的にもハード
      • ドメイン知識が自分にはあるが他メンバーにはない偏り
    • 少人数、知識差の状況は崩壊時に似ているが、生存ではなく、成果を出し続けることがミッション
    • それまでのリーダー像:サーバント、ピープルマネジメント徹底でボトムアップ
      • 「弱めのEM」
      • 守る姿勢、支援が、前に進めたいフェーズだと停滞に変わる
        • ピープルマネジメントが厳しい意思決定における免罪符に
    • 「細かいことは後で考え、今は自分が決めて進める(覚悟を持つ)」
      • 合意形成→即断
      • 采配と調整を一手に引き取り、分散させるより判断速度を上げる
      • ゼロベースの設計の初動を引き取り、詰まったら即介入する
    • ただ、全員で回す仕組みは残した(スクラム、毎日1時間の相談会での対話)
    • 重要機能の実装はできるメンバーに任せ、貢献実感を感じてもらう
    • しかし、しわよせが生まれた:透明性、合意形成、自律性(これからしっかり作っていく)
  • 守りと攻め、どういうバランスにする?
    • 事業推進と、チームの健全さ/負債解消 これらはトレードオフなのか?
    • 「その意思決定が企業価値にどう影響するのか、で考えれば良い」
    • DCF法、事業価値の計算式(を企業価値に置き換え)
      • EMの判断は、CF(cash flow)とr(risk)を通じて企業価値に影響
      • 事業貢献とは、キャッシュフローを上げていくこと
      • 反対に、リスク(リスクを取り続ける、リスクが大きい)が企業価値を削る
  • 結論:事業貢献だけでもピープルマネジメントだけでもなく、企業価値への影響を考える

「開発生産性」ではなく「事業生産性」こそが本質 ~ ROICで紐解く、開発の「稼ぐ力」の最大化 ~

江副 廉人 さん

  • EMという型にハマろうとしていないか?(経営との接続、開発生産性、ピープルマネジメント、、)
    • 本質的には事業成長とステークホルダーへの還元
  • 我々が働く意義
    • 株式会社=投資家からの資本を集め事業活動を通じて得た価値を最大化する→投資家に還元し、さらに投資を呼び込む好循環
    • 投資家は、キャピタルゲインかインカムゲインとして利益を得る
      • 開発成果が直結するのはキャピタルゲインのほう(売却益)
      • 企業価値の向上に伴う、株価向上:企業価値は将来的なフリーキャッシュフローへの期待によって形成
        • FCFは本業のCFから事業に必要な設備投資(投資CF)を引いたもの
        • 企業価値の算出方法:DCF法
      • FCFはあくまで結果、EMとしては遠い
      • 稼ぐ力として、投下資本とFCFの間にあるROIC(投下資本利益率)=稼ぐ力(事業生産性)
        • 「ROIC経営」
  • 開発生産性の罠
    • 開発生産性の向上はROIC(事業生産性)に直結するのか?→NO
    • 開発生産性のレベルは順に上がる、という思い込み
      • LV1: 仕事量
      • LV2: 期待付加価値
      • LV3: 実現付加価値
    • 生成AIで生産性が上がっているという思い込み
      • 生産量は確かに増えるが、事業価値にどれだけ転換できるかが重要(ユーザーにどれだけ使われるか)、見せかけの生産性
    • 開発生産性を高めることが目的になってはいけない、本質は、事業生産性(ROIC)の向上
  • ROICを意識した取り組み
    • ROICを高めるメカニズム
      • ROIC=税引後営業利益/投下資本
      • 投下資本を運用視点で整理すると、運転資本と固定資産
      • 開発と関連が深い項目
        • 無形固定資産:ソフトウェア
        • 売上原価:開発費、インフラ費
        • 販管費:減価償却費など(ソフトウェア資産が減価償却される)
      • 何が言いたいか:日頃の意思決定はBS/PLに反映されている
    • CAPEXとOPEX
      • CAPEX:ソフトウェア資産への投資(将来にわたって価値を生む前提で投資するもの e.g. 建物、ソフトウェアも同様)=未来への投資、積み上がるもの
      • OPEX:インフラ費などの事業運営費(人件費、インフラ)=今かかっているコスト、ワンショット
    • 開発者が知っておくべきROICを高める視点
      • 分母の投下資本を最適化するか、分子のNOPATを上げていくか
      • 利益を高める開発なのか、資本を効率的に活用するに資する開発なのか
        • SpeakerDeck参照
    • ROICを意識した取り組み
      • 1: ソフトウェア資産に計上する開発の管理:エンジニア自身が投資対効果への説明責任を担う(開発開始申請から予実報告)
        • リターンがいつ生まれるかにより、減価償却がいつ始まるのか
        • ワークフロー申請をエンジニアが行い、毎週チームリーダーが予実管理を報告
      • 2: 財務知識向上のための勉強会
        • マネージャーを対象、投資家目線、経営者目線の双方から事業や開発をとらえる視座を身につける
      • 3: 開発スピードの向上
        • AIによるレビュー効率化、設計テストも含むAI活用など、リードタイムの短縮
        • コード品質、体験品質だけでなく、開発開始時に宣言したリターンの品質も
  • EMの存在価値
    • エンジニアが事業に徹底的に向き合わない「正当な理由」は多くある
      • 事業フェーズ上その状況でない、job description にない
    • そのなかでどう組織に浸透させるか?
      • 気合い:根性論ではなく、「意識の高い人」をマジョリティにする
      • 全員にとって当たり前の状態にしていく
    • EMの役割の枠組みにとらわれたままで、成長事業が作れるか?
      • ヒト・モノ・カネを戦略的に活用、他事業部とコミュニケーションし事業推進
      • 事業成功のためにあらゆる手段を尽くす

AI時代、mentoが考えるマネジメントサクセスとその実践

matsumatsu202 さん

  • AIの登場でマネジメントの仕事楽になったか?
  • エンジニアリング領域はAGI水準に近づいている
  • アウトプットはめちゃくちゃ増えたがアウトカムは微増
    • 情報が爆増する中人の意思決定がボトルネック
  • エンジニアリングの現状は、全職種が直面する未来の予告編
    • AIによる生産性革命は、スタートアップエンジニアリング
    • ここから非エンジニアやエンプラへ
  • EMはすでに未来のマネジメントを実践している:AIのロングラン、dangerous modeの利用、そのためのセキュアなサンドボックス環境、Skills, CLAUDE.mdによる振る舞いのコントロール
    • これらは自律化の支援、チームマネジメントと同じ構造
  • グローバルなトレンド
    • span of control の拡張、階層を減らしたフラット化(組織階層を減らす、チームの人数を15-20人に増やす)
    • 間違いなく日本にも来る
    • フラット化はしんどい、マネージャーのエンゲージメントは過去最低
  • 誰がこのマネジメントを変えるのか?
    • EMが全社を救う先行事例
  • どうマネジメントのOSを変えていく?その仕組みとソリューションについて
  • 管理職に戦略的余白を作り、時間の使い方を変える
    • 1: 余白を作るのにマネージャーが頑張るのではなく、メンバーレイヤーが自律的に行動する(セルフマネジメントの)支援が必要
    • 2: 評価、1on1といった業務支援も必要
    • 3: 空いた時間で、マネージャー自身が時間の使い方を内省する
  • 実践1 組織に意図のデータを落としていく
    • 情報処理コストは上がっても、Whyの情報は落ちていない→メンバーが一人一人がどんなモチベーションを持ち、どんな意図を持って、何に困って、というところをデータ化していく:日報文化ではこれが大事
    • AIがメンバー全員とコーチングする
  • 実践 2 AI対話型の目標設定
    • どれだけ目標をわがごと化できるか?が自律化の鍵、15-20人規模で全員に向き合うのは無理、Continuous Management Systemで、日々一人ひとりが目標に向き合って、そこにフィードバックをしたのが評価になる、という考え方を海外では導入されている
    • メンバーが上位の目標をブレイクダウンし、対話形式で自分の目標に落としていく(ドラッカーの言う、自己管理化された目標設定)
  • 実践 3: マネージャー自身が自らの行動を変えていく
    • カレンダーの情報を読み込ませて、こう言う時間の使い方をしたい、ありかたでいたいが、それに沿っているか?をAIからフィードバックもらう
    • マネージャーが変えていけるかが大事:自分がこうありたい、部下からこうして欲しい、上司からこうして欲しい、と言ういろんな期待にマッチしているかどうかのギャップを把握すること
    • 修正サイクルで可視化しながら継続的にチューニングしていく

AI Coding の先にある、Engineering Manager の本当の仕事

藤倉 成太 さん

  • AIは我々が作るもの、仕事のありかたをどう変えるのか?
  • ソフトウェアの価値の変化について
    • AIが高度に発達すると、一般的なソフトウェアの価値は減っていく、存在意義がなくなってしまうのでは?SaaS is dead?
    • NO: 過去革新的技術の誕生時を紐解く
      • 電子計算機:業界によってすぐに活用できる、まだできないグラデーションがあった→補完するためにソフトウェアが作られ、複雑化していき、SWEが発達していった
        • 革新的技術誕生時に人類はグラデーションの「間を埋める」ことをしてきた
      • 蒸気機関、内燃機関、インターネット、、
        • まずは人間の作業を代替してきた
        • この段階はマクロ経済へのインパクトはあまりない(人間の工数を機械が奪うだけ)
        • 人を置き換えるだけでなく、新しい技術を前提とした変化があったとき人マクロレベルの影響がある(e.g. 蒸気機関→電力:配線の自由さや小型化で工場ラインやサプライチェーンのあり方が変わった)
      • AI時代にSWEの仕事が置き換わった後、AIを前提とした法律、組織、収支計算の考えが変わって初めて、経済的インパクトを持つのでは
  • SWEの仕事の変化について
    • 一般的にとどまらずごく一部に限られたエンジニアの知見すらAIが代替している
    • Google検索以前:ソフトウェア開発の知識をどれだけ「持っているか」が重要(専門書籍で学習して)
      • 検索技術の発達で知識を「持っている」ことが重要でなくなった
      • 経験による知識(検索でヒットしない)には価値があり続けた
      • AIの台頭によってそれすらに意味がなくなってきた
    • AI時代に、エンジニアの持っている能力の何を発揮するべきか?
      • 従来的には、設計がうまくできる、コーディングが速い、綺麗、、
      • 今後も大事になるのは、何を作るべきかを考える、作るかどうかを判断する、技術選定をする、そして結果に責任を持つ・責任を取る
      • 結果への責任は従来もあったが、他が多くあってone of themだった
  • SWEの仕事が変わると開発チームはどうなる?
    • 4-5人のチームにリーダーがいて、というパターンが多かった
    • サイズは小さくなる?大きくなる?ひとりユニコーン企業?
    • エンジニア組織は小さくなっていくという感覚
      • 必ずしも少なくて良い、ではない(ミッションの壮大さに対しては数が多い方が良いに決まっている)
      • が、結果的に小さくなるだろう(必要なスキルセットが少なくなり、そこにマッチしないと活躍ができないから)
    • 「考えて、判断して、責任を取る」だけだとタフ過ぎ、ひとりのエンジニアだけに任せるのは難しい:チームやマネージャーで複数人責任分担する(2、3人)かたちになるのでは
    • 従来的ないろんな職種でワンチーム(e.g. PdM、デザイナー、エンジニア、、)は、役割分担に意味が薄れ職種の境界線が解ける(PdM兼UXデザインみたいな)
  • エンジニアリングマネジメントはどうなる?
    • エンジニアそれぞれがエージェントをマネージする時代に必要なくなる?NO
    • 仕事のやり方や注意の向き先は変わってくるだろう
      • PMは相対的に重要性が下がる
      • ソフトウェアの複雑さはラップされて減っていき、再利用可能なものの組み合わせになっていく→技術的な不確実性は下がってきたし、AIの登場でさらに向き合う必要性が下がっていく
    • 技術マネジメントの重要性:技術の何を管理する?が変わってくる
      • 設計の良し悪しもコモディティ化されていくだろう
      • How 実現方法よりも、どの技術を使うべき/使わないべき の判断が最重要の部分になってくる
    • 相対的に需要が高まるのは、組織、人のマネジメント(仕事を人間としている以上なくなることはない)
      • メンバーが「考えて、判断して、責任を取る」をマネージしてあげる必要がある
      • 従来ジュニアの「設計ができない」「実装が遅い」がなくなる→「どういうプロダクトをマーケットに当てるのが勝ち筋か?」「どう責任を取ったら良いか?」に変わる
    • 開発のスループットの向上は当面向き合う必要がある
      • スループットの大小は、人やプロジェクトやアーキテクチャによって違う現状
    • 向き合うべきチームサイズ:人数減ると、見るべきチーム数が増えるか?NO
      • エンジニア一人一人が見るべき責任範囲が広くなり、意思決定のスピード、支援、環境整備も伴って速くなっていき、厳しくなるのでは
  • 責任を引き受けるマネジメント
    • 未来を予想する、想像することに意味があるのか?
    • インターネットやSaaSの登場、トレンドごとに意見を持つが、あまり当たらない:今回も当たらなくても仕事は続いている
      • 常にアンテナを貼り、プラクティスを取り込み、トレンドに順応していく、でよくないか?
    • プラクティスが出てくる前も、自分なりに考えて、仮説を持って、今考えうるベストを実行し、その結果に向き合い責任を持つことがEMに残り続けるやるべきこと
  • この瞬間を楽しもう

聴講メモ:五反田.mobile Vol.2 – モバイルアプリデザイン最前線

前回初開催だった、五反田.mobile の第二回はデザインがテーマ。間違って前回の開催場所だったウェルスナビさんに行ってしまい、1セッション目は間に合わなかった。

AIコーディング時代におけるデザインとの連携をどう滑らかにするか?を考えてはいるものの、エンジニアサイドは自発的に様々な工夫をする一方で、デザイン側との接点については手探り感があった。今回そのヒントがいくつか得られて良かった。

パネルディスカッションは、プレゼンター以外の社員さんの参加もあってエピソードが豊富だったし、またプレゼンテーションという粒度外の話もてんこもりで(そういえば、みたいな思い出しもあり)素敵な試みだった。

イベントページ:https://gotanda-mobile.connpass.com/event/382518/


Figmaを使ったAI駆動モバイルアプリ開発

@naoele_dev さん

  • よくある失敗例
    • レイアウト設計(Auto Layout, Constraints)
    • コンポーネント設計(Components, Variant)
    • トークン設計(Color, Theme)
  • 失敗原因:Figma の設計が曖昧だから
    • Frame 名が初期値のまま→意味のある命名がされている
    • 手動配置されている、色が直接指定されている;Auto Layout や Variants を使っている
    • コンポーネントを使ってない
  • レイアウト設計の悪い例、良い例
    • 重要なのは、レイヤー構造がコード構造になる(Auto Layout, Constraints)
    • 意味のある名前をつける
      • → Figma のデザインデータそのままで生成される(クラス名や変数名にも反映される)
    • Auto Layout = Stack, Column
    • Figma の Constraints: サイズが変わった時に、中のTalkで部品がどの様に振る舞えウカを決める(寄せ方)
  • コンポーネント設計の悪い異例、良い例
    • 状態ごとに別コンポーネントになっているのは悪い例
    • 一つのコンポーネントに Variants が指定されていて、状態管理されている
    • UI部品をメインコンポーネント化し、Variants に切り出すと、その差分をAIが理解してくれる
  • 絶対ルール
    • 数値を直接書かない、Design Token 化する
    • AIのためでも、将来の自分たちのためでもある
  • Figma は絵を描く場所ではない、恒常を定義する場所
  • チェックリスト
    • Auto Layout を使っているか
    • Frame 名に意味があるか(ListItem みたいな名前になっているだけでも違う)
    • Variantsで差分を表現しているか
    • Token を参照になっているか

iOSデザインシステムとデザイナーと連携した取り組み

ひなっこ さん

“聴講メモ:五反田.mobile Vol.2 – モバイルアプリデザイン最前線” の続きを読む

聴講メモ:Mobile Tech Flex 〜4社合同!私たちのモバイル開発自慢大会〜

久々のイベント物理参加。冒頭から高密度なAI活用に関する発表が続いて、AIの勉強会かと錯覚した。が、それほどにAI活用が「AIすごい!」を超え、エンジニアのコーディングにとどまらずQAや顧客対応にも浸透していると感じた時間だった。発表の中で、Claude Code/Copilot/Devinの使い分けの勘所に言及されていて参考になった。仕様駆動が当たり前の様に語られていて、弊社でも実践している。ただ「仕様駆動」で満足するだけでなく、いかに効率性や確実性を高められるかに、世の中の関心ごとが移っていることは明らか。こうした会を通じて各社のナレッジに触れられるのは大変ありがたい。

イベントページ:https://mobiletechflex.connpass.com/event/381976/


AIとなら実現できる事業と品質のシン化の両立

@a_key_bako さん

  • シン化とは?
  • AIによる外部環境の変化(CodexでSoraが28日で)
    • 専門のAndroidチームがいたわけではなかった
    • 爆速で使えるが、品質要求は自ずと高いものが要求される
    • 各社のAI活用法や課題共有に価値がある
  • 現状
    • Deploys/Developer/Day 指標の変化推移
    • デプロイされた数を、開発者x営業日で割る
    • 1を超えた:かなり高い
      • Mobileはデプロイを意識しない:masterブランチへのマージ数をdeployとカウント
    • 変わったこと
      • ジュニア:アウトプット出しながら学習(先輩への質問以外という選択肢)
      • シニア:自身の知識が生産性に直結(ボイラープレートをAIに任せる)
    • 役割での使い分け
      • コーディングはCC、レビューはCopilot、越境はDevin(テストケースを尋ねたり、いろんな職能が使う)
      • CC:低コストでペア作業
        • CLAUDE.md、git worktree、ghコマンド(巨大PRの分割もスムーズ)
      • Devin:
        • 専門街プラットフォーム越境に便利(mobile→BE)
        • 作業プロセスがチームに見える
  • これからの課題
    • 課題1:技術的夫妻
      • 返済はできない
    • 課題2:AI活用の限界
      • 今のプロセスだとせいぜい一人ができることの効率化で限界がある(2倍にはなってもそれ以上には)
    • 納期ベース下での事業と品質のトレードオフ
      • リソースが潤沢でないと大規模リファクタリングができない
      • 課題をブレストすると、課題の洗い出しと優先度づけをした(重要度、漸進可能性、楽しさ)
        • 重要度:プロダクトへの影響度→やらざるを得ない
        • 漸進可能性:少しずつ進められるか(Viewごとに進められる?画面ごと?or一気に置き換え必要?)
          • 高いものはAIによる自律的置き換えに向いている
        • 楽しさ:学びの多さ、賞味期限→投資効果が高い
  • AI支援によって、専門外でも一定品質でコード生成可能に
    • ガードレイルの重要性が増す
    • 原理原則をガードレイルにする

OSアップデート:年に一度の「大仕事」を乗り切るQA戦略

@Myamaguchi75201 さん


  • OSアップデートはなぜ大仕事なのか
    • リリースが多く、クライアントによって機能の紐付け設定が多様
    • OSアップデートによる調査工数が増大
    • リグレッションテストケースが肥大化
  • 現状のテスト戦略の課題
    • テストケースが肥大化しQAリソースが不足
    • 機能仕様の理解の属人化(QA担当者が一番詳しい)
    • 担当者による観点粒度に差分
  • 対策
    • 観点粒度を汎用的にし、テストケースを見直し
    • テスト自動化(勉強会を開催し共有)
    • ↑アウトプットのテストコードをGitHubで一元管理
    • 相互機能影響をAIで抽出(過去実施のテスト観点や実装PRを用いて)

“レビュー”だけだったAI活用から半年。ヤプリのiOS開発・運用はどう変化したか?

@ko_yack さん

  • 活用深化と活用領域のマッピング
    • チームでの半年前はコーディングとレビュー
    • CCに設計テストレビューするまで全て行っている
    • アプリビルドはDevin経由
    • 問い合わせ調査はAtlassian Rovoでエンジニアが一時解凍できる様に
  • CCの活用における課題
    • コンテクストの枯渇:AIが参照不要な情報を読み取ろうとし、コンテクスト枯渇し忘却する
    • AI用ドキュメントをどこに置くか:CLAUDE,mdだとツール入れ替えた時にスイッチできない
    • 広い範囲の修正をしたい
    • メンバー習熟度の違い
  • 課題の解決
    • ドキュメントの構造化:root.instructions.mdを起点として、アーキやコーディングプラクティスを記載する
    • ドキュメントは読むべきタイミングと参照先をセットで管理し、無駄な参照を防ぐ
  • Spec-Driven Development (SDD) の導入
    • Proposal phase, Research & Planning phase, Implementation phase, Retrospective phase
    • フェーズごとにsubagentで分ける
    • 例: Swift移行のために、設計やマイグレーションのナレッジを構造化
    • 例: iOSで作った設計ドキュメントをもとにAndroidでもなぞらせた
  • Snapshotテストを導入
    • UIテストもAIに自律的に修正させる
  • Skills の活用
  • 問い合わせチケット切られたらRovo AgentにJiraなどの情報をRAG経由で参照させ、回答させる

謎現象の解決手段を発見して プチ英雄になりました

@shiosioco40 さん

  • Androidだと、React移行後JSInterface経由のインタラクションができなくなった
  • zod: プロパティアクセスと呼び出しの分離が原因
    • 参照と実行顔同時でないとJSInterfaceのメソッドをWeb側が実行できない
  • 回避策:JSInterfaceの参照を無名関数でラップする(アクセス実行の寸前まで触れない)

Claude × Markdown で仕様書をいい感じに管理したい

@AtriaSoft さん

  • Claude Code を使った仕様書作成管理の便利さと課題
  • 仕様書の老朽化問題(Confluenceの最終更新が2年前、、)
    • メンバー入れ替わりでメンテナンスが宙ぶらり
    • エンジニアに書くモチベーションがない、余裕がない
  • サブエージェント4体
    • reader, writer, reviewe, simpler(簡潔に書き換える)
    • 自然言語で指示したら、readerが既存仕様書やコードベースを読み解いて、writerに渡して仕様書を作成、更新。reviewrがその仕様書の生合成をチェックし、simplerが仕様書を簡潔に書き換える
    • エンジニアがレビューしてPR、レビュー、マージ
    • honkitを利用して、mdファイルは見やすい形にエクスポート
  • 良かったこと
    • 「書く」でなく「レビューする」で知り的ハードルが激減
  • 課題
    • 出力が冗長になりがち、コンテクスト共有に最適化されていない、図表表現に限界(Mermain導入したい)

Kotlin Multiplatform + iOS アーキテクチャの実践

株式会社ディップ 権 さん

  • KMPの実運用での使い分け
  • ビジネスロジックをKMP共有、UIは各OSネイティブ
    • Presentationは書くOS
    • sharedで、Domain/DataをKMP共有
    • modelはPure domain model
    • データ変換フローは、
      • Entity
      • DTO
      • Model
  • iOS側のUIアーキテクチャ
    • 画面ごとの状態管理がバラバラだと、状態遷移の追跡とKMP連携の責務分離が難しくなる、自作アーキテクチャ(Store Pattern)を採用(Intent(ユーザー操作)/Store/State/View)
    • iOS側はMVIをStore Patternで実装し、Android MVIと読み方揃t、チーム認知を統一
    • ObservableでState変更を購読
  • Store Patternのメリット
    • 複雑な機能にスケールしやすい:小規模から大規模まで設計を継続可能
    • チーム運用しやすい:Androidと似た設計で読み方統一、UIイベントの扱い方を共有化でき、レビュー観点揃えられる
  • KMPのSwift側の呼び出し体験をSKIEで改善
    • 今後、Swift Exportで、Obj-Cヘッダ経由の負荷を減らせる可能性があり、experimentalだが、よりSwiftらしいAPI公開に期待

バイトルiOSアプリのリアーキテクト / SwiftPMとAIルールで実現するモジュール設計

株式会社ディップ 宮川さん

  • 20年以上続くシステム課題の解消
    • ドメイン駆動設計、AI前提の開発プロセス、AIネイティブな体制
  • SwiftUI、デザインシステム、KMP、Strinct Concurrency Checking…
  • Swift Package Managerによるパッケージ管理
    • 分割の基準、機能画面ごと、外部依存の隔離(Firebase, KMPなど)、再利用性の担保(UI components, design system)
    • 全体構成が把握しやすくなり、循環参照を抑止できた
  • SwiftPMにおける課題
    • KMPなど外部に依存している状態で、SwiftUI Previewが不安定(タイムアウト)
    • 外部サービス依存のモジュールを限定的にし、protocolやmockのみを定義したInterfaceモジュールを定義し、中間に挟む様にし、KMPなどへの直接依存を回避した
      • poinfree / swift-dependencies により実現
  • AIコーディングによる課題(CC)
    • 意図しないモジュールにコードが生成される
    • モジュールごとに定めた依存関係のルールを守らない
    • CLAUDE.mdに全ルールを記述していたが、コンテクスト肥大化するため、.claude/rules/を活用して最適化した
    • レイヤー概念を導入してルールをシンプル化:モジュール数の増大で依存関係が複雑化する、AIにとっての認知負荷も増大するため、モジュールの責務ごとにグルーピングしたレイヤーを導入した(同じレイヤーは、同じ依存ルールに則る)
    • ruleファイル自体が設計ドキュメントとして機能

RELAX PIXEL TUNES CD PLAYER を購入した

10年くらい前から、ONKYOのCR-N755というオーディオレシーバーを使っているのだが、数年前からCDプレイヤーが壊れて聴けない状態が続いていた。

とはいえCDはまだ手元にあるし、Apple Music や Spotify にない音源は買うしかない。さらにコンサートに行けばサイン目当てにCDを買ったりもする。なので聴く手段はないがCDの数は増えていくという不思議な状態に陥っていた。

そんな中この記事で Relax というメーカーのCDプレイヤーを知り、先日とうとう購入した。

初代iMacから着想を得たCDプレーヤー「RELAX PIXEL TUNES」新色「Ray of Light」 – AV Watch

かつてはこうしたCDプレイヤーは珍しくなかったはずだが、時代はMD、iPodと移り、いまやストリーミング意外の手段で聴くのはオーディオマニアくらいに限られた今、逆にポータブルにCDを聴けるという体験が新しい。

さらに、CD主流の当時であってもこうして本体独立で音源再生できるのは決して多くはなかったのではないだろうか? ラジカセ感あるローファイな音質で、ながら聴きだとかえって疲れしなくて良い。きちんと聴きたければヘッドフォン端子に有線イヤホンや外付けスピーカーを刺すか、Bluetoothイヤホンとペアリングすればよい。

なにより、CDが回転する様子を眺めているのが楽しい。音飛び防止としてオンメモリに音源を読み込む機能が搭載されていて、その都合でCDの回転が途中で止まったり、再開したりする挙動は、何度見ても不思議。この機能はON/OFF可能なので、ずっとCDを回転させ続けることも可能。

こうした機能性抜きにしても、初代iMacを想起させるボンダイブルーの筐体は可愛らしくて眺めてても楽しい。個人的には良い買い物だった。

Android:空白にSpacerを使うべきかpaddingを使うべきか

Android 開発に入門して半年以上が経つ。

画面実装で避けては通れないコンポーネント間の間隔について、Spacer を使うべきか、padding を使うべきか時々悩むことがある。というのは、自分の手で実装する場合は割と手癖的に padding ベースで書くことが多い気がするだが(SiwftUIでもそうしていたので)、Claude に書かせていると惜しげもなく Spacer を挿入してくるので、どちらが適切なのだろう?と疑問に思ったのだった。

もちろん、Spacer / padding の判断は要所要所で行って良いはずだ。代表的な例で言えば、画面幅によって可変する間隔は迷いなく Spacer で表現するだろう。とはいえ、どういうケースでどうするべきか、網羅的には言語化できていなかった。

Android 開発でのデファクトがどうなっているのか、”Jetpack Compose Spacer vs padding” のようなキーワードで検索してみたところ、いくつか興味深い情報を見つけたので、ここで何か結論を出すつもりはないが個人的にメモしてみる。


  • Space Hoisting: Should I use the padding Modifier or the Spacer composable?
    • お馴染み “State Hoisting” の概念をもじって “Space Hoisting” という考え方を紹介している。間隔のレイアウトを子ではなく親に委ねるというもの(子は自身の周囲に空間を持たず、親側で SpacerModifier.padding(...) で空間をレイアウトする)
    • その上で、Spacer の有効性を説明している
      • 空白の表現を意図的に伝えられる
      • コンポーネントのカプセル化を保てる
      • 対象がタップ可能の場合、当たり判定や ripple effect への影響を考えるとよりシンプル
      • コンポーネントのサイズ計算に影響しない

ごもっともである。

いっぽう、両者でレイアウト処理のパフォーマンスに違いがありそう(感覚的に、要素数の増える Spacer の方が遅い気がする)だと感じていたのだが、実際に検証している Stack Overflow の投稿を見つけた。

android – Compose Spacer vs view padding performance – Stack Overflow

極端な事例では Spacer のレイアウトコストが顕にはなったが、結論ケースバイケースで、どちらかを一辺倒に選択する根拠にはならないことが分かった。


他の投稿を読んでも共通してケースバイケースに捉えている。あるとすれば、対象要素がコントロールの場合は、タップ(Android では特に ripple effect を含め)どのように作用させたいかで考えれば良さそう。

STORES さんのように、どういったケースでどちらを使うか、ルール化しておくと AI に書かせてもブレないので、これを参考にチームでも検討したいと思った。

Claude Code 生みの親による10のtipsを読んだ

最近開発するときは、仕事・個人共に Claude Code 全振りなのだが、Claude の開発者 Boris Cherny 氏が、Claude Code を使う際の10のチップスを共有していたので、勉強がてら読んでみた。

Claude は雰囲気だけで十二分に使えてしまうので、意識的にこうした手法を取り入れてトライ&エラーしないと、我流のまま世の中の進歩から取り残されてしまう実感がある。

  1. 並行でより多くを行う
    • 複数セッション起動し、それぞれに git worktree (大半の Claude Code チームが好んでいる) を走らせる
  2. 複雑なタスクは必ずプランモードから始める
    • ある Claude にプランを書かせ、別の Claude にそれをレビューさせる
    • 問題があればプランモードに戻し、プランし直す
    • 実装だけでなく、検証時もプランモードを活用する
  3. CLAUDE.md に投資する
    • 修正のたびに、同じ間違いをしないようCLAUDE.md を修正することを、Claude に指示をする
    • CLAUDE.md に惜しみなく修正を加え、目に見えて間違いが減るまで繰り返すこと
  4. スキルを作成し、Git にコミットし、すべてのプロジェクトに流用する
    • 1日のうちに複数行うことは、スキルかコマンドにすること
      • すべてのセッションの終わりで実行し、重複したコードを削除するコマンドを作る
      • 1週間分の Slack、ドライブ、GitHub などの情報をコンテクストダンプに同期するコマンドを作る
  5. Claude はたいていのバグを自身で修正できる
    • Slack MCP を有効にし、Slack URL を Claude Code に与えて修正を依頼する
  6. プロンプトをレベルアップする
    • 自己レビューしてテスト通るまでPR出すな
    • ここまでの知見を活かして、現状を破棄しより良い方法で実装しなおせ
    • 仕様を詳細に書き実装前にあいまいさを減らせ
  7. ターミナルや環境のセットアップ
    • Claude Team 推奨の Ghostty
    • /statusline コマンドでステータスバーをカスタマイズする
    • 音声認識を使う:タイピングよりも3倍早く指示できる
  8. Subagent を利用する
    • “subagents を使うこと” を、より複雑な課題解決を依頼する際に加える
    • 個別タスクを subagent にオフロードすることで、メインのコンテクストをクリーンに保てる
    • 承認リクエストをフック経由で Opus 4.5 にルートして、攻撃をスキャンし安全なリクエストを自動で承認させる
  9. Claude をデータ分析に用いる
    • bq CLI を用いて Claude にデータ取得と分析をさせる
    • BigQuery スキルがコードベースに組み込まれていて、Claude チームの誰もが Claude Code でクエリを書いている
  10. Claude で学ぶ
    • Explanatory または Learning アウトプットスタイルを有効とし(/config で)、Claude が変更の「なぜ」を説明できるようにする
    • HTML 表現による説明、ASCII 図による説明の生成
    • 自分自身の理解を Claude に述べ、Claude がフォローアップをすることで不足を補う(spaced-repetition learning)

参加メモ:iOSエンジニア & デザイナー ガチもく会

昨年から仲良くしていただいているショウヘイさんが主催されるもくもく会に行ってきた。中野駅近くのコワーキングスペースNAKANO HAKO、参加費は個々の利用料2,500円。

イベントページ:https://mokumokuios.connpass.com/event/381241/

こんな感じで、Vision Pro でミラーリングしながら週末プログラミングの延長線的な作業をしていた。

飲み物、お菓子食べ放題なのは嬉しい。お菓子のセレクションが素晴らしかった。

参加者はiOSエンジニア、Webエンジニア、個人開発者、デザイナー(プロダクトデザイナーの方も)とさまざま。

各々で作業しているときは、文字通り黙々と手を動かしているのだが、こんな感じで作品見せあったり談笑したり、情報交換できて楽しい時間だった。


おまけ:お昼に食べた、会場下のCoCo壱カレー。

Vibe Coding でワイヤーレベルの図示化に Playground を書かせてみた

週末ふと思いついたアイデアを、Claude Code を使ってかたちにしてみようと思った。

仕事でも Claude Code を使っていて、実装は99%手で書くことがなくなったのだが、どのように指示しているかというと、まず要件レベルのドキュメントを Claude に与え、詳細設計レベルの仕様書に落とし込んでもらい、それをもとに質疑を交わしたり認識合わせを経てから、コーディングに落とし込んでもらっている。

いっぽう個人開発は、よりふわっとしたアイデアからスタートするので、数行のアイデアメモから始まる。これを実現するために、AIにとっての不足情報を質問形式で引き出し、それに答えながら構想を詳細化していく。

ちなみに筆者の場合、この質疑応答はチャット上ではなくテキストファイル上で行っている。質問が書き出された .md ファイルに筆者が回答を記載し、追加で質問があればさらに書き込んでもらい、、というラリーをひたすら繰り返す。質疑以外のコミュニケーションもコンテクストに溶けないよう、かたちに残るファイル上で行っている(特別な方法ではないはずだ)。

ドキュメントベースでレビューできる内部ロジックに限らず、外見の画面イメージがAIと認識が揃っているかも、本実装の前にきちんと把握しておきたい。そこでAIに図示を依頼すると、大抵ASCIIアートで描いてくるきらいがある。しかし文字列で表現できるレベルなんてたかが知れているし、そもそも表示が崩れまくるので使い物にならない。

そこで Swift Playground でモック実装させてみたら、これがうまくいった。例えばオーディオデータを扱う筆者のアイデアは、波形を描画して、範囲選択をし、編集操作を行う要件がある。これを人間の手でサクッと作るのはガワだけでも結構大変だ。だがAIなら、アイデアの壁打ちを始めてからたった10分足らずで次のような絵に仕上がった。ほぼ一発で、バシッと筆者のイメージを具現化してくれた。

あとはボタンの配置がどうの、配色がどうのと細かい部分を指示し、随時 Preview 上で反映を確認しながら、ワイヤーレベルのデザインを固めていった。


ちなみにこのアイデアだが、アプリとしてきちんと形にしようと思うと、音声処理に関する実装知識が必要だし、インタラクションや機能の複雑さもあるため、日曜大工感覚で1ヶ月くらいは掛かるだろうと見込んでいた。が、Claude Code を使えば日曜の夕方2時間程度でほぼほぼ完成形までこぎつけられた。(といっても、今更このスピード感に驚くこともないのだが、、)

この時点でバグは多いものの、実際に手に取って動かせることで、UIやインタラクションの課題が浮き彫りになり、アイデアのブラッシュアップに繋げられた。まさに Vibe Coding 的な体験だった。

Screenshot

claude コマンドの実行に失敗

これまで Cursor を使っていたが、仕事が Claude Code 1本なので、個人開発でも使おうと Claude をインストールしたが、claude コマンドの実行時で失敗してしまった。

$curl claude
warn: CPU lacks AVX support, strange crashes may occur. Reinstall Bun or use *-baseline build:
  https://github.com/oven-sh/bun/releases/download/bun-v1.3.6/bun-darwin-x64-baseline.zip
error: Invalid DNS result order.

Terminal.app が Rosetta で起動する設定になっていたのが原因だった。チェックボックスを外して再度実行したら成功した。

This website stores cookies on your computer. These cookies are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to to opt-out of any future tracking, a cookie will be setup in your browser to remember this choice for one year.

Accept or Deny