約１週間かけて、いろいろな資料(プログラム)を用意した。

　開発の勉強会の二回目が行われる。
　もう、諦めた。十倉さんも、あの後、謝罪してくれたが、もうやってみよう。実際に、就職に役立つ知識ではないが、まったく無意味な知識でも無いだろう。

　特別授業の教室は、前回と違って、パソコンルームで行われる。

　まずは、電脳倶楽部が策定した仕様とスケジュールが提示され、説明が行われる。

　うーん。無理目なスケジュールになっている。機能も詰め込みすぎている。

　指摘するのは簡単だ。

　戸松先生と目が合う。

「篠崎。何かあるのか？」

「はぁ・・・。スケジュールですが、戸松先生が詰め込んだのですか？」

「ん？どういうことだ？」

「いえ、あまりにも綺麗にできているので、気になったのです」

「言っている意味がわからない」

「全てが、予定通りに進む前提で作られています」

「当然だろう？」

「えぇ問題が発生しなければ、良いのですが、どこかが遅れたら、全部が遅れます。やはり機能を削ってバッファーを作るべきです」

「そうなのか？」

「はい。他にも、テスト期間が短すぎます。バグがない前提でテスト期間が作られています」

「うーん」

「今の倍は欲しいですね。バグを修正する時間も必要になります。開発期間とテスト期間を同等にしてもいいと思います」

「それだと、テスト期間が多くなりすぎないか？」

「短くして、キツキツで作業をしたいのなら、今のままでもいいと思いますが、学校の作業でデスマは止めたほうがいい。余裕があると思って作ったスケジュールをさらに倍にする位の気持ちでちょうどいいと思います」

「それだと、仕様を策定した機能の半分程度しか実装出来ないぞ？」

「戸松先生。”半分も”実装ができるのです。それに、テスト期間中に新しい機能の実装を始めれば、テストが終わる頃には、次の機能のテストが開始できます」

「え？」

「一度に作る必要はないでしょ？そもそも、無理です。最低限の機能でサービスインして、作り上げていくのが健全です」

　結局、戸松先生に質問される形で、ダメ出しをしてしまった。
　余裕を持ったスケジュールにしておかないと、普通科の教諭たちが何を言ってくるのかわからない。予定よりも、早く進んだのなら文句は言われないが、予定よりも遅れると、文句を言われる可能性がある。成果物が同じなら、圧倒的に前者のほうが問題に発展する可能性が低い。

「そう言っても・・・」

「だから、仕様は、最終的に目指す所まで作って、今期は”ここまで”とかにすればいいと思います」

「ん？」

「最後の形が見えないから、文句を言い出す人たちが居るのです。だったら、目標とする形が見えるようにして、文句があるなら、金と人材を寄越せと言えばいいのです。予算が着いて、初めて外部を頼ってもいいのでは？」

「それだと、計画の変更とか難しくないか？」

「だから、スケジュールを短期間で区切るのです。リリースのタイミングを多くして、ユーザからの意見を聞いて、目標の形を修正していくのです」

「・・・。そうか、それなら問題はなさそうだな。年度末にして、第一弾をリリースして・・・。来期から利用すると考えて、機能を絞り込んだスケジュールを考えるか？」

「はい。導入できる人員を考えれば、その辺りが無難だと思います。機能分けをする時に、他との関連性や難易度も考えるとスケジュールが組みやすいですし、進んだ時や、遅れた時に、組み換えが簡単になります」

「難易度か、考えていなかったな・・・。でも、篠崎、電脳倶楽部の技量が上がれば、難易度も変わってこないか？」

「指標を作ればいいと思いますよ。”技術的に難しい物”/”作り方が想像できる物”/”作ったことがある物”/”組み込んである物”/”作りたくない物”に、区分すれば、難易度は定義できると思います」

　戸松先生は、電脳倶楽部の面々を見て、やってみるかと頷いている。メンバーたちも、考えてみると言っているので、任せる。来週、もう一度、発表して話をすることになった。

　勉強会のメンバーは、なぜか増えていた。
　１６名だったと思ったが、新しく３名追加されて、電脳倶楽部から５名が参加することになった。一人と勉強会をするのも、２４名と勉強会をするのも、さほど違いはない。問題はない。面倒だけど、”問題がない”と考えないと、テンションだけが下がっていく。だから、問題はない。

　まずは、先週の質問に対する答えを提示する。
　持ってきた、ノートパソコンをプロジェクタに繋いだ。

　簡単に、説明をする。

　Javaで作られたプログラムが動作する環境にしてある。
　PHPがコマンドラインで動作する環境にしてある。
　C#で作られたプログラムが動作する環境にしてある。

　他に、C言語やDelphiやPythonやJuliaやRubyの環境も用意してある。完全に、同じではないが、その辺りは目を瞑ってもらおう。
　言語の特性を理解する為に用意しただけだ。

　説明をした後で、各言語で作成したプログラムを見せる。
　簡単に、プログラムの説明を行う。

　１～１０万までの素数を表示するプログラムだ。ソースコードを簡単に説明する。

「篠崎！」

「なんでしょう？」

「なんとなく、俺たちも言語の違いを考えてみたが、今、お前が見せたコードは、殆ど同じに見えるぞ？」

「そうですね。ある程度は、同じに見えるように作りました。言語が違っても、大筋には違いが出ないので似てきます」

「そうなのか？」

「はい。『代入して計算して比較して繰り返す。結果を出力する』のは基本ですから、大きく違いません」

「・・・」

「次に、実行する為のスクリプトですが、実行の開始に時刻を保存して、プログラムの終了で、かかった時間を計算して表示します。ただ、言語の実行環境で、起動方法に違いがあります。その辺りは、こういう物だと考えて下さい」

　それから、各プログラムを実行していく、テストはしてあるので、結果は同じになるが、実行速度に差が出ている。
　１回目の実行と２回目の実行で速度が上がる言語も多い。

「篠崎。なんで、こんなに結果が違うのだ？１０倍以上も遅い言語もあるよな？」

「あぁその話は、次と次の結果を見てからにしましょう」

「わかった」

　ノートパソコンのOSを切り替える。
　次は、Linuxだ。全部が動くわけではないので、動かない物は動かないと説明して、同じように動かしていく。

　そして、最後は、Android タブレットを取り出して、動く物を動かす。何もかもが違うので時間の計測はしていない。言語で、動作が違うという認識をしてもらう。

「篠崎、iPhoneでは動かないのか？」

「あぁある程度は動きますが、iPhoneは少しだけ面倒な手続きが必要なので、作ってきていません。興味があるのなら、作り方を教えます」

「そうか、わかった。なかったのが不思議だっただけだ」

「各、OSで言語別に同じ結果になるプログラムを実行しました。大まかにですが、特性がわかったと思います」

「篠崎。でも、遅い言語にも理由があるのだろう？」

「そうですね。スクリプト言語は基本的に遅いです。次に、中間バイナリを生成する言語。そして、コンパイル言語です」

「それらの違いは？」

「スクリプト言語は、１行１行解釈されて実行されます。中間バイナリ言語は、実行に必要な部分を切り離して、OSに依存しない部分だけをコンパイルで生成して実行されます。コンパイルは、OSに依存する部分も組み込まれてから実行されます」

　言い方は乱暴だが、この程度の認識で問題はない。

「そうか、そうなると、スクリプトが遅くて、コンパイル言語が早いのだな」

「そう考えて居れば、大きく外しません。OSに依存すればするほど実行速度が早くて、OSに依存しない言語は速度が遅くなると考えて下さい」

「わかった。それで適材適所になってくるのだな」

「はい。それは、各言語が持っている特徴にも繋がります」

　やっと、今日の本題に入ることができる。
　言語の得手、不得手を説明しなければ、開発の勉強に進めない。