テーブル定義(DDL)から Laravel の web api を ChatGPT で作成する

さらに、ChatGPT でコーディングをするシリーズの続き。

いわゆるスキャフォールディングの手法を使います。CakePHP や Ruby on Rails には、テーブルからコマンドを使って MVC パターンの各クラス&メソッドを生成することができるのですが、何故か Laravel にはありません。いくつか、それっぽいものがあるのですが、実際にやりたいところとして、

  • SQL の create table 文を渡す
  • 適当にリレーションを解釈して欲しい。
  • 出力は Controller/Model を出力して欲しい。
  • Laravel の場合は api.php も必要
  • web api で利用するので、View の blade は必要ない

という要件があるので、通常のスキャフォールディングツールでは過剰なところがあります。特に View の部分はいらないのと、できれば Vue3 の出力までして欲しい、という感じです。

仕方がないので、何かの機会があったら PHP のツールを作ろうと思っていたところなのですが(Laravel が PHP なので…これは仕方がない)、ChatGPT がでてきました。

SQL を渡して、出力を要求する

プロンプト以下のように、SQLをベタ打ち、できるだけ指示を短くしています。

以下の SQL から、指定した店舗内にある商品一覧を表示する。
これを、Laravel の web api で作成して。

--
-- 店舗テーブル
-- 
create table Stores ( 
	id int not null,		-- 店舗id
	name varchar(100),		-- 店舗名
	address varchar(255),	-- 店舗住所
	created_at datetime,	-- 作成日時
	updated_at datetime,	-- 更新日時
	is_delete bool		-- 削除フラグ
);

--
-- 店舗から商品への連携テーブル
--
create table store_product_link (
    store_id int not null,	    -- 店舗ID
    product_id int not null,	-- 商品ID
    stock int,				    -- 在庫数
    created_at datetime,	    -- 作成日時
    updated_at datetime,	    -- 更新日時
	is_delete bool		        -- 削除フラグ
);

以前、GPT-3.5の頃にはうまくいかなかったのですが、GPT-4o ではかなり綺麗に出力されます。

コツとしては、Laravel で出力を要求するところと、SQL のコメントにある「店舗」や「商品」などをプロンプト内に明確に追加することです。ただし、ここの新人教育で使っている店舗や商品の SQL 自体が、GPT-4o で出力したものなので、GPT 自体に読みやすい(内部的に保持している者に近い)形式になっているだけかもしれません。実運用で使われている業界用語を場合はうまくいかない可能性もあります。

そのような場合は、完全に自動生成されるのを期待するのではなく、多少の手作業の時間を残しておいたほうがよいでしょう。そうだとしても、結構面倒な Model 同士の連結なども出してくれるので、最初のテンプレートとしてかなり重宝します。

カテゴリー: 開発 | テーブル定義(DDL)から Laravel の web api を ChatGPT で作成する はコメントを受け付けていません

ER図作成とコードファースト(migrate)に GitHub Copilot を活用する

設計書に ChatGPT を使うシリーズの続き。

以下の手法は、ChatGPT 上でも可能ですが、Visual Studio Code 上で Github Copilot を使ったほうが便利です。現在、自分は ChatGPT と Github Copilot に二重に課金をしている状態なのですが(執筆の関係上というのもあるけど)、通常の開発者ならば Github Copilot だけで十分かもしれません。

テーブル定義(create table)から ER 図を作成する

いわゆる DDL(create table の定義)から、ER 図を作成できる。テーブル作成自体は SQL Server Managerment Studio とか MySQL Workbeanch とかを使っても構わない。この手のツールでは、create table をダンプする機能があるので、それを使ってSQL文を書けばよい。あるいは、手書きでもかまわない。

実際に 10 個程度のテーブルが書いてある。この最後の行当たりで、次のプロンプトを書く。

「これらのテーブルから ER 図を書いて」

これを ChatGPT でやると「ER図のツールがあれば、云々」と文句を言が「mermaid形式で書いて」と頼むと、素直に以下のように erDiagram で書いてくれる。mermaid 形式は、markdown 形式を使って図を書くフォーマットである。

この前後に、「“`mermaid」を入れると、プレビューで ER 図を表示できる。

これを手作業で直しても良いし、そのまま仕様書に貼り付けても良い。

Laravel の migrete を作る

同時に、Laravel の migrate も作ってしまう。

php artisan make:migration create_products_table

このように database/migrations の下にファイルができるようにする。

migrate ファイルに該当する create table の SQL を貼り付けて選択状態にする。

プロンプトで「createに直して」で十分である。手作業で直すよりも圧倒的に早いし、created_at と updated_at を timestamps() に変換してくれる。softDeletes() のほうはたまに失敗するので、手作業で直すとか、何度か生成させればよい。

注意:softDeletes() にすると、deleted_at か is_delete になるので、厳密にしたい場合は指定したほうがいいかも

ChatGPT だと、関連するコードを貼り付けたり言語をしていしないといけないが( ChatGPT のデフォルト言語が Python なので、Python コードが最初に出力されてしまう)、VSCode 上の GitHub Copilot だと、拡張子や前後のコードから判断してくれるらしく、かなりスムーズにコードが生成されることがわかる。

参考先

https://github.com/moonmile/h2w-traning-2024/tree/master/src/laravel/webapi の ER.md あたりを参考にしてください。

カテゴリー: 開発 | ER図作成とコードファースト(migrate)に GitHub Copilot を活用する はコメントを受け付けていません

映画「オッペンハイマー」の感想

原子力学科卒としては、観ておかないといけないなぁと思いつつ、そのままになったていたのだが、時間が取れたので映画館に行った。

結論から言えば、ツイートした通り、同時公開されたときに何故か日本だけ外された(あるいは外した)ことが悔やまれる内容である。宣伝の仕方が不味かったのもそうだけど、宣伝的に原爆実験をしたシーンが表に出てきてしまい、それに反感を覚える日本人(あるいは広島在住者?)が多かったのかもしれない。バービーとのコラボ?っぽいツイートで騒動になったのもそれだろうが、結果的に同時公開しなかったことが悔やまれる。

映画としてはマンハッタン計画の中心人物として持てはやされるオッペンハイマーが、当時の「機密安全保持疑惑」に嵌められたというスタイルを取っており、それが史実かどうかはよくわからない。アメリカ内ので彼の評判も私はよく知らないので、なんとも言えないが、日本側から見ると、

  • アメリカが原爆を開発した。
  • ポツダム宣言以後に、広島と長崎に原爆を落とした
  • アメリカでは原爆は戦争を終了させる人助けとして認知されている

という見方になるが、映画を見るとアメリカから見れば

  • ドイツやソ連に先立って、アメリカは原爆を開発する必要があった
  • ドイツが敗北した後でも、日本の侵攻を防ぐために攻撃する必要があった
  • 政治的な問題として、ポツダム宣言以前に原爆実験を成功させる必要があった
  • 政治的な問題として、威力を示すために、広島と長崎に原爆を落とす必要があった

となっている。映画「オッペンハイマー」では、オッペンハイマー自身の苦悩としてあらわしているものの、実際のところ、

  • ポツダム宣言の前に、原爆実験を成功させる

ことを「成功」と呼び、そこにいた科学者も含めて成功者としてオッペンハイマーを称え狂喜するシーンがある。それにオッペンハイマー自身が応じるわけだが、ここでは

  • 回りの狂喜する声が聞こえない。
  • オッペンハイマーは、自分自身の声をぼんやりと聞いている

という演出がなされる。

直前の原爆実験の秒読みや実験直前の嵐のシーンなどは、なんらかの科学実験を連想させ、その成功を映像とともに観客も喜び出しそうになる(実際、アメリカが歓喜があがったようだ)のだが、その直後の先ほどのシーンを考えれば、それがほんとうに「喜ぶべきものだったのか?」と自問させるところである。

日本人から見れば、大量殺戮兵器としての「原爆」の完成を喜ぶなんて!と思うところだが、当時のアメリカ人からすれば(それはオッペンハイマー自身もそうだっただろう)、原爆による悲惨さ(とくに火傷や後遺症など)は知るべくもない。誰も実際に広島に投下するまでは解らなかった時系列があり、その事実の前では原爆も完成を喜ぶのも無理はない、という感じがする。映画を見ている私達は、原爆の事実を知っているのので、あのシーンに疑問を投げかけることができるが、知らなければそれは「狂喜」しただろう。いや、誰もが喜んだと思われる(殺傷力も過小に見積もられていたし)。

そこで一緒に映画の中で成功を喜ぶ科学者と同じく声を上げたアメリカの観客が、その後で、オッペンハイマーが、黒焦げの子供の消し炭を踏み潰したシーンを、どう見ただろうか?ということである。その落差が非常にうまく演出として効果をあげている。

「トランスサイエンス」という言葉がまさにこの映画にあてはまると思う。いや、アルビン・ワインバーグ – Wikipedia 自身もマンハッタン計画に加わっているので、まさにそれなのだろう。物理学者の世界では、どうしてもこの原爆を作ってしまったという「マンハッタン計画」を歴史上避けられない。おそらく、それはコンピュータを主とするソフトウェア開発者もあてはまる。私の場合は、二重にあてはまるのだが。

追記

いくつかツイッターで検索すると、原作があるそうなので、後で読むことにする。

Amazon.co.jp: オッペンハイマー 上 異才 (ハヤカワ文庫NF) eBook : カイ バード, マーティン J シャーウィン, 河邉 俊彦, 山崎 詩郎: 本

感想として「オッペンハイマーを英雄として描いている」部分が気に入らない方が多いようだが(実際に演じた役者にとっても、「原爆の父」あるいは「原爆」がアメリカの大切な資産として扱っている人が多いらしい)、実際のところ当時のアメリカにとってオッペンハイマーは英雄であったろうし、おそらく今でも英雄的な扱いと思われる。

映画の中でトルーマン大統領が言っているが「恨まれるのは科学者ではなくて、政治家だ」と言っている通り、裁かれるのは当時の政治家であり、おそらく大統領の言葉は、当時のチャーチル首相を模した言葉だろう。敵国(この場合は日本、チャーチルにとってはドイツ)にとって憎まれるのは、当然のことでありむしろ勲章に近いものがある。

が、科学者としての物理化学者としてのオッペンハイマーは、そのような政治屋ではない。という描き方がされている。だから、当時のアメリカ国民から「英雄」とされつつも、原爆を作ってしまったという自責の念があり、それは最後のアインシュタインの言葉の通り、最終的に評価されるということは科学者自身のためではなく、周りが納得いくための儀式でしかない。つまりは、原爆を落とし、その後の被爆者という現実を作ってしまったことに対しても、時間が経過すればそれらの現実味が薄れて、最終的には「原爆の父」であり「泥沼の戦争を原爆でケリをつけた」という認識しか大衆には残っていないのである。

果たして、日本人がそれを受け入れられるかどうかは分からない。少なくとも30年前にこの映画があったらならば、まだ相当数生き残っていた被爆者からの声明がでたであろう。しかし、今に至っては被爆者も減り、当の広島や長崎からも「オッペンハイマー」という映画に対してなんらかの声明が出た(でなかったと思うが?)ようすはない。

そこは、同時上映にならなかたことで逃してしまった残念な点であると思う。

もうひとつ、余談ではあるが、当時の反共という流れ、戦時中はアメリカはソ連との同盟国であり、それと同時に冷戦時代になり「反共」という形で、一気に掌返しが起こる。オッペンハイマー自身が、共産主義に共鳴し、党員ではないが「共産党的な考え方」に共感を覚えるのは無理もない。当時の財閥対労働者、戦時中の資本家上位の風潮に対して、大学教員(教授も含めて)≒労働者というスタイルにならざるをえない。ここは、現在の共産主義とは違うところだ。

このあたりの雰囲気は、いまの大学も変わっていないだろうし、人道主義が優先なのは(同区立法人化したとはいえ)変わってないと思うのだが、さて。国立の授業料の件などでどうなるだろうか?大学紛争時代に戻ってしまうのか、興味あるところである。

カテゴリー: 開発 | 映画「オッペンハイマー」の感想 はコメントを受け付けていません

「BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか?」の感想メモ

ベント・フリウビヤ、 ダン・ガードナー著「BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか?」 の感想メモです。

サブタイトルに「どデカいことを成し遂げたヤツらはなにをしたのか?」とあるが、巨大プロジェクトの自慢話が書いてあるわけではない。どちらかというと、巨大プロジェクトが如何に失敗しているのか、というのを分析した話である。サブタイトルの付け方に失敗して対象する読者層が間違っているような気もするのが、いわゆる、行動経済学を応用したプロジェクトマネジメントの話になる。

まだ第1章とちょっとを読んだばかりだけども、面白そうなのは確かなので記録を残しておこう。ツイッターだと、消えてしまいそうなので。

参考文献と論文

巻末には参考文献と著者らが書いた論文集が載っている。なので、通常のビジネス本とは違い、なんらかの根拠がある(あるいは偽根拠があるw)ことが示されているので、それらの文献にあたれば数々の発言の再現を確認できるだろう。

Full article: The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution https://www.tandfonline.com/doi/full/10.1080/07421222.2022.2096544

ファットテールの図などが載っているメインとなる論文だろう。

フィッティングする数式もある。が、果たしてこれが過剰なフィッティングでしかないのかは分からない。参考にしたプロジェクトは1万件を超えるのでサンプリングとしては十分である。そのデータも公開されているらしい。

第1章は序章

第1章は、いくつかの具体的なプロジェクトの例に過ぎない。「ゆっくり考えて、素早くはじめる」という(たぶん)「ファスト&スロー」の中に書かれている内容の追随になっていると思う。

これは第1章を読んだばかりだけど

  • 失敗学
  • 「アジャイルな見積もりと計画づくり」
  • 「失敗の本質」

あたりが思い浮かぶ。

実は、10年前だったか CCPM を知って、ITプロジェクトに応用しようとして、そのテールの分布を計算していた時期がある。ほぼ同時期(自分より2,3年前になるが)コーン氏が同様のことをやっていて、テールの部分を数式化してマネジメントソフトウェアとして販売していたという実績がある。しかし、現在の彼のサイトを見ると解るが、このソフトウェアはない。実は開発会社はつぶれていて(あまり売れなかったのだろう)、今では小さな?コンサル会社になっている。この手法だが、マネジメントソフトウェアにしてもあまり意味がない。属人性が強すぎるので、テールの分散が広くPM個人に依存してしまうからだ。私個人の経験でも、大きく失敗しないPMは、常に大きく失敗しない個人的な手法を持っている。これは20年著っとの個人的な経験で幾人か知っている。逆に、大きく失敗するPMは常に失敗する。

失敗するPMがあまり顕在化されないのは、一度失敗してしまった(大きく赤字になってしまった)PMはこの業界から一瞬で消え去ってしまうか、あるいはこの著作のように「大きなプロジェクトを任された」という実績にて、次のプロジェクトに参画するためだ。失敗学的な「失敗」を定義されないまま、別の会社のプロジェクトに組み込まれることが多い(いわゆる根性があるとか最後までやりぬくとか体力があるとか、あるいは権力に従うとか)ので、プロジェクトを失敗させやすいPMは常にプロジェクトを失敗させる可能性を含んでいる。

この部分、「BIG THINGS」に書かれているかはわからないのだが、文化的な進化論のひとつである。第2章以降を読み進めるとわかるかなと。

第2章以降は行動経済学に沿う

第2章以降は、行動経済学の各ナッジについて解説することになる。行動経済学が眉唾だと思う人にはちょっと向かないかもしれない。ちょっと言い過ぎ(都合のよい事象を出し過ぎ)な感もあるが、リチャード・セイラー著「実践行動経済学」を読んでいれば大丈夫だろう。

各種の決め台詞っぽい名づけ(「コミットメントの錯誤」とか「戦略的虚偽表明」とか)に引き付けられる向きもあろうが、ここは眉唾してスルーしておくのがベターだ。具体例は、各論文にでてくるだろうから。

「要求仕様の探求学」では、要件定義工程での品質の作り込み(品質の上げ方)の手法が書かれている本である。結構古いのとウォーターフォール開発の頃の著作なので、昨今のアジャイル開発では向かないが、最近の反アジャイル思想の中で、開発途中では品質は上がらない、というような話がでてきたときには「要求仕様の探求学」を出してみるとよい。G.M.ワインバーグの著作である。まずは、「品質とは何か?」をきちんと定義してから、議論してみるのがよい。

2000年頃のITプロジェクトは確実に他業界よりも遅れていたのだが、本書をみていくとプロジェクト進行に関してはITプロジェクトは追いついている印象を受ける。むしろ、2002年から始まるアジャイル開発のノウハウが本書の各章にでてくる。

現時点(2024年時点)で、ITプロジェクトでは成功と失敗(みずほ銀行、COCOAの失敗、ガバメントクラウドの失敗…途中?)の差は大きく、大規模プロジェクトや官庁プロジェクトの失敗が目をひく。で、当たり間のことだが、失敗プロジェクトを見習いたいわけではなく、成功プロジェクトの秘訣を(あるいはプロジェクトを失敗させない要素を)ピックアップしておきたい。

  • 第2章の「早く決めたい衝動」については、アジャイル開発により、まず手を付けてプロトタイプを顧客に見せるという手法がITプロジェクトでは可能になっている。ゆえに、全体を決めなくても、最初の一歩を踏み出すほうがITプロジェクトでは良い。ただし、その後は最初のプロトタイプに縛られない工夫が必要である。官庁系のプロジェクトで大きく失敗するのは、ここの「熟考のし過ぎ」あるいは「官僚の作る5か年計画に縛られる」に原因がある。
  • 第3章の目標をはっきりとさせるは、PMBOKにおけるプロジェクト計画書やプロジェクト憲章にあたる。CCPMでは、目的から各タスク(WBSでもよい)を導き出して無駄なタスクを作り出さない手法がある。本書では「フローチャートを「逆」から埋める」という書き方がされていて、「バックキャスティング」という用語を使う。
  • 第4章は、いわゆる設計で使う「ポンチ絵」のことであり、システム構成図であったりシステム概要であったりする。試作品を作り「イテレーション開発」を行うことを勧めている。
  • 第5章と第6章お場合は、経験から学ぶことと、過去のプロジェクトから計画見積もりをすることを示している。ITプロジェクトでは、PDCAやファンクションポイント法などの見積もり法がある。ファンクションポイント法は今はほとんど使われていないが、過去の似たプロジェクトを参考にしながら目の前のプロジェクトを試算するのはIT業界では普通に行われている。おそらく建築業界よりもプロジェクトの単位が短くなった(WEBプロジェクトでは2,3か月というのがざらである)ので、進化のサイクルが早くなったと考えられる。
  • 第6章で、マイルストーンではなくインチストーンの提案をされているが、アジャイル開発あるいは最近のITプロジェクトでは「チケット駆動」という形でインチサイズの「チケット」が使われる。スクラム開発のバックログがそれにあたる。
  • 第7章は、アジャイル開発の手順そのものである。
  • 第8章のチーム作りに関しては、「ピープルウェア」がある。本書でも「リーン開発」が言及されている。また、IT業界で流行っている「心理的安全性」≒テスト駆動などの手法がある。
  • 第9章は、IT業界が得意とするモジュール化やコンポーネント化の話になる。マイクロサービスやAzure FunctionsやAWS Lambda のサーバーレス技術もそれにあたるだろう。WEB API もこれにあたる。「反復開発」なんて当たり前のようにやっている。

という訳で、残りは「終章」しかないのだけど、BIG THINGSの本に書いてある内容は「行動経済学」がベースになっているわけだが、その現実的な手法としては「アジャイル開発」のさまざまな手法あるいはここ2000年以降のITプロジェクトが培ってきたノウハウや経験に等しいことが伺える。

まあ、それでもみずほ銀行のシステム統合や遅々として進まないガバメントクラウドやデ庁のしぐさもあるわけで、ITプロジェクトだからといって成功するわけではない。ゆえに、失敗プロジェクトに身を投じないだけの思慮をプロジェクトリーダーやマネージャは必要とされていると私は考える。

ちょっと興味深いので、ダニエル・カーネマン著「ファスト&スロー」を読んでから、また追記しよう。

カテゴリー: 開発 | 「BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか?」の感想メモ はコメントを受け付けていません

「プリンセスコネクト!Re:Dive」の脚本の可能性について

プリンセスコネクト!Re:Dive (プリコネR) 公式サイト | Cygames https://priconne-redive.jp/ というスマホゲームがある。ウマ娘の2年前ぐらいから数か月おきにやっていたりするので、そんなに古い訳じゃないけど、確か深圳のドローンか競馬のプリンニシテヤルノ https://db.netkeiba.com/horse/2018105075/ が話題になった頃だと思う。

当時、艦これとアズレンを並行していた頃のと、「数か月おき」にやっていたのは、フルボイスの脚本が非常に面白かったから、というのがある。この手の美少女ゲームは、ところどころにキャラクターのストーリーが挟まっているわけだけど、キャラクタの絵とキャラクタ担当の声優のワンセット位で、ストーリーは字だけの場合が多い。字だけどと、まあ、それでもいいのだけど、読むのが面倒くさくてだんだんとスキップしまうのだ。

その点、「プリコネR」や「このすば」の場合は、声優が科白をきっちりと読み切るので所謂読み聞かせ状態になって便利である。なんか別のことをやっていてもいいので。

で、この手の美少女ゲームで何時からなのか知らないけど、いわゆる何かのパロディ(特に登場当時?に流行っていたアニメとか漫画とか)のキャラクタとストーリーを突っ込んてくることが多くなっている。おそらく、完全なオリジナル作品を作ると読者層というかゲーム層にあたるかどうか分からないのと、キャラクタのバックグラウンドを実際の別のアニメに寄せることができるので、楽なのでは?と思ったりする。当初は「楽」だったからなのかもしれないけど、現在では結構意図的に寄せているところが面白い。たぶん、コラボという形での相互宣伝だけではなく、一見、関係のなさそうな美少女ゲーム同士でも、似たようなキャラが似たようなストーリーで出てくることがある。

たとえば、ウマ娘の「ライスシャワー」と、アズレンの「霞」と、プリコネRの「アネモネ」とか、同じ造詣から来るものかな、と思ったりする。単なる眼帯パターンかもしれないけど。

で、それぞれのゲームのキャラクタが、多分設定書みたいなものが裏にあって、それに沿ってキャラクターを中心にストーリーを作っているのだけど、敢えて何かに似せてパロディにしているところが興味深い。というか、もともと小説とか脚本とかはそういう前提があるものを読者層が知識として持っていて、それを匂わせつつ、現在目の前にある小説なり脚本なりを読むことになる(あるいは演劇)のではないだろうか、と思ったりする。

古くは、ギリシャ神話だったり古事記だったり、歴史的な戦記ものであったり史実だったりを、少し変形しながら小説に入れ込む。ある意味、「里見八犬伝」や「水滸伝」もそうだろう。既に現在において「里見八犬伝」は古典だから、「里見八犬伝」を模した小説がたくさんある。さらに、三国志をベースに持つ「グインサーガ」や、国盗り物語をベースにする「十二国記」がある。「十二国記」に出てくる地形はおよそ現実的なものではないけど、それを模した形で「マロニエ王国の七人の騎士」みたいなものがでくる。他にも「指輪物語」とか「ロードス島戦記」とか。古典とまではいかないけど、皆が知っているであろうことを前提として、パロディあるいはオマージュとして描けるものがある。絵画であればコラージュという手法が取れる。

そういう視点でみると、「プリコネR」の各種のサイドストーリー(本編ではない方)の組み方が興味深い。サイドストーリーは過去分もできるようになっているので、数か月おきにアクセスしてみては速攻(オート処理で)ストーリーをクリアしてから、音声で流し聞きをするわけですが。

この本編とは異なるサイドストーリー(いわゆる外伝あるいはスピンオフの短編)は、エンタメ要素としては非常にやりやすい方式ですね。流行する要素も入れやすいし、なんとなく他のアニメや小説を匂わせる用語も入れやすいし、「段ドリ~」に取り込める記述要素だなぁと思ったりする。まあ、単純に聴いていても楽しい。ああ、プリコネRについては「なかよし部」関連のサイドストーリーが楽しいです。夢野久作を思い起させるので。

追記

「プリコネR」のサイドストーリーが何故興味深いのかを少し追記しておく。

もともと本編があり、ストーリーに沿ってRPG(っぽいもの)が進むというのがこの手のゲームのなのだが、この手の美少女ゲームは艦これをはじめとして、非常に多くの登場人物がでてくる。多分「同級生」あたりがスタートだと思うのだけど、育成要素プラス育成する対象が幾人もいるということで、ゲーム自体の寿命が延びるという要素が大きいのだろう。漫画言えば「5等分の花嫁」とかそんな感じ。「ガルパン」も同じジャンルかもしれない。

歴史的なところはさておき、艦これやアズレンは艦船の擬人化なので艦船があればそれだけ登場人物が増え、そのままアニメにしたり漫画にしたりしてバリエーションを増やす。ただし、アニメーションの場合は資金の関係もありそう何本も作れるわけではない。なので、できるだけ登場人物を詰め込み、登場人物の美少女(≒ゲームをやっている人の推しキャラ)が登場するという形でストーリーを組み立てることになる。なかなか大変だ。実際、艦これとアズレンのアニメのほうを見ると大変さが垣間見える。

一方で「プリコネR」の場合は、前作もあるということで(前作のほうはやっていないのだが)、何らかの形で登場人物がいて、それぞれに特徴があり、それぞれが主役級という形になっている。以前、ウマ娘のアニメを娘に見せたとき「皆、主役級の色合いでうるさい」という話あった。そう、大抵は脇役やモブの場合は服装などが主役よりも省略される場合が多いのだが、ウマ娘はそれぞれが主役級の「ウマ娘」な訳で、画面がうるさいことこの上ない。これは仕方がない現象でもある。その傍ら、ウマ娘よりも先に cygames が提供している「プリコネR」では、ギルドという形で数名がグループを作っているという設定になっている。このギルドというグループ単位でストーリーが展開することになるので、本ギルド以外のキャラは出てこなくても構わない。つまり、アニメや本編のストーリーを進めるときに、それぞれ「主役級のギルド」というものが定義されるわけである。

ギルドの数名の美少女+主人公という組み合わせになり、本編のストーリーやサイドストーリーは進む。サイドストーリーのほうは、別のギルドのメンバーが混ざったりするわけだが、基本は少人数のパーティという形になる。つまり、サイドストーリーを作るうえで、いくつかの前提条件が出てくる。

  • 本編とは関係ない外伝またはオムニバス形式でストーリーが組める
  • 数名の美少女キャラは、既に性格付けが明確になっている(キャラの説明がいらない)
  • 「プリコネR」の主人公は、基本何もしないので、ストーリーは美少女たちだけで進められる
  • 美少女キャラにはそれぞれ推しがいるので、ハッピーエンドで終わる必要がある。
  • 「プリコネR」に限っては、魔物が非常にシンプルである
  • なんらかの形で「魔物」のボスと戦う必要がある。

という条件さえ揃えば、基本何をやってもよいらしい。そもそも、登場してくる美少女キャラは、何かのパロディだったりすることが多いわけで(他ゲームのコラボキャラだけじゃなく、既存アニメやゲームを思わせるキャラクターが多い)、それらも含めて性格付けや背景付けがなされている。

いわば、常に「二次創作」状態でサイドストーリーが進むわけだ。

二次創作状態ではあるが、本編自体の著作権は cygames 自体が持っているので、正式にはスピンオフというところだが、サイドストーリーのストーリー自体が何かの映画やアニメのパロディを思わせたりする。キャラ自体が何かのアニメやキャラっぽいところに加えて、ストーリーもパロディっぽいので、脚本としてはかなりやりたい放題だとは思うのだけど、上記のような制約(必ずハッピーエンドであること、魔物と戦うこと)があるので、そのままではストーリーが単調になりかねない。

サイドストーリーに登場するキャラが違っても、ストーリー自体が似たり寄ったりでは、ゲームをしている人には飽きられてしまうだろう。そういう意味では商業的にも継続できそうなストーリーを提供する必要がでてくる。

そういう意味で「プリコネR」のサイドストーリーは興味深い構造になっているのである。で、脚本的に面白いのもあれば、まあ、そこそこなのもあるけど、個人的な趣味から言うと夢野久作タイプの「なかよし部」(通称ユニちゃんズ)の脚本が好みだったりする。確か、サイドストーリーごとに脚本家が違った筈(メインは、日日日氏)。あの、小難しいっぽい(根拠はあってもなくてもいい)用語を並べ得るのはなかなか大変なのだけど、頑張ってください。

カテゴリー: 開発 | 「プリンセスコネクト!Re:Dive」の脚本の可能性について はコメントを受け付けていません

「リファクタリングの基礎~」の有料オンラインセミナーの案内

リファクタリングの基礎と効果的なソフトウェア劣化対策のポイント ~デモ付~<オンラインセミナー> | セミナー | 日本テクノセンター

https://www.j-techno.co.jp/seminar/seminar-61762/

2024年5月24日(金曜日)に、日本テクノセンターにて有料のオンラインセミナーを担当します。

基本は、マーチン・ファウラー著「リファクタリング」 になるわけなのですが、

ファウラー氏の「リファクタリング」がかつてクラス(オブジェクト指向)への移行をベースにしていたのと、発刊以降の変遷(組み込みシステムの発展や関数型など)を考えたとき、もう少しベタな実装に沿って講義するのもよいでしょう、ということで、主にC言語、C++をベースにして「リファクタリング」を実践していきましょう、というセミナーです。

以下、目次にあると通り、

  • 価値(バリュー)からスタートするという、DevOps的考え方
  • ルールとしてリファクタリングするのではなく、価値を創出するリファクタリング場所の見つけ方(あるいはリファクタリングしなくて良いポイント)

を原著の「リファクタリング」に追加して、其の後では CUnit/CppUnit などを含めて具体的なデモを使い解説する予定です(Google Testなどの最近の mock を扱ってもよいのですが、組み込みシステムを考えると、古い CUnit あたりが妥当かなと)。

問い合わせなどは、日本テクノセンター経由でして頂けるとありがたいです(ツイッターでもいいけど)。

目次

1.リファクタリング実施の背景と現実
  (1).なぜ、リファクタリングをしなければいけないのか?
  (2).リファクタリングすると、どのような価値が生まれるのか?
    a.コスト面
    b.メンテナンス面
    c.運用面
  (3).リファクタリングする場所を見つける
    a.リファクタリングの定番:コードの不吉な臭い
    b.修正するときにあちこち手をいれる
    c.バグが怖くて手が出せない
  (4).修正とバグによる堂々巡り
  (5).堂々巡りにならないためのポイント

2.リファクタリング前の準備
  (1).テストコードとの組み合わせ
    a.関数やクラスの抜き出し
    b.抜き出せない場合の対処法
  (2). 変更とテストのサイクル作りとそのポイント
  (3). 開発環境のリファクタリング機能の効果的な活用

3.リファクタリングのパターンと実施ポイント
  (1). コードが読みづらい場合
  (2). コードが長すぎる場合
  (3). 変更がやりづらい場合
  (4). やたらにコメントを付けないとわからない場合
  (5). 人に説明がしづらい場合
  (6). 複雑すぎるクラスを整理する
  
4.実践リファクタリング<デモ>
  (1).長い関数を整理してみる
  (2).テストコードで動かしながら試す
  (3).変数名を変更する
  (4).関数やクラスに分割する
  (5).機能を追加する
  (6).できあがったコードを再び整理する

チラ見せ

カテゴリー: 開発 | 「リファクタリングの基礎~」の有料オンラインセミナーの案内 はコメントを受け付けていません

仕様書作成にChatGPTを活用してみる(構造設計)

そういえば、「基本設計」は何処にいったのだろうか?と問い直してみるのだけど、拙著の場合は「基本設計」は、「概要設計」「構造設計」を示します。この手の文書の対応は、PMBOK でもそうなのですが多少揺れています。

  • 概要設計と詳細設計
  • 基本設計と詳細設計
  • 外部設計と内部設計

要は、全体を見通したときの設計(概要設計や基本設計)と、プログラムコードに即した設計書(詳細設計や内部設計)に分けるということです。近年ではVue.jsなどを使いいきなりコーディングをすることも可能なので、詳細設計や内部設計は省略する傾向にあります。私もそれで十分だと思います。ですが、全体的な設計(概要設計、構造設計、ネットワーク設計、システム構造設計など)を省略してしまうと多人数でのプロジェクトでの意思統一が混沌となってしまったり、プロジェクト終了後の運用段階に入ったときに復旧や改修などに手間が掛かることが多いのです。その区切りとしても、概要設計は残し、詳細設計は捨てる、という線引きが重要になります。ひとりプロジェクトだとしても、構造設計なんかもざっと数ページでもよいので書いておくとベターですね。先の概要設計も、多少箇条書きにしてもでも残しておくと数年後に役に立ちます。

構造設計書を書く

構造設計書の目次はこんな感じです。

概要設計書がシステムの具体的な動きを記述するものに対して、構造設計書ではシステムの物理的な配置を記述しておきます。いわば、ネットワークの状態やデータベースの配置、システム内で利用するフレームワークやライブラリの配置です。

ネットワーク図というと今ではAWSの構成図とかを書くことが多いのですが、かつては各種ハードウェアの接続状態を示すものです。このあたり、

  • 各種の機能に関して、箇条書きをしておく。
  • 箇条書きから、ネットワーク図を書いて貰う。

という手順を使います。要件定義書を要約して箇条書きにしたように、概要設計を要約して箇条書きしたものをつかってもよいでしょう。少なくとも「いくつかのコンポーネントが繋がっている」ということが箇条書きで解るようにしておきます。

ChatGPTで、以下のような機能別の解説を付けて貰います。

これをもとにして、「mermaid形式でネットワーク図を書いて。」と ChatGPTに頼むと、下記のようなネットワーク図を書いてくれます。

mermaid 形式( Mermaid | Diagramming and charting tool https://mermaid.js.org/ )は、markdown の中にコードとしてフローチャートなどを入れ込む書式です。最初はUML一般だったのですが、だんだんと拡張されて上記のようなネットワーク図っぽいもの(実際は状態遷移図と思われる)も書くことができます。うまく工夫すると AWS のコンポーネントの組み合わせも書けるらしいので、試してみるとよいです。

基本、ChatGPT は「図」というものが書けません。レスポンスでも各種のツールを使ってください、と返してきます。ただし、この mermaid 形式だけは別で、結構な確率で中身を解釈してくれます。

のようなプロンプトを喰わせると、

このように mermaid 形式で書けるコードを返してくれます。これを、vscode の拡張機能などを使い図にします。

これをそのまま貼り付けてもよいし、文言を手直してしてもよいでしょう。

ハードウェア構成のほうは、うまくいかないのでパワポを使って手作業をしています。

visio などの専用ツールを使えば綺麗に書けるのでしょうが、ひとりプロジェクトだったり、数名の小規模プロジェクトであればこれで十分です。修正をしやすくしておくことが肝心です。修正がしにくくなると、形骸化してすぐに古くなって仕様書/設計書の手直しができなくなってしまいます。

最近では、Microsoft 365のようにクラウド上に設計書をアップしておくとがあるでしょう。そのときに綺麗なフォーマットにこだわるよりも(Office 365のWordの崩れはかなり酷いですね。Googleのほうがきれいに出力されます)、まあ、「情報がきちんと残っている」ことが重要でしょう。

カテゴリー: 開発 | 仕様書作成にChatGPTを活用してみる(構造設計) はコメントを受け付けていません

仕様書作成にChatGPTを活用してみる(要件定義、概要設計)

新人教育用に「ハンバーガー注文サイト」を実装してもらっているのですが、その設計書づくりが非常に面倒くさい。きっちりと設計書を作るのか、アジャイル開発風にチケットで作るのかと思いつつ、3年程経ってしまっている。

サンプルプロジェクト

以下に拙著「システム開発者のための仕様書の基本と仕組み」のサンプルプロジェクトの仕様書があります。実際のプロジェクトを模倣して、要件定義書や設計書などを作成しています。

https://github.com/moonmile/specification-samples/tree/master/samples/ハンバーガー注文サイト

各仕様書・設計書の内容は書籍のほうをみてください。従来型のウォーターフォール開発≒計画駆動を想定した設計作りなので、官庁の受注や100名程度の大手プロジェクトに参加されたことがある方は、なんとなく想像がつくと思います。

  • 要求定義書(要件定義書) いわゆる発注側が作るRFP
  • システム概要設計書 RFPを受けて受注側が作成する
  • システム構造設計書 システム開発をするための構造設計
  • 各種外部設計書 ユーザーインターフェースを記述
  • 内部設計書は省略
  • 結合試験仕様書 構造設計に従い試験を行う

要求定義書(要件定義書)の作成

おおむね発注元のコンサルタントか発注先の会社が代筆することが多いので、ChatGPTを使うところと言えば、

  • おおまかなシステム要件を ChatGPT に提案して、機能要件を煮詰めて貰う
  • 機能要件にいくつかの具体的な要件を加えてブレークダウンさせる

と言う形で文章を広げていくおように ChatGPT を使っています。この場合は

  • ハンバーガー注文サイトを作るときの要件を書いて。
  • 制限事項を書いて
  • 機能要件をまとめて
  • システム機能外要件をまとめて

のようなプロンプトを ChatGPT に食わせます。プロンプトを喰わせたあとに、文章が短い場合は、

  • 制限事項を2000文字位で書いて

のように文字数を指定すると多めに書いてくれます(実際には文字数ではなくて、トークン数になっているはずです)。

よくプロンプトエンジニアリングである「あなたは○○のプロフェッショナルで~」という文章はいりません。だいたいデフォルトの数値で大丈夫です。以前の入力候補(compiletion)ではなく、チャット型式(chat completion)なので、ちょこちょこと情報を追加していって、少しずつ文章を組み立てていきます。

AIのレスポンスが長くてうっとおしい&時間が掛かるかもしれませんが、いずれOpenAIの日本語版が出てくればスピードがアップするので、将来的にレスポンスが問題になることはないでしょう。

文字数を指定して長めに書いたあとに、余分なところを削っていくほうがうまくいきます。

概要設計にChatGPTを活用する

要件定義を作るときには最初のアイデア出し、つまり ChatGPT へのインプットを試行錯誤することになるので結構大変なのですが、概要設計の場合は「要件定義書」に書かれているものインプットにできるので比較的楽です。

先の要件定義書の「はじめに」の部分に、いくつかの要件がまとめられています。

ここの3点を、そのまま ChatGPT に喰わせて、概要設計をしてみます。

「概要設計を作って」と書いたあとに、要件定義の箇条書きを貼り付けるだけで ok です。要件定義書が長い場合には、あらかじめ ChatGPT を使って要件定義の「要約」を作って貰うといいでしょう。

概要設計の中に構造設計(具体的なテーブル構造やフレームワーク名)などが出てきますが、適宜、「概要設計」と「構造設計」を分けながら文書を組み立てていきます。開発プロジェクトによって、は概要設計(Outline design)と構造設計(Structural design)を区別しないことがあるので、これは開発プロジェクト(というか会社の形式)にあわせてください。PMBOKやSWEBOKに合わせるのがベターです。

要件定義の項目を少しずつ掘り込んでいくと、システムを構築する際の足りない部分を概要設計で補うことができます。分厚い要件定義書を作ってしまうよりも、目的のはっきりした要件定義書を作っておいて概要設計で地盤を固めるほうが無難です。まあ、ゼネコンの関係から「分厚い要件定義書」をコンサルタントが作ってしまことが多いのですが。そのあたりは、現実にあわせるのがよいでしょう。

数枚の要件定義ですが、概要設計では以下のような目次ができあがります。

適宜増やしておきたいところ(販売レポート、クーポンシステムなど)を追加して概要設計書をボリュームアップしていきます。実際には、プロジェクト予算と期間は限られているので、それに見合うように概要設計を作ります。あるいは、要件定義を受けて予算と期間を見積もるときに概算としての概要設計(本来はそのような作り方をするべきです)をさっくりと作成します。

従来であれば、要件定義を読み解いて概要設計を作るのはかなり人手と時間が掛かってしまうところですが、ChatGPTの機能を使うと(これは他の生成AIでも同じことができるでしょう)、

  • 適宜、要件定義から「要約」を抜き出す
  • 要件定義の「要約」から、概要設計に落としていく。
  • 要件定義のキーワードや、システム開発で必須なもの(経験上あるいは社内での知見)を含めて、概要設計を膨らませる

のように比較的短期間で概要設計を作ることができます。完璧なものでなくても、少なくとも概算が出る程度まで作れればよいのです。

カテゴリー: 開発 | 仕様書作成にChatGPTを活用してみる(要件定義、概要設計) はコメントを受け付けていません

段ドリーの奇妙なプロジェクト 第04段

## 第04段

「それは、『紙飛行機』を分解しているだけじゃないですか?」

「ご名答、そう、これは『紙飛行機』の製作を分解しているものです」

非1番が勢いよく答える。ドリーにとっては、当たっていいものなのか悪いものなのか分からず、むしろ当たってないほうがいいのだが、返す言葉もなく苦笑いをするだけだった。1番に問い合わせたのに、非1番が答えることなんて日常茶飯事だ。なにせ、このプロジェクトでは1番も非1番も赤いシャツと赤いズボンを着ていて見分けがつかないからだ。区別ができるとすれば背番号しかない。

「ソフトウェア開発というものは、まずは要件定義から始まって、概要設計、外部設計、内部設計、詳細設計を行い、コーディング、そして単体テスト、結合テスト、システムテストと続くことは、ご存じですね」

「ええ、はい」

「いわゆる、V字モデルというか、V作戦というか、V字回復というものです。要件定義からはじまって各種の設計をしているうちにだんだんと落ち込んでしまってしまい、混沌とした中でコードを書いているうちに、単体テストから再び復活して水中から顔が出せるという潜水艦のような仕組みです。紙飛行機は潜水艦のように水に潜ってしまうと、紙が水にぬれて進まなくなってしまうのですが、そこは例えなので大丈夫です。例え話はご存じですよね」

「えええ、ええ、まあ・・・」

「例え話をすると、その中に出てくる登場人物があたかも現実化のように思えてきて、テレビの中の登場人物なんだけど、それが真実のように思えてきて、感動してしまい涙を流し共感をしてしまう現象は『トゥルーマン・ショー』でおなじみなのですが、実はそれを演じているジム・キャリーは俳優なのです。テレビを見ている人は彼が俳優とは知りません。映画を見ている人は知っています。映画を見ている人はテレビを見ている人を見ているわけですが、同時にテレビの中で動いているジム・キャリーも見ているわけです。いくら感情移入をしたって映画館をでてしまえば消え去ってしまう銀幕ですから、その中にあるものは架空の俳優に決まっています。でも、現実にジム・キャリーは俳優なのですから、そこれ演じている物語はやっぱり架空でしかないのです。現実の俳優が架空の主人公を演じていて、さらに架空の主人公は映画の中の観客にとっては現実にいる人なわけで、けれども架空の主人公にとってまわりの家具や家や友人は映画のセットであって、それは実際の俳優としてのジム・キャリーにとっても架空の映画のセットなわけですね。つまりは、テレビの中にいるトゥルーマンは、現実から非現実、さらに非現実から現実に至るという反転を得て、現実のジム・キャリーそのものになってしまうんですね」

「はあ、ええ・・・」

「そのあたりのたとえ話は脇において、別のたとえ話をしましょう」

「えええ???」

「例えば話は、物事を簡単に理解するための手助けみたいなものです。現実は複雑です。現実は悲壮です。現実は無感情なものです。ひとりの人の感情とは関係なく現実は動いていくし、現実は変化していきます。いえ、変化しているように見えますが、将来的に見ると1本の確実な道筋しかないのです。だから、それぞれの人が現実を見て、悲壮に変化しているように考えたとしても、それは確実に1つの現実でしかないのだから、悲壮なり楽観なり優雅なりだまし討ちなり討ち入りなり技あり1本という訳ではないのです。ひとつの現実をみて、さまざまな人がさまざまな感想を述べているだけなのです。だから、複数の複雑の絡み合ってしまいそうで、実はちっとも交わらないゆがんだ関係を整理するためにたんと話がひつようとなるのです。たとえ話は、花咲か爺さんでも桃太郎でもかぐや姫でもかまいません。どの昔話をとってもかまいません。現実に花咲か爺さんは存在しません。過去にも未来にも存在しません。当然、今ある時空では存在しないのです。ですが、『花咲か爺さん』と言ったとき、それは花咲か婆さんでもなく花咲か姉さんでもなく花咲か兄さんでもありません。蛇足を言えば、花咲か赤ちゃんでもありません。親指がパパで人差し指がママだとしたら、小指がない人はどう思うでしょうか。そう、確実に子供がいない人のことを示すのです。このように、たとえ話は人々の見ている複雑な現実を簡略化してひとつにまとめる効果があります。例えるならば、生成AIで使われる10億以上のパラメータを縮退させて1つか2つにしてしまうようなものです。1つか2つならば簡単です。2つであるならば、当てずっぽうでいっても二分の1の確率であたるのです。センター試験ならば四択ですから、25%の確率です。2割5分ですね。指名打者になると3割位は欲しいところですが、2割5分でも我慢ができるところです。だから、2つぐらいのほうがいいのです。5割の確率で正解を引きあてることができますからね。ちなみに、占い師が10人に適当なことを言っても、そのうち1人が『当たった、これは凄い、預言者だ!』と言えば、経営は成り立つのです。素晴らしい事ですよね」

「ああ、え?」

「ね、素晴らしいですよね」

1番も畳みかけるようにドリーに話しかけるのであった。

余談であるが、このような本当のような嘘のような嘘のような嘘を、だらだと書くのは生成AIの得意とするところ・・・と思われるのだが、さてどうだろうか。文章の助詞や副詞や女子力をつなげたところで、内容に意味はないのだが、その区切り区切りのところ一貫性があるように聞こえてしまうのが『文法』の不思議なところである。つまりは、文法に則っていれば、説得力があるという幻覚を堪能してしまうのだ、甘い汁を知ってしまうのだ、けしからん、実にけしからん。

「で、話を元に戻しましょう」

トイレットペーパーをぐるぐると巻き戻すように1番は、話を巻き戻した。いったん引きずり出してしまったトイレットペーパーを巻き戻してしまったとしても、もとのきっちりとした巻物に戻るわけではない。かなりごわごわした、膨らんだ感じになってしまう。それもで巻き戻したと言えるだろう。1番の話の巻き戻し方も同じようなものだった。

「『紙飛行機』の『紙』について順番にお話しをしましょう。まずはこの『紙』、先頭にくっついています。語尾にくっついたら『飛行機紙』になってしまいますよね。まるで『飛行機神』ですから、墜落しあにあるいは墜落する神様みたいなものになってしまいます。『神飛行機」の場合は、よく飛ぶ紙飛行機を想像できるので、この『紙』の位置は重要ですし、さらに「かみ」という音から『髪』を示すこともできるわけですから、頭の部分にあったほうがいいのです。足の裏にあったら、ちょっとごわごわして歩きづらいですよね」

「ほら、ヒバゴンの足裏にも毛は生えていませんからね。猫の肉球みたいなものです。可愛いものですよね」

可愛いかどうかは別として、足裏の髪の毛を想像してちょっと気持ち悪くなってしまうドリーであった。

「ソフトウェア開発において『紙』といえば、設計書です。要求文書です。契約書です。つまりは『書』のことですね。紙飛行機プロジェクトでも『書』は大切なので、最初に説明しておかねばならないかなと思った次第です。書というのは、つまりは文書管理のことです。品質管理システムのISO9000のことですね。ドリーさんはご存じですか?」

「ええ、文書管理については一応」

「一応・・・一応では困るのですが」

「ああ、一応じゃなくて、完全に大丈夫です。品質管理システムにはプロジェクトの段取りの重要な手順になっていますから」

「「・・・・」」

いや、また、何か変なことを言ったのだろうか、とドリーは思った。このプロジェクト、実に落とし穴が多すぎるのだが、いったいどこが落とし穴なのかドリーには解りかねていた。プロジェクト全体が大きな落とし穴のような気もするし、底なし沼のようなきもする。でも、落とし穴自体が巨大であったならば、もはや穴の中に住んで入ればそれは平地と同様ではないだろうか。『火の鳥(黎明編)』に出てくる窪地で生活するシーンがある。窪地に生えている草を食べ、窪地で結婚をし、窪地で子を育てる。すでにそこは生活の場なのだから、落とし穴とは違うのではないだろうか。他にも『砂の女』では蟻地獄のように砂の窪地に住んで配偶者を待っている。実に様々な落とし穴があり、生活感がある。

「いえいえ、完全である必要はありません。完全という証明は難しいものですから。ただ、一応では困るので、二応だったり三応、慶応だったりでもいいですが」

「ああ、じゃあ、慶応で」

「なるほど、慶応ぐらい理解できているのならば大丈夫です」

早稲田では駄目なのだろうか?とふとドリーは疑問を持つ、が口には出さないことにする。

「それで、『紙』というのは『書』のことです。『書』は紙に書き記したものを刺しますから、冊子になっている必要があります。しかし、最近では「電子文書」という形もあるので、必ずしも『紙』である必要はありません。文書という形で、なんらかの形で整理されていればよいというものになっています」

「例えば、昔の記録紙として木簡がありますよね」

突然、1番でも非1番でもない、ええと、1番と非1番の間の否1番が語り出した。1番と非1番というと相反の関係にあるように思えたが、実はその隙間があったということだ。番号を確認すればよいのだが、こっちを向いているので背中が見えない。向う側に鏡もない。定番の「近い近い近い近い・・・です」とでも言いたくなくぐらい近くに寄ってくるのだけけど、多分Aボタンで投げたとしてもすぐに近くに寄ってくると思う。カスタムしてなければ多分Aボタン。決してBボタンの笛で呼びたい相手ではない。

「木で作られた木簡ですね。竹で作った場合は竹簡、総称を簡牘という訳ですが、パピルスのような草からできた紙とは違い、木簡や竹簡の利点は表面を削って何回か使えるところです。そういう意味では書き換え可能な石板や粘土板と同じですね。掘り込みが失敗したら表面を削ってもう一度書き換えればよいのです。墓石も同じ。失敗しても表面を削ってしまってもう一度掘ればいいのです。将棋盤も同じですよね。線を間違えてしまった場合は、薄く削って線を引き直す。あたかも、現在のHDDやSSDと似た感じで書き替え可能なわけですね。あるい意味ROMじゃなくてRAMだと言えます。ただし、常に書き換え可能という訳ではなく、フラッシュICのように一旦紫外線を当てて消さないと駄目というひと手間があります。そういうひと手間を掛けて現在の記録を消す、そして上書きをするというところの木簡は成立しているのです」

「はあ・・・」

「記録的にはガラスも同じです。ガラス製の板にデータを書き込んでおいて、数万年後の未来に送るという案もありました。HDDだと磁気的に揮発してしまうし、フラッシュメモリも消えてしまう。CDやDVDでも光電子のあたり具合やプラスティックという媒体上、朽ちて果てる可能性もが高いのです。そういう意味ではガラス質は割れない限り、未来にデータを残すことが可能ですよね。また、レコードのように使うことを諮詢しているのは『Dr.STONE』にあるところです。まあ、『Dr.STONE』自体が古い漫画ですがね」

Dr.STONEがちょっと前までのアニメだということは知っているが「古い漫画」というほど古いものかどうかはドリーにはわからなかった。だって、ホコタテ星人だし、とドリーは思った。

「木簡が書き換え可能、さらに言えば、数千年前の木簡が現在でも読める形で残っているということから、今後同じような形で木簡や竹簡を残したとしても数千年後に残る可能性は高い訳です。地球の組成上、木簡に使っていた木の質が変わっている可能性も否めませんが、白亜紀のシダ類を使った木簡ではないのですから、数千年位ならば木の質が変わるとは思えません。まあ、東京都の杉の木ならば変わってそうな気もしますが、大体において木の寿命のほうが、地球人よりも長いので大丈夫でしょう。ああ、大王具足蟲ならばわかりませんが」

「・・・・」

「話を元に戻しましょう」

どこから話が外れてしまって、どこに戻っていくのかドリーには解らなかったが、どうやら否1番さんにはわかっているようだ。

「表面を削ってしまえば数秒で書き換え可能になってしまう木簡、その後、手を加えなければ数千年もデータを保ってくれる木簡というものがあります。これは非常に安価であり経済的な記録媒体です。データを保持するのに電力がいるわけでもなく、分子的な分解もほとんどありません。これ木という植物の細胞壁が動物のような細胞膜とは違って、生物的に死んでも壁として残るという特徴にあるでしょう。まあ、地球人にはミイラというものがあるので、ミイラに記録をする、いやミイラから記録を得るということも大いにあるわけですが」

そして、否1番がうしろから、木簡・・・らしきものを取り出した。木簡のなのか、別のプラスティックの板なのかわからないが、さっきから木簡と言っているぐらいだから木簡なのだろう。本物の木簡は初めてみるが。

「見てください。この木簡には本プロジェクトの要件定義がびっしりと書き込まれています。データにして、数ギガバイトあります。要件定義が数ギガバイトもあるのもおかしいような気もしますが、木簡に書き込まれた要件定義と言うこと自体が画期的なので勘弁してください。ここで便利なのは、木簡は削ってしまい上から墨で書き換えることもできるけど、いったん保存してしまえば数千年も持つとうことです。この木簡を紙飛行機の翼の部分に使います。紙飛行機なのに木を使うなんて、と思うかもしれませんが、最初の話を覚えていますか?」

「いいえ・・・」

「ああ、話が回りくどくてすみません。3つの物事しか覚えていられないスタンドに掛かっているわけじゃあないのに忘れているのはどうかとは思うのですが、ちょっとした健忘症に掛かっているのかもしれませんね。いや、私は気にしないから大丈夫です。それは貴方が気にするところです。私はペンではありません。あなたもペンではありませんね」

「はい・・・」

「木という材料を使っていますが、木簡は記録媒体として優秀です。記録媒体という者はISO9000の品質管理システムでは、『紙』と同等にあつかってよいものです。むしろ、紙として印刷されているものよりも、場合によってはインクが劣化して消えてしまう感熱紙のレシートよりも、電子的に保存されている領収書のほうが有効であったりします。それこそインボイスですね。国会議員はマイナンバーカードをもって記録をつけておくべきです。改竄ができないように。つまり、データを記録できておける『紙』相当ものがあり、その後に何十年も残して置けること(ただし、領収書は10年という期限があり、ひょっとすると「クレジットカード引き落とし」でも十分な可能性はあるのですが)、そして検索性があれば『紙』としての意義をなせるのです。いや、むしろ、もともとの紙では駄目で、むしろ電子的な検索ができる『紙』こそが紙たるという逆転に至っています。つまりは、記録用紙としての『紙』は、木簡でも代用が可能と言うことデス。『紙』ニアリーイコール木簡なわけです」

「ああ、ええと、つまり、紙飛行機の材料が木簡なわけですね」

「はい、そうです。実に意図が通じていますね」

木簡、確かに数千年はもつわけだけど、火事になったらどうなるんだろうか。そんな不安もあったのだが、あえても紙じゃなくて木簡で作らないといけない理由があるのだろうか?とドリーは疑問に思った。が、疑問に思ってもいけないような顔を否1番はしていた

「ニッコリ」

カテゴリー: 段取り | 段ドリーの奇妙なプロジェクト 第04段 はコメントを受け付けていません

「図解即戦力 アジャイル開発の基礎」の第7章の正規分布を Excel でシミュレーションする

第7章の補足の続き。

実際のプロジェクトで計測してもよいのだが、実際のプロジェクトでは「同じプロジェクトは二度と発生しない」という1回性の制約がある。これはウォーターフォール開発でもアジャイル開発でも同じである。特殊な場合として「Wordpress を使ってホームページを量産する」ような工場生産のようなパターンもあるが、これはプロダクトの生産プロセスとして扱う方がよいだろう。つまりは手順化する&自動化するのが一番早いという形になる。

1回性のプロジェクトではあるが、毎度難解な試行錯誤を繰り返すのはプロジェクトメンバーの心理的な負担でもあり、毎回終わりのわからない未知のプロジェクトが発生するのはよくない。これは20年前以上から言われたことで「デスマーチ」というミームが使われている。

実験的に計画と実績を測定する

これをシミュレーション的に数百回繰り返せば、だいたい正規分布に従う結果がでるはず。というのを書籍でやりたかったのだが、ちょっと紙面が足りなかったのと、間に合わなかった。

ここで Excel を使って実験をしてみよう。

  • 30個のチケットを作る
  • 各チケットは3時間程度を目安にして、適当に散らばっている
  • 実績時間は、やや遅れる傾向にある

という条件を付けてシミュレーションをしてみる。

マクロ付の Excel EVMと正規分布の解説.xlsm

ボックス・ミュラー法

チケットの予定時間や実績時間は正規分布で配置することと仮定している。これは後日証明することになるが、ひとまず、正規分布に従った予定時間や実績時間を計算するために「ボックス・ミュラー法」を使う。以下は、VBA のコードで、先のマクロ付きのシートに記述してある。

''' ボックス・ミュラー法
''' mean: 平均値
''' stdDev: 標準偏差
Function BoxMuller(mean As Double, stdDev As Double) As Double

    Dim u1 As Double, u2 As Double
    Dim z0 As Double, z1 As Double
    Dim pi As Double
    Dim i As Integer
    Dim v As Double
    
    pi = 3.14159265358979
    
    ' 0と1の間の乱数を生成
    u1 = Rnd()
    u2 = Rnd()
    ' ボックスミュラー変換
    z0 = Sqr(-2 * Log(u1)) * Cos(2 * pi * u2)
    z1 = Sqr(-2 * Log(u1)) * Sin(2 * pi * u2)
    ' 平均と標準偏差に基づいて調整
    v = mean + z0 * stdDev
    
    ' 結果を返す
    BoxMuller = v
End Function

平均と標準偏差を決めてチケットを作成

予定時間は、3時間を中心に標準偏差1時間で散らばることにする。書籍では3時間と決め打ちにしていまっているが、実際にはある程度チケットによって時間が変わるだろう。

予定時間に従って、実績が決まってくる。予定よりも早く終わることもあれば、予定よりも遅く終わることもある。大抵の場合、予測よりも遅くなることが多いので、4時間を平均値として標準偏差1時間で散らばることにする。もう少し正確な方法として、予定時間を平均値として標準偏差を1時間にするとよいのだが、ここでは思考実験なので数値を簡略化しておく。これを「実績」とする。

もう一つの列として「実績2」がある。これは書籍にあるように「タスクは予定よりも早く終わらない」原則を計算したものである。例えば、予定時間が3時間のときに、そのタスクが2時間で終わってしまったときに、残りの1時間をどう使うか?の問題である。大抵の場合、コードの品質を上げるために3時間まで使ってしまうか、休憩として使ってしまう。つまりは、予定3時間のタスクの実績は3時間以下になることはない、という想定である。これを「実績2」とする。

※後述するが、チケット駆動では、この余った時間を寄せ集めるように「チケットを前倒しにする」ことをでプロジェクトの納期を守る確率を上げるとができる。

これらをヒストグラムにする。

チケット数が30位ではうまいぐあいに正規分布にはならないが、おおむな3時間を中心にして前後に散らばっていることが解る。

また、実績では、中心が4時間となった同じ形のグラフになる。つまり、全体的に予定3時間が実績4時間に増えているわけで、1時間 x 30 チケット = 30時間の余裕をつければよい、ということが解る。

しかし、予定より早く終わることがない「実績2」のヒストグラムをみてみよう。

予定よりも早くおわることがないので、前者の「予定」と「実績」のグラフとは異なっている。ランダム値による計算なので、Excel を開くたびにかわってしまうのだが、予定に近い3時間の部分をピークとして、左側の3時間以下はほとんどなく、実績の4時間のほうに長いゆがんだグラフになる。これはもっと、チケット数を多くしてシミュレーションすると解ると思われる。

この実験の統計値をみてみよう(Excelシートでは、ランダム値を使わない「実験1」のシートがある)。

ランダム値なので、毎回計算値が変わってしまうが

  • 計画時の合計 79.3時間
  • 実績の合計 108.7時間(計画との差が約 30時間)
  • 実績2の豪快 114.9時間(計画との差が約45時間)

という結果が得られる。

プロジェクト計画と実績との乖離は、要因として見積もりの甘さ(楽観的な規模見積)が伴うものが多く、これを回避するために保険(1.2倍や1.5倍など)をいれることもあるが、実際には、

  • 計画から実績へのバラツキ(正規分布等)がある
  • 実績は予定よりも短くなることはない

という理由があり、規模見積をしたときの保険自体の甘さも入ってくる。

ただし、これらの見積もりの甘さを複雑な計算式を使って正確に実績を予測することも可能おではあるのだが、あまり意味がない。というのも、開発を担っているのが人間である以上、「計画から遅れたら、残業してでも頑張る」という心理状態が働いてしまうからだ(あるいは、むしろ働かないほうを前提としたほうが期間見積はしやすい)。また、このシミュレーションでは複数のタスクをひたすら長い期間で対処できるのだが、実際の開発では1日の労働時間(8時間)に縛られるし、8時間の区切りでうまくタスクを調節しないといけない。それこそ会議や昼休憩などが挟まるので、思考のセットアップなどを含めると更に遅れることになり、測定値からずれることになる。ゆえに、正確な計算はあまり妥当ではなく、もっと大雑把な「方針」が求められる。方針を決めた上で、プロジェクトの着地地点(主にスケジュール)を立てることが求めらるだろう。

おまけ

なお、この現象は、WBSなどで区間をきっちりと区切ってしまうことによる弊害である。特に、きっちりと工程管理をされたウォーターフォール開発に多い弊害である。「きっちり管理」することにより、余計遅れるという現象である

チケット分割をして、「このチケットが終わったら、他のチケットも少し進めておこう」という、早めの着手ができる状態にしておくと解消される。これは書籍にも書いた方法である。

カテゴリー: 開発 | 「図解即戦力 アジャイル開発の基礎」の第7章の正規分布を Excel でシミュレーションする はコメントを受け付けていません