時、巻き戻った後9
輪太郎は作るべきソフトを検討し始めます。
さて、一番儲かったワープロソフトや表計算ソフトも難しいことが解った。
そうなると、どんなジャンルのソフトであれば勝ち抜けるだろうか？
解りやすいようPC向けやスマホ用アプリでありそうなのを上げていくことにする。
ネットワーク関連がまだない時代なのでブラウザ、メーラ、メッセンジャー、ニュースアプリ、ＳＮＳあたりはまだ無理だ。
パソコンにまだマイクがないので音声の録音再生関連も難しい。
当然ながらカメラもGPSも歩数計もないのでその系統のアプリも無理になる。
辞書や百科事典、地図を取り込むにはFDDやHDDのサイズ的限界がある。
パソコン自体が持ち運べるサイズじゃないので、スケジューラ、電話帳等は作れても利便性が低い。
それに、電話帳や住所録あたりは専用アプリより、ワープロソフトか表計算ソフトで作られて、紙で運用される気がする。
となると、すぐに思いつくのはお絵かきソフト、アニメ作成・再生ツール、作曲ソフトや音楽再生用ソフト、印刷物関連のソフト、あとは開発ソフトの定番、エディタ、データベース、アセンブラやコンパイラ等の言語、天文ソフト、教育用や占いとかのキオスク系ソフト、あとは業務用ソフト類あたりか。
まずは業務用ソフト。
ほとんどの業務用ソフトはデータベース機能をもっていて、入力インターフェースからデータの操作ができ、指定フォーマットで印刷出来ればだいたい完結できる。
例外はハードウエアと連携して機械をコンピュータから操作するような場合だけだ。
だから、作れるかと言われると、特に問題なく作れる内容になる。
むしろ、入力インターフェースと印刷機能を備えた高機能なデータベースソフトウエアを作っておけば、それでたいていの業務アプリが作れるようになるとは思う。
問題はどんな業務アプリを作るか、なんだよなあ・・・。
業務用ソフトの多くは作るだけじゃダメで、業態に応じた入力支援の仕組みが必要になる。
プログラム自体というよりは、業務に特化した専門家がいて、そのニーズに合わせた開発が必要なになるわけだ。
つまり、作れはするけど、作るだけではだめで、専門家が使いやすく作ることが必要になるんだよな。
逆に言うと、協力してもらえる何らかの専門家を知り合いに見つけられれば、十分目があることになる。
悲しいかな、現時点ではそういう相手がいないので、まずそれを探す必要があるだろう。
そういうわけで、現時点では業務用ソフトの開発は保留かな。
それ以外というと・・・うーん、見事なまでに開発ツールばかり。
エディタ、データベース、言語はもろに開発用だし、お絵かきソフト、作曲用ソフトあたりはゲームを作るならツールとして必要になる。
アニメ作成・再生ソフトはFlashみたいな高度なものじゃなく、複数枚の画像を使ったパラパラ漫画みたいなものを作成、再生することを想定しているが、これ単体でも十分ゲームの素材に使える。
もちろん、画面の切り替えが出来るわけだから、一時停止や前後へ移動できるようにするだけでプレゼンテーションソフトにもなるし、ボタンを付けて別画像への画面遷移機能なんかを付ければキオスク端末なんかに使う事が出来るようになるわけで、結局使い方なんだけども。
唯一、開発ツールじゃないのは印刷関連だけだが、これもハードル高いんだよな。
当面は色数の問題でカラー写真を素材として使えないため、モノクロ用として作成していく必要がある。
そのうえ、DOS環境の時点で、画面表示時とプリンタ間の縦横比問題がでる。それもプリンタごとに。
(縦横比問題：パソコン上で正円を描いて、それを印刷しても紙に印刷されるのは歪んだ楕円になるという問題。原因は画面側のドットの縦横比がプリンタ側とそろっていないことが原因）
これを解消するには、画面に表示する文字サイズからの調整がひつようになる。
つまり、テキストモードでの操作ではなく、文字入力まで全部グラフィックモードで処理する必要があるし、そうなるとフォントサイズを画面に合わせて調整する必要があるので、同梱フォントが必要だ。
また、フォントも1種類だけではだめで、複数種類を切り替えられないと意味がないだろう。
そうなると、その分のフォントも自作が必要だ。
また、機能的に縦書き横書きや２段組み程度ならすぐにワープロソフトで出来るようになるので、それより複雑な構造が組めなくては、印刷専用としてはメリットが薄い。
しかし、組版まで考えるとＧＵＩでの操作方式などがかなり作りこまないと難しくなる。
テキストベースだとそれこそ、スクリプト書いて印刷書式を生成するTeXみたいなソフトになりかねない。
それじゃだめだ。画面を見ながら編集できないとパソコンの意味が無い。
うん、どれもできなくはないが難易度が高いことばっかりだなあ。
しかも、売り込み先が狭いうえに、パソコンでできるのはモノクロ原版までとなると、すぐさまの収益としては期待しにくいような気がする。
ただ、業務用ソフトの項目でも書いたけど、印刷自体はほとんどのソフトで使う必要がある機能だ。
だから、ここまでの精度は不要にしても、ある程度部品としては作りこむ必要はある。
まったく作らないというわけにもいかない部品なんだよな。
さて、だいたい作れそうなソフトについては考えてみた。
とはいえ、こうしたソフトでも、現在の環境を考えるとかなり制限が必要になるケースがある。
どんな感じに制限を受けるのか、実例を挙げて説明してみたい。
何か・・・そうだな、まず、最初はお絵かきソフトについて考えてみよう。
具体的な環境も想定したほうが解りやすいかな。
比較的ましな環境であるNECのPC-9801環境で考えることにする。
とりあえず、まずは機器の仕様からの制限が多い。
まずもって、パソコン本体にマウスが付属しない。
単体購入しようとすると、公式のPC-9872が2万円。
タッチパネルはあるが、公式のPC-9803が標準で5万円。
タブレットに至ってはまだ概念さえ存在しない。
2万円や5万円というのもマウス1個、モニタに付けるタッチパネル1枚の値段だよこれ。
前世の価格と、物価の差を考えると恐ろしい価格差といえる。
OSにGUIが無いから必要性がなく、量産効果も出ないので当たり前だが、それにしても高い。
とにかく、まず絵が描けるってことが先だろうから最初はキーボードだけでもなんとかなるだろう。
でも、マウス対応も必要になるだろうから、やっぱりマウスも購入しないとだめだろうなあ。
次に色の話。
画面表示できる色が少ない。
PC-9801の場合、画面表示はデジタル8色やアナログ16色が当たり前の時代。
まあ、デジタル8色で絵を書くのはさすがにハードル高すぎだと思うので、アナログ16色を前提にするが、
それでも使えるのは16色である。4096色中から選んだ16色が使える形だ。
ちなみに、アナログ16色を使うためにもそれなりに資金投資が必要だからね。
PC-9801 VMでアナログ16色使うには2万円の増設ボードを追加しなくちゃいけなかったから。
当然、16色しかない色で主線も塗りもということになると、自由自在というわけにはいかなくなる。
だから、べた塗りだけじゃなく、16色の選びなおしとドットパターン中間色とを柔軟にできないと、表現力が足りなくなる。
パレット操作はメニュー側でRGB数値入力でカラーを選択し、それをパレットに割り当てる形だろう。
本当は色相バーからマウスで色を選択出来るようにしたいところだけど、一度に16色しか表示できないのでそれは無理だ。
マウスでの入力でも、RGBの数字をスライドバーで選べるようにする位しか出来ないだろう。
あと、16色と言っても、その全部をパレットに使用できるようにする事も難しい。
お絵かきツール側の背景色と文字色がいるので、普通の人なら14色が精いっぱい。
絵の出来を重視してソフトの背景は見にくくてもいいというならあと1色、つまり１５色まで変更できるだろうが、文字色は背景と反対色でないと文字が読めなくなる。
そこの入れ替えはできないようにしておくべきだろう。
とはいえ、アニメ塗りの線の色として文字色である黒を使う、とかはあり得るので、塗り自体には16色全部を使える必要はあるだろうけど。
それから、指定範囲を塗る際に、アナログ16色でのべた塗りのほかにも、4x4とか6x6とかのタイルパターンでも塗りつぶせる必要がある。
色数が少ないので、タイルパターンで中間色表現をするしかない為だ。
また、タイルパターン領域を別のタイルパターンでの塗り替えとかもしたいので、複数色を指定してそれら指定した色がつながっている領域だけを選択し、その範囲をまとめて塗りつぶせるようにもしなくてはならない。
機能的にはもっと低機能だけどフォトショップでいうところのマジックワンド機能みたいなもんだね。
ああ、あと、せっかくコンピュータで描くので、数回程度でも元に戻すとやり直しも欲しいかも。
とは言え、これも実装するなら物理的な制限が出てくる。
変更点を全部記憶しなくちゃならないとなると、かなりメモリを食うのである。
例えば16色(4Bit)で640×400のイラストを描くと、無圧縮だとデータ量は最低125KB必要になる。
これは、1Byteが8bitのところ、1色あたり4Bitのデータ量があるので1Byteで2ピクセル分の色が記憶できるからだ。
640×400×0.5=128000、ただし、1KB=1024Byteなので125KB必要。
ファイルとして保存する場合、実際にはこれプラス、ファイルヘッダの大きさが加わるのでもう少し大きくなる。
今回の場合、アンドゥのためのデータで履歴にしか過ぎないのでファイルヘッダも要らないし、圧縮も可能と考えて、1/3位になると見て1枚辺り41.3KB。
現在の何ギガバイトの世界であれば、吹けば飛ぶようなメモリサイズだが、この時代の場合そうはいかない。
この当時のPC-9801 VMの場合、標準搭載のメモリ量は384KBしかない。
キロバイトだよ、キロバイト。
実行プログラムの大きさも影響するが、高機能なソフトで、メモリの半分を使ったとすると、余った自由に使えるメモリはわずか192KB。
このうち、1枚分は現在の絵の保持、1枚分は編集前の画像保持に使用するので、残りは108KB、つまり、実質2回しかアンドゥできない計算だ。
つまり、アンドゥ・リドゥを有効に使いたいなら追加メモリが必須になる。
しかし、PC-9801 VM2のMS-DOSでは1MB以上のメモリは使えない。(CPUが8086互換のV30だからね)
となると、特殊な方法でメモリを追加するしかない。
その特殊な方法がバンクメモリやEMSメモリである。
両方とも、使えるメモリ領域の一部から増設したメモリの中身を見えるようにし、増設したメモリ内をページ切り替えしながら覗けるようにすることで実質増設したと同じように見せる、という技術になる。
バンクメモリはI/Oデータの独自形式で、その後規格化されたものがEMSメモリになるが、いずれにしろどちらも高価だった。
同じメモリ量で比較してみようか。
I/Oデータの2MBのバンクメモリ、PIO-9234-2MD(2MBモデル)がソフト付き72,000円
ハードウェアEMSメモリボード(PC-9801-53)は1MBが89,000円、2MBへとさらに1MB増量する(PC-9801-54を追加)と、さらに60,000円が必要。
149,000円使って、これでやっと42回アンドゥが出来るだけ、という・・・。
さらに気になるのが、GUIに関する慣れの問題になる。
問題になるのは新規作成・開く・上書き保存・名前を付けて保存、等の必ず使うが使う回数が少ない重要な命令の取り扱いだ。
本当はWindowsみたいにアプリケーション上面に設置されているプルダウンメニューに入れたいところだ。
しかし、1985年だとまだ国内にはプルダウンメニューが使われているコンピュータが存在していない。
最初に登場したのは1983年1月発売のApple Lisaからで、これは高すぎて売れなかったので、国内にはほとんど入っていない。
現実的な価格で登場するのはAppleからMacintoshが発売されてからになる。
しかし、1984年中に発売されたMacintoshの128Kや512Kは日本語が使えず、これもほとんど国内では見かけられなかった。
じゃあ、国内でプルダウンメニューがそれなりに見かけられるようになったのは何時か、というと、日本語に対応した漢字Talkを備えたMacintosh Plusの登場以降になる。
1986年1月以降の事だ。
つまり、今はまだプルダウンメニュー自体が国内にほとんど存在しない時代、なのである。
実際、国内でGUIというと最初に登場したのは1983年のNEC PC-100になるのだが悲しいことにこれは普通のMS-DOSマシンだ。
GUI対応のアプリと縦横切り替え可能な高解像度のモニタが付いていただけである。
なにしろプログラムの起動はコマンドラインからだけだし、全画面モードのアプリしかなく、操作は一番GUI化されていたワープロですら全力でボタンとダイアログだけの構成なんだよな。
いきなりプルダウンメニューを採用しても、インターフェースとして解ってもらえるかがかなり微妙・・・。
となると、むしろ、普段は表示されてないシステムパレットに入れておいて、必要な時だけを特定キー押して出して呼び出す感じのほうが理解しやすいのでは？
実際、Multiplanとか、一太郎とかはESCキーを使ったこういう構成だしね。
システムパレットなら画面全体を使っても問題ないだろうし、ボタンを並べまくっても混乱しなくてすみそう。
とまあ、こんな感じだ。
ソフト開発自体の難易度は現在のC系統でソフト開発するのと大きくは変わらないと思う。
結局はハード自体の仕様がわかっていないと作れないのは変わらない。
むしろアセンブラ自体はこの時代のCPUの集約度を考えると、ハードウエア構成が簡易なので見通しがよく、作りやすいほうだとさえいえる。
ウェブサービスを作る際に抑えておかなきゃいけない技術の数を考えると、こちらのほうが全然楽だといえるくらいだ。TCP/IPまわり、サーバOS、データベース、キャッシュサーバ、バックエンドの言語環境、HTMLやXMLの仕様、JavaScriptやその上のライブラリ、CSSのプロパティごとの意味と効果ならびに、それに対するブラウザの仕様など、必要な要素の多さにくらくらする。
しいて言うならライブラリから全部手で作る必要がある点がややハードルが高いことくらいか。
足し算引き算から全部実装が必要になるからなあ。
代わりに、ユーザサイドで現在使われている基本的な機能を実現するとなるとにかく金がかかる。
まあ、GUI環境がなくては実現できないお絵かきソフトだからこそ、という面はあるにしろ、やっぱり現在のソフトとは違う面で大きなハードルだろうなあ。
ま、とにかく、そういう時代だということだ。
そして、その中でどういう環境でどういう開発をしていく必要があるかを考える必要がある。
