Moonmile Solutions Blog

上板橋あいキッズで、去年（2017年4月）から隔週でプログラミング教室を担当している。板橋の「あいキッズ」というのは、いわゆる「学童」で共働きの家の子供が親が帰ってくるまで「預け」られる場所になっている。預けられるとはいっても、昨今では小学生の半分の親は共働きなので、当然のことながら児童の半分はあいキッズにやってくる、ってなわけで、昔とは違ってかなりの人数が集まってくるわけだ。板橋区の「あいキッズ」制度は、学童単位でそれぞれの民間業者に委託しているので、小学校によってあいキッズ内で行う「プログラム」に差がある（それぞれの業者が何らかを企画するためだ）。そんな中で、上板橋あいキッズを担当している放課後NPOさんから話を請けて「プログラミング教室」ってのを隔週で1時間ほどやっている。

ちなみに無償ではなく報酬は貰っている。「子供のためだから」といってボランティアでは続かないと思われたのと（続く人もいるんだけど、どうも私は続かない）、実際なにがしかの時間が掛かっているためだ。十分とは言えないし、半分ボランティアな感じなんだけど、持ち出さないようには注意している（苦笑）。

以下、いくつか去年の話を書き留めておこう

ノートパソコンを用意して貰う

特に Scratch がという訳でもなかったのだが、念頭にはあったのと、できれば Python とかを教えたかったのでノート PC を用意して貰うことにした。ひとり1台が望ましいのだが、最低限でも2人で1台が使えるようにしたい。募集人数もそれに絞って欲しい旨を伝えて、中古のノート PC を購入して貰う。予算が潤沢にあれば（都なり区なりから出して欲しいよね）新品とかを買えるんだろうが、そうもいかないので、中古で1.5万円程度の Windows 7 を購入して貰う。これ、こちらで代理で探してもいいのだけど、その費用は貰っていないのであいキッズ側で探して購入して貰っている。

最初は8台からスタートしたと思う。機種はばらばらだが、ほどよく大き目のノートPCが用意できて、無線LANを使えるようにする。…が、ここで問題があって、プログラミング教室をやる部屋があいキッズ内の無線が届かない位置にになっていて、一応ブースターを購入＆設定して貰ったものの、あまり接続状態がよくない。なので、初めの2回はブラウザでの Scratch だったが、急遽ダウンロード版の Scratch を使うことにする。学校の教室で Scratch をするときも同じ問題が発生するし、無線ルータの状態によっては人数分（ひとクラス30名とか）一斉に繋げると接続状態が確保できなかったりするので、今後も課題になる。

ただし、ネットワークが全然駄目というわけではなくて、個人持ちの無線ルータの設定をしているので本家の scratch.mit.edu に繋げないこともない。ただし、一斉に繋げたり大量にダウンロードするとパンクしてしまうので、「スクラッチのサイトだけ」という限定にしている。つまり、Youtube とかは駄目。即座に、プチンと切ることにしている。そこはルールだからね。

実に騒がしく統率できない

あいキッズなので、3年生から6年生までを対象にしている。初年度ということ双方ノウハウがないので、半年ぐらいは様子見な感じで進めていた。ちなみに、本来は1年単位の契約なんだけど、撤退しやすいように半年契約にして貰っている。

私自身、社内研修とか勉強会での発表とかをこなしているので、解説とか講師っぽいところは慣れているのだけど、蓋を開けてみれば小学生3-6年生には通用しなかった。というか、学校の教室で教えるようにはいかんわ、これは、な感じなスタートであった。これにはいくつか理由があるのだけど、いわゆる発達障碍児が3人ほど含まれていたのと、プログラミングのような「面白そうな興味のあるもの」だと騒がしくなるのは当然で運動部のようにはいかない。授業っぽくやろうかという話もあったのだが、到底無理なことがわかったので、それぞれで自由にやらせる/やってもらうことにした。

最初の思惑としては、プリントを配って解説をして、それに沿ってスクラッチで作ってみる、そして半分は遊びとか思っていたものの、無理無理。たぶん、中学生か高校生ならば「学習するスタイル」ができているのだが、小学生ではまだまだで、騒がしいことこの上ない。

実はプログラミング教室に参加する場合には何がかのお金を取ることになっている（300円ぐらいだったか）。印刷物の問題もあるけど、参加人数を制限したかったのと、なにがしかのお金が払って「プログラミング」するならば、親もなんらかの形で真剣になるだろうという思惑であるが、そうなったかどうかは定かではない。ちなみに、ひとり300円何某の分は私は貰っていない。印刷物のプリントアウトはあいキッズ側に任せたかったのと、講師料がちょっと増えたぐらいでは半分ボランティなのは変わらないからだ。まあ、気分的にも楽なので。

そんな訳で、プログラミング教室に出席させるにはなにがしかのお金を払っているので、プリント代として返そうという訳である（これは、区への申請を通すためでもある）。スクラッチの説明やらブロックの説明やらを書いたプリントを私が2,3枚で作って、隔週で印刷して貰っている。

半年過ぎたら、人数が半減した

前期（10月頃）までは、16名体制だったのだが、後半になって8名位に減った。いわゆる、面白くないからやめたのだが（途中でおもしろくないから来なくなった子もいる）…まあ、営利業務ではないので、半分に減ってちょうどパソコンの台数と子供の数が等しくなったので結果オーライというところである。

おもしろくないの理由のひとつとして、課題が簡単すぎて何をやっていいのかわからない子と、課題をほっぽっといて絵とか好きにやっていきた子が、混在している。16名は抱えきれない（補佐で1人ついて貰っているけど）のと、本格的なプログラミング教室（月謝が1万円ぐらいのやつとか）や CodeDojo とは違うので、子どものモチベーションは様々だ。そして、あいキッズ側の主目的としては「プログラミングを学ぶ」のではなく、「安全に子供を預かる」なので、それに沿うことにしている。ほかにも、将棋教室とか音楽教室とかサッカー教室なんてのもあるので、プログラミングだけではないのだから、気に入らなかったら他のところで遊べばよい。

と割り切ることにして、後半は

• 20分ぐらいだけ課題をやる
• 残りの時間は、Scratch で遊ぶ

ことにした。ちなみに、課題は Scratch の簡単なプログラムをあらかじめ私が書いておいて、それ改造するという手順にしていた。いわゆるリミックスという奴なのだけど、今年はサンプルを作ることをやめている。というのも、サンプルを作るとそれを動かすだけで満足しちゃうんだよね。まあ、ゲームを動かすとかそれはそれでもパソコンに触れる（キーボードを打つ、マウスを動かす）こと習熟できるのだけど、もうちょっと自分だけでやってほしいのと、個々人で学習度合いは異なるのだが、子ども同士で教えあうほうが良いみたいだから。

今年は課題シートを作った

なんやかやと、去年はサンプルコードを作っていたので、かなり蓄積ができた。遊ぶ子はそれを眺めて貰うとして、自分で学習したい子のために課題シートを作ってみた。プールとか縄跳びの級みたいに、ちょっとずつ目標をこなしていく感じ。

これも、集まった子たちの性格にもよるんだろうけど、男子は完全無視というか適当にぱらぱらやって飽きてしまって Scratch ゲームを探してやっている（野球とバブルを消すゲームがブームだ）が、女子3名が熱心に課題をこなしているという具合だ。そこは男女の性格があるのかどうかわからないし、5年生の男子はプログラムが初めてなので熱心にブロックを積み上げているし、4年生の子は既に Scratch を知っているので勝手に拡張してあれこれやっている。まあ、それはそれでよい。

ちなみに、プログラミング教室の子ども面子はごっそりと入れ変わっていて、また最初から Scratch でということにしている。まあ、隔週だし、ほどよく出来たら家でもできるしね。あと、6年生は卒業してしまうし、5年生は中学受験があってというパターンもある。なので、1年周期で考えるといいんじゃないかと思う。

ちなみに、去年と今年のサンプルは 1-1 矢印キーで上下左右 な感じで作っている。去年の一番人気は いらいらボール だった。

Scratch 以外を導入したい

去年からずっとタイミングを見計らっているのだけど、Arduino か Python を導入したいとは思っている。のだが、それは「大人の都合」でしかなくって、子どもの興味/楽しみからしたら隔週でノートPC使って Scratch ゲームで遊ぶほうが楽しいかもしれない。

と、去年の最後に Arduino とサーボモーターを使った電子工作モノを持っていたところ、6年生の子が Arduino IDE でバシバシとコードを打っていたんだよね。一度、書いてあるものを写経っぽくキーボードで打ち込むのは、それはそれで楽しい作業らしい。そう、昔 BASIC マガジンからマシンコードを打ち込んだ感じとか、N88Basic のゲームを雑誌から打ち込んでいる感覚なのかもしれない。

なので、1,2台に Arduino IDE を入れて、電子工作ができるコーナーを作るのもよいだろう。手元には Aliexpress で購入した互換 Arduino があるし、ブレッドボードとかLEDとか妙に大量に手元にあるので。

予算さえあれば、新規作成 or 完全移植してしまうのがベターなのだが、多くの場合予算の関係で VB6 の業務アプリをそのまま使い続けることがある。旧来の PC（Windows 2000やXPも含む）にインストールされている VB6 の業務アプリを専用機器のまま使う（あるいは、PC から吸い上げて仮想モード内のみで使う）方法もあるのだが、いくつかのネックがある。

• 既存バグが解消されない
• 新規システムと接続できない（修正できない）
• 既存PCの CPU 速度に引っ張られて遅い

こともあり、 VB6 の業務アプリから何らかの形で引っ越したいところなのだが、予算がない、あるいは既存の業務アプリが複雑怪奇すぎるための引っ越しの予算が掛かかるかもしれない、という理由から、なんとか既存 VB6 コードを弄ろうとする。それは試算は試算なのだから、工場の機械よろしく使い潰すのがベターともいえる。

で、まったく移行予算が取れない場合は論外なのだが（社内等で VB6 のまま弄るしかない）、なんらかの予算が取れれば移行を外注することも可能ではないか？…という「仮定」のもとに考察してみる。

移行先のフレームワークを考える

VB6 の業務アプリの場合、C/S 方式が主なものになる。SQL Server か Acesss にデータを集めるために（当時の予算枠の具合で SQL Server か Access かが決まってくる）、ODBC, RDO, ADO を使って VB6 からデータベースサーバーへアクセスする。ユーザーが入力する画面では、旧文化オリエントのコントロール、スプレッドシートが使われていることが多い。実際、2002年頃に VB.NET が出てから、VB6 から VB.NET へ移行するために、各種の既存コントロールを .NET 化させたものが発売されている。ただし、VB のコンバートツールがあるものの、これらの .NET 用のコントロールまで網羅してくれてはいない。あくまで標準的なコントロールのコンバートのみとなり、スプレッドシートでかなりの部分をあれこれしている場合には、自動コンバートしたときにもアレコレしないといけないという「手間」が掛かってくる。イコール、移行予算が跳ね上がるのである。

また、2002年当時であれば、VB.NET や .NET の業務アプリも素朴なフレームワークなものが多かったのだが、今となっては、VB6 で作ったフレームワークをそのまま VB.NET に持って来るとコーディングの効率の悪さやメンテナンス性の悪さも引きずってしまう可能性が高い。たとえば、RDO や ADO で延々と SQL を書いている部分は、今であれば LINQ に直してしまうのが望ましい。特に Entity Framework と組み合わせてしまうと、INSERT/DELETE/UPDATE のコードはほぼ1行で済んでしまう。

また、当時から PC での C/S アプリをブラウザ形式の WEB アプリにすることが盛んであった。失敗には終わったが、Java アプレットや Siverlight、Flex のようなブラウザ上でのコンポーネントに移行してしまうというパターンもいくつかある。となると、既存の VB6 の C/S 形式のアプリを、何も考えずに C/S に直すというのもちょっと問題がある。潤沢ではない限られた移行予算となる場合は、

• 移行時のコード量が、元のコードよりも大幅に減り、開発時間を減らす。
• 移行時のテスト期間を何らかのツールを使って、大幅に削減できる。

という点に注視する必要がある。たとえば、移行コード量が移行前のものと同じでしかないのであれば、開発期間も同じぐらいかかり、単純に同じ程度の開発/移行コストが掛かるという見積もりになる。移行予算が潤沢に取れればよいが、そうもいかないであろう。IT 業者としては、新しい機能を盛り込むという理由を付けて、それなりの予算を取りたいところであるが、移行を頼む側から言えば、「同じ機能を実装してくれればよい」ので、余分に予算を取りたいわけではない。ある意味では、移行前も移行後も「同じ機能」でしかないので、できることなればい移行はゼロ円で済ませたいところなのだ。

一般的にソフトウェアは、劣化しないものとされているが、そういう意味では長期でソフトウェアを資産とするには、経年劣化があり資産価値がゼロになるということだ。このあたり、IT業者も非IT業者もあまり真面目に考えていない。

なので、旧来の VB6 の業務アプリは、OS がサポートから外されている、既存バグを直す人がいなくなっている、という理由から新しい業務アプリに移行するのが主な理由になる。そうなると、既存の VB6 と使用感は変わらないほうがよい。つまりは、「既存の VB6 アプリを Xamarin でタブレットアプリに移行しませんか？」というのはムダである。できることなれば、そのままでいいのだ。既存の不具合は直したいところだけど。

そうなると、移行先のフレームワークは限られてくる。ユーザーの特に新しくない使用感に合わせるためには、

• VB6 業務アプリで C/S 風に使える

というのがベターである。この場合、ブラウザでぽちぽち入力するのも許容範囲であれば、

• 現状の C/S をそのままのシステム移行
• 内部で Web API を利用する C/S 方式へ移行
• ブラウザ方式に移行

というパターンに落ち着く。既存の VB6 では RDO/ADO 等が使われているが、C/S 方式であっても EF+LINQ を利用する（コード量やテスト効率を含めて）、あるいは C/S でストアドプロシージャ等が使われていれば Web API/REST に移行するのもよいだろう。画面が多少パタパタしてもよいのでれば、HTMLを使ったブラウザアプリ（ASP.NET、PHP など）でも構わない。少なくとも、既存の C/S 方式をそのまま自動コードのコンバーターを使って移行するのは得策とはいえない。

移行先のプログラム言語を考える

2002年当時、VB6 から自動コンバートすると VB.NET のコードが出力される。今でもそうだけど、VB6 から C# へのコンバートはされない。先の理由から、自動コンバート自体おすすめできないので、なんらかの手作業による移行が必要になる。手作業であるから、移行できるコード量と、移行後のコード量というのが開発/移行コストに大きくかかわってくる。

既存の VB6 のコードで、標準モジュール（いわゆるライブラリ）が多ければ、*.bas なコードをそのまま VB.NET に持ってきても良いだろう。モジュールのままでもよいし、適当なユーティリティクラスでラップしてしまってもよい。特に複雑なロジックが入っているのであれば、*.bas なコードをそのまま流用できるならば、移行的にはかなり楽になる。

…ハズなのだが、実は、VB6 業務アプリでロジックが重要ということはあまりない。科学計算を必要とするとか、ブラックボックス的な業務ロジックを組む場合には、既に C++ であったり、C# に移行してしまったり、ストアドプロシージャで整理されていたりするので、VB6 自体には *.bas で移行する部分はほとんどないといってよい。*.bas なコードを眺めると、文字列の編集だとかデータのコンバートだとか、いまであれば .NET クラスライブラリに入っていそうなものばかりである。なので、VB6 だから VB.NET が有利である、というプログラム言語が同じであるというメリットはかなり低い。

そうなると、プログラム言語は、C# であっても VB.NET であっても構わない。C# の場合 VB6 から IF文や FOR文を移行するときにかなり書き替えなければいけないのだが、LINQを使うとかラムダ式をつかうとかイベントを多用するとか、を考えると VB の冗長なところが面倒だったりする。

なので、移行先のプログラム言語は、プログラマ自身が得意と思われる（チームが得意と思われる）言語がよい。C# か VB.NET のどちらを選んでもよい。まして、ブラウザアプリに切り替えてしまうのであれば、PHP でも十分なはずだ。

データベースを考える

C/S 方式の場合、サーバーにデータベースを据えることが多い。実際、VB6 での業務アプリの場合はサーバー側は十中八九 SQL Server となる。SQL Server のカラム名が日本語であったり、ひとつのテーブルのカラム数が50位あったり、正規化が不十分だったりすることは多いのだが、実は、データーベースの寿命はデスクトップアプリのそれよりも長い。

となれば、データベースの構造は、目をつぶってそのまま使うのひとつの方法である。よほどひどいモノでない限り、SQL Server のものを SQL Server のまま扱うのがよいだろう。このほうが EF + LINQ との相性もよいからだ。

ただし、EF を使うときに制限があり、テーブルに「主キーがひとつ」必要になる。LINQ が主キーを頼りに SaveChange するためなんだが、これはADO.NET Model のデザイン対象となるデータベースを仮に作ってしまい、主キーを付けることで回避できる。

印刷/帳票機能を移行する

旧来の VB6 では印刷機能が貧弱であったため、旧文化オリエントのスプレッドシートやレポートツールを使っていることが多いのだが、現在もそれを使い続けないとけない理由はない。

• PDF に直接出力する
• Excel や Word に出力する
• HTML形式で出力する

最終的に紙に印刷するにしても、.NET から PDF に出力するライブラリはたくさんある。データをリスト形式で印刷するならば、HTML 形式を通して印刷してもよいだろう。

また、Excel や Word であらかじめテンプレートを作っておいて、データを埋め込む方法もできる。こうすると、微妙なフォントの大きさや印刷位置の調節をあらかじめ Excel や Word 上で確認することができる。

移行時の予算を考える

先に示した通り、現状の機能を移行する「だけ」なので、発注側にとって移行コストはゼロ円が望ましい。しかし、実際のとこころは資産価値が減少するのであるから、使い続けるためにはなんらかのコストを掛けるのは否めないというところだろう。

目安として、移行コストは新規開発の予算の半分から1/3といったところだろう。これは、機能はそのままでの移行案件の場合、

• 要件定義、設計工程を省くことが可能
• テスト工程で、正しい動作（既存の業務アプリ）が確認できる

ことになるためだ。多少の既存バグを修正する場合はよいのだが、移行時に機能追加をする場合には、その分のコストは別途見積もるのがよい。

また、これ以下の予算しか取れないばばあいは、コードを修正するような移行は諦めて、仮想環境への移行など延命処置に切り替える。この場合、当然のことながら VB6 の内部コードを弄ることはしないので、既存バグは既存バグのまま残ることになる。どちらを選択するかは顧客が選ぶことなる。

移行スケジュールを考える

大抵の IT プロジェクトの場合、予算が決まればスケジュールが決まる（人月で割るから）なのだが、VB6 からの移行の場合は、それは当てはまらない。というのも、単純に安めの移行予算を人月で割ってしまうと、超短期なスケジュールになってしまい納期遅延が必至になってしまうからだ。なので、移行スケジュールは、予算とは関係なく3か月から半年程度取ってしまうのがベターだ。

半年のスケジュールとなると、通常開発であれば（中小企業にとっては）相当な金額になってしまうものだが、実はフルタイムで移行プロジェクトに関わらなくてもよい。いや、むしろフルタイムで関わってしまうほうが移行プロジェクトのリスクが高くなってしまうとも云える。

プロジェクトの各タスク/WBS/チケットを出した後は、適当に順番にこなしていくのが移行プロジェクトを推進するときのノウハウになる。というのも、機能だけ移行する場合は、機能追加などの要件の調査や概要の再設計などが必要ないので、一種のウォーターフォール的な開発にバラすことができる。つまり、ひとつのチケットに対していつ開始していつ終了しても全体コストが変わらないパターンとなる。

適用条件としては、

• 大幅な機能追加がないこと。「移行」だけに専念でき、要件定義、設計はそのままとする。
• 既存のシステムが正常に動く（既存バグは除く）こと。

ということになる。この範囲であれば、顧客との交渉を減らすことのができ所謂コミュニケーションコストを減らせる。そして、週報等も省略し、適度なマイルストーンのみを配置する。全体的に緩くスケジュールを組み、別のプロジェクトと平行にこなす（保守プロジェクトとか）ことにより、チケット駆動開発が有効に働く。

これらの条件が揃ったときに「移行プロジェクト」の成功率は格段にあがる。