アマゾンのレビューに想うこと

10数年前にエーアンドエーの新庄さんと著した『CADリテラシー演習』は初めてVECTORWORKSに触れる人向けであり、当時からその続編あるいは補足版を作りたいと思っていました。それがこのブログを立ち上げたひとつの理由でしたが、『CADリテラシー演習』を発表したエーアンドエーのシンポジウムでお会いした編集者さんのおかげで二年半前に『VECTORWORKS ベストテクニック 100』（エクスナレッジ）を発刊し、このブログを作った目的をほとんど果たせた気がしています。そのこともあって更新は２年以上前で止まってしまっていますが、未だに少なくないアクセスがあって嬉しいです。

一方で、今でもこのブログに記したような情報が求められるのは、ソフトが表面的に進化しても根本は変化していないと好意的に受け取ってもよいのでしょうが、情報発信を続けてきた者としては、このブログにあるような情報はもっと公式の立場から発信されなければならないものだから、ある種の絶望感もあります。

私がずっと理想だと考えているのは「ソフトがユーザーを育て、ユーザーがソフトを育てる環境」ですが、実現はなかなか難しいのでしょう。現実的にはソフトの枠内でしか作れないクリエイター志望者が増えているような気がしています。ソフトの枠からの逸脱は、ソフトとユーザーの両方を育ててくれるのですが、、、、。

*

さて、『VECTORWORKS ベストテクニック 100』についてアマゾンで不思議なレビューが書かれていたので、ここで一言述べようと思います。（アマゾンのレビューに対して著者自らが他の場所で見解を述べるのは江戸の敵を長崎で討つような印象をもたれるかもしれませんが、そうではなく単にアマゾンのような場のレビューに対して著者が直接返答するのは不謹慎だと思うので、こちらに記す次第です。）

そのレビューをかいつまんで言えば「教材データが無い→実際に演習できない→駄本」という話の展開であり、最低評価（★１つ）が付けられていました。

アマゾンで閲覧できる目次で分かると思いますが、この本はページをめくりながら順に進めても良いのですが、むしろ自分で好きな項目を読んで方法を知り、読者自身のスキルやアイディアを高めるような使い方が向いています。極端な言い方をすれば、逆引きマニュアルあるいはFAQ集です。

このレビューの最初の部分「教材データが無い」は事実です。しかし、本のコンセプトから言えば教材データを付けたら「駄本」になります。というのは、課題となる状況を著者が教材データとして読者に与えるのではなく、読者自身がその状況を作り出すこと、あるいは、自分が陥っている状況がこの本に記されていることを発見することが重要な学習であるからで、

課題となる状況を自分で作り出せる

　→そこに存在する課題の意味合いが分かる

　　→作業中に行き当たった課題とこの本の項目の関係を把握できる

と考えます。

そもそもこの本は入門用ではなく、一定のスキルを獲得している人向けなので、「読者は本で説明した状況を意図的に作り出せるだけのスキルを有している」という前提です。だから、申し訳ない言い方だけれど「教材なし＝駄本」という判断は、レビュー者のスキルがこの本のレベルに達していないことを示していると推察できます。ピアノで言えばバイエルを終えてハノンやブルグミューラーやツェルニーに入ってしばらく経った人レベルに向けた本です（逆に言えばショパンやリストを軽々と弾ける人には無用の本です）。数か月～数年、VECTORWORKSを真っ当な方法で学べば、この本には教材が不要であることが理解されるでしょう。

*

なお、アマゾンには「あなたはこの本の関係者ですか？」と尋ねたくなるほど、コンセプトをしっかりと理解してもらえたと感じるレビューがあり著者としてとても嬉しく思いました。

*

ところでアマゾンのレビューといえば、私が関わった『図説年表 西洋建築の様式』に★１つと★４つがついています。★１つの方にはレビューが書かれていますが、低評価の理由は「発注した業者の対応」に対するもので「本の内容とは無関係」です。私はたまたま出版に多くかかわってきているし、『建築文化』誌に書評（＝レビュー）を継続的に書いたり、学会誌の書評を書いたことがあり、その経験から読者が読みたいことを想定しながら書く習慣が身についていますが、世の大半の人はそういう経験を持たないので自分の言いたいことを書きがちです。だから読者アマゾンなどショッピングサイトのレビューにおいて、客観的であるべきレビューと主観だけで許される感想文が混然一体となっている状況は受け入れざるを得ないと思っていますが、上記のようなことで評価の平均値が下がるのは困ったことです。

正当な理由による低評価なら受け入れて次の機会に反映させられますが、上記の2つの事例は誰にとっても何のプラスにもなりません。たとえば『VECTORWORKS ベストテクニック 100』では「私は教材データ付きだと勘違いして買った。教材データが必要な人は注意せよ」のように書けば世のため人のためになったでしょう。

*

これがこのブログの最後の投稿になる可能性が高いのに、VECTORWORKSの知恵とは無関係な内容で失礼しました。

【VectorScript】 私のプログラミング言語体験

VectorScriptについていくつか書いたついでに、私のプログラミング言語体験を思い出しながら書いてみます。誰の役にも立たない内容かも知れませんが、私が現在VectorScriptを使う上で、あるいは、いろいろなソフトをトラブルを最小にしながら使う上で、以下の経験がとても役に立っています。プログラミング言語学習としていきなりVectorScriptを始めるのはハードルが高い気がする場合は、現時点では手始めに Squeak に触ってみるといいと思います。

*

以下、体験した順に思い出しながら記すので、時系列は多少あっちこっちすると思います。

APL

大学１年のとき渡辺仁史先生の研究室でデータ入力の手伝いをしました。このときのプログラムがAPLで書かれていました。IBMのAPL専用マシンでAPL独特の記号がキーボードに並んでいました。APLを使ったプログラムは自分自身では書いたことがありませんが、プログラムの中身をちょこちょこ見たりしていました。私がAPLとApple IIの違いすら知らなかった頃のお話です。

プログラミング電卓のBASIC

友人がSHARPの関数＆プログラミング電卓を持っていました。これには階乗計算が標準搭載されていなかったので、説明書と首っ引きで内蔵BASICで作ってみました。たぶんこれが最初のプログラミング体験です。変数やループについて知る良い経験になりました。ディスプレイに一行しか表示できなかったのでプログラムを書くのは大変で、実行速度もとんでもなく遅かったことが、マイコンが欲しいという気持ちに繋がりました。

F-BASIC

新宿の西口界隈をぶらついていたら、ある店の前で高校の同期に呼び止められました。その店はCSK、当時はマイコンの小売りもやっていました。友人はそこでアルバイトしていたそうでMZ-2000の中古を買わないかと持ちかけられ、すっかり買う気になっていたのに元所有者の都合でドタキャン。そして、その勢いのまま発売されたばかりのFM-7をローンで買いました。当時は電源を入れるとROM-BASICが立ち上がりプロンプトがピコピコするタイプのものが普通で、FM-7に搭載されていたのはF-BASICです。当時主流であったNECのPC-8001や8801のN-BASICとはちょこちょこ違いがありましたが、便利になる側に働く相違でした。当時はプログラムが掲載された月刊誌が複数発売されていたので、それらを買って書いてある通りに打ち込みながら学習しましたが、大したものは作りませんでした。雑誌に掲載されるのはN-BASIC用のプログラムが大半だったので、それらをF-BASICに移すのは良い学習になりました。月刊誌Oh!FMの発刊は、ちょうどそのころだったと思います。

Fortran

FM-7はモトローラの6809という8ビットCPUを積んでいましたが、当時の8ビットCPUはZ-80が主流でした。FM-7には別売でZ-80カードが存在し、それを入れるとCP/M-80というOSを動かせました。CP/M-80はOSなので、その上でいろいろな言語を動かせました。そのひとつがFortranです。当時のパソコン雑誌にFortranを使った3Dパッケージが掲載されていて、それを使ってパース作成プログラム（今で言う3D-CAD）を作りたくてFortranをかじりました。

FortranはBASICのベースであったと思うので、BASICの知識をベースにわりとすんなり入れましたが、入出力の面倒くささには辟易しました。パース作成プログラムもデータの格納方法（データベース構築）で行き詰まって挫折しました。あらかじめ定まったポイントをつなぐだけなら何とかなりましたが、どんなパースでも描けるようにするためには不特定多数の３次元座標を扱う必要があります。またそれを間違いなく入力する手法も要求されます。汎用性を持たせることの重要さと大変さ、インタフェース設計の重要性を痛いほど理解できました。

BASIC-09

FM-7（モトローラ6809）で動いたOS-9上で動く構造化BASICです。「OS-9はMacintoshだ、おまえは間違えている」と主張する変なアップルユーザがいて困ったことがありますが、そっちはMac OS 9、由緒正しいOS-9と別物です（OS-9はMac OS 9よりずっと前に登場したものです）。

BASIC-09は強いて言えば、通常のBASICとPascalの間にあるような言語でした。構造化されているからF-Basicで書くものより美しく分かりやすいプログラムを書けました。

OS-9がマルチタスクだったので、640×480の画面を田の字に４分割して、それぞれで異なるリサジュー図形を描かせたりして遊んでいました。8ビットCPUでのマルチタスクだから、田の字に分割した画面すべてに線画のリサジュー図形を描くのに丸１日かかったりしていました。

LISP, Prolog

これらはCP/M-80、OS-9、MS-DOSなどでやったと思います。概念的な側面に対しては興味を引かれていましたが、Prologでとても小規模な、いまで言えばSiriやAlexaとの会話っぽいプログラムを作って終わりました。

LISPはAutoCADに搭載されたAutoLISPへの興味が大きかったのですが、AutoLISP自体を使う機会がありませんでした。

LOGO

亀さんを動かして遊んだ程度です。私には、何の役に立つのか全く分かりませんでした。

Turbo Pascal

記憶が定かではありませんが、PC-9801でやったと思います。Pascalの特徴は構造化されていて、BASICみたいなスパゲッティにならない（というよりスパゲッティを作りにくい）点が大きな特色です。しかし、私は構造化できるBASIC-09を知っていたので、Pascalは非常に面倒くさい言語だという印象しかもちませんでした。私のPascal嫌いはここに始まります。その後、Turbo Pascal以外のPascalに触ったこともありますが、入り口を入ってすぐに逃走しました。ところが今もっとも使う言語がPascalライクなVectorScriptであるのは、何という皮肉なのでしょうか、、。

dBASE

初めて触ったのはCP/M-80版です。本格的に使ったのはPC-9801のMS-DOS版でした。これを言語と言ってよいのがどうか分かりませんが、dBASEは素のままでは大変に素っ気ないデータベースプログラムで、搭載されているdBASE言語で実用的なものを作る必要がありました。ほとんど個人的な趣味としてやっていましたが、『図説年表 西洋建築の様式』の年表を複数人で執筆するときに、データ入力と整理のためプログラムを書きました。他のメンバーはデータベースソフトに触るのが初めてだったので、インタフェースを親切に作ったら200行を超えました。不親切なインタフェースならば半分以下の行数で済んだと思います。

dBASE言語は目的がはっきりした言語だったので、使いやすく、実用性の高いプログラムが容易に書けました。私が最ものめりこんだ言語です。一方で、プログラミング言語でアプリケーションソフトウェアを作ることのハードルの高さを思い知らせてくれたのもdBASE言語でした。データベース用に特化されたdBASE言語と、汎用の言語では必要なリソースもエネルギーも桁違いだということ、まともなアプリケーションソフトウェアを作るためにはその筋のプロになる必要があることをdBASE言語が気付かせてくれたのです。この経験から私は本格的なプログラミングを作ることを断念し、ユーザに徹することにしました。

MILC

MS-DOS時代に愛用していたMIFESに内蔵されていた言語です。Cベースだったので、MILCはCへの入り口となってくれました。たとえば、当時最も優れたファイラーであったFDを呼び出すとか、テキストをメール送信するために一定文字数ごとに改行を入れるとか、あるいはそれを復元するとか、かゆいところに手を届かせるための数行から数十行程度のマクロをあれこれ作っていて、それらをNifty-ServeのMIFESのフォーラムにアップしていたら、月刊誌 Oh!PC となんとかムックに掲載されました。原稿料は一方が現金5000円、もう一方が図書券5000円分でした。当時は貧乏学生だったので大いに助かりました。

自分にとって「実用的な」プログラムはMILCで作ったものが多かったです。

Turbo-C

Cについてはポインタというものがなかなか理解できずに手間取りました。どんなものを作っていたかは忘れましたが、数十行程度のものは書けるようになっていました。関数自体に返値があることをしっかりと把握できたことが自分にとって画期的で、これがVectorScriptのハンドル理解に役立ちました。Cはその後はMS-Cなどにちょこちょこっと触ったくらいで、そのうちにC++がでてきましたが、プログラミングをやめてアプリケーションユーザに徹すると決めた後だったのでC++の経験はありません。

FORTH

スタック指向とか逆ポーランド記法という言葉に興味を引かれてかじってみましたが、使う目的が見つからなかったので、学習本を少し勉強しただけでやめました。FORTHと言えば、日本語Mindもかじって関西弁で書いてみたりしていました。（逆ポーランド記法的入力はArchiCADで使われていますね。）

QBASIC

構造化BASICで、BASIC-09に似ていてとっつきやすかったこともあり、趣味的に数百行くらいの図形を扱うプログラムをいくつか書いて遊んだ記憶があります。

N-BASIC

NECのBASICです。イスタンブールの、とある歴史的建造物の調査に参加したとき、極地研さんから光波測距機を借りられることになりました。そこで当時はまだ無名だった友人＝ロボット専門家の山海君に頼んで一定のピッチで光波測距機を動かすロボットを作ってもらって、それの制御と計測値取得のためにN-BASICでプログラムを書きました。このとき、なぜN-BASICを使ったかというと、調査に持っていくラップトップPCがNEC製だったからです。測距機とPCはRS-232Cで繋げました。

調査後は、距離と角度から空間座標を算出し、メッシュで表現するプログラムを書きました（記憶が曖昧ですが、たぶんQBASIC利用）。これにはけっこう骨が折れました。今だったらExcelに座標を取りこんで3Dグラフで表現したか、あるいは、VectorScriptで書いたでしょう。いま書きながら思い出しましたが、当時、すでにLotus 1-2-3があったのだから、それでやればよかったかもしれません。

DesignCAD内蔵のBASIC？？

1990年代前半ごろ（？）に存在していたDesignCADという3D-CADに、カスタマイズのためのBASICが内蔵されていました。当時のPCのパフォーマンスでは3Dはまともに動かなかったので、エッシャー風の2D図形を描かせて、それを立体化して遊んでいました。（これを利用して当時の勤務先にあったNCルーターで置物でも作ろうかと思っていましたが、実現しませんでした。）

Squeak, Scratch

Squeakは、長い間、SmallTalkというものに興味があったので使ってみましたが、プログラムを書くのをやめて久しかったので雰囲気を味わって終わりです。Scratchは子供にプログラミング言語を体験させるために使ってみただけです。プログラミング入門には適していると思います。

SED

プログラミング言語と言えるのかどうか知りませんが、MS-DOS時代、テキスト処理によく使っていました。その後、同様のことができるプログラミング言語としてAWKが広まったようですが、必要なかったので使っていません。

MS-DOSバッチファイル

これもプログラミング言語とは言いきれませんが、かゆいところに手を届かせるため／処理の簡便化のために今でもよく使います。ほとんどが大量のファイルの一括処理なので、エディタではなくExcelで書くことが多いです。

VectorScript

Pascalベースだから読んだときに内容を掴みやすい点は良いのですが、大嫌いなPascalベースだから敬遠していました。しかし20年ほど前、授業で教科書に採用した本の特定操作のマクロを作る箇所で本の記述通りに進まず授業が止まってしまいました。そこでやむなく避けていたVectorScriptに触りました。当該マクロのVectorScriptを見たら、表面的なマクロ作成では予期できないパラメータが勝手に入っていことが原因であると直ちに分かったので、それを削除することで解決しました。この問題発見には様々な言語をかじってきたことが大いに役立ったと思います。それ以来、ちょこちょことVectorScriptを使うようになりました。私にとっては、MIFESでMILCを使うのと同様かゆいところに手を届かせるためなので、大きくても数十行程度です。一度だけVectorworksにない機能を補完する必要に迫られて数百行ものに挑戦したことがありました。手作業で発生しがちなヒューマンエラーを回避するためでもあったので、なんとか8割方完成するところまでこぎつけましたが、結局時間不足のため断念しました。未完成で放置したものの、VectorScript学習として得たものは大きかったです。

*

他にもかじった言語があったかもしれませんが、思い出せません。

ほとんどが興味本位の遊びの範疇でしたが、プログラミング言語学習を通して自分の瞬間的思考の解析や何かの手順を人に説明することもうまくなりました。また、いろいろなソフトが内部でどのような処理を行っているかの見当が付くようになったので、より効率的な手順を見つけたり、バグを回避する手法を見つけたりできるようになっています。私にとっては、そのことがプログラミング言語そのものを修得することより飛躍的に大きな意味があったと思います。近いうちに小学校教育にプログラミングが導入されるようですが、上記のことからは歓迎すべきことでしょう。しかし、まともにプログラミングを教えられる指導者を育てることが至難の業だと思います。英語も同様で、子供が和英辞典の丸写しの英単語羅列文（すなわち英語ではない）を教わってきたときに愕然としましたが、プログラミング学習がそのようにならないことを祈るばかりです。

ところで、プログラミング言語で遊んでいたころの私は西洋建築史の研究者でした。今はCADとか情報リテラシーの専門家として扱われることが多いです。全く畑違いのように見えますが、物事を客観的に突き放して観察する姿勢が必須である点では共通しています。

【作図のヒント】 位置決めには面図形も使えます

手書きの図面は、補助線を引いて位置を決め、不要になった補助線を消しゴムで削除しながら作図します。Vectorworksでも同様の方法で位置決めできますが、補助線ではなく、補助図形（面図形である四角形や円など）を使いましょう。最大の理由は、面図形と線は、書く手間に差がない一方で、面図形は線よりも選択・スナップなどが楽だから、位置決めするのも、後から削除するのも楽なのです。

*

以下に使いからの例を示します。

• ここでは、補助図形を使ってテーブルセットを3000mm右にコピーしてみましょう。アクティブクラスは何でもかまいません。コピー元の図形の基準となる点をスナップして、幅3000mm（高さは任意）の四角形を描きます。

• コピー元の図形の基準点をスナップして、Ctrlを押しながらドラッグし、③で書いた四角形の右上にスナップさせます。

• 上の手順で描いた補助図形を使う必要がない場合は、補助図形（今回は四角形）を削除します。もし同じ補助図形を今後も使う可能性があれば、残しておきます。※残す場合が多ければ、あらかじめ補助図形のためのクラスを作っておいて、上記の作業とに、データパレットから補助図形のクラスを「補助図形のクラス」に変更します。

*

ひとつひとつの補助図形へのクラスの割り当て方については、これが絶対に良い、こうでなければいけないという決まりごとはないので、クラスの一般的な考え方「図形の意味合いが異なる場合は異なるクラスに入れるのがよい」に従えば十分です。手順④に描いたように、この後も使う可能性の有無で考えましょう。

【重要】このTIPSと同じ操作は、他の手順（たとえば同位置複製＋数値移動、ポイント間複製）でも可能です。このような場合に考えてほしいのは、操作のステップ数を少なくしたり、自分が使うコマンドを絞り込むことによって、総合的な作業時間を短縮することです。ここで示した方法を使うと、右手、左手の動きをかなり低減できます。来る日も来る日も何百、何千回とあっちこっちに手を動かし続けたときに、少しでも身体に負担が少ない方法を身につけることはとても大切です。

*

『VECTORWORKS ベストテクニック 100』

今までのVECTORWORKS解説書にはなかった、より便利に速く図面を描くためのVectorworksの使い方を100コ紹介しています。

『Vectorworks ベストテクニック 100』発刊

2018/4/28に、エクスナレッジから『Vectorworks ベストテクニック 100』が出版されます。

30年近くにわたるノウハウをベースにした、Vectorworksを上手に使い回しながら初級者から中級ユーザに進むためのTIPS的テクニックを集めた本です。たぶん？、きっと？、絶対に？、、、、目から鱗が落ちるようなテクニックが見つかると思います。これらを身につければ、操作スピードがかなり向上するはずです。

Amazon で購入

いわゆる学習テキストは、必然的に著者の設計に対する考え方や姿勢が反映しますが、この本では、考え方や姿勢を削ぎ落としたときに残る合理的・効率的な操作方法を紹介しています（そのつもりです）。誰にとっても有用であろうことを考えながら著しました。

ところで、この本には書いていませんが、設計の考え方や姿勢に対するTIPS的なネタもたくさんあります。セミナーではそれらをお話ししたりしていますが、いつか、本を書けたら良いと思っています。

【一般】 コメントについてのお願い

このブログの記事にコメントするには、WordPressのアカウントが必要なので幸いとコメントはほぼゼロですが、最近、「○○××についてご教示ください」と書いたコメントが入りました。

その日のうちに（＝24時間以内に）私にできるアドバイスを返信しましたが、一週間以上経ってもなしのつぶてです。その人物の文章は丁寧で好感がもてるものではありましたが、「ご教示ください」と自ら書いておきながら、返信に対して何もコメントしないというのは無礼きわまる行為だと思います。

コメント者はそういう質問をしたこと自体を忘れているのかもしれません。とにかく、こういうことが起きるのはインターネットではやむをえないことは承知していますが、気持ちの良いことではないので、今後は、質問に対する回答は書かずに、この記事のURLを教えることにしようかと思います。

ということで、質問がある人は、教えてgoo、OKWaveなどのそういうオンライン質疑応答システムを使ってください。といっても、これらには無責任な回答を書く人がいるようなので、しっかりとした回答を得たければ、VectorWorksのユーザークラブを使うのがよいと思います。

公開での質疑応答も質問者と回答者の間に閉ざしたコミュニケーションという認識でいる質問者が多いようですが、自分が質問して、誰かに回答してもらうことが、今後、同じ疑問をもった人の役に立つかもしれないという意識をもっていない人はダメな人だと私は思います。私がコメントに返信するのも、当事者宛てだけではなく将来の誰かの役に立つかもしれないという気持ちがあるからです。