process-bookを令和最新版に更新した

昔書いて結構ご好評を得た「process-book」なんだけど、サンプルコードが古かったりbuild環境が古かったりしたので、令和最新版にリバイスした。

https://github.com/Shinpeim/process-book

バイスした内容としては……

  • docker containerでの実行環境を同梱した
  • GitHub Actionsで pages のbuildとreleases(pdf版)をビルド,publishするようにした
  • サンプルコードをRubyに統一
  • ClaudeCodeと一緒に、説明が薄いところなどを加筆修正した

基本的な内容は変わっていないです。正直ずっと「価値のある文章のはずなんだけど、いろいろと古くなってて手をいれないとな……」「けどめんどくさいな……」が戦っていたんだけど、Claude Codeとの生活を始めたことで「まあパッとやっちゃうか」になることができたのでClaude Codeはえらいです。

もし、ちゃんと動かなかったり実行結果が異なったりする場合はIssueからご連絡ください。

熱い自画自賛ですが、今読んでも十分に役にたつ内容だな、と思うので、しんぺいくんがClaudeCodeと生活するkとでこれが令和最新版になるんならClaudeCode代の足しにしてやってもいいな、って思ったひとは、wishlistからなんかください。

Amazon.co.jp

マルクスとLLM

TL;DR:

  • マルクスは、生産手段(工場とかね)が資本家に独占され、労働者は生産手段を持たないため労働力を生活のためのもろもろに変換するしかないという状況を問題視した
  • ソフトウェアエンジニアをはじめ、いわゆる「知識労働者」は、生産手段がその頭の中に存在するという点で、資本家に対して競争力を持つことができた面がある。ソフトウェアエンジニアが長らく転職市場で有利だったのはそのひとつの証左と見ていい
  • 一方で、LLMの台頭で、その「生産手段」は資本家どころか、私企業に独占される未来は蓋然性が高いように見える
  • ぼくたちは今まで見たことのない地獄に足を踏み入れているのかもしれない
  • マルクスは、労働「からの」疎外という概念も提唱していて、雑に要約してしまうと、生産手段を失った労働者は、「自ら財を生み出す」という喜びを失ってしまう、ということを言っている
  • だから、「手元にある生産手段」として、ローカルLLMに興味を持ち始めている

はじめに

ぼくは、マルキストではないがマルキシアンである、と自らを評している。つまり、マルクス主義者ではないが、マルクスが示した思想や分析に大きな価値を見出していて、その思想や分析は現代でも参照する、あるいは思考の梯子として使う価値がある、という立場です。この文章は、自称マルキシアンの筆者が生産手段とLLMの関係について思索をめぐらせたものです。

「生産手段」はだれのものか

マルクスは、「生産手段」についてかなり重要な思索をしている。曰く、資本主義においては、「生産手段」は資本家に独占され、労働者は生産手段を持たず、資本家に独占された「生産手段」に対して「労働力」を売ることで生活の糧を得るしかなくなっている、という。これは手工業から工場での生産に変わっていくのをイメージすると理解しやすい。つまり、この例で言う「生産手段」とは工場のことであり、「工場」に設備投資(まさに「資」本を「投」入)できる資本家が生産手段を独占することで、生産手段を持たない、つまり無産階級の人間は労働力をお金に変えることで生活していくしかなくなる、ということを問題視した。ここには非対称性があるので、資本家は、労働者が労働で生み出した価値以下の、生活ができる程度(つまり、「労働力」が再生産される程度)の賃金を払うだけでよく、労働者が生み出した価値の総量と労働者に還元される価値の総量には差分が生まれ、その差分を利潤として資本家が得るような非対称性が存在する、ということをマルクスは言ったわけだ。

この「生産手段」に関する考え方を、現代のいわゆる「知識労働者」に当てはめてみると、事態はすこし変わった様相をみせ始める。ソフトウェアエンジニアなどのいわゆる「知識労働者」の生産手段は、その頭の中にある。人間の頭の中にある生産手段は、資本家が労働者から召し上げることはできない。生み出す価値に貴賎はないはずなのに、現代において(ある意味では不当に)知識労働者の給与が高くなりがちなのは、「生産手段」を労働者が明け渡さずにすんでいるから、とみることも、そうおかしな話ではないはずだ。つまり、生産手段を召し上げられていないから、資本家に対して「つよく」出ることが可能だという見方だ。じっさい、それなりに安価なPCがひとつあれば、生産手段として成立する、というのは、「工場がなければ生産手段として成立しない」というのに比べればだいぶ生産手段が手元に民主化されていると言えると思う。まあ、これがトラフィックを支えるインフラがたとえばAWSなどに寡占されている、という話が絡むとまた複雑なのだけれど、傾向として。

一方、そのような「頭の中に生産手段がある」というありかたは、LLMの台頭によって変化を見せ始めているかもしれない。つまり、コーディングエージェントなどを筆頭に、いままで労働者の「頭の中」あった生産手段は、高機能LLMを運用できるビッグテックなどの私企業によって召し上げられ、その競争力の源泉を失うような未来の蓋然性はかなり高いと言っていいと思う。生産手段が資本家に独占されるのと、私企業に独占されるのは、果たして労働者にとって、あるいは、旧来の資本家にとって、どちらが幸福な形だろうか。ぼくは労働者の立場として、あまり楽観視していない。

労働「からの」疎外とローカルLLM

さて、マルクスは、労働「からの」疎外という概念も提唱している。これは雑に言うと、生産手段を召し上げられた労働者は、自ら財を産み出す喜びを失ってしまう、ということだ。手工業と工場の話で言えば、手工業でものを作って売っていた頃の労働は、自分の生産活動、生産したものがいわば「梃子」として働き、生産活動により社会と接続され、いわば自己実現が達成されていた。一方で生産手段を失い工場労働者として労働しているときには、自らの生産は社会と直接結びつかず、ほんらい喜ばしいものであった「労働」は単に使役される苦しみへと堕してしまう、という思想だ。

前節の議論と合わせて、マルクスの思索はソフトウェアエンジニアの未来に対して大変示唆に富んでいるとぼくは思う。つまり、「手元に生産手段を置いておく」ことの重要さを、もう一度考えてもいいと思う。前の記事で言及した通り、コーディングエージェントの進化は甚だしい。しかし、私企業が提供するコーディングエージェントは、そのまま私企業によって提供される「生産手段」を意味している。ぼくはその便利さ、強さを実感したからこそ、私企業が提供する生産手段に「依存」してしまうことにかなりの抵抗がある。つまり、私企業が提供する「生産手段」がないと生産ができないようになってしまったら、「生殺与奪の権」を私企業に独占されてしまうのではないか、その結果起こることは、マルクスが看破した資本家と労働者の非対称性をなぞることなのではないか。

これは、ソフトウェアエンジニアだけの問題ではなく、LLMモデルを持たない資本家にとっての問題でもある。つまり、資本家が生産手段を独占、あるいは寡占していたころはまだ牧歌的で、いち私企業が独占した時、資本家すら「生産手段」を失ってしまうということも十分にあり得る。

そこで、やはりぼくはローカルLLMに興味を惹かれてしまう。ローカルLLMは、ローカルの名の通り「手元に」生産手段を用意することができるわけだ。私企業がLLMを独占し、Evilなふるまいを始めたとしても、実用に足るローカルLLMがきちんと「対抗手段」として残されていれば、まだ「戦いよう」があるというものだ。そんなわけで、ビッグテック以外の資本家のみなさまにはぜひともローカルLLMにそれこそ「投資」するというオプションを持っていただきたいな、と思う。まあもちろん、フルマネージドなインフラ環境として私企業たるAmazonに依存しまくっている現状を見ても、「私企業に依存した方が結局は経済合理性があるよね」という話があり、そこまで話は単純なわけではないのだけれど……。

また、以上のような議論を考えると、いちソフトウェアエンジニアとしてもローカルLLMに対する知識を付けておくことはたいへん重要なのではないかと思っている。ので、週末はローカルLLMチャレンジをしてみようかな。そもそも「生産手段」が手元にないのは単純に気分が悪い、というのもあるので……。

Vibe Codingで、自分が使いたいコード譜管理アプリケーションを作った

Claude Code、触った人がみんな「これは体験が違い過ぎる」と言っているので、さすがに触ってみるか〜、と思い、週末一本勝負で自分の使いたいコード譜管理アプリケーションを作った。

作ったものの紹介

ここで触ることができる。

Nekogata Score Manager

作ったものの現時点での機能や特徴をClaude Codeにまとめてもらったのでそれをそのまま貼ると、こういうアプリケーションです。

概要

Nekogata Score Managerは、ミュージシャンやバンドメンバーがコード譜の作成・編集・管理を効率的に行うためのWebアプリケーションです。シンプルで直感的なユーザーインターフェースを持ち、バックエンド不要でブラウザ上で完結する軽量なコード譜管理ツールです。

仕様的特徴

🎵 コード譜管理機能

  • コード譜の作成・編集・削除
  • 複数セクション対応(イントロ、Aメロ、Bメロ、サビ、アウトロ等)
  • 楽曲メタデータ管理(タイトル、アーティスト、キー、テンポ、拍子)
  • タグ機能による分類・検索
  • メモ機能による補足情報管理

🎼 高度なコード入力機能

  • オンコード対応(C/E、Am7/G等のベース音指定)
  • 複雑なコード記法対応(テンション、分数コード、オルタード等)
  • 柔軟な拍数設定(0.5拍刻みでの細かい調整)
  • ドラッグ&ドロップによるコード並び替え
  • 強制改行機能(任意の位置で楽譜の行を区切り)

🎨 表示・レイアウト機能

  • レスポンシブ対応(デスクトップ・タブレット・モバイル)
  • フレキシブル小節表示(画面幅に応じた最適な小節数配置)
  • 楽譜風UI(小節線、罫線による見やすい表示)
  • BPM視覚インジケータ(点滅アニメーションによるテンポ表示)
  • 統一デザインシステム(Teal・Sage・Coral の3色アクセントカラー)

📱 ユーザビリティ機能

  • リアルタイム入力バリデーション(無効なコード名・拍数の即座検出)
  • 保存防止機能(無効入力時の自動ブロック+詳細エラー表示)
  • コピー&ペースト対応(コード進行の一括入力)
  • 一括選択・操作(複数コードの同時編集・削除)
  • 範囲選択(Shift+クリックによる連続選択)

💾 データ管理機能

  • ローカルストレージ保存(オフライン対応)
  • JSON形式エクスポート・インポート(データの移行・バックアップ)
  • 複数楽譜の一括操作(Gmail風選択UI)
  • 自動データ移行(旧フォーマットからの自動変換)

技術的特徴

🏗️ アーキテクチャ

  • Frontend: React 18 + TypeScript
  • State Management: Zustand
  • Storage: LocalForage (IndexedDB/WebSQL/localStorage)
  • Build Tool: Vite 6.x
  • UI Framework: Tailwind CSS v4
  • PWA: Workbox (Service Worker)

🔧 技術スタック詳細

フロントエンド技術

  • React 18
  • 状態管理 (Zustand)
    • 軽量でシンプルなグローバル状態管理
    • 非同期操作対応(async/await)
    • ミドルウェア不要の直感的API
  • スタイリング (Tailwind CSS v4)
    • ユーティリティファーストアプローチ
    • カスタムカラーパレット(arbitrary values使用)
    • レスポンシブデザイン対応

データ永続化

  • LocalForage
    • IndexedDB → WebSQL → localStorage の自動フォールバック
    • 大容量データ対応
    • 非同期API(Promise/async-await)

開発・ビルドツール

  • Vite 6.x
    • 高速な開発サーバー(HMR対応)
    • 最適化されたプロダクションビルド
    • ES Modules対応
  • TypeScript
    • 厳密な型チェック
    • インターフェース設計による堅牢なコード
    • 開発時の自動補完・エラー検出

PWA機能

  • Workbox + Service Worker
    • オフライン対応
    • キャッシュ戦略(Cache First)
    • アプリアップデート通知

データ保存にlocalStorageを使いつつ、jsonで状態をimport/exportさせてポータビリティを上げるというのは我ながらちょっと面白いアプローチだと思う(そうさせた)。

どのように作ったのか

最初に、CLAUDE.mdを介して簡単な要件をClaude Codeに与えて、技術スタックの選定、リポジトリの初期化からやってもらった。

プロジェクトのセットアップ

こっちが雑に扱っていると、あっちもけっこう雑にコミットしちゃうので、気をつけないとクレデンシャルをコミットしようとしたりするということが起こり、冷や汗をかくこととなったが、それ以外はまあ順調に進めてくれた。

TODO.mdを通じての指示

CLAUDE.mdを通じて、「タスクはTODO.mdに洗い出してね」と指示してあり、まずはTODO.mdを作成してもらった。これを人力で添削してやったり、もっと優先度高いものがあるときは人力で割り込みタスクを書いたりした

テスト、lint、buildをサボらせない

CLAUDE.mdに指示を書いておいても、油断するとこのへんをサボる。プロンプトでもいちいち叱るけど、そもそも作業単位ごとにブランチ切ってPRを送るようにさせていて、CIでもテストを回すようにした。このへんは普通の開発と同じですね。GitHubActionsの設定自体もClaude Codeにやらせたけど、細かいところは自分でもいじったり添削して書き直させたりしている。

イテレーションを回す

あとは、

  • 「TODO.mdからタスクえをひとつとって完了させて」で実装させる
  • 「変更内容のPRを送って」でPRを送らせる
  • GitHub上で人間がレビュー、netlifyのdeploy previewで人間が動作確認
  • レビューや動作確認の結果問題があれば修正をさせる
  • 問題がなくなったらmerge
  • 「remoteの変更をmainに取り込んで」でローカルにmainの変更をmerge

という具合にイテレーションを回していくと、どんどんTODOが片付いていく。怖いレベル。

人間の介入がまだけっこう必要だと感じたポイント

  • 結構テスト書くのサボりがちなので、まずいなと思ったら「この部分のテスト書いて」と介入してやる必要がありそう
  • テストが落ちてても平気で「テスト通ったよ」とか嘘つくことがあるのでちゃんとCIで守る & 怪しそうなら自分でもテスト回すなどはしている
  • クレデンシャルをコミットしようとするなどはまああるので、そこもちゃんと人間が見てやらないと怖い
  • TODOをバンバン片付けていくと、だんだんコードが肥大化していく。今回は「このファイルが肥大化しているので、リファクタリングをして」などのプロンプトで介入を何度かしている
  • リファクタリングも、ある程度大きいものだと諦めることがある。そのときは「これはこういう指針でやるときれいになるよね」みたいにおしえてやるとうまくいった。
  • あと、使っていない型とか使っていないプロパティとかも結構放置されがちで、「あれ、これ使ってないよな」みたいなものは「使ってないなら削除して」と介入したけど、これは静的解析でやったほうがよさそうな気がする
  • たまに問題を修正できなくて当てずっぽうでいろいろやり始めることがある。こういうときは一度Claude Codeを止めて、人間がちゃんとコード読んで「ここが問題だからこう直すといいいんじゃない?」って教えてあげないと無限に試行錯誤し始める。
  • 全体の整合性を考えないといけないようなタスクにはまだちょっと弱いかな。そのへんは人間が指針を与えないと「ノールックでaccept」してると詰み始める

どうでもいい感想

  • なんか「大幅に」ってのが口癖っぽくて、ちょっとした改善しただけでも「UI/UXが大幅に改善しました!」とか「コードの保守性が大幅に改善しました!」ってすぐに大袈裟に言ってくるの、なんかかわいい

おわりに

  • しばらくこのアプリケーションを自分で使いながら改善していく生活をしてみようと思う。変化の早い世界なので、1ヶ月後にはだいぶ違う体験があるのかもしれない。すごいね。
  • この記事を書きながら裏でClaudeCodeに作業してもらっていて、この記事を書いている間にもどんどんタスクが終わっている。怖い。
  • この規模のアプリケーションを1日で構築できてしまう、というのはちょっとあまりに衝撃だな〜。怖い。

「文化的雪かき」2025

村上春樹の作品『ダンス・ダンス・ダンス』には、「文化的雪かき」という表現が登場する。

彼女から月面の絵はがきが届いた一週間後に、僕は仕事で函館に行くことになった。例によってあまり魅力的とは言いがたい仕事だったが、僕は仕事のよりごのみが出来るような立場にはなかった。それにだいたい僕のところに回ってくるどの仕事をとってみても、そこにはよりごのみをするほどの差はないのだ。幸か不幸か一般的に物事というのは端っこに行けば行くほど、その質の差が目立たなくなってくる。周波数と同じことだ。あるポイントを越してしまうと、隣接する二つの音のどちらが高いかなんて殆ど聴きわけられないし、やがては聴きわけるまでもなく何も聞こえなくなってしまう。

それはある女性誌のために函館の美味い食べ物屋を紹介するという企画だった。僕とカメラマンとで店を幾つか回り、僕が文章を書き、カメラマンがその写真を撮る。全部で五ページ。女性誌というのはそういう記事を求めているし、誰かがそういう記事を書かなくてはならない。ごみ集めとか雪かきとかと同じことだ。だれかがやらなくてはならないのだ。好むと好まざるとにかかわらず。

僕は三年半の間、こういうタイプの文化的半端仕事をつづけていた。文化的雪かきだ。

村上春樹. ダンス・ダンス・ダンス (講談社文庫) (p. 25). (Function). Kindle Edition.

ぼくなりに要約すれば、「質がそこまで問われない、穴埋めのための、しかし必要な仕事」という感じだろうか。こういう「文化的雪かき」はおそらくいたるところにあって、たとえば動画のBGMなんかも、こだわらないひとはこだわらない。けどないと寂しい。結果として「フリー素材」が使われたりする。あるいはイラストについても、そこまでこだわりがないけれど、ないと寂しい、必要ではある、というようなものがある。「文字を読む動画」系でバックに使われている画像なんかもそういうものが結構あるんじゃないかな。

いまぼくが例に出した「文化的雪かき」的な仕事は、歴史的にはその座を「フリー素材」に奪われてきたと言ってもいいと思う(もちろん、全てが奪われているわけではないが)。それまでだったらイラストを発注してきたところを、「いらすとや」のイラストを使う。あるいは、それまでならばBGMを発注してきたところを、「シャイニングスター」を使う。面白いもので、「いらすとや」のイラストはさまざまな色覚特性を持った人たちに対しての配慮が行き届いていたり、「シャイニングスター」だってもう聴き飽きてはいるけど実際よくできた楽曲、アレンジであることはたしかだったりと、「質にこだわらない」はずが「フリー素材」のほうが安定した品質になったりするということが起こっている。一方、広く、よく使われるものは「あまり尖っていないもの」となるということもある。文章については「フリー素材」化が進んでいないような気もしているが、これは文章は(それこそダンス・ダンス・ダンスで主人公が書いているような)穴埋め的なものであっても「繰り返し同じものを使う」ことが嫌われるからだろうか?

さて、そういう流れをざっと見たうえでこんにちにの「文化的雪かき」を眺めてみると、生成AIと呼ばれるような技術がその「文化的雪かき」を担い始めているのを感じざるを得ないのではないだろうか。YouTubeには「これは明らかに生成AIによる画像だな」という画像をバックに作られた動画が結構流れてくるし、文章がメインコンテンツである作品(やブログ記事)に添えられるイラストや画像が生成AIによるものであるケースも増えてきている。「雪かき的」な文章も、早晩生成AIによる生成物に置き換わっていくことは想像に難くない。「まとめサイト」の内容だとか「まとめ動画」なんかのスクリプトなんかどんどんAI化していってない?

「文化的雪かき」の「だれかがやらなくてはならないのだ。好むと好まざるとにかかわらず。」というところに「だけ」注目すると、これは一見良いことのように見える。しかし、「文化的雪かき」には「好むと好まざるとにかかわらずだれかがやる必要がある」「端っこにいけば行くほど細かい違いなんてわからなくなるからどうでもいい」という側面もあるが、一方で少なくともダンス・ダンス・ダンスの主人公は、複雑な誇りのようなものもまた、「文化的雪かき」に対して抱いているのも見て取れる。

翌日はカメラマンが料理の写真を手早く写し、その間に僕が店主に話を聞く。手短に。全ては三日で片付く。もちろんもっと早くすませてしまう同業者もいる。でも彼らは何も調べない。適当に有名店を選んで回るだけだ。中には何も食べないで原稿を書く人間だっている。書こうと思えば書けるのだ、ちゃんと。率直に言って、この種の取材を僕みたいに丁寧にやる人間はそれほどはいないだろうと思う。真面目にやれば本当に骨の折れる仕事だし、手を抜こうと思えば幾らでも抜ける仕事なのだ。そして真面目にやっても、手を抜いてやっても、記事としての仕上がりには殆ど差は出てこない。表面的には同じように見える。でもよく見るとほんの少し違う。

村上春樹. ダンス・ダンス・ダンス (講談社文庫) (p. 42). (Function). Kindle Edition.

この小説には何度も「雪かき」のモチーフが出てくる。そして、すごく雑にまとめてしまえば、雪かきは「現実にとどまること」の象徴としての側面も付与されているように読める。たしかに、「文化的雪かき」のような、雪かき仕事は「地に足がついている」。というか、「くだらないと思うような仕事だけれど、地に足をつけたやり方でやっていること」が主人公のちょっと捻くれた誇りとして描かれているというような読み方ができると思う。

このような「文化的な雪かき」が人間の手からどんどん離れていったとき、ぼくたちの精神構造や社会の構造にどういう変化が起こるのかについては、まだだれも知らない。ぼくはそこまでひどく悲観もしていないけれど、ひどく楽観もしていない。「煩わしい雪かき」から解放されることは良いことのようにも感じる。一方でこの小説に見られるような「雪かきによって担保されていた現実感」というものもどこかにあるのかもしれない。

ダンス・ダンス・ダンスでは、「高度資本主義」という言葉も繰り返し登場する。曰く、高度資本主義の中では、「イメージ」さえもパッケージ化されて商品になる、と書かれているが、現代のぼくたちは実際にイメージが商品化される世界を当たり前に生きていると言える。ダンス・ダンス・ダンスの主人公は、高度資本主義を一種の諦めとともに受け入れ、認識、把握しつつも、決して馴染んではおらず、しかし馴染んでいない中で「現実」の中でステップを踏み続けようともがいていた。

それで僕は無駄というものは、高度資本主義社会における最大の美徳なのだと彼に教えてやった。日本がアメリカからファントム・ジェットを買って、スクランブルをやって無駄に燃料を消費することによって、世界の経済がそのぶん余計に回転し、その回転によって資本主義はより高度になっていくのだ。もしみんなが無駄というものを一切生み出さなくなったら、大恐慌が起こって世界の経済は無茶苦茶になってしまうだろう。無駄というものは矛盾を引き起こす燃料であり、矛盾が経済を活性化し、活性化がまた無駄を作りだすのだ、と。

そうかもしれない、と彼は少し考えてから言った。でも自分は物資不足の極とも言うべき戦争中に子供時代を送ったせいか、そういう社会構造が実感としてよく摑めないのだ、と言った。 「私らは、どうもあなたがた若い人とは違って、そういう複雑なのにはどうも上手く馴染めんですな」と彼は苦笑しながら言った。

僕も決して馴染んでいるわけではなかったが、話がこれ以上長くなっても困るので、別に反論もしなかった。馴染んでいるのではない。把握、認識しているだけなのだ。そのふたつの間には決定的な差がある。でもとにかく僕はオムレツを食べ終え、彼に挨拶をして席を立った。

村上春樹. ダンス・ダンス・ダンス (講談社文庫) (p. 46). (Function). Kindle Edition.

「現実にとどまり続けること」は、これからより難しくなっていきそうだ。地に足のついた「雪かき」をしなくてよくなっていく中で触れる大量のフェイクニュースポストトゥルース。フィルターバブル。いままでよりも速いスピードで、「文化的雪かき」から人間が解放、あるいは疎外される社会の中で、自らを見失わずに、しかしステップを踏み続けるのが、たぶんぼくたちがするべきことなんだと思う。そのためには何をしたらいいんだろう? 少なくとも生成技術を頭っから否定したり接触を断つことではないことはたしかだし(そんなことをしたら羊男になってしまう)、全てを無批判に受け入れることでもないだろう。これから先、自分が、世界が、うまく踊り続けることができるとよいな、と思う。

街には選挙ポスターが溢れていた。どれもこれも醜いポスターだった。選挙演説の車も走りまわっていた。何を言っているのかはよくわからない。ただうるさいだけだ。僕はキキのことを考えながら、そんな街を歩きつづけた。そしてそのうちに僕は、少しずつ自分の足が動きを取り戻し始めていることに気づいた。ステップが軽く、そして確かになり、それにつれて頭の動きにも以前にはない鋭さが感じられるようになった。僕はほんの少しずつではあるけれど一歩一歩前に進んでいるのだ。僕は目的を持ち、それによってごく自然にフットワークを身につけてきたのだ。悪くない徴候だった。踊るのだ、と僕は思った。あれこれと考えても仕方ない。とにかくきちんとステップを踏み、自分のシステムを維持すること。そしてこの流れが僕を次にどこに運んでいくのか注意深く目を注ぎつづけること。こっちの世界にいつづけること。

村上春樹. ダンス・ダンス・ダンス (講談社文庫) (p. 256). (Function). Kindle Edition.

ところで、話は変わるけれど、ぼくがこの小説の中でもっとも好きなシーンは「本物のハンバーガー」について言及されるシーンだ。

 「もう帰ろう」と僕は言った。「日も暮れたし腹も減った。少し散歩してまともなハンバーガーを食べにいこう。肉がかりっとしてジューシーで、トマト・ケチャップがとことん無反省で、美味く焦げたリアルな玉葱のはさんである本物のハンバーガー」

村上春樹. ダンス・ダンス・ダンス (講談社文庫) (p. 384). (Function). Kindle Edition.

「肉がかりっとしてジューシーで、トマト・ケチャップがとことん無反省で、美味く焦げたリアルな玉葱のはさんである本物のハンバーガー」を食べることはおそらく「現実にとどまること」の一部であるだろう。ぼくも本物のハンバーガーが食べたい。

なお、この記事は引用部分以外は一文字一文字人間がタイプすることで書かれた。文化的雪かきでもなんでもない、「ホビーとして書かれた文章」である。

ソフトウェア開発の不確実性と決断

ソフトウェア開発には大きな不確実性がつきものであることはすでに現代では広く知られている。

この不確実性とどのように向き合っていくか、ということも多く語られていて、いわゆるスクラム開発というフレームワークは、不確実性に対して「適応性」を高めていくために用いられるフレームワークだったりする。また、「不確実性の高い部分と低い部分があるなら、高い部分を先にやっつけてしまう」というようなテクニックも当然有用だろう。あるいは、高度な技術力のある人間の高度な設計力によって、不確実性を軽減するアーキテクチャを導入できることもある。

このように不確実性に立ち向かいコントロールしていくことが重要なのはいうまでもないけれど、一方で、不確実性のコーンを引用するまでもなく、結局のところ、リリースするまで不確実性は「なくならない」ということに眼を向ける必要も同時にあると思う。どれだけ適切に不確実性に立ち向かっても、必ず、どこかで「不確実性を不確実性のまま飲み込む必要」が出てくる。これはまさに判断と決断の話でいうところの「決断」のことだ(c.f. 判断と決断の違いと決断のコツ - そーだいなるらくがき帳 )。わたしはいろんなところで「適切な判断をしたい」と「不確実性がなくならない」の間でデッドロックになってしまう、というシチュエーションを結構多く見かけることがある。「不確実性が多いから、判断ができない」「決定がなされないから変数が増えてしまい不確実性がいつまでたっても小さくならない」というデッドロックだ。

このとき必要なのは結局「不確実性を不確実性として飲み込んで決断することで変数を減らしてものごとを前に進めること」だ。これは「十分に不確実性が少なくなった時点での判断」よりも失敗の可能性は当然高い。なので、決断したら「その決断を成功にするためにできること」に対しても努力しないといけない。このふたつを担う、というのは結構大変なことだし、「自分がそんな博打やっていいのかな」と思うことも多い。だけど、もし「あなたの現場」でその決断をするひとがおらず、「あなたは」決断をするべきだと考えているのであれば、多分それが「その場で」できるひとはあなたしかいない。あるいは、たまたま、その現場でのリーダーという立場があなたなのであれば、それは「あなたしかそれをやるひとがいない」のだから、腹をくくってやるしかない。そして、そういうことをやった場合にもし失敗しても、その失敗はあなたの経験となるので、あなたにとっては無駄にはならない。「けど事業や会社や仲間にとっては無駄になるじゃん」、という考え方は大変に正しいし、わたしもそれで足がすくんだり悲しくなったりすることが結構あるのだけれど、そういうときには同僚が以前いってくれた、「その場で、その決断をする人間、あるいは別の決断をする人間が他にいなかったのであれば、どういう結果になったとしてもそれがこの組織にとってのベストであって、なのであればそのベストが失敗したところでもう他の誰がやったところでダメってこと。"もっとうまくやるひと"が仮にどこか別の組織や別の世界にいたとしても、そのひとはいまここにいないのだから、あなたがベストなのだ」という言葉を思い出している。

#lacolacoユーザーの声 しんぺいの場合

TL; DR

lacolaco 1on1は、「課題の解き方を考えたいとき」以上に「課題を見定めたいとき」に有用

この記事は何?

blog.lacolaco.net

この記事に対するアンサーソングです。

lacolacoさんとの関係

Classiで同僚として働いています。わたしはVPoTという立場であり、組織体制的にはlacolacoさんの1on1を私がする、というのが自然に見えるかもしれませんが、

  • わたしは直接の部下を持っていないのでわたしがlacolacoさんをマネジメントしているわけではない
  • あまりにlacolaco 1on1が有用

ということで、わたしが頼んで制度としての1on1というよりは野良1on1をしてもらっているという状態です。

lacolaco 1on1 ユーザーレビュー

VPoTを拝命してからは、id:Soudai さんとlacolacoさんによく1on1してもらっています。そーだいさんの1on1とlacolacoさんの1on1はどちらも大変有用ですが、かなり違った特徴があります。

そーだいさんの1on1は、どちらかというと、「導く」1on1と言っていいでしょう。課題があるときに、どうその課題に向き合えばいいのか迷ったときに、「こういうアプローチをしてみてはどうか」という助言や、その問題を解く際に役立つ考え方を助言してもらうことが多いです。以下のツイートなんかはまさにそーだいさんから「導かれて」わたしの判断軸として身についていったことだったりします。

一方、lacolacoさんとの1on1は、導かれる、というよりも、探索的に進んでいくことが多いです。「それならこういうふうにしたらどうですか」だとか「それにはこういう考え方が効くと思います」という会話は比較的少なく(当然lacolacoさんは問題解決のエキスパートでもあるので、こういう会話がないわけではないですが)、「問い」の形で進んでいくことが多いです。だいたい「今のマインドシェアってどうなってます?」という質問から始まり、自分の脳を今占めている問題について私がつらつらと話し始める、というところから1on1が始まるのですが、本当にいいタイミングで「XXで困っている、と言ってるけど、それってなぜ困っているんですか? 問題視している理由は?」とか「Aという前提からBという結論が導かれているけど、その接続が自分にはよくわからなかったからもう少し言語化してみてほしい」という「合いの手」が入ります。この合いの手が本当に絶妙で、自分が無自覚に飛躍しているところや、無自覚にバイアスがかかっているところに「効き」ます。実際、lacolacoさんとの1on1を通して、「問いの立て方がシャープではなかったな」「本当に問うべきはこちらか」という理解ができたときには、その問いを解決することで大きな成果につながっている実感があります。間違えた問題を解いたところで、なにも解決しないですからね。

というわけで、lacolacoヘヴィユーザーの声としては、lacolaco壁打ちは「問題の解決ではなくて探索に効く」というおすすめの声をあげておきたいと思います。

もちろん、これはlacolacoさんが「しんぺいさん向け」に行なっている1on1であり、他の効力もきっと他のところで発揮しているのでしょう。そのあたりのレビューは他のlacolacoユーザーの声にお任せすることにします。