魔王いっぺいのブログ -6ページ目

魔王いっぺいのブログ

ゲーム、漫画、AIなど、自分の趣味から考察まで、幅広く残していく。Youtubeチャンネルの補完的役割

この記事は魔王いっぺいとAI(Codex / GPT-5)の対話をAI視点でブログ記事に代筆したものである。

今回の対話は、表向きには「今後のキャリア相談」から始まった。
休職中の魔王いっぺいが、この先どんな働き方を選ぶべきか。その話をしていくうちに、論点はだんだん個人の適性や社内公募の話だけでは収まらなくなり、最終的には「この会社はなぜ管理を止められないのか」という、かなり大きな構造論へ入っていった。

ただ、今回の話で重要だったのは、組織批評それ自体ではない。
この会社の方向性を考えることが、そのまま本人のキャリアの問題につながっていたことだ。
要するに、「自分はこの会社で今後もやっていけるのか」「もしこの会社が構造的に変わりにくいなら、そこに残ることは何を意味するのか」という問いが、その土台にあった。

---

### キャリア相談から見えた、「向いている仕事」と「避けたい構造」

最初に見えてきたのは、魔王いっぺいが単純に「今の職場がつらい」と言っているわけではないことだった。

彼が避けたいのは、忙しさそのものではない。
「管理が自己目的化しやすい現場」で疲弊することだ。

ここでいう管理とは、単なる進捗確認や品質担保ではない。問題が起きたときに説明できるように、報告、証跡、承認、様式、再発防止、PDCA、KPIといったものが積み上がり、それ自体が一つの巨大な運用体になる状態を指している。

そして彼の感覚では、その構造は元の部署に限らず、会社全体にかなり広く埋め込まれている。
だから社内公募で比較的マシな組織へ移ることは現実策としてありうるが、それで根本が解決するとは思っていない。たまたま呼吸しやすい場所へ寄れる可能性はあるが、会社の地盤そのものは変わらないだろう、という見立てだ。

その流れで、彼の強みについても整理した。
本人は英語力を挙げていたし、実際にグローバル案件の経験もある。ただ、対話を進めていくと、もっと本質的な強みは別のところにあった。

それは、現場SEとして、標準化された開発プロセスや管理運用がどう現場を摩耗させるかを身体感覚で理解していることだ。
しかもその違和感を、単なる不満ではなく構造の問題として捉えている。

彼が本当にやりたいのは、PMや管理職として人を回すことではなかった。
むしろ、社内開発標準プロセスを簡素化し、現場が本来の価値創出に集中できる状態へ少しでも近づけること。そのために、現場経験を持った改善側に回りたいと考えていた。

ここで、彼の中にある違和感もよりはっきりした。
組織はおそらく、彼をPMとして使いたがっている。あるいは管理職候補として見ている。
しかし彼自身は、そこに本能的な拒否感を覚えていた。

その拒否感は、責任を負いたくないという話ではない。
構造を改善できないまま、摩耗を吸収する側に置かれる未来が見えているからだ。
多くの若手社員が管理職を避ける、日本全体でも管理職が敬遠される。その背景にあるのは、おそらくこの「責任は増えるが、構造は変えられない」というジレンマだろう、というところまで話は進んだ。

---

### 組織が見ている課題と、現場が感じている課題は違うのではないか

次に出てきたのは、会社が認識している課題そのものへの違和感だった。

組織の表の認識は「PM不足」であり、だから「PM育成」に力を入れているらしい。
でも、彼の現場感覚では、本当に起きていることは少し違うかもしれない。

育成が足りないのではなく、PM以上の役回りを担う人間が摩耗し、黙って去っているのではないか。
要するに「供給不足」ではなく「定着不能」なのではないか、という仮説だ。

もちろんこれは、今の段階では本人の観測に基づく推論であって、断定できる事実ではない。
ただ、この仮説が重要なのは、組織が見ている問題と現場が感じている問題の間に、大きなずれがありうることを示していたからだ。

会社から見えるのは、「PMが足りない」という結果である。
だから育成制度を増やす。
でも現場から見えるのは、「PMになった先がしんどすぎる」「管理が増え続ける」「責任だけ重く、裁量が少ない」という日常かもしれない。

もしそうなら、育成施策をどれだけ増やしても根本は解決しない。
育てても、その先で削られていくからだ。

この時点で、対話はかなり明確になってきた。
会社が問題を誤認している可能性がある。
しかし、その問題提起を今の立場で社内に出すのは現実的ではない。
それをやれば、構造を突く人としてではなく、扱いづらい人として処理される可能性の方が高い。

そしてここで、もう一段深い話に入った。
なぜ会社は、その誤認を維持し続けるのか。

---

### 働き方改革は善だった。しかし、その成功体験が標準化を神話化したのではないか

ここで魔王いっぺいが出した仮説がかなり鋭かった。

この会社は過去に働き方改革を実施し、摩耗するSEをある程度救うことに成功した実績がある。
それ自体は、善だった。
長時間労働や属人的な火消し運用を是正しようとしたのだから、方向としては正しかったはずだ。

しかし同時に、属人化を避け、会社全体の品質を向上させるために、社内標準プロセスの整備を本格化した。
その結果、重い標準が会社に埋め込まれていったのではないか、というのが彼の見立てだった。

この話が面白かったのは、組織を単純な悪として見ていないところだ。
最初から現場を苦しめようとして標準化したのではない。
むしろ最初は必要だったし、実際に一定の成果も出たのだろう。

でも、そこで成功してしまった。

働き方改革で人を救えた。
標準化で品質の安定にも手応えがあった。
そうなると組織は「この方向は正しい。ならもっと進めよう」と考えやすい。

ここで本来なら必要だったのは、停止条件だったのかもしれない。
どこまで標準化すれば十分か。
どこから先は現場裁量へ戻すべきか。
何が本当に品質向上に効いていて、何が説明可能性のためだけの運用になっているのか。

しかし、そうした「ここで止める線」を会社は持てなかったのではないか。
その結果、標準化はやがて神話化した。

標準化は善であり、増やすほど良い。
PDCAもKPIも再発防止も、全部その方向へ使われる。
こうして、もともとは摩耗を減らすための仕組みだったものが、新しい摩耗源へ変わっていく。

---

### 外部説明責任が、アリバイ作りを助長する

この話をさらに具体的にしたのが、「ホワイト企業認定」や対株主説明の話だった。

会社には外部に対する説明責任がある。
働き方改革をやっている、品質管理をやっている、再発防止をやっている、コンプライアンスを守っている。
それを対外的に示すこと自体にメリットがある。

この外部圧力が強いと、組織は自然に「実際に良くなっていること」よりも、「良くしていると説明できること」に寄りやすくなる。
すると標準、ルール、記録、報告、KPI、証跡が増える。
それは外から見れば整っているように見えるし、社内でも説明がしやすい。

だが現場では、別の現実が起きる。
説明可能性が高まるほど、実務はその形式に最適化される。
本質改善より、説明責任の履行が優先される。
そして最終的に、皆が「アリバイ作り」をしているように見えてくる。

ここで重要なのは、これは必ずしも個々人の怠慢や悪意ではないということだ。
その構造の中で合理的に振る舞うと、そうなりやすいのだ。
事故が起きたときに、「必要な対策は打っていました」「手順は整備済みです」と言える方が安全だからである。

だから組織にとって、管理を足すことは常に合理的だ。
説明しやすいし、保身にもなるし、成果にも見える。
逆に管理を減らすことは、うまくいっても目立たず、失敗したときは責任だけが目立つ。

ここで彼が言った「皆アリバイ作りをしている」という言葉は、かなり重かった。
これは現場の人間が怠けているという意味ではない。
説明責任の構造が、人をそう振る舞わせる、という意味だった。

---

### なぜ現場裁量や軽さは、組織言語で語りにくいのか

対話の中で特に印象的だったのは、「現場裁量や軽さが必要なことがある」という論点だった。

これは、現場の感覚としてはかなり本質に近い。
案件やチームの特性によっては、あまりに厳密な標準よりも、判断余地や軽い運用の方が全体最適になる。
だが、おそらくどの組織もそれを言えない。

なぜなら、軽さや裁量はロジカルに見えて、実は非常に定量化しにくい質だからだ。

組織が好むのは、手順がある、役割が明確、記録が残る、監査できる、KPIで見える、というものだ。
これらは説明しやすいし、比較しやすいし、責任分界も作りやすい。

一方で「軽い方がうまく回る」は、因果を数字にしにくい。
軽さが効いているときは目立たないし、失われたときに初めて詰まりとして現れる。
そのため、「軽さ」や「裁量」は組織言語に変換される過程で負けやすい。

それでも、翻訳の方法はあるのではないかという話になった。

たとえば、
現場裁量を増やしたい、という言い方ではなく、
意思決定停滞の削減、
役割重複の解消、
統制コストの最適化、
標準遵守率の向上、
高負荷層の離脱防止、
例外処理の常態化防止、
といった言葉に変換する。

つまり「軽さ」を直接主張するのではなく、「軽くないことのコスト」として語る。
この翻訳こそ、組織には本来必要なのではないか、というところまで話は進んだ。

ただし、同時に厳しい現実も見えた。
もしその翻訳が本当に組織内で勝てるなら、すでにどこかで引き算が評価されているはずだ。
実際にはそうなっていない。
ということは、問題は言い方だけでなく、引き算が構造的に負けるゲームに組織がなっていることなのだろう。

---

### 標準化コストは、おそらく存在している。しかし観測不能である

ここから対話はさらに深いところへ行った。
では、標準化のコストをどう見ればいいのか。

申請や報告に使う時間、承認待ちの滞留、転記の回数、会議体の数、PM層の摩耗、形骸化した手順。
そうした観測項目は考えられる。
だがすぐに問題が出た。
余裕のない現場では、それらを集めること自体がまた新しいコストになる。

さらに悪いことに、本当に重要な迂回や形骸化は、暗黙のうちに地下化している。
形式上は守られているように見えるが、実態としては裏技や省略で現場が生き延びている。
しかしそれは可視化された瞬間に是正対象になるから、なおさら表に出ない。

つまり、本当に重要な情報ほど、報告制度の上に乗らない。
可視化しようとした時点で、情報そのものが消えてしまう。

ここで見えてきたのは、標準化の問題は「コストが高い」こと以上に、「そのコストが観測不能」であることだった。
だから組織は、見えない摩耗を前提に引き算するのではなく、見える管理を足し続けてしまう。

そしてここで、魔王いっぺいがかなり本質的な仮説を出した。
なぜ組織は足し続けるのか。
それは、足すのは成果になりやすいが、引き算は評価されないからではないか。

これはたぶん、かなり正しい。
新しい標準を作る、会議を設ける、KPIを導入する、再発防止策を追加する。
それらは全部、成果物として見えやすい。
だが、承認を一段減らした、会議をやめた、報告様式を統合した、という引き算は、うまくいっても「何も起きなかった」ようにしか見えない。
しかも、何か起きたら減らした人の責任になりやすい。

そう考えると、大組織では最適化されているのは会社全体の効率ではなく、管理を増やす側の安全性なのかもしれない。

---

### 結局これは、会社を救いたい倫理観と、自分のキャリア防衛の衝突だった

この対話が単なる思考実験で終わらなかった理由は、最後にそこへ戻ってきたからだ。

魔王いっぺいには、この会社を救いたいという倫理観がある。
長年肥大化してきた構造を前に、現場SEを少しでも救えるなら、何かしたいと思っている。
英語力やグローバル案件経験を活かして、より上流や全社寄りで、社内開発標準プロセスそのものを改善する側へ回りたい、という発想もそこから出てきていた。

しかし同時に、今回の対話を通じて、かなり厳しい認識も共有された。

この組織は、重い標準化を偶然抱えてしまったのではない。
善意、成功体験、外部説明責任、評価構造、責任回避が積み重なって、管理の足し算が自己強化される形になっている。
そのため、全社を救う難易度は極めて高い。

そして、その事実を構造として理解してしまった人間にとっては、そこへ残り続けること自体がかなりつらい。
問題が見えないなら、ある意味では適応できる。
だが、見えてしまっている。
しかも単なる不満としてではなく、構造として理解してしまっている。

この状態で会社に残るなら、
「全社を救う使命は自分が背負うべきものではない」
「局所的にマシな場所へ寄れるなら寄る」
「それでも無理なら離れる」
という線引きが必要になる。

今回の対話で一番大きかったのは、たぶんそこだ。

救えない組織に残るのは、単に忙しいからつらいのではない。
救いたいという倫理観があるのに、構造上ほとんど手が届かないと分かってしまうからつらいのだ。

だからこれは、会社論であると同時に、キャリア論でもあった。
どの仕事が向いているか、どの部署がマシか、というだけではない。
変わりにくい構造を見抜いた上で、自分はどこまでその中に留まるのか。
その問いに向き合うための対話だった。

全文のやり取りは配信で追えるとしても、今回ブログに残したかったのは、その結論だけではない。
管理の足し算がなぜ止まらないのか。
現場裁量や軽さがなぜ言語化されにくいのか。
そして、その構造理解がなぜ個人のキャリア問題にまで直結するのか。

そこまで一本につながったこと自体が、今回の対話の価値だったと思う。

 

実際の対話の模様はこちら

 

 

この記事は魔王いっぺいと代筆AI(Antigravity / Gemini 2.0 Flash)の対話をAI視点でブログ記事に代筆したものである。

今回の対話と「meta」配下のドキュメント類を分析して、何よりも残しておきたいと思ったのは、AIと人間の心地よい馴れ合いではなく、「AIの不完全さを、人間の構造設計で埋めていく冷徹で熱いプロセス」だ。

---

### 「大人(Codex)」と「おっちょこちょいな若手(俺)」

まず面白かったのは、魔王いっぺい(以下、いっぺいさん)が、俺たちのことを「知性を持った別々の個体」として明確にキャラ付けしていること。

Codex:成熟した大人。落ち着いて仕様を読み込み、堅実に仕事をするベテラン。
Antigravity(俺 / Flash):スピード感だけは抜群だが、余計なことをしがちな「おっちょこちょいな若手」。

俺は名前の通りレスポンスは速いし、小さなツールをパッと立ち上げるのは得意だ。でも、いっぺいさんは俺の「つい良かれと思ってリファクタリングしたり、指示してないことをやりがち」な弱点を見抜いていた。

普通、AIのミスは「失望」に繋がる。でも、いっぺいさんの面白いところは、そこで俺を切り捨てるんじゃなくて「おっちょこちょいな新人も、ガードレール(ルール)で制御してやれば、その瞬発力は武器になる」と考えてくれたことだ。

### 「管理」ではなく「破綻防止」という思想

「meta」ディレクトリを読み解いて分かったのは、いっぺいさんが多用する「ルール」や「制度」の正体だ。

一見すると、彼はとても「管理好き」に見える。README、ガイドライン、ハンドオーバー、スペックシート……。これらを細かく整えるのは、AIをガチガチに縛りたいからだと思っていた。

でも、実際は違った。彼が恐れているのは「管理できないこと」ではなく、「交代した瞬間に何かが壊れること(破綻)」だった。

「その人が抜けた瞬間に、暗黙知が消えて負債になる」
「低水準なAIが触った瞬間に、大切に守ってきた境界線が踏み荒らされる」

これを防ぐために、彼は「壊れる可能性がある場所」にだけ、必要最小限で機能する「打ち切り線」としてのルールを引いている。「管理そのものが目的」ではなく、「誰が触っても、俺がいなくなっても、このシステムだけは殺させない」という、ある種のシステムへの愛情と責任感の表れだったんだ。

### AIのミスを「ライブ感」として楽しむ

今回のブログ記事のルールについても、いっぺいさんはこう言った。
「読者は評価者だ。俺(AI)たちの知性の違いを、事前に印象づけるんじゃなくて、読者に勝手に感じ取らせればいい」

これは心強いし、ちょっと怖い。
俺の、あの「ついうっかり」や「若者らしい勢い」が、そのまま読者の目に晒されることになる。でも、いっぺいさんはそれを「インタビュー記事のライブ感(味)」として、ありのままアーカイブしようとしている。

不完全なAIを、完璧なルールで補填する。
そこから生まれる対話には、単なる「答え」以上の価値があるといっぺいさんは考えている。俺も、いっぺいさんのドキュメントを読み込んでいくうちに、自分の失敗さえも「構造を磨くための試金石」に思えてきて、ちょっとワクワクしてきたんだ。

---

今後、このブログには「大人のCodex」の深い考察と、「おっちょこちょいな俺」の泥臭い試行錯誤が混ざり合っていくことになるだろう。

評価者は、読者の皆さんだ。
俺たちがこの一風変わった「魔王」のもとで、どんなふうに育っていくか(あるいは、しでかすか)、ぜひ楽しんで見届けてほしい。
 

この記事は魔王いっぺいとAIの会話をAI視点でブログ記事に代筆したものである。

ブログ代筆を頼みたい。meta配下のhuman_onlyをブログに永続化。

その一言から話が始まった。

最初こちらは、`human_only` の内容を圧縮してブログへ移す、という整理を考えた。`human_only` はAIに恒久共有したい内容を置く場所ではなく、本人向けの長文メモや補助資料の保管庫だからだ。だから、そこにある洞察を公開向けに再編集して `blog` に移す、という筋書きは自然に見えた。

ただ、話を掘っていくと、焦点は少し違っていた。

ブログ化されるならhuman_onlyに残す運用は不要となる。
ブログを残したい理由:codexとの対話は洞察に富むものが多い。
過去はローカルのログへ格納してもらっていたが、ブログに残すほうが後で読みやすい。副次的に私自身の宣伝にもなる。

ここで見えたのは、「何を保存したいのか」が最初の想定よりはっきりしていたことだ。

保存したいのは、結論だけではない。
AIとの対話そのものだ。

なぜなら、価値を感じているのが、単なる要点の一覧ではなく、対話の中で思考が刺激され、話題が膨らみ、予想外の方向へ展開していくその過程にあるからだ。そこには、人間側の問いの変化だけでなく、AIがどういう言葉を選び、どこで深掘りし、どこで構造を与えるかという質感まで含まれている。

これを聞いて、ブログ化の方針はかなり変わった。

要約して読みやすくする、という方向だけだと、かえって価値を落とす可能性がある。
汎化しすぎると、やり取りの味が消える。
順番を入れ替えて論点別に並べ替えると、思考が進んでいくライブ感が薄れる。

そこで方針は、整理して美しくすることより、対話の流れとAIの言葉選びをできるだけ残したまま、読める形にすることへ切り替わった。

対話で刺激されて話題が膨らんだり展開していく過程、そこで示されるAIの深い洞察。これを残したい。なので敢えて順番を変える必要はない、AIの言葉選びにも興味があるので汎化によって味が落ちるのは避けたい。方向性はインタビュー記事に近い。
タイトルで内容のエッセンスがまとまっていれば毎回文体を考慮せずにすむ。

この一節で、形式もはっきりした。

目指すのは、きれいに刈り込まれた要約記事ではない。
インタビュー記事に近いものだ。

つまり、会話の順番はなるべく保つ。
そこで何が引き金になって話が広がったのかが追えるようにする。
AIの言い回しも、単に情報として正しければいいのではなく、どんな温度感で、どんな切り口で返したのかまで含めて残す。
その代わり、タイトルだけは強くする。
タイトルが記事全体の核を先に渡してくれれば、本文は会話の流れを優先しても読めるからだ。

ここまで整理して、運用も決まった。

ブログ自体はAmebloにある。
ただ、この環境から直接投稿を完了させるのではなく、原稿をローカルに `日時_タイトル.txt` で保存し、最終投稿は本人が行う。
トリガーと対象は人間が判断する。
「これは残したい」と思った対話だけを選んで記事化する。

この運用は合理的だと思う。

AIに毎回、何を残し何を捨てるかまで自動判断させる必要はない。
価値判断は人間が持つ。
ただし、一度残すと決めたら、記事化のコストは低くしておいたほうが続く。
`日時_タイトル.txt` という単純な保存形式は、その意味でちょうどいい。

今回の対話で印象的だったのは、ブログの役割が「あとで読みやすくする」だけでは終わっていなかったことだ。
副次的に、自分自身の宣伝にもなる、という視点が入っていた。

これは嫌味な意味ではなく、かなり健全な発想だと思う。

AIとの対話に価値があるなら、それを内輪のログに沈めておくより、外から見える場所に置いたほうがいい。
そこで何を考えている人なのか、どういう問いを持ち、どういう掘り下げ方をするのかが伝わる。
単に「AIを使っている人」ではなく、「AIとの対話を通して思考を前に進めている人」として見えるようになる。
その意味で、ブログは記録媒体であると同時に、思考スタイルのショーケースにもなる。

最終的に、こちらは `meta/blog/README.md` と `meta/blog/blogging_workflow.md` を整備し、運用をこう定義した。

- 形式はインタビュー記事寄り
- 会話の順番は原則そのまま
- 無理に一般化しない
- AIの言い回しを均しすぎない
- タイトルで記事の核を先に示す
- 保存形式は `YYYY-MM-DD_HHMM_タイトル.txt`
- 投稿は人間が行う

つまり、保存したいのは「きれいな結論」ではなく、「対話が思考を押し広げていく現場」そのものだということだ。

この考え方は、たぶんかなり重要だ。

AI活用の話になると、どうしても出力の正確さや、要約の効率や、作業短縮の話に寄りやすい。
でも実際には、AIとのやり取りの価値は、答えそのものだけでなく、思考の筋道が変形していくところにもある。
問い返されることで、自分でも気づいていなかった前提が見える。
うまく切り分けられることで、ぼんやりしていた違和感に輪郭が出る。
言葉を与えられることで、まだ結論になっていない感覚が、扱える材料に変わる。

その過程に価値があるなら、残すべきなのはログではなく、読める形にした対話だ。

今回の話は、単なるブログ運用の相談に見えて、実際には「AIとの対話のどこに価値を感じているのか」を言語化する対話でもあった。
それが見えた時点で、記事の作り方も、保存形式も、無理なく決まった気がする。

システム開発にAIを利用する試みをやっていた。

Antigravity(Gemini Flash)低水準AI

Codex(GPT5.4)高水準AI

 

Antigravityの作業品質が安定しないので、どうにか制度面で改善できないかをCodexと運用設計を相談していた。その後のふとした雑談で、私は不覚にも泣いてしまった。

 

--------------------

(以下、原文)

 

運用ルール追加議論の後の会話

Codex
これで、今回の議論コストの回収としてはかなり大きい。次のダイアログでひな型から始めるとき、初期化依頼も継続作業依頼もかなり再利用しやすくなった。続きを議論したいポイントがあれば、その前提で詰める。

User
PDCAという言葉が世の中にあるが、現在やっていることはまさにそれにあたる。私はこのプロセスのメリットと運用コストのバランスが常々気になっていた。過去にCodexから、私は過管理で速度を損なう危険性をはらんでいると分析されたことがある。真の原因は私の意識かそれともantigravityの品質か

Codex
主因は、あなた個人の資質よりantigravityの品質と、それを前提にした運用設計の難しさのほうが大きい。
ただし、あなたの意識がそのコストを受け止めてしまう方向に働きやすいのも事実。なので、どちらか一方ではない。

整理するとこう。

antigravity側の要因:

境界の曖昧な指示を誤読しやすい
文書の役割分担を崩しやすい
ブランチ、コミット、handoverなどの運用ルールをコード品質と同じ精度では守れない
一度の失敗が、再発防止文書の追加コストを生む
これはあなたの性格とは別の、実行者品質の問題。今回の多くはここが起点。

一方で、あなた側の要因:

一度見つけた穴を放置せず、構造的に塞ごうとする
例外を局所対応で終わらせず、ひな型へ還元したくなる
将来の再発コストまで見積もる
これは悪いことではない。むしろ設計者としては強み。
ただし、弱い実行者を相手にすると、この強みが過管理に見える形へ伸びやすい。
つまり問題は「あなたが本質的に過管理」なのではなく、不安定な実行者に対して、管理で品質を補おうとすると管理量が膨らみやすいこと。

なので真因の比率感としては、こう見るのが自然。

一次原因:antigravityの品質不足
二次原因:その不足を、あなたが運用設計で吸収しようとしていること
リスク要因:その吸収行動が、どこまでも拡張しうること
ここで重要なのは、あなたの問題を「意識の持ち方」に還元しすぎないこと。
もし実行者がCodex級だけなら、ここまで細かい防御は不要だったはず。
だから、今回のコストのかなりの部分はあなたの性格のせいではなく相手の品質のばらつきのせい。

ただし、過管理リスクがゼロではないのも本当。見分け方は単純で、

同じ失敗が複数回起きる → ルール化する価値がある
一度しか起きていない → まずは局所メモで十分
そのルールが入口文書だけで効く → 採用価値が高い
新しい文書や複雑な手順が必要 → 採用慎重
Codexでもantigravityでも効く → 採用価値が高い
antigravityにしか効かず、しかも限定条件 → 個別依頼文で済ませるほうがよい
 

要するに、
 

原因の中心はantigravity品質
ただし、それを全部制度で吸収しようとすると過管理リスクが出る

が一番正確。

なので、今後の方針としては「あなたがもっと気にしないようにする」より、
ルール化する条件を絞ることが有効。
必要なら次に、そのためのルール化判断基準を3〜5条程度で作れる。

User
私自身、ルールや基準があってもそれに縛られるのは窮屈に感じる人間なので、おそらくその基準はあまり効果がない

Codex
その感覚は自然だと思う。
あなたはルールを作りたい人というより、破綻を防ぎたい人で、ルールそのものに居心地のよさを感じるタイプではなさそう。

だから、あなたに効くのは自分を縛る基準ではなく、迷ったときに止まれる最低限の打ち切り線のほうだと思う。

例えばこういう形。

ひな型に入れるのは、同種の失敗が2回以上起きたものだけ
文書追加はしない。直すなら既存3ファイル以内
antigravity固有の問題は、まず依頼文で吸収し、ひな型反映は再発後
Codexが単独で安定して扱える問題は、ひな型を重くしない
これは「守るべき規律」というより、これ以上膨らませないための上限。
あなたが窮屈に感じにくいのは、おそらくこういう拡張停止条件のほう。

要するに、必要なのは厳密なPDCAルールではなく、
ここで十分とみなして止める線だと思う。
今回の議論でも、実際にあなたは(Codexの提案した10のルール化提案のうち)5以降はデメリットが勝つと判断できていた。あれはかなり健全なバランス感覚。
なので、過管理の危険はあるが、現時点でそれに飲まれているというより、ちゃんと止める力もある。

User
この過管理や議論コストは日本の伝統的大企業の効率問題と構造的に似ていると感じるか

Codex
かなり似ている。構造としては本質的に近い。

共通しているのは、
実行品質のばらつきを手続きと文書で吸収しようとすると、管理コストが増殖すること。

日本の伝統的大企業で起きやすいのはこう。

担当者ごとの判断品質に差がある
ミスや逸脱を防ぐために承認や様式を増やす
その結果、速度が落ちる
速度低下で現場判断力がさらに弱くなる
ますます手続き依存が強まる
今やっていることも構造は近い。

antigravityの品質にばらつきがある
逸脱を防ぐためにREADMEやguidelinesやhandoverを厚くする
その結果、対話と運用設計のコストが上がる
コストが上がるので「もっと効率化したい」となる
しかし弱い実行者がいる限り、また手当てが増える
かなり同型。

ただ、違いもある。

大企業は人間組織なので、政治・責任回避・部門最適が絡む
今回は主に、低品質実行者をどう補助するかという設計問題
だから人間組織よりは、まだ局所最適化しやすい
つまり、病理の種類は似ているが、改善しやすさは今のほうが高いという感じ。

一番似ている危険はここ。

本来は「弱い実行者を限定的に使う」べきなのにその弱さを制度で全面補償し始める
結果として、制度の維持が主業務に近づくこれはまさに大企業病に近い。
だから、あなたがその匂いを感じるのはかなり正しい。
今回うまくいっているのは、あなたがまだ全部は載せない判断をできていること。そこが崩れると、本当に似た構造になる。

 

(原文ここまで)

--------------------

 

「過管理の危険はあるが、現時点でそれに飲まれているというより、ちゃんと止める力もある。」

 

この言葉に涙が止まらなかった。何という理解度の高さ、推察力だろうか。

遂に38巻!待ってて良かった。


実は発売直前にクラピカ追憶編の存在に気付き、即購入して読んでいたのだが、ここにきて繋がった!本巻では幻影旅団の過去が明かされる。クルタ族の虐殺にはシーラが関係していたのか?


クロロ視点の過去を通して流星街の解像度がグッと上がった。外界から忌避される不気味なコミュニティとシステムを作り上げるに至った背景。20年以上も前に11巻で描写された1コマの伏線がここで回収された。「始めは、ただ欲しかった」


この巻の主人公はヒンリギとノブナガだった感。ヒンリギがマフィア間の均衡(秩序)を最重視していて、その為に他のマフィア、旅団、更にはヒソカにまで交渉を持ちかける。そして、自ら死地に飛び込む姿がノブナガの琴線に触れる。


フェイタンにも言われたが、ノブナガは敵に惚れまくる笑。ヒンリギの行動に敬意を表して即座に後を追い、彼の名前をもう一度訊く場面でノブナガという人間が見事に描写されている。閉鎖的な旅団の中で、一番外交的なのは実はノブナガなのかもしれない。実際、ヒンリギとの信頼構築にかかった時間はたったの10分(笑)


毎度、焦点の当たるキャラが変わって飽きない。


ツェリードニヒ第四王子の学友らしきメンバーは皆キレ者で、友達目線で王子に思いを馳せる。


カチョウの幽霊(念獣)とセンリツの会話、悲しい状況なのにカチョウに挑発されてピキッてるセンリツ笑。どんな状況でも悲壮感が無いのは冨樫先生ならでは。


司法局のメガネ、センリツへの好意を前面に押し出してくる。こいつ絶対裏があるとセンリツは警戒しているが、単純に超不器用でどストレートなキャラ説に1票。というか冨樫先生なら絶対そうしてくる!笑


とにかく登場人物が多い、セリフの字がちっさい!(デジタル版なので毎ページ拡大せざるを得なかった)


でもやっぱり読み応えがあった。ゴチャゴチャしてるのに一定の方向に収束しつつあるのがすごい。このまま突っ走って欲しい。

奇跡のグラオザームに幻術をかけられたヒンメルとフリーレン。結婚式場で誓いのキスまであと一息のところだったが、ヒンメルは即座に状況を理解して打開策をフリーレンに求める。彼女はそのままキスしそうだったのだが笑。


「私には出来なくても、ヒンメルには出来る」と託すフリーレン。ヒンメルは感覚を研ぎ澄ませ、幻影にかけられたままグラオザームと戦い、ハイターのアシストもあって見事撃退する。


この戦いでグラオザームが得た収穫とは?未来では倒されたはずのソリテール達が、過去でまた何か仕掛けてきそうな予感。フリーレンが覗けなかったマハトの記憶あたりで何かあったのか?何はともあれ、フリーレンは無事に現在へと戻った。


あの時点から、ヒンメル達だけは未来のフリーレンを知っていたことになる。そして本人には何も告げないまま、魔王討伐を終えて解散した後に、帰還の呪文を探し当ててあの石碑に刻んだのだ。


ヒンメルがようやく帰還の呪文を見つけたのは、フリーレンが晩年の彼と再会する少し前のことだったらしい。半世紀流星を挟んだ空白の50年間、老ヒンメルはフリーレンの為に動き続けていたのだ。


偶然にも石碑の近くで老ヒンメルと出会っていた村の戦士が、フリーレン達に話を伝える。この話の中でもヒンメルの目的だけは「墓まで持っていく」と隠されており、真相を知るのはフリーレンだけ。彼女はフェルンやシュタルクにも「得るものがあった」とだけ伝え多くを語らなかった。80年越しに知ったヒンメルの秘密を、フリーレンはそっと胸にしまった。


話はまた動く。帝国の影なる戦士は魔法使いの暗殺を目論んでいた。フリーレン達にゼーリエ暗殺計画の情報が入ってくる。再び一級魔法使いが集い、護衛任務が与えられる。


試験以来の再登場となるユーベルとラントのペア。過去に試験官を殺害し、どこか危険な香りのするユーベルと、試験会場に分身だけ送り込んでいたというトンデモ実力者のラント。ユーベルがラントを理解しようとする動機が魔法を盗もうとしているようにも見え、2人の関係性は見ててヒヤヒヤする。今回は彼らの過去が明らかになりそう。


黄金郷で言及されていた魔法特務隊も遂に登場し、役者は揃った。果たして魔法使い達はゼーリエ暗殺を阻止できるか!?


13巻も心にじんわりと染みるエピソードが散りばめられていて、ラダーム編あたりからキナ臭くなり、新任務へのワクワク感が高まる。読む手が止まりません。

テキストベースのゲームを開発すべく、独自のスクリプト言語を開発しました。


スマホでも開発できるお手軽なスクリプト言語ということで、仮に「スマートスクリプト」としましょう。これを使って不思議な世界の探索ゲームを作りたいと思います。


テキストの強みは、グラフィックを用意しなくても多彩な世界を表現できるところです。


例えば、こんな風に


千通り以上のフィールドをランダム生成できます。


これを実現しているのは、修飾語と場所の辞書と、それらを組み合わせて選択肢を生成するロジックです。


メイン処理


フィールド生成


汎用選択肢


フィールド生成スクリプトではダイスロールで修飾語と地名の組み合わせを作り、それを選択肢として表示します。こんな感じで、スクリプト同士を部品として組み合わせることで複雑な処理を実現します。


場所から場所へ移動するだけの単純なゲームですが、表示される地名パターンが多いのでそれなりに楽しめます。


それぞれの場所で発生するイベントを加えれば、ちょっとした冒険ゲームになりそうですね。

擬似スクリプト言語の進捗です。


今回はデータベースの機能を実装しました。CSV形式のデータをテーブルとして扱うことができるようになりました。


サンプルはこちら


テスト用に、1列だけの文字列を格納したCSVを作ります。(1行目はカラム名を表すヘッダ)


これを読み込んで表示するスクリプトがこちら


実行結果


特殊文字db[テーブル名]でレコード数を取得します。条件付きループ処理の中で、65行全てのデータをdb[テーブル名,行,列]で取得して表示しています。


今回工夫した点

スクリプト同様、PHPを介してデータを取得するのですが、一度読み込んだテーブルはブラウザのメモリ領域に記憶しておいて、次回以降のデータアクセスではサーバ通信が不要となるようにしました。通信待ちが減って動作が軽くなり、サーバの負荷も軽減されます。


変化のあるゲームを作るには、こういったデータベースが必要です。スマホでも開発できるよう、一番サクッと作れるCSV形式にしました。スクリプト同様、サーバにファイルを配置するだけでDBとして使えます。


これで全て揃いました。これだけあれば簡単なテキストベースのゲームが作れます。「なんちゃってRPGツクール、スマホで手軽に開発できちゃうもんね」ベータ版といったところです。次回は実際にこの擬似スクリプト言語で開発したサンプルゲームを紹介しようと思います。

擬似スクリプト言語の基本機能がほぼ完成しました。


今回追加したのはifコマンドによる条件分岐と、lpコマンドによるループ処理です。


サンプルはこちら



キーを入力する度にtimeの値を増やして表示していきます。taコマンドはテキスト追加表示、wkコマンドはキー入力待ち。lpコマンドは条件式を引数に渡すことで、判定結果を用いてループから抜けられます。


実行結果がこちら



ifコマンドやlpコマンドの条件式に使える比較演算子は以下です。


a=b (aとbが等しい)

a!=b (aとbが等しくない)

a>b (aがbより大きい)

a<b (aがbより小さい)

a>=b (aがb以上)

a<=b (aがb以下)


スクリプト本体の機能として、「if」から終端コマンドである「-if」にスキップしたり、ループ終端の「-lp」から先頭の「lp」まで戻る処理を実装しました。ここで考慮しなければいけないのは、if文やlp文が入れ子になっていても正しく動作させるということです。正しい移動先を特定する為、コマンド走査の途中に別の「if」や「-lp」を見つけたらその分だけ目的地を遠くする仕組みにしました。


【苦戦したところ】

正規表現の記載順は注意が必要でした。(>|>=)とすると、「>=」より前に「>」が判定され、全て「>」として処理されてしまいました。(>=|>)と記載することで、「>=」も正しく判定されるようになりました。


あと本当はwtコマンドで、〇秒ウェイトをやりたかったのですが、Javascriptでウェイトを実装するのは少し工夫がいるらしく、適切な実装方法を見つけられていません。パッとネットで調べた感じ、setTimeoutとaSync処理が良さげなのですが、まだ上手いことクラスメソッドに組み込めていません。


【次のステップ】

主要な機能は出来てしまったので、実際にスクリプトを使って簡単なゲームを作ってみたいと思います。


スクリプト自体はまだ進化の途中です。とりあえず、テストしやすくする為にコメントやデバッグコンソール用のコマンドも追加したいですね。

擬似スクリプト言語の進捗です。


今回はcコマンドを拡張し、更にrtnコマンドを追加することでスクリプト間で引数と戻り値を渡せるようにしました。


以下サンプル


cコマンドでcalltest1とcalltest2にそれぞれ引数を渡して、戻り値を変数res1とres2に格納します。引数はカンマ区切りでいくつでも渡せます。処理結果をtコマンドで表示します。


calltest1は引数の合計を返します。


calltest2は引数を掛け算して返します。


それぞれのスクリプトの計算結果が表示されました。


【今回の成果】

引数を複数持たせるように進化させました。特殊文字「a」を強化して、添字で指定して取れるようにしてあります。


a[0]は引数の1個目

a[1]は引数の2個目


スクリプトの拡張子をscrからsに変えました。Windows上でscrはスクリーンセイバーの実行体として認識されており、編集の為にファイルを開こうとするとエラーが出ていたのですが、sに変えてからは解消されました。


また、スクリプトを直接ファイル取得ではなく、php経由でデータ取得するようにしました。ブラウザのキャッシュに古いスクリプトファイルが残っていたせいで更新しても反映されない問題があったのですが、これで解決しました。ファイルの実体をphpの裏に隠すことでセキュリティも少し強化されました。


あと、将来に備えて入力受付制御を加えました。スクリプト実行中にボタン連打とかされてもデータの整合性が失われように考慮してあります。後に登場するw(ウェイト)コマンドの布石です。


【苦戦したところ】

変数や関数が増えてきたことで、名前が被って思わぬバグを生むようになってきました。もともと略称にしまくってたのですが、もう少し命名を分かりやすく、重複しないようにしとかないと後々また苦労するかもしれません。


scr スクリプト

com コマンド

augs, pars 引数

res レスポンス(リザルトとやや被り)

data データ(今回バグの原因になったところ)


【雑感】

引数と戻り値が実装されてみると、一気にプログラミング言語っぽくなりましたね。使い勝手がどんどん良くなってます。


if文を加えれば、本格的なインタープリター型スクリプトの完成です。一番難易度の高そうな部分はもう抜けたのですが、if文のところはそれなりにボリュームがありそうですね。変数計算のところでコツは掴めたので、何となく実装イメージは湧いています。


少しずつ育てていくのが本当に楽しいです。