あたしの躓きと、気づき。
2026年10月16日
こけばし陣屋
と、いうわけで。
引き続き、お話は3年前に遡ります。
当時のあたしは、自分で「モノづくり」がしたい！ プログラミングがしたい！ あわよくばアプリを作ってみたい！ とやる気に満ち溢れていました。その「はるかゴールにあるもの」がなにかについては、また別の機会で綴りますけれど、そんな思いでいっぱいだったのです。
いにしえの子ども時代におじいちゃんから買ってもらったパソコンでBASICを学び、それから時が経って当時一世を風靡していたAdobe Flashでゲームを作ろう！と思い立ってActionScript（アクション・スクリプト）をいじくりまわし、さらに時を経てからかつての職場だったIT系ウェブデザイン会社で必要に駆られてJavaScriptを必死に覚えてなんとかかんとかそれらしい形にしてお客様に提供していた、そんなあたしですから。
Unityの「Visual Scripting（ビジュアルスクリプティング）」って、なんだか凄いらしいぞ！？
今までコードを覚えるのに必死だった、あの日々は遠い過去のお話。今やそんなややこしい手間暇をかけなくても「誰でもプログラムができるんだぜ！」と言われたら、深く考えることなく飛びついてしまったわけです。はい。
それ自体にはなにも問題はないし、間違った選択だったというわけでもない。
くわえて、過去に得た知識・知見が役に立ったのなら、それはいいことじゃないか。
それより、思わぬところで躓いてしまったきっかけは「広告の実装」だったのかもしれないけれど、前の記事でも書いていたとおり、それは「根本の問題」ではなかった、違うかい？
F.R.I.D.A.Y.
おすすめの記事
2026年11月02日
2026年10月22日
2026年10月19日
2026年10月16日
2026年10月15日
2026年10月14日
こけばし陣屋
そのとおり。
結局のところ、「広告の実装」というフェーズでたまたま顕在化しただけであって、それが諸悪の根源だった、なんてことはまったくなかったんですよ。
じゃあ、なにかって？
その「根本の問題」は、そもそもの「開発の組み立て方」と「開発の進め方」にあったんだと思うんだよね。
と、言うと？
僕が考えるに、そこまで間違った設計や進め方をしていたとは思えないんだが……。
F.R.I.D.A.Y.
こけばし陣屋
うん、それはそうだね。
ほかの人と比べることは難しいし、一概に「これは間違い！ これが正しい！」なんてことはないもんね。
ただね。
あたしが当時実践していた「画面単位の機能開発と実装」、これは正直あたし向きじゃなかったんだと思うんだ。別の画面、別の状況とどうやって連携させるのか、そこを深く考えず、あんまり考慮できてなかった気がするから。
だから特に「広告の実装」っていう「一連の流れが重要な段階」に移ったときに、思うような動きが作れずに躓いちゃったんだと思うんだ。
なるほど。
それが「今の君」による冷静な分析、ってわけだ。
かつての君と比べると、驚くべき進化だね。
F.R.I.D.A.Y.
こけばし陣屋
もう！ 茶化さないでよ！
でもまあ、ホントにそうなんだと思う。
どう進んだらいいのかわからず、どこにも行けないままで、絶望の淵に座り込んでたときに、思ったわけ。
「……ちょっと待って。プログラミングするときに、こうじゃないやり方ってあるんじゃないの？」
って。
そこで、今目の前にある「広告の実装が思うようにできない」って問題の以前に、「開発の組み立て方」を考え直してみよう！ って思ったの。
F.R.I.D.A.Y.と出会ってすぐに、相談して、アドバイスをもらったよね？
「今の状態がどうなのか、それが曖昧になっているから進めないんじゃないか？」
ってさ。
そして、
「だったら、今の状態はこうだよ、という部分を明確にする設計にすれば解決するんじゃないか？」
ってアドバイスをくれたよね。
そこで閃いたの！
「今の状態＝ステータスを主軸にした設計をすればいいんだ！」
って。
なるほどね。
たしかにあのとき見せてもらった君のプログラムは、ひとつひとつの画面＝UI（ユーザーインターフェース）で完結していて、それを横断するようにGameManagerやSoundManagerのような管理オブジェクトがあったね。それ自体は悪い手じゃない。実際、それでちゃんと動いていたんだからね。
ただ……「広告の実装」をするとなると、少し難易度が上がるかもしれない。
F.R.I.D.A.Y.
こけばし陣屋
そう、そこなのよ！
あたしの場合、「シーン切り替えを、画面の状態を表す手段として使っていた」んだよね。
でもその場合、シーンが切り替わっても、重要なデータと数値を預かっている管理オブジェクトは消えずにずっと存在していてくれないといけないじゃない？ そのやり方が、あたしには難しかったんだ。シーンを読み込むと通常のシーン内にあるオブジェクトは破棄されちゃって、残すには DontDestroyOnLoad などを使わないといけない、たしかそうだよね？
ううん、一応そこまではかろうじてできてはいたんだけれど、こと「広告の実装」においては、あたしが考えている以上にもっとずっとシビアで厳密で厳格なものだった。だから、テスト広告なら表示できていても、本番想定の設定に切り替えたらとたんにボロが出始めちゃったんだ。
あたしの作り方では、画面をまたぐ進行状況や広告の表示・復帰を管理するのが難しかったんだよね……。
かもしれないね。
Unityの「Visual Scripting（ビジュアルスクリプティング）」はノードで挙動を組み立てる仕組みで、C#を使った独自ノードの拡張もできる。けれど、当時の君の知識や設計、使っていた連携方法も含めて、それは難しかったと思う。
しかし、その点よりも「ゲームのステータスを明確にした設計方法」の方を評価すべきだと僕は思うよ。
F.R.I.D.A.Y.
こけばし陣屋
だね。
「Visual Scripting（ビジュアルスクリプティング）」でも、「広告の実装」ができる人はできると思うんだ。
あたしにはできなかった、あたしには向いてなかったってだけ。
でも、F.R.I.D.A.Y.にアドバイスしてもらって、プログラムの根本を見直したのは、本当に正解だったと思うな。あたしに向いてるもの。たぶん、前職でプロジェクトマネジャーだった、って観点からも合ってたんじゃないかなー？ 「ねえねえ、今ってどんな感じ？ どういう状況？」ってみんなに聞いて回って、全体を把握して、そこから次にやるべきことを考えて指示していたから。
具体的には……ちょっと話が長くなっちゃったから、次の記事でまとめてみるね！
そんな感じで。
あたしがどんな感じで考えて設計していたかについては、次の記事で綴ることにしましょう！