約１週間かけて、いろいろな資料を用意した。
開発の勉強会の二回目が行われる。
もう、諦めた。十倉さんも、あの後、謝罪してくれたが、もうやってみよう。実際に、就職に役立つ知識ではないが、まったく無意味な知識でも無いだろう。
特別授業の教室は、前回と違って、パソコンルームで行われる。
まずは、電脳倶楽部が策定した仕様とスケジュールが提示され、説明が行われる。
うーん。無理目なスケジュールになっている。機能も詰め込みすぎている。
指摘するのは簡単だ。
戸松先生と目が合う。
「篠崎。何かあるのか？」
「はぁ・・・。スケジュールですが、戸松先生が詰め込んだのですか？」
「ん？どういうことだ？」
「いえ、あまりにも綺麗にできているので、気になったのです」
「言っている意味がわからない」
「全てが、予定通りに進む前提で作られています」
「当然だろう？」
「えぇ問題が発生しなければ、良いのですが、どこかが遅れたら、全部が遅れます。やはり機能を削ってバッファーを作るべきです」
「そうなのか？」
「はい。他にも、テスト期間が短すぎます。バグがない前提でテスト期間が作られています」
「うーん」
「今の倍は欲しいですね。バグを修正する時間も必要になります。開発期間とテスト期間を同等にしてもいいと思います」
「それだと、テスト期間が多くなりすぎないか？」
「短くして、キツキツで作業をしたいのなら、今のままでもいいと思いますが、学校の作業でデスマは止めたほうがいい。余裕があると思って作ったスケジュールをさらに倍にする位の気持ちでちょうどいいと思います」
「それだと、仕様を策定した機能の半分程度しか実装出来ないぞ？」
「戸松先生。”半分も”実装ができるのです。それに、テスト期間中に新しい機能の実装を始めれば、テストが終わる頃には、次の機能のテストが開始できます」
「え？」
「一度に作る必要はないでしょ？そもそも、無理です。最低限の機能でサービスインして、作り上げていくのが健全です」
結局、戸松先生に質問される形で、ダメ出しをしてしまった。
余裕を持ったスケジュールにしておかないと、普通科の教諭たちが何を言ってくるのかわからない。予定よりも、早く進んだのなら文句は言われないが、予定よりも遅れると、文句を言われる可能性がある。成果物が同じなら、圧倒的に前者のほうが問題に発展する可能性が低い。
「そう言っても・・・」
「だから、仕様は、最終的に目指す所まで作って、今期は”ここまで”とかにすればいいと思います」
「ん？」
「最後の形が見えないから、文句を言い出す人たちが居るのです。だったら、目標とする形が見えるようにして、文句があるなら、金と人材を寄越せと言えばいいのです。予算が着いて、初めて外部を頼ってもいいのでは？」
「それだと、計画の変更とか難しくないか？」
「だから、スケジュールを短期間で区切るのです。リリースのタイミングを多くして、ユーザからの意見を聞いて、目標の形を修正していくのです」
「・・・。そうか、それなら問題はなさそうだな。年度末にして、第一弾をリリースして・・・。来期から利用すると考えて、機能を絞り込んだスケジュールを考えるか？」
「はい。導入できる人員を考えれば、その辺りが無難だと思います。機能分けをする時に、他との関連性や難易度も考えるとスケジュールが組みやすいですし、進んだ時や、遅れた時に、組み換えが簡単になります」
「難易度か、考えていなかったな・・・。でも、篠崎、電脳倶楽部の技量が上がれば、難易度も変わってこないか？」
「指標を作ればいいと思いますよ。”技術的に難しい物”/”作り方が想像できる物”/”作ったことがある物”/”組み込んである物”/”作りたくない物”に、区分すれば、難易度は定義できると思います」
戸松先生は、電脳倶楽部の面々を見て、やってみるかと頷いている。メンバーたちも、考えてみると言っているので、任せる。来週、もう一度、発表して話をすることになった。
勉強会のメンバーは、なぜか増えていた。
１６名だったと思ったが、新しく３名追加されて、電脳倶楽部から５名が参加することになった。一人と勉強会をするのも、２４名と勉強会をするのも、さほど違いはない。問題はない。面倒だけど、”問題がない”と考えないと、テンションだけが下がっていく。だから、問題はない。
まずは、先週の質問に対する答えを提示する。
持ってきた、ノートパソコンをプロジェクタに繋いだ。
簡単に、説明をする。
Javaで作られたプログラムが動作する環境にしてある。
PHPがコマンドラインで動作する環境にしてある。
C#で作られたプログラムが動作する環境にしてある。
他に、C言語やDelphiやPythonやJuliaやRubyの環境も用意してある。完全に、同じではないが、その辺りは目を瞑ってもらおう。
言語の特性を理解する為に用意しただけだ。
説明をした後で、各言語で作成したプログラムを見せる。
簡単に、プログラムの説明を行う。
１～１０万までの素数を表示するプログラムだ。ソースコードを簡単に説明する。
「篠崎！」
「なんでしょう？」
「なんとなく、俺たちも言語の違いを考えてみたが、今、お前が見せたコードは、殆ど同じに見えるぞ？」
「そうですね。ある程度は、同じに見えるように作りました。言語が違っても、大筋には違いが出ないので似てきます」
「そうなのか？」
「はい。『代入して計算して比較して繰り返す。結果を出力する』のは基本ですから、大きく違いません」
「・・・」
「次に、実行する為のスクリプトですが、実行の開始に時刻を保存して、プログラムの終了で、かかった時間を計算して表示します。ただ、言語の実行環境で、起動方法に違いがあります。その辺りは、こういう物だと考えて下さい」
それから、各プログラムを実行していく、テストはしてあるので、結果は同じになるが、実行速度に差が出ている。
１回目の実行と２回目の実行で速度が上がる言語も多い。
「篠崎。なんで、こんなに結果が違うのだ？１０倍以上も遅い言語もあるよな？」
「あぁその話は、次と次の結果を見てからにしましょう」
「わかった」
ノートパソコンのOSを切り替える。
次は、Linuxだ。全部が動くわけではないので、動かない物は動かないと説明して、同じように動かしていく。
そして、最後は、Android タブレットを取り出して、動く物を動かす。何もかもが違うので時間の計測はしていない。言語で、動作が違うという認識をしてもらう。
「篠崎、iPhoneでは動かないのか？」
「あぁある程度は動きますが、iPhoneは少しだけ面倒な手続きが必要なので、作ってきていません。興味があるのなら、作り方を教えます」
「そうか、わかった。なかったのが不思議だっただけだ」
「各、OSで言語別に同じ結果になるプログラムを実行しました。大まかにですが、特性がわかったと思います」
「篠崎。でも、遅い言語にも理由があるのだろう？」
「そうですね。スクリプト言語は基本的に遅いです。次に、中間バイナリを生成する言語。そして、コンパイル言語です」
「それらの違いは？」
「スクリプト言語は、１行１行解釈されて実行されます。中間バイナリ言語は、実行に必要な部分を切り離して、OSに依存しない部分だけをコンパイルで生成して実行されます。コンパイルは、OSに依存する部分も組み込まれてから実行されます」
言い方は乱暴だが、この程度の認識で問題はない。
「そうか、そうなると、スクリプトが遅くて、コンパイル言語が早いのだな」
「そう考えて居れば、大きく外しません。OSに依存すればするほど実行速度が早くて、OSに依存しない言語は速度が遅くなると考えて下さい」
「わかった。それで適材適所になってくるのだな」
「はい。それは、各言語が持っている特徴にも繋がります」
やっと、今日の本題に入ることができる。
言語の得手、不得手を説明しなければ、開発の勉強に進めない。
