情報科学科の先輩に聞く!

現役学生OBインタビュー「先輩たちの仕事の原点」各界で活躍する先輩たちが教えてくれる“仕事の本質”

座談会トップへ戻る

世界一の計算性能に向けて 〜スパコン一筋30年

富士通株式会社|堀田耕一郎さん (情報科学科2期)
インタビュー年月日
平成21年 3月 19日
堀田耕一郎 
情報科学科2期生。
富士通の次世代テクニカルコンピューティング開発本部ソフトウェア開発統括部の統括部長代理。富士通のスパコンの最適化コンパイラや、新しい並列言語の開発を手掛けている。

富士通は法人向けにサーバーやネットワーク機器や、個人向けにパソコンや携帯端末、さらに、最先端のLSIの開発などを行っている。
渡邉健人(学部3年)、 泊久信(学部3年)
情報科学科の授業でも度々扱われる、コンパイラや計算機アーキテクチャに興味があり、その傍らで仕事をなさっている堀田さんに是非話を伺いたいと思い今回訪問に伺いました。
現在のお仕事



現在どういったお仕事をなされているのですか?
直近では、スパコンの開発をしています。僕は最近の人ではほとんどいないと思いますが、学部卒でコンパイラをやりたいと思って入社しました。 1980年に入社したのでもう29年、わずかに離れた時期はありましたが、ほぼコンパイラ一筋です。入社当時はベクトル型スパコンの自動ベクトル化を担当していました。最近は富士通はベクトルはやらずに、スカラーの並列マシンを開発していますので、スカラ並列のコンパイラが担当分野です。その他に社外での活動として、最近は情報科学科4期で現在は筑波大にいる佐藤さんや、NEC、日立、各大学、研究所等と一緒に日本発の新しい並列言語を作ろうとして、言語使用の検討をしています。これは、学術的に良いものができても使ってもられるかどうかとは別なので、普及させるのは大変です。
最近の最適化コンパイラのターゲットはどのようなものですか?
まず、現在のスパコンは、複数のノードをネットワークで繋いだマルチプロセッサになっています。現在はノード間の自動並列化はできないので、MPIのライブラリと並列言語でプログラム開発することになります。ですから、我々はMPIと並列言語を開発しています。ノード内の最適化は普通のスカラー系の最適化に加え、マルチコア下でのスレッドレベルの自動並列化を行っています。アカデミックなところではもっと前からだと思いますが、市場では90年代前半からスカラー系の最適化が非常に重要になってきました。それまでは、命令の数さえ減れば速くなっていたのですが、スーパースカラーなどでは命令レベルの並列性を追求しないと満足な性能が出なくなりました。また、命令のサイクルばかりが速くなってきて、メモリ関連がボトルネックになってきたのでキャッシュを効率的に扱うことも非常に重要です。ベースとして命令の数を減らすのはもちろんですが、最近はこういったハードウェアと一対一になったような最適化が非常に重要になってきました。富士通の場合はSPARC64はすべて自分で作っていて、コンパイラの開発者もハードウェアの設計段階から関わっており、プロセッサはこうあるべきだとか、命令を追加することもありますし、キャッシュの大きさにもついてなどもソフトウェアの観点から考えています。
アーキテクチャ関係で、ターゲットがSPARCということを伺ったんですが、x86とかではなく、あえてSPARCを使う理由はあるんですか?
まず、x86については、富士通はパソコンやPCクラスタはもちろんx86でやっているわけです。しかし、性能を出してお客さんのプログラムをとにかく速くしたいという時に、限界があるので、やっぱり、自分で作ったSPARCを作ろうということになりました。もちろん、プロセッサの開発には大きなコストがかかるので会社としての大きな判断をしています。こういう考えで開発しているので、富士通のSPARCには独自の拡張をしています。そのため、自前のコンパイラも必要になります。
もう一つ、アグレッシブに性能を出していくためだけでなく、プロセッサやコンパイラの開発を通じて技術者が育っているという面もあります。
経営的に本当に正しいのかについては、議論があるようですね。社外からも「もうやめたほうがいいんじゃないか。」とか、「そもそも、プロダクトを辞めたほうがいいんじゃないか。」とか聞こえてきます。
僕なんかは技術者として入って来てるので技術を追求したいし、だったら自分で作らなかったらおもしろくないというのがあります。仕事はおもしろいからやっているんですよね。
情報科学科でもSPARCは人気なんですよ。
やっぱり僕としては、RISCのほうがコンパイラは作りやすいんじゃないかと思います。もちろん、RISCの場合はコンパイラへの要求が高くなります。しかし、CISCだと考えられるいろんなパターンの中から、1番いいものを選ぶという作業があって、結構難しいと思います。この辺では良かったけど、この辺来たらレジスタ足りなくなったりしてかえって悪くなってしまったなんていうことは、CISCの方が大変じゃないかな。
富士通は以前、ベクトル型をやってきいて、最近はスカラー型に移行したということですが、それはコンパイラとしてはベクトル化はやりにくいということですか?
スカラーの並列化に比べて難しいかというと、そんなことはありません。少なくとも富士通では、ベクトルを始めたときに、きちんと理論だてた自動ベクトル化のロジックが組めたので、そんなに苦労せずにベクトル化できましたし、ユーザーさんの期待に応えられたと思います。細かくスカラーとベクトルの行き来をしてもオーバーヘッドはあまり大きくならず、遅くなることは非常に少ないからです。もちろん、やりすぎると遅くなるケースもありますが。ところが、並列化はそうではなくマルチスレッドのバリアなどベクトルに比べると重いので、簡単に自動並列化すると遅くなってしまう危険があります。富士通ではスカラーのマルチコアの範囲では、キャッシュをsharedキャッシュにして衝突を起こりにくくしたり、ハードウェアの機構にバリアを入れたりしてオーバーヘッドを減らそうとしています。オーバーヘッドを減らすと、マルチコアは、ベクトルに近づくわけです。だから、今でもベクトル化の技術は使っていて、現在、並列化をやっているメンバーは、以前、ベクトル化をやっていた人たちです。
だとすると、単純にベクトル型のプロセッサがそんなにたくさん売れないから、スカラー型にしたということですか?
やはり、ベクトルプロセッサを作るコストは圧倒的にかかるわけですよね。スカラーはきめ細かいアーキテクチャの工夫やソフトウェアのような比較的コストが掛かりにくいところで性能を出していますが,ベクトルはハードウェアの物量で性能を実現しているところがありますので。
今後しばらくは、スカラー型のプロセッサをたくさん並べて自動並列化をやっていくという方向でコンパイラはやっていくということですか?
そうだと思ってます。コア数はもちろん増えて行くでしょう。 32までいくのか、64、128までいくのかなぁとかはありますけど、理屈の上ではソフトから見ると同じなので。でも、実際にやってみるとそんなにたくさんはうまくいきませんとか、なにかどこかにボトルネックが見えてくるとかありそうです。さらに、PCクラスタもそうですし、ネットワークでつないで並列実行っていうのは、もちろんある話です。夢としてはそちらも自動でやりたいんですけど、まだまだ先だなと。僕が会社にいるうちは無理じゃないかなとなんとなく思っています。だから、並列言語をつくろうとしているわけです。
新しい並列言語にはベースとなる言語などはあるのですか?
ベースはFortranとCで、その拡張としてディレクティブを採用しています。超並列になると通信の問題が大きくなるのでどのような通信をするかを指定します。大規模な通信の解析は難しいですし、通信の際のオーバーヘッドなどもあるので単純に全ての部分を並列化すればいいわけでもないです。今のところは、ユーザーさんに指定していただかないと現実的ではないです。ただ、高級言語のコンパイラができた頃はプログラムをアセンブラで書いた方が速いと言っていたそうですが、現在では逐次処理の範囲ならばコンパイラに任せた方が多分速い。並列化に関してもそうなればいいと思っています。
ハードウェアの人も沼津にいらっしゃるのですか?
いいえ、川崎工場にいます。
コンパイラの開発者のハードウェアへの要求はどこから出てくるのですか?
まず、仕事の流れから説明します。スパコン系は特にそうですが、大きなセンターの商談が始まると、まず何テラFlops以上などの要件仕様が出て、さらに大抵の場合、プログラムをいただき、それを何秒で走らせられるかを各社で競います。価格と性能でどこのシステムを買っていただけるかが決まるわけです。このプロセスの中で、プログラムを必死に見てコンパイラのチューニングをし、また、アプリケーション自体のチューニングも許される場合が多いので行います。めでたく採用していただき、製品を入れた後は、大きなところでは定例会のようなものがあり、そこでいろいろな要望を受けます。お客さんはプログラムの観点から要望を出しますし、そういうのは技術者としては非常に糧になります。ハードウェアの変更はほとんど無理で、最初はアプリケーションの改良、次にコンパイラないしは、ランタイムライブラリのチューニングを行います。入札のときはそんなに密接にはお話できませんが、入ったあとは密接なコミュニケーションがあるのです。
このような活動の中で、チューニングをしているときにソフトでやっているけど、ハードがこうなっていたらもっと良いのにという発想が当然でてくるわけです。だから、そういうところから次の世代のハードウェアに対する要求事項っていうのが見えてくるわけです。
スーパーコンピュータは年間どれくらい売れていて、どういう応用で使われているのですか?
金額としては事務系のコンピュータの方が量としては多くて、それに比べると非常に小さいです。現在の不況でどうなったかはわからないですが、IDCという調査会社のレポートでは、市場の伸びは事務系の分野よりも高いという結果が出ています。お客様は、大学のセンター、JAXA、理化学研究所といった大きなユーザーさんがあります。何に使っているのかは、シミュレーションが1番多いと思います。例えば、自動車会社では車をぶつけて実験しますが、実際に行う回数を減らしてシミュレーションをしてコストダウンを図っています。航空宇宙技術なんかでは、数値風洞と言って、風洞のシミュレーションをやってます。もう少し小規模なお客様では、最近では、金融シミュレーションのような用途にも使われています。シミュレーション以外ですと、遺伝子解析などは検索に近い技術なのではないでしょうか。
富士通だとおそらくF2MC,FRシリーズといった組み込み用のコンパイラは別の部門になるんですか?
最近分社化したデバイス部門で開発していますが、関係はあります。コンパイラのベースは沼津の部隊が一番よく知っているので、FRVやマイコン系についても、量子デバイス部門と一緒に全部やってました。ただ、向こうのビジネスなので、主体はあちらにおいて、我々が協力をするという形でやってました。組み込みであっても、コンパイラ技術はそれほど変わるものではありません。
FRVになるとVLIWになると思いますが、コンパイラ側からはそういう技術に対してどう思いますか?最適化がしにくいとかありますか?
いや、そんなことはないです。縦のものが横になっただけです。富士通のベクトル並列スパコンのVPPもVLIWでした。ただ、スーパースカラーだと並べておけば、もしかするとハードウェアがひっくり返して勝手に高速化してくれるということがありますけれど、VLIWだと言った通りにしか動かないから、きちんと処理しないといけないというのはあります。しかし、結局、技術としては大して違わないと思っていますし、実際そうやってきました。はるか昔の、メインフレーム、VPぐらいの時まではそこのプロセッサ専用にコンパイラを作っていたのですが、VPPの頃にはほかのハードウェアにも共通化しようってことになりました。ある意味、理想論のところもあるんだけど、結局、コンパイラってインターフェースは一個でソースコードを解析するところはFortran,Cのように2 種類、3種類持っててそれが同じインターフェースに落として、同じ最適化をして、最後に命令に変換する時にSPARCにしたりx86にしたり、まぁ、マイコン系にしたりするという発想で作ってるんです。もちろん、ハード依存のところもあって、例えば、レジスタ割りつけなんかは絶対ハードに依存してるわけで、そこは一旦、切ってやってるんですけど。そうやって、ある意味二段階の最適化、マシン依存のCISC的なレベルでの最適化をしておいて、RISC的な中間コードにしておいてから、もう一回それを最適化すると。その中で命令のスケジューリングもやるし、キャッシュのことも全部ここでやるんですよね。そうすれば、最適化のエンジンの部分は1個でいいだろうということで作ってるんです。まぁ、ときどきそうはいかなくて、Fortran専用のルートだとか、Cで使わないからいいじゃないかというところにif FORTRAN とかってかいてありますが。理想的には、入力と出力は複数あって真ん中が一つになっているというものを作っていますし、ある程度はそれができてます。
入社当時の思い出

入社した直後からスーパーコンピュータのコンパイラを作り始めたのですか?
この会社は、昔からわりと入社時の希望をかなえてくれちゃう会社で、入社時の面接で「コンパイラをやりたい。」と言ったらすぐに、沼津に来ちゃいました。当時はスーパーコンピュータの話とかも全然知らないで、あんまり真面目に勉強してなかったですけど、コンパイラなら何やるかわかりそうだなと思って軽く言ったんですけどね。当時、FORTRANの全盛期でした。企業ではCはあまり知られていませんでした。入ってみたら、FORTRAN77が出たばっかりの頃で、やることないじゃん、もう作るものはないのではないかというのが最初の感想でした。しかし、実はVPPの一世代前のVPというマシンの丁度設計のタイミングだったので、面白いテーマに取り組めたわけです。最初はプログラムなんか書かせてもらえないし、書く状態じゃなかった。新人だったので、もちろん大事な設計もできるはずなく。入ったのは、VPの命令セットが決まったあたりだったかな。そしたら、「まず、シミュレータを作ってください。」と言われて。 VPは当時のMシリーズ、メインフレームのスカラーの上に機能拡張がついている命令セットだったので、スカラーの命令の中にベクトルの命令も入っているわけです。そのメインフレームはベクトルの命令は知らないわけですから、その命令をベクトルとして処理するようというのを全命令について作りました。あとは、割り込みのルートを作ったり、というのから始めましたね。入社1年間はそれをやっていました。それをやった後には少なくとも命令の仕様に関しては他の人よりは詳しくなりましたね。このシミュレータはハードウェアができる前に、コンパイラのテストにずいぶん役にたちました。シミュレータが終わってから、いろいろな機能がある中の自動ベクトル化の部分をやれと。まぁ、設計書は既に出来ていたので、それをだんだん詳細化していくというところから作業から入って。シミュレータはもちろんコーディングはしましたが、次の年は設計書ばかりで全然コーディングしてないんじゃないかな。 3年目になってやっと製品になるプログラムを本格的に書き始めたんです。当時は、開発スパンが非常に長かった。今はもう3ヶ月とかで作ってしまうこともあります。半年だと長い方じゃないかな、今と全然違いましたね。当時は、TSSの端末が何人かに1台しかなくて、取り合いになるわけです。基本的にはプログラムは紙に手で書いていて、そのプログラムをカードにパンチするように外注するわけです。だから、夕方に出しておくと翌日24時間後ぐらいに出来上がってくるわけです。もちろん入った後は、自分で端末からやってましたけどね。パソコンとかはもちろんまだありませんでした。

入社の時はなんでこんなところ来てしまったんだろうと思いました。コンパイラやりたいなんて言うんじゃなかったと(笑)。(沼津は自然がたくさんです。)景色は確かにいいけど。 1年先輩が遊びにきたので、連れてきて会社のまわりを走ると「俺、軽井沢で仕事したくないよ。」って言って(笑)。でも、住めば都というか、一人当たりのスペースが他の事務所よりひろいんですよね。自宅も近くにあって、住宅事情も東京に比べると圧倒的にいいわけで。
学部時代

コンパイラは学生の時から研究していたのですか?
学部卒なので、研究なんていう言葉を使うのはおこがましいんですが、コンパイラって何やってるか一番わかりやすいなっていうのと、一応、当時4年生の後半はAPLのコンパイラを作ったんですね。たまたまその時、当時の理学部1号館にいたんですが、DECのマシンが入ったときになぜかAPLのキーボードがついてたんですよ。これを使わない手はないなと。おもしろそうだと思って始めたんですよ。規模が大きくて手に負えなかったので、中途半端なところで卒業しちゃいましたけど。あの頃は(4年の)前期と後期で、ある意味、仮配属で入ったんですね。 4年生の後半は、IBMから東大に移られた山田先生という、確か当時日本語入力をメインで研究してた人だと思うんですが、そこにいました。前期は現在、金工大かな、前は会津大学の学長をやっていた國井先生のところにいたんですけど、当時、國井先生はその半年間アメリカにいたっていう(笑)ことで全く顔を見ませんでした。そこでD3の方のお手伝いをしていました。プログラムはパズルを解くプログラムなどいろいろ作ってましたが。大学で興味がでたというよりは、最初から興味があったとか、ある意味わかりやすいと思っていたとかですね。
当時、情報科学科は言語系以外はどのようなことをやっていたのですか、ハードウェアなどは?
当時は、ハードやってる人はいなかったんじゃないかな。学科長の後藤先生は兼務しておられた理研の方ではジョセフソン素子をやっているって仰っていました。後藤先生は、御自身が学生のときに画期的だったパラメトロン素子を発明した人なんですが、「僕はパラメトロンの後藤じゃないんだ、ジョセフソンの後藤なんだ」って仰ってましたけどね。どの先生が、どの研究をやっていたかはあまり覚えてないです。単に忘れてしまったのかもしれませんが、研究分野がなにかとは言ってなくて、なんとなく、お話の中から山田先生は日本語入力で、國井先生はデータベースなのねっていうのはありましたけど、これはあくまで当時の印象。アルゴリズム論はどの先生がっていうのもなかったと思います。当時は情報の講義は種類は少なくて、自分のところだけでは卒業単位が足りない。物理の講義を受けたり、数学の講義を受けたり、工学部の講義を受けに行ったり。特に、物理は同じ建物だったのもあるし、数学と物理だったら物理のほうがまだできる、といって大半は物理の講義を受けてました。ある意味、新設学科はおもしろかったけど、カリキュラムとして成立しているかというとまだまだ初期の段階でした。グラフィックスなんて興味あったけど(学科パンフレットを見つつ)こんなこと考えていなかったし、当時こんなグラフィック出せませんしね。グラフィックは当時テーマとして上がってたけど情報科学科では聞いたことはなかったですね。自然言語なんかや、今、平木さんが取り組んでおられる通信なんかもなかったと思います。かなり、数学に近いグラフなんかはやってましたね。数値計算系は情報科学にはいらっしゃらなかったなぁ。平木先生はいくつ年上か知らないんだけど、あのときから、院生の控え室に行くと今と同じかっこう、感じでいましたよ(笑)

なにしろ、2期生だったので学科の形が固まってないんですよね。それだけにおもしろかったんですけどね。物理と数学が集まってできた学科だったし、物理の実験のレポートで小柴先生の面接があったんですよ。今テレビで見るとやさしいお爺ちゃんっていう感じですが、あの頃は怖くて、殴られたわけでも、怒鳴られたわけでもないんですけど、怖いって感じでした。物理学科以外の物理系、地球とか天文とかの同じコマでやったのかな。こうやればいいデータが解析ができると言われると我々はプログラムを書いて、一緒にレポート書いてとそんなことをやっていました。真空やら放射線やら、どうして情報で実験するのかなと思いました。情報の演習ではプログラムずいぶん書かされて、プログラム自体の評価というか、アルゴリズムの評価とか解析とかは叩きこまれたとか、自然に身についたというか。今にして思うと範囲が狭かったんじゃないかなとおもいますね。でも、はじめははじめでおもしろかったですけどね。学生控え室っていうのがあって、ロッカーは当然のごとく新品なわけです。でも、あとはなんにもない。さぁ、ここの部屋を居心地よくしなくてはならないと。ふと、下を見たら中庭にソファーベッドが捨てられていたんですよ。あれもらっていいよなって、まずそれをもってきて。コーヒーを入れるにはとか、ガスがあるのでガス台をもってきたりと。そういうことを一生懸命にやってたわけですね(笑)
その辺は今と同じですね。
学部のプログラミングと企業での開発の違い

実際に企業に入って開発するのは、実験の時のプログラミングとどう違いましたか?
仕様書をきちんと書いて、テストの仕様書まで書いて、テストをすごく真面目にやってというプロセスは学生とは全然ちがいます。テストもかなりビックリしたけど、仕様書は本当にこんなにやるんだっていうのはありましたね。私のときの情報科学科の演習は1週間で課題を出さないといけないわけで、仕様書を書いてる暇なんかなくて、プログラムを書いて後からちょっと解説を書いてというので、僕は最初の1、2回はフローチャートを書いて出したら、「こんなの解説じゃない。」、って言われて、ああ確かに違うよなと思って。でも、やっぱり会社に入ったら、30年近く前ですが、まず、フローチャートを書きましょうと言ってやってるわけですよ。情報科学科は情報工学でもソフトウェア工学でもないので、あんまりそういうことはやらなかったですね。企業では分業だから隣の人とのインターフェースっていうのは非常に重要ですし、ドキュメントにしないとおそらくうまくいかないですよね。そのあと、メンテナンスが必ずありますから、そのときに自分がそこにいるかは保証の限りではないわけですよ。基本的には社内に残った人が保守しないといけないわけで、そのためにドキュメントを残しておけよということです。僕もプログラム書くのは好きでしたが、ドキュメント書くのは好きではありませんでしたから、早くプログラム書きたくて仕方なかったのを覚えています。さっさとコーディングしたいと思う人がある意味優秀なプログラマだと、少なくとも、天才的プログラマはそうだと思うんですけどね。それに、テストだって好きじゃないだろうと思うわけです。でも、企業の中はそうはいかないよと。後は、ソースコード、ドキュメントのレビューをジックリやります。私が作ったプログラムを印刷して説明していくわけです。そうすると、「ここおかしいんじゃない。」とかっていう指摘を受けるのが本来のレビュー姿です。僕の経験では多くの場合、説明している時に自分で気がつくんですよね。でも、前に人がいないと気付かないから不思議です。こういうことは、少なくとも学部の間では考えられないことでしたね。ソフトウェア工学的なことは、企業の方が真剣に取り組んでいるだろうと思いますね。
もともと、大学入る前からもともとパソコン等の情報系のものに興味があったんですか?
パソコンは存在していませんでした(笑)。当時は、マイコンって言われ始めていた時期でした。僕はコンピュータは高価なおもちゃだと思ってたんで、おもしろいおもちゃを触りたいと思っていたんですよね。当時、駒場で理系はコンピュータを扱う講義や演習はなにもなかったんですよね。文系はやってたんですよ。で、いいなぁと思ってて、情報科学科に入ればきっとなにかできるに違いないと。だから、何にも触ってないですし、触ることもできないから本も読んでないですし。情報科学科に入って最初の演習はFORTRANで書かれた100までの素数を求める、エラトステネスの篩のプログラムを一枚渡されて、ロジックの説明と、FORTRANの説明をしてくれるわけですよ。第一回の課題はこれをそのままカードにパンチして走らせてきなさいというものでした。ところが、パンチ機の電源まずどうやって入れるのって言うところから始まって、今にして思えばつまらないところですけど、それはそれで苦労したわけですよ。それをパンチして、走らせて、じゃぁ、100までじゃつまらないから1000までやってみようかとかとなるわけです。それが、自分がなにかしたプログラムを走らせた最初の経験です。その次は完全数を求めるプログラムっていうのからロジックに入り、後は、ソーティングの評価とかをやったのを覚えていますね。おもしろかったけど、結構大変でしたね。ある意味になにも教えてくれませんでした。FORTRANを90分で解説して以上FORTRANは終わりっでしたから。会社だと新人が入ると一生懸命懇切丁寧に説明しながら、俺らの時は1時間で終わっただぞって言ってましたが(笑)。 Pascalも1時間で終わりました。当時はPascalとFORTRANで、Cは後から出てきました。今にして思うと、僕はlispを全然使わなかったので、一応ルールは知ってるけど、どうやって使うか実についていないので、惜しかったなと思っています。やりたかったなと。いずれにしろ、ほとんど、教えてもらったっていう感じはなくて、みんなで伸びてったていう感じで。それが教育なのかなって、大学は全部教えてくれるところじゃないと。ロジックに対してどう考えるかっていうことを僕自身は学んだ気がします。
インタビューを終えて

富士通ではインタビューだけでなく、池田敏雄さんの業績や、古い論理回路素子や富士通のスパコンの歴史の紹介などがある池田記念室も案内していただきました。さらに、現在稼働するコンピュータとしては世界最古のものというリレー式計算機、FACOM128Bを実際に動くところを見せていただき、非常に貴重な経験になりました。電磁気によってスイッチが切り替わるパチパチという音がして、現在の計算機と違って実際に計算しているのだなというのが直感的にもわかりやすかったです。

今回インタビューを行った富士通のある沼津は、自然が豊かで、海も見える、非常に落ち着いた感じのするところでした。出来たばっかりの頃の情報科学科の話は聞いていておもしろかったですし、学科で教える内容は時代に合わせて変わっていますが、その頃も今も教え方は変わっていないのだなと思いました。堀田さんは学部の4年の時にAPLのコンパイラを作ったとおっしゃってましたが、学部の頃にそういうある程度の大きさのプログラムを組むというのは大事だと感じました。いろいろと至らないところもあったと思いますが、気さくに受け答えしてくださった堀田さん、有難うございました。