仕様書作成に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を活用してみる(要件定義、概要設計)

新人教育用に「ハンバーガー注文サイト」を実装してもらっているのですが、その設計書づくりが非常に面倒くさい。きっちりと設計書を作るのか、アジャイル開発風にチケットで作るのかと思いつつ、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でも同じことができるでしょう)、

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

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

カテゴリー: 開発 | コメントする

段ドリーの奇妙なプロジェクト 第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番はしていた

「ニッコリ」

カテゴリー: 開発 | コメントする

「図解即戦力 アジャイル開発の基礎」の第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などで区間をきっちりと区切ってしまうことによる弊害である。特に、きっちりと工程管理をされたウォーターフォール開発に多い弊害である。「きっちり管理」することにより、余計遅れるという現象である

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

カテゴリー: 開発 | コメントする

CドライブのSSDを512GBから2TBに換装する

ストレージ容量の限界

開発環境の設定には大量のデータ容量が必要であり、特にXamarinのAndroid開発環境が非常にスペースを多く消費していることがあります。Visual Studioが利用する Adnroid SDK とAndroid Studio の利用する SDK がばらばらになっているのが原因です。相互に勝手に更新すするので、どうしても二重に用意しておく必要があります。

で、現在512GBのSSDを使用しているが、現在のプロジェクトとドキュメント、さらにはAppDataによって生成される一時ファイルにより、残りの容量が30GB未満になることが多いのです。ここ半年ほど、ゴミファイルを消すなどしていたのですが、ちょっと限界。

SSDのクローンによる解決策

この問題を解決するために、現在のSSDをより大容量のものに交換することにしました。重要なのは、開発環境を一から再設定することなく、すべてを新しいドライブに移行させることです。これには、AOMEI Backupperというソフトウェアを使用し、「ディスククローン」機能を利用しました。特に、業務用PCなので安全性を重視し、Pro版を選択(費用は1万円弱の一回払い)。このツールはフォーマットの違い(MBRやGPT)にも対応しています。

詳細は Windows 11/10/8/7で新しいPCへ古いPCのデータを移行する方法 を参考にしています。古めのPCなのでフォーマットが MBR に揃えてあるのですが、この際 GPT に直して、アプリケーションを購入することにしました。業務PCだし。

クローニングプロセス

クローニングは、512GBのデータを新しいSSDに移行するのに30分弱という短時間で完了しました。プロセスが完了すると、BIOS設定を介して起動ドライブを新しいSSDに切り替えました。

SSD は差しっぱなしにして、BIOS でブートする SSD を切り替えます。そのうち、古いシステムの SSD はフォーマットしてデータようにします。

結果として

新しいSSDにより、以前に経験していたストレージの問題から解放され、より快適に開発作業を進めることができるようになりました。クローニングにより、再設定の手間も省け、作業効率が大幅に向上しました。また、将来的にはさらに多くの開発プロジェクトやアプリケーションを追加する余地もでき、作業の幅が広がります。

赤くなっているのが元Cドライブ。いつもギリギリな状態が続いていた。

一番大きいのは心理的安全ですね。残り切りぎりぎりでせめぎあうよりも(残り 30GB を切ってしまうと、シミュレータ等をいくつか入れるとCドライブが死んでしまうので注意が必要です)、この際、空き容量を増やしてしまったほうがベターです。

この業務PCでは、主に

  • Visual Studio
  • Android Studio
  • Office 系
  • SQL Server/MySQL

と映像系は入っていないのですが、どうも Android 開発関係で肥大化してしまいます。最初の頃は 512GB で十分なのですが、開発していくうちに残容量がぎりぎりになってしまうのです。できれば最初から 1TB の Cドライブを用意したいところです。なので、ノートPCの初期状態では難しいかなと。ノートPCで開発する場合は、カスタマイズをして SSD の容量を増やしておくおとが肝心でしょう。

まとめ

SSDのクローンとアップグレードは、特にデータ重視の作業において、時間とリソースの節約につながります。この方法を選択することで、システムのダウンタイムを最小限に抑えつつ、効率的に環境をアップグレードできるため、開発作業をスムーズに進めることが可能です。

数年前はクローンが大変だったので、開発環境の入れ直しが多かったのですが、いくつかのクローンソフトがあるようでかなり楽になっています。ちなみに、SSDは突然死するので、バックアップ等が必須です。私の場合は、仕事用のファイルは全てDドライブ(別のHDD上)に動かしています。なので「ドキュメント」配下で一時的な作業をするのはよいのですが、仕事上のファイルを置くことはお薦めできません。適当なディレクトリを作ってください。・・・と新人教育で言うわけだけど、何故かドキュメントフォルダ配下に作りますよね。OS、というか Windows が作るの仕方がないというのもあるわけですが。

カテゴリー: 開発 | コメントする

「図解即戦力 アジャイル開発の基礎」の第7章の正規分布の補足

  • 正規分布でボックス・ミュラー法を使う
  • Excel でタスクを予測する練習問題

書籍のほうではかなり端折ってしまいましたが、要するにプロジェクト内の複数のタスクはとある確率(ここでは正規分布)で分布するので、それらをかき集めると概ねプロジェクトの遅延具合が予測できる、ということです。

この理論自体はゴールド・ラット氏の「制約理論」を利用したCCPMのプロジェクトバッファで話されているところで、予測値として、遅延具合を1.5程度にするのが数学的に計算できる、というのが根拠となっています。書籍のほうでは、1.2から1.5程度と言う形で「プロジェクトバッファ」の幅をとっていますが、いわゆる保険となる期間はプロジェクトエンドの受容性に関わってくるものです。この確率の幅は、プロジェクトでの制作物が「人」によりものであり、「人」が恣意的に遅れを嗅ぎ取って開発スピードを上げたり、あるいは平常に戻したりということを行うので、実は「確率」に従わないという事情がはいっています。

なので、おおざっぱに、「プロジェクトは必ず遅れがでる」ことを前提として(タスクを早めることはしないので)、あとはどの程度のプロジェクトバッファ≒保険をとればよいのかという議論にしぼっています。

数学的な分布の根拠

数学的な厳密さを求めることはできませんが(さらにプロジェクトは一回性なので、再確認をすることもできません)、ある程度の予測を立てることは必要です。PMBOKでの予測、というよりも、CMMIに則った予測可能なプロジェクト運営という点では、単純なチケット駆動による後からのフォローでは順調なプロジェクトというものは無理という現実があります。つまり、チケットが発生した後で、規模見積りあるいは期間見積をするために常に後手に回ってしまうということです。

つまりは、作業用のチケットが発生する前にチケットの作業時間を予測しなければいけません。でなければ、プロジェクトの完了日は常に予測不可能となってしまいます。チケット駆動などのアジャイル開発を忌諱し、安易にウォーターフォール開発に回帰しようとするのはこのせいでもあるでしょう。もちろん、きちんとした「計画駆動」をとる場合は、ウォーターフォール的な開発手法もよいのですが。

もう少し詳しい解説を追加しようと思ったのですが、もう少し時間がかかりそうなので、数学的根拠を箇条書きで加えておきましょう。

  • チケットやタスクの粒をある程度揃えれば、それぞれの作業は繰り返し作業と同等と考えられる
  • 実験計画法と同じように、タスクの実績時間には分布があり、測定誤差とみなせる。
  • タスクが30チケット以上あれば、それは正規分布に従う
  • プロジェクトの遅延が正規分布に従うので、80%の確率でプロジェクトが成功する、期限日を事前に求めればよい

この正規分布するプロジェクト遅延で80%確率の地点が、1.5倍ということになり、これが数学的な根拠です。実は、遅延の分布をいろいろと変えることも可能ですが(かつて、アジャイル開発プロジェクトの遅延などを測定する製品があったのですが、現在はなくなっています。なぜなれば、そこまで正確に測定をしても意味がないのです。「人」が遅延を感じとってしまい、遅れを解消しようと「努力」してしまうためです)。

プロジェクトの持つチケットの数(WBSの数でも構いません)が30以上あればよいので、例えば、半年間(20×6 = 120日)のプロジェクトであれば、4日/チケット前後に粒を揃えればよいという計算になります。ただし、チケット駆動の場合は、未完了/完了を明確にしておきたいのと(チケットの内の進捗度というものも意味がありません)、人の生活習慣である1日や週単位にしておきたいので、1日程度というのが妥当なところでしょう。

また、計画駆動的に解決するのであれば、各工程(設計工程、実装工程など)の中で、30程度の作業(PERT図)を作っておくとよいでしょう。

実験計画法とEVM

その昔、品質工学で使われる直交表の意味がわからなかったのですが、Excelで実験計画法を行う書籍を手にいててやっと納得がいきました。

  • 実験自体は、物理的な制約から数回しか行えない。
  • 数回の実験結果から評価誤差と測定誤差を含めて、正規分布で評価をする

工業的な製品(熱の加え方や材料の混ぜ方など)の評価試験を行うときに、実験というものは数回しか行えません。場合によっては、それぞれの材料を組み合わせて1回位しか行えないものです。その中で、物理的な誤差や測定誤差を含めて、実際の効果(多要素分析でもあります)を検証しないといけないのです。つまりは有意性検定をする必要があるのです。

薬剤やワクチンの効果も同じです。

さて、この有意性検定が必要なのは実は実験数(計測対象の数)が30以下の少ないときに限られます。というか、30以上の大量にある場合は、分布が正規分布に近づくので誤差の扱いを「正規分布に沿う」という形でも十分だから、という意味も含まれます。

ここで物理現象を扱う場合には30という数は結構多いのですが(同じ実験を30回も繰り返すのは大変ですよね)、ソフトウェアの場合は自動テストなどを繰り返せば、数万回繰り返すことも可能です。ここに大きな認識の違いがあります。つまり、ソフトウェアでいうところのシミュレーションを繰り返すことによって、測定誤差が正規分布に近づくということです。ここは MCMC 法と言う形で、いくつかの物理実験でも示されているところです。

MCMC法、つまりランダム値を使って数百回とシミュレーションを繰り返すことによって、複雑と思われるような物理現象(これは開発プロジェクトのタスク消化も含めることができるでしょう)をとある分布つまり正規分布に収束させることが可能です。

果たして、プロジェクトの完了日をぴったりと予測するのは難しいのですが、とある幅をもって「このくらいには80%でプロジェクトは完了するであろう日」というのは比較的容易に計算ができます。さきに書いた通り、プロジェクトのタスク消費も物理現象に従うので、実験計画法などと同じように、標準偏差(σ)を使って求めることができるということです。これは、EVMの解説にでてくるところです。

というわけで、あれこれと数式をならべてもよいのですが、ある程度のチケット数を持つプロジェクトを100回ほど繰り返すと遅延確率が実地で計算できます。現実問題として同じプロジェクトを100回繰り返すことはできませんが、100回シミュレーションすることは可能です。

このあたりの話は、Excelを使った実験を後でアップする予定です。適当なプロジェクトを作り、チケットの予定と実績をとある分布に従ってシミュレートするものです。

カテゴリー: 開発 | コメントする

「.NET MAUIによるマルチプラットフォームアプリ開発」のサンプルを .NET 8 へ

書籍のほうは、2023年1月に発売なのだけど、タイミング的に対象が「.NET 6」となってしまっているので、ひとまず .NET 8 対応のものを上げておきます。サンプルを作ったときに .NET 6 で作っていたのですが、発売直後に .NET 7 になっていまい、今ロングサポートが .NET 8 に切り替わる状態となっています。

本来はライブラリ自体も少し変わってきているので、いずれ改版したいところなのですが、さすがに1年しか経っていないので改版はしにくいので、暫定的にサンプルコードだけでも、というところです。

サンプルコード

https://github.com/moonmile/maui-samples のブランチ「net8」で取得してください。

git clone -b net8 https://github.com/moonmile/maui-samples.git

修正点

プロジェクトファイル(*.csproj)で、TargetFrameworksを.net8 に変更

		<TargetFrameworks>net8.0-android;net8.0-ios;net8.0-maccatalyst</TargetFrameworks>
		<TargetFrameworks Condition="$([MSBuild]::IsOSPlatform('windows'))">$(TargetFrameworks);net8.0-windows10.0.19041.0</TargetFrameworks>

パッケージに「Microsoft.Maui.Controls」等を追加。.NET 8 ではNuGet参照となっている。

	<ItemGroup>
		<PackageReference Include="Microsoft.Maui.Controls" Version="$(MauiVersion)" />
		<PackageReference Include="Microsoft.Maui.Controls.Compatibility" Version="$(MauiVersion)" />
		<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="8.0.0" />
	</ItemGroup>

その他

  • 第5章の MVVM では Prism.Core を利用している。現在 .net8 対応が beta 版なので、8.1.97 のままにしておく。https://github.com/PrismLibrary/Prism いずれ、Prism.Maui に変更しておきたい。
  • 第6章の Comet の利用は現在開発が停滞しているようなので https://github.com/dotnet/Comet 修正対象からは外す。
カテゴリー: 開発 | コメントする

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

「紙飛行機を飛ばす、あれ?今、馬鹿にしませんでしたか?」

「・・・、いえ」

いや、実際、馬鹿にしてしまった。というか、紙飛行機。一体どこがこのITプロジェクトに関係しているのだろうか、とドリーは思わざるを得なかった。馬鹿にする、というよりもソフトウェア開発のプロジェクトで『紙飛行機を作る』というのはどういう目標だろうか?なにか、ITに関係があるのだろうか?

「いや、無理もないです。紙飛行機なんって誰でも作れるもの。誰でも飛ばせるものと思うじゃないですか。10歳の子供が、いや幼稚園児だって紙飛行機ぐらい作って飛ばせるようなものです。飛ぶ原理はわからなくても、折り紙を折ってロケット型にしてぴゅーと飛ばすとか、イカ型の紙飛行機とか絵本にでも載っているじゃないですか。それを真似たら、誰でも作れる紙飛行機。そう、誰もが作れるのに、このプロジェクトで作るのに意味はあるのか?という疑問ですよね。当然です。当然の疑問ですよ」

と、急に3番さんが話に割り込んできた。いままで、キーボードとにらめっこしていた人だが、ええと本当の名前はぴくみんだったかピクミンだったか覚えていないのだが、1番さんと同じ赤いシャツに赤いズボンをはいている。けど、背中に番号が振ってある。いつ付けたのか分からないが・・・。

いや、3番と書いてあるけど、5番かもしれないが、まあ、ここはどうでもいい、非1番の人が話しに参加してきた。

「ええ、その、紙飛行機は何か特別なものなんですか?」

「いや、特別ではないですよ。誰でも飛ばせる紙飛行機だし、誰もが作れる紙飛行機です」

「・・・・」

「覚えていますか?子供の頃に紙飛行機がたくさん載っていた厚手の本があったじゃないですか」

「そうそう、小学生の頃に流行りましたよね。二宮さんの紙飛行機集ですよ」

「1ページかな2ページぐらいでひとつの紙飛行機ができていて、本自体が厚紙なっているんです。うまく切り抜いて接着剤で貼り付けるとゴムでよく飛ぶ紙飛行機ができるやつです」

「そう、頭の部分にクリップを付けておいて、割りばしにつけたゴムで引っ掛けて飛ばすやつですよね。非常によく飛ぶんですよねぇ。子供の科学だったか子供の化学だったか、大人の科学だったか忘れてしまいましたが、いろんな飛行機がありましよね」

「だえん型とか無尾翼とか普通の飛行機じゃない型もありました」

1番さんと3番さんが楽しそうに紙飛行機の会話をし始める。

そうだ。折り紙で作っている手軽な紙飛行機じゃなくて、子供、といっても小学生の高学年の子が作るような紙飛行機だろう。自分で作るとなかなか飛ばないのだが、あの本に載っているものをうまく切り抜いて貼り合わせると、よく飛ぶ、そう。

「ああ、思い出しました。あの紙飛行機ですね。100メートルぐらい一気に飛ぶやつですね」

「「・・・・」」

いや、違ったか。100メートル程度だったら、飛行機としては飛んでいるうちにはいらないかもしれない。そもそも、ジャンボジェットの全長が70メートル近いのだから、100メートルだったら飛ぶというよりも、ちょっとジャンプしてしまう位の感じだろう。そう、「岸和田博士の科学的愛情」にでてくる轟天号が25メートルプールで飛び込みをしたときに、ちょっと飛ぶだけで飛び込み台から25メートル先、つまりはプールの縁か縁まですぐに達して頭をぶつけてしまう位の感じだ。

だから、もうちょっと飛ぶかもしれない。例えば100光年とか。

「すみません、単位を間違えました。100光年ぐらい飛ぶやつですね。わたしの子供の頃にはやりましたよ」

「「・・・・」」

なにか不味いことを言ったらしい。いや、ドリーにとっては「地球のことはわからないから、ホコタテ星の基準しか知らないので」というところなのだが、それが通じる相手なのかいまのところは検討がつかない。

「いや、さすがに、100光年だとだめなんですが」

「もうちょっと、飛ばないと駄目ですよね、1万光年位ですかね?」

100倍位ちがっていたらしい・・・。

「なるほど、そうなると、紙飛行機の選定の部分から大変そうですね」

「おお、解ってくれるじゃないですか」

「そうなんですよ、たかが紙飛行機なんですが、材質から選定しないといけない。ときには、新しい材料も探していかないといけないというプロジェクトなんです」

「新しい材料となると、色々とありますね。「紙」飛行機という名前になっていますが、なにも紙じゃないと駄目という訳でもないのです。無限にある材料を紙のように薄く引き伸ばして、長距離を飛べるように形作っていくわけで、まさしく「神」飛行機ですね、はははは」

「はははは」

「はあ・・・・」

1番と非1番が談笑しているのをドリーは眺めているわけでが、談笑しているからといってプロジェクトがうまくいっているとは限らない。プロジェクト計画書があって、進捗状態が99%だとしても、シュローは困っていたわけで(いや、ドリーに無理難題を押し付けていてホッとしていたかもしれないが、あとで思い出してみよう)、このプロジェクトが終わる見通しが立っているかどうかが問題なのだ、とドリーは気を引き締める。談笑に騙されてはいけない。

「プロジェクト目標が『紙飛行機を作ること』はわかったのですが、そこに至る手順というか道筋を聞いておきたいのですが、よろしいでしょうか?」

「ということは、この紙飛行機作成プロジェクトを納得して頂けたということでしょうか?」

「あ、いえ、納得というか・・・」

世の中、不思議なプロジェクトというものはたくさんある。短期もあれば長期なものもある。スタートとエンドがあるからプロジェクトであって、繰り返し生産ができればそれはプロダクトの領域だ。紙飛行機を量産というと、なんらかの機械があって時間内にいくつ紙飛行機が飛ばせるのか、飛ばした紙飛行機を籠に入れるまでの競技があったりなかったりするのだが、その紙飛行機を折る機械を作ろうとするならばそれはプロジェクトだし、プロジェクトなりのノウハウを活用できる。

「まずは、その紙飛行機プロジェクトの内容を聞いてみないとなんとも言えないものがありますので・・・」

「ごもっとも、話は簡単ですよ。紙飛行機を目的に向かって飛ばそうプロジェクトです。このプロジェクトに既に3年も掛ってはいますが、全体の進捗としては99%であともう一息というところです」

1番は、壁に貼ってあるホワイトボードに図を書き始める。確か壁一面に付箋やら設計図やらが貼ってあった筈だが、その部分だけ1面まっしろとなってぬけている。不思議だ、と思ったら壁に貼ってある設計図の上に新しい紙を貼ったらしい。横からみるとどんどん紙が重なっていて地層のようになっているけど、重力で落ちないか不安だ。いや、そもそもここに重力があるのか?足が浮いているような気もするけど気のせいだろう。

「まずはここ、中央に『紙飛行機』があります」

典型的なマインドマップあるいはWBS(work breakdown structure)の類だろうか。なぜにITプロジェクトで紙飛行機なのかはわからないが、目的ははっきりしているらしい。

「次に『紙』、こっちに『飛』、こちらに『行』、さらに『機』があります」

1番は「紙飛行機」を1文字ずつ分解しているようにみえる。何?何がはじまったのだろうか?

「さらに『紙』は、ごぞんじのように『糸』と『氏』にわかれますね。『行』、これは簡単ですね。『ノ』と『イ』と『テ』に分けることができます」

まてまて。漢字を偏と旁に分解するわけではないらしい。一体何をやっているのか?

「さらに『テ』なのですが、『一』と『丁』に分けることができますね」

「あ、いちばんさん。『テ』は、確か『二』と『ノ』に分けたと思いますよ」

「ああ、そうでした。『一』と『丁』の組み合わせだと、なかなかコストがかかってしまうので、受託コストの安い『二』にしたんでしたっけ。こうすると『ノ』のところが共有部分になって製作期間が短くなりますからね」

「『ノ』をふたつ作ればいいのと、最終的に『二』は2つの『一』から成り立つことになるので、ここも繰り返し計算で済むというのが便利です。for文を使ってもいいですし、コレクションやリストをつかってもいいです」

コンピュータプログラム言語っぽい用語を出しているようだが、ドリーにはさっぱりわからない。単に漢字を分解してみせているだけだが、これはいったいなのだろうか?設計なのか?

1番が言う。

「ドリーさんには少し難しいかもしれませんが、もう少し解説させてください。ここが難しいところですし、このプロジェクトでは大切なところなのです」

「あああ、はい・・・」

「『飛』これが難しいところです。最初は『升』と2つ『て』にわけて、ニスイにしたいところだったのですが、このニスイがなかなか難しいのです」

「というと?」

「漢字変換で、なかなか出ないんですよね。「ニスイ」と書いても「にすい」と書いてもだめなので、よくよく調べてみると『冫』という形で書けるのです。部首としては「ひょうぶ」と読むらしいですが、ここでは『冫』としておきましょう。そうなると、『升』と2つの『て」そして2つの『冫』で構成されるわけですが、ここで問題が発生していまいます」

「・・・・」

「『冫』というのが、コミュニケーションしにくいのです。お客に説明するときにも『冫』の部分を読むことができないし、開発者の間でも『冫』を勘違いしやすくなってしまいます。ラショナル統一プロセスの辞書作成の基準なのですが、できるかぎり顧客つまりは利用者の言葉を使ってみたり、開発者の間で齟齬がないような用語をまとめておくようにする決まりがあるのですが、ここで『冫』を使ってしまうと、いちいちコピペしないと出てこない漢字・・・といいますか、部首、これを口に出していうのもなかなか難しいので、このプロジェクトでは『冫』を使うことを諦めました。混乱はプロジェクトの停滞のもとですからね。プロジェクトが潰れかねません。開発チームを崩してしまいます」

意味がよくわからないが、その、なんか「ン」に似ているものどうするかという話だろう。チームを混乱に落とし込むような要因は避けたほうがいいのは同意する。完全ではないが同意したいところだ。

「そういう訳で、『冫』を使うのはやめて『ン』にしたんです。ですが、『ン』にしても『ソ」と間違える人が多くて困っているのです。日本人だと大丈夫っぽいのですが、非日本人だと駄目なんですよね。『ン』と『ソ』を間違ってしまう。たとえば「ソン」と言ったときに、何故か「ンン」と伝わってしまったり、「ソソ」と伝わってしまったり、逆に「ンソ」と聞き違えてしまう場合もあるのですよ」

「はあ・・・」

「いや、非日本人というのは宇宙人や猿も含めるわけで、猿ならばいいんですが、宇宙人となるとちょっとやっかいで」

確かに厄介な問題になりそうだ。差別というか区別というか、日本人と宇宙人と猿を同列で扱っていいものなのだろうか?ホコタテ星人がはいっていなのがちょっと不満であるが、とドリーは思った。

「なので、『ン』は諦めて、『ニ』を使うことにしました。ちょっと字の形が違ってしまいますが、2つ『ニ』を使えば『ン』よりも『ソ』と混乱しないで済むと思われるのです」

「ですが、ちょっと注意してくださいね。ドリーさん」と急に割り込む非1番。

「勘違いしないで欲しいのですが、先の『二』と『ニ』では字形が違うことがわかりますか?最初の『二』は『一』に分解できる『二』なのですが、こっちの『ニ』は2つの『-』を使うのです」

違いが全く分からん。。。

「さらに細かくなるのですが、『-』と混乱しやすい『ー』を使うところが台無しになってしまうのです。見た目は似たように思えるのですが、縦書きになるとほら、こんな風に『1』になってしまいますからね」

兎も角、紙飛行機プロジェクトが混乱の極みになりつつあることはわかった。しかし、混乱しつつもうまくメンバーがアイデアを出してプロジェクト計画に沿って文書作りをしていることが判明した。ここは、もうひとつ『ニ』と『二』がいったい何なのかを詳しく聞かねばなるまい。

ドリーは若干の不安を抱えつつ、少し問題が解決したような全く解決していないような、けむに巻かれてしまった気持ちで、1番に質問をするのであった。

カテゴリー: 段取り | コメントする

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

さて、一方、やってんどーの部屋でのドリーである。

プロジェクトメンバーを数えると、1人2人3人・・・と5人いる。まずはプロジェクトリーダーが誰なのかを見極めないといけない。ドリーの武器は「段取り」一本である。段取りの一歩目はまずは状況把握が大切である。

メンバーは5人。名前を聞いてみると

「ひくみん、です」

「びくみん、です」

「ひぐみん、です」

「びぐみん、です」

「ぴぐみん、です」

という答えが返ってきた。なんだ、オリマーはいないのか、と思ったドリーだが、某天堂ゲームではないのでオリマーがいるはずがない。いや、オリマー役がこのプロジェクトには必要なはずだが、実はだれかがオリマー役を担っているのかもしれない。

「段ドリー、です。よろしくお願いします」

自己紹介?は済ませたので、早速だれがリーダー役かを聞いてみる。

「この5名のうちの誰がリーダー役なんですか?」

「「「「「?」」」」」

なんとも怪訝な顔をした「ひくみん」達が並ぶんだが。いや、区別がわからない。首の傾げ方も同じだし、実は服も同じだ。赤いシャツを着ていて、赤いズボンをはいている。ほっそりした体系もみな同じだ。頭にぴょこんと馬鹿毛が生えている・・・訳ではないが、似た感じの髪型をしている。区別がつかない。

「ええと、リーダー役は、ひくみんさん、あなたですか?」

適当なひとりを指さして尋ねてみる。果たして、彼・・・あるいは彼女が、ひくみんさんかどうかもわからないし、リーダー役かどうかも分からない。両方が当たる確率は5×5で、1/25の4%というところで限りなく低い。

「違いますよ」

案の定、否定の言葉が返ってきた。

「そうですよ」

意外にも、肯定の言葉が返ってきた。

はずれが4/5、あたりが1/5の確率で事前確率と事後確率のベイズの関係だ。

「ひとまず、ひくみんさん」

「ええ」

「ちょっと、皆同じ赤い色のシャツを着ているし、顔もどこととなく似ているので、みなさん区別がつくないので、右から「1,2,3,4,5」と呼んでいいでしょうか?」

「・・・・」

ひくみん達が怪訝な顔をして顔を見合わせている。

あまり区別がつかないといはいえ、冒険ダン吉のように番号で割り振るのはあまりにもだと思う。でも、どうみても区別がつかない。A、B、Cでもいいし、い、ろ、は、でもいいのだが、さすがに番号は失礼だろうか。せめて、国語、算数、理科、社会とか、青、赤、黄、白、黒とか五行大儀風に揃えたらいいとかしたらよいだろうか。

「ええ、いいですよ」

「え?あ?いいんですか。ちょっと失礼かと・・・思ったんですが」

「いえいえ。無理もないです。地球の人たちには私達はまったく同じに見えるはずですよ。同じ赤いシャツと同じ赤いズボン、更に同じ顔に同じ髪型をしているから外見では区別はまったくできません」

「・・・・」

「なので、区別しようとしても無理です。無駄です。徒労です。お疲れ様なのです」

「あのう、ひとつ聞きたいのですが」

「はい、なんでしょう」

「あなたがた、ええと、ひくみんさん達はどうやって、区別されているんですか?」

「え?、どういうことです?」

「ええと、ひくみんさんと、ひくみんさん以外が区別がつかないとなると、番号を割り振る位しかないので、区別できなくて困りませんか?」

「はい、まったく困りませんよ。自分と自分以外を区別するのは用意だし、場合によっては区別する必要はありませんから」

「いえ、なんというか、たとえば、ひくみんさんとぴくみんさんを区別する必要があると思うのですが」

「いやいや、まったく大丈夫です。ここにいる人といない人ぐらいは区別がつきますからね」

「あ、ありがとうございます」

なんだよくわからないが、校正者が発狂しそうな感じだが、ありがたくもひくみんさんたちは番号で呼ぶことができるようになった。ありがたい。

「では、ええと、1番さん。最初の質問に戻るのですが、このプロジェクトのリーダー役は1番さんですか?」

「いいえ、違います」と1番が首を振る。

「じゃあ、2番さん?」

「いいえ、違いますよ」と1番が答える。

「そうなると、3番さん?」

「いいえ、そうではありません」と1番が再び答える。

「ひょっとすると、4番さん?」

「いいえ、そうではありません」と1番が再三答える。

「ええと、5分の1の確率で外れたということですか。そうなると、5番さんなのですね?」

「いいえ、残念ながら違うのです」と1番が言う。

「ん?どういうことでしょう?ひょっとすると、さっきのシュローがリーダー役なのでしょうか?」

「そんなことがある訳ないじゃないですか!」

最後の答えだけ1番は怒ったように声を荒らげる。何故、怒っているのかわからない。いや、そもそも顔も赤っぽいので(服やズボンの照り返しかもしれないけど)興奮している訳ではないかもしれないけど、口調が違うのは確かだ。シュロー、嫌われているのか?

「ちょっと、よくわからないのですが・・・、もしかしてリーダー役は今日はお休みなんですか?」

「いいえ。ドリーさん、ちょっと勘違いしているようですが。このプロジェクトにはリーダー役がいないんですよ」

「リーダー役がいない?」

「ええ、プロジェクトにはリーダー役がいません」

「リーダー役がいなくて、どうやってプロジェクトを動かすことができるのですか?船頭役がいなければ、プロジェクトは路頭に迷ってしまうし、船が丘に上がってしまうかもしれませんよ。いや、丘に上がるのは船頭役が多い場合だから、遭難してしまう船に例えたほうがいいですね。どこに行く付くかわからないじゃないですか」

「ええ、センドウ役ならいるんです」

「え?船頭役はいるんですか?」

「ええ、センドウ役は私です」

「・・・・」

船頭役がいるのにリーダー役がいないというのは不思議な話だが、ひとまず1番がリーダー役ということらしい。何かのプロジェクト独自のルールがあるのだろう。「プロジェクト」と「プロダクト」の微妙な違いを主張したり、「コンテキスト」と「コンテクスト」を区別したり、「顔認証」と「顔認識」をごっちゃにしてしまって叱られることぐらい意味があるものかもしれない。

「なるほど。1番さんがリーダー役・・・じゃなくて船頭役なわけですね」

「はい、センドウ役です」

リーダー役の1番の他にも確認を求めたほうがいいかもしれないとドリーは考えたが、他の忙しそうなプロジェクトメンバーを見ていると、このまま1番さんに話を聞いたほうがよさそうな気がした。他の4人はカタカタとキーボードをかき鳴らすことなく、椅子の背もたれに体重を預けながら瞑想しているように目をつぶっている。とても忙しそうだ。設計を考えているのか、小難しいロジックを考えているのか、それとも新しい発想を実現するための手順を頭の中でフル回転させているのか。いびきをかいたり、舟をこいだりしているメンバーもいるが、気のせいだろう。

「ところで、1番さん。このプロジェクトの目的は何なんでしょうか?」

プロジェクトの目的はプロジェクト計画書に記述されているはずだ。PMBOKにはプロジェクト憲章がある。しかし、あの「憲章」というのは何だったのだろうか?皆で意思を統一するための憲章だったのか、皆さん頑張りましょうのための集まりだったのか、それとも単なる飲み会だったのかさだけではないが、100年もの長く続いているプロジェクトにとってプロジェクト憲章とは一体何なのだろう。いや、100年プロジェクトのほうは憲章は必要かもしれない。

いきなり、プロジェクト計画書を見せてください、というのもアリなのだが、プロジェクト計画書がないあやういプロジェクトの場合だと「プロジェクト計画書とは何ですか?」とか「ふふふ、いまどきプロジェクト計画書なんて古いことをやっているんですか、ぷぷぷ」と笑われたりしそうなものだし。ここは円満に、目的を聞いておくのがいいだろう。でも、目的を知らないメンバーがプロジェクトに入ってくるのも問題だし。

「ここに、プロジェクト計画書があります」

1番は、机の上からプロジェクト計画書の冊子を持ってきた。

「ああ、プロジェクト計画書、あるんですね」

「ありますよ。当然じゃないですか」

「そうですね、当然ですね」

「当然ですよ」

ああ、この当然ができないプロジェクトがなんと多い事か!いや、冊子にしなくてもいいのだけどせめてプロジェクトの目的が明確になってから「プロジェクト化」することをして欲しいものです。漠然と営業目標からもってきたものは、達成基準がないからゴールがなくて「プロジェクト化」にならないんですよ。

とドリーの心の叫びで代弁をするのはこれまでとして、ドリーは冊子を開いた。

『プロジェクトの目的:紙飛行機を飛ばすこと』

「あの・・・」

「はい?」

「これが、プロジェクトの目的ですか?」

「ええ、これがプロジェクトの目的ですよ」

「紙飛行機を飛ばすこと、って書いてありますが」

「ええ、紙飛行機を飛ばすことがこのプロジェクトの目的なんです」

「・・・・」

前途多難の予感しかしない、とドリーは思わざるを得なかった。

カテゴリー: 開発, 段取り | コメントする

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

史郎は、「小さなIT会社」という会社に勤めている会社員である。一応、マネージャをやっている。マネージャーだけど、「小さなIT会社」(略してSITC Small IT Company)には社員が史郎ひとりしかいない。

でも、部署はいろいろあって「やってんどー」やら「がんばってんどー」などの不思議な名前の協力会社、という下請け会社というか外注会社とチームを組んでやっている。いや、チームを組んでいるのかさだかではないのだが、なんとかプロジェクトをこなしている。というか、毎回「炎上」している。

そんなところにドリーが新入社員として入ってきた。

性別は不明。年齢不詳。最近の履歴書には写真も載っていないし、性別も書いていないし、誕生日も書いていないことが多い。いわゆる、お台場シティというやつだ。いやダイバーだったか、サイバーだったか、よくわからなけど、そういうやつだ。

しかし、出身地のところに書いてある「ホコタテ星」というのはなんだろうか。まあ、出身地がどこだってかまらないのだけど、「ホコタテ星」というのは何処にあるのだろう。ペンギン村は日本にあるらしいけど、ホコタテ星は聞いたことがない。

「名前は、段ドリー。出身はホコタテ星です!」

目の前のドリーが自己紹介をする。彼女…なのか彼なのか不明だけど、一応彼女っぽく見える。いや、本当の性別はわからないけど。

「ホコタテ星?」

「ホコタテ星です」

「それはどこにあるの?」

「地球ではないことは確かですね」

「いや、日本のどこにあるの?北海道とか?」

「いいえ、地球ではないどこかです」

「・・・」

「禁則事項ですから」

いや、新入社員なのだから、禁則事項とか企業秘密とかいうもんだいではあるまい。

「大丈夫です。会社に通うには問題ないですから」

そう言い切ってしまわれると仕方がない。彼女、というか彼というか、ドリーは「ふんむー」と徳家げな顔でこっちを見ているのだが、まあ、いいか。会社に通えるならば問題ない。

「さて、新人の君の仕事なんだが・・・」

「え?新人?私が?」

「ああ、新人だろう?この会社の新入社員なのだから」

「いや、新人じゃないですよ、ベテランです」

「・・・」

「ベテランですよ。段取りのベテランです」

何を言い出すのかよくわからないが、ドリーはベテランらしい。

「何?何のベテラン?」

「だから、段取りのベテランです」

「段取り?何それ?」

「段取りですよ、ダ・ン・ド・リ。知らないですか?段取り!」

「初耳だなあ・・・」

ダンドリってなんだ?聞いたことがない。なんだそれ。

「プランニングとか、ガントチャートとか、チケット駆動とかそういうやつ?」

「いえ、ダンドリですよダンドリ。段取り八分、電話は二番ってやつですよ」

「何それ?」

よくわからないが、貴重な新入社員だ。まあ、社員は一名しかいないわけだが。これで俺、史郎の仕事も楽になるってもんだ。

「まあ、ダンドリはさておき、新人の君の仕事の説明なんだが」

「ベテランです」

「・・・・」

「ベテランです!」

「まあ、いいや。ベテランの君の仕事ななんだが」

「むふー」

いや、その得意満面の顔はいいから、話を続けさせて欲しい。

「べつの部署で、「やってるどー」というのがあるのだ。いま、プロジェクトが進行中なのでそれのマネジメントを君にやってもらおうと思っている」

「やってるどー、ですか、なかなか楽しいプロジェクトそうですね」

「そうだろう、なんとかやってるどーってことで、やってるんだよ」

「なるほど」

実は、やってるどーのプロジェクトは5名の派遣社員というか協力社員というか、メンバーでやっているのだが、まあ、進捗が悪い、というか、なかなか進まない。あまりにも進まないので、3年もプロジェクトが停滞しているぐらいだ。普通、3年もプロジェクトが終わらなかったら困る状況になるのだが、ともかくやってるどーの雰囲気が強くて、何も言い出せない。とにかく、やってるんだ。プロジェクトをやっている感がすごくて、やっている。だけど、終わらない。

「つまり、そこでわたくしが段取りしろというとですね」

「そう、察しがいいね。マネジメントして欲しいんだ」

「段取りですね」

「ああ、マネジメントなんだよ」

「段取り付けるんですね」

「ああ、ああ、わかった、そのダンドリってやつでいいよ」

「むふー」

言い負かされているような気もしないでもないが、まあいいや。ともかく「やってるどー」から離れられれば万々歳だ。ともかく3年も停滞しているプロジェクトで終わりが見えないのが、なんだかーなというプロジェクトなのだから。

「ところで、やってるどープロジェクトは、どこでやっているんですか」

「こっちだよ」

史郎は、隣に続くドアを開いた。実はやっているどープロジェクトは隣の部屋でやっているのだった。真ん中にテーブルが置いてあって、部屋の壁向きに5人が座っている。キーボードをカタカタを押して、モニタにちらちらと文字が書かれている。たまに画面が映っては、マウスでボタンをぽちぽちしたりしている。なにをやっているのかよくわからないが、ともかく凄いやっている。何かやっている。すごくやっているのだが、3年経っているのにこのプロジェクトが終わらない。どこから資金がでてきるのかわからないが、ともかくやっている感が凄いのだ。やる気満々という感じだ。

壁には一面に付箋が貼ってある。いろいろな記号(クラス図やらシーケンス図)が書いてある。壁一面に書いてあって、もとの壁がどこにあるかわからない位だ。壁が三角なのか四角なのかも良く分からない具合で、バーンダウンチャートと棒グラフが書いてある。たくさん書いてあるのだが、何がどうなっているのか分からない。

「やってますか?」

史郎は傍らのひとりのメンバーに声を掛けた。だれがリーダーなのか名前が何と言うのかわからない。自己紹介をしてもらったのは3年前なんだけど、それ以来名前を聞いたことがない。ともかく忙しそうで、掛けづらいのだ。

「やってますか?」

返事がなさそうなので、もう一度声を掛けてみた。いや、返事が返ってこない死人のようだ、という訳ではなく一心不乱にキーボードをたたいているわけだから、仕事をしているのは確からしい。いや、仕事をしているのかどうかわからないけど。

「やってますよ」

返事が返ってきた。

「やってますよ。ほらたくさんやってます。ここのコードをみてくださいな。こんなにもやってます。いろいろとやっているので、一言では説明しきれないのですが、その概要は壁に貼ってある、あれとこれとそれとあれを組み合わせて、ここの画面に出てくるこれとそれを表示させて、最終的にあれとこれがこうなって、それとそれとを組みあわせ、あっちのほうに出てくるのです」

声を掛けたのは失敗したかもしれないが、まあ、いつものことだ。何を言っているのかさっぱりわからないが、ともかくやっているのは確からしい。寝たりサボったりゲームをしたりしていたら、

「さぼらないでくださいねー」

と声を掛けることもできるのだが、忙しく仕事をしている人には声を掛けづらい。さらに、詳しく説明してくれるし、よくわからないけど何かができあがってくる雰囲気だけはあるので、その圧が強い。いやあ、いいものができてくるんじゃないかという感触はある。感触はあるのだが、3年間できあがらないのは、何故だかよくわからないのだけど。まあ、いいものができあがるのは確かなことだろう。信用第一だ。

「で、進捗具合はどうなのですか?」

「進捗ですか、そう進捗ですね。ええ、進んでいますよ、かなり進んでいます。でも、なかなか難しいところがあるので、あと一歩ということろですね」

「進捗率で言えばどうなんですか?」

「そうですね。99%というとろでしょう。あと一息なんですよ」

それはすごい。進捗率99%だなんて、あともう少しじゃないか。いつ終わるのか分からないけど、進捗率が99%なんだから、あと残りは1%だけだ。残りの1%が仕上がれば、晴れてやってんどープロジェクトも完成というところだ。

「ええと、ドリーさん・・・ドリーさんでいいですか?」

「いいですよ、シュロー」

「・・・」

あの、呼び捨てですか。まあ、いいけど、新人だからいいんだけど。

「ドリーさんは、このやってんどープロジェクトを担当してもらいます」

「段取りですね!」

「ええ、まあ、そうです。ダンドリですね。そのダンドリとかいうのを使って、プロジェクトを完成させて欲しいのです」

「いま、聞いたように、現在進捗率は99%!といういうことは、あと1%で完成というところですよ。もう少しなんです」

「なるほど、あと1%なんですね」

「そうです。あと1%なんです」

「・・・」

ドリーはあたりを見回している。壁いっぱいに張られた資料やらグラフやらクラス図やらに圧倒されているらしい。これぞITプロジェクトつまりはアジャイル開発プロジェクトの真髄といったところだろう。黙々とキーボードをたたくベテランメンバーたちに圧倒されているところだろう。新人とは、あと1%のところなのだから、なんとかなろうだろうし、なんとかならなくてもやってんどープロジェクトのメンバーがなんとかしてくれるだろう。そう、なんとかならなくても、俺のせいではなくなるので丁度いいものだ。史郎は胸をなでおろすのだ。実に順調に進んでいるやってんどープロジェクトなんだが、一抹の不安がよぎるのだ。一抹の不安がもう3年も続いているのだが、よくわからない。進捗率は99%であともうひといきなので、大丈夫なはずなのだが一抹の不安がよぎるんだよなー。なぜだろう。

「わかりました!私の段取り力に任せてください!」

「任せました。お願いします」

で、史郎はやってんどーの部屋から元の部屋に戻ったのだった。

カテゴリー: 段取り | コメントする