第九話 開発支援
開発に参加する人数を聞いたら、十倉さんと安池さんを除くと、合計で１６名。そうなると、２つのチームに分けるので、機能を８つ作る必要がある。
十倉さんと安池さんには、ランチャー機能を作ってもらう。パフォーマンスチェックはそれほど難しくはない。電脳倶楽部が頑張った結果。メモリの使用率やCPUの負荷率まで取得できるようになっている。
パフォーマンスチェックの機能
・APIの応答時間
・データベースの応答時間
・APIサーバのメモリ使用率
・データベースサーバのメモリ使用率
・APIサーバのデータ領域の空き領域
・データベースサーバのデータ領域の空き領域
・APIサーバのCPU負荷率
・データベースサーバのCPU負荷率
一つ一つをフォームで作ってもらう。ランチャーから起動するようにすればいい。
設定ファイルやフォームの位置/サイズの保存は、サンプルを作って渡せばいいだろう。
死活管理も同じにする。
使うAPIを同じにしておけばいい。
パフォーマンスチェックは、履歴を残せるようにしておく。死活管理は、閾値を設定して下回るか、上回ったらアラームで知らせる。電脳倶楽部の面々にメールを飛ばせるようにすればいい。メーリングリストを作成して、アラームメールを送付すればいいだろう。学校内で利用するCRMが出来てきたら、アラームを自動的に登録できるようにしておけば、対応状況も判断しやすい。
ランチャーは、ボタンを並べるだけで良いので、難しくはないだろう。
画面の設計も簡単にしておこう。コントロールの配置だけ行っておけばいいだろう。
パフォーマンス確認のフォームは、データの表示にはグラフコントロールを使用する。グラフの使い方だけでもかなりの手間だが、一人ができれば、あとは真似をすればいいだけだから、なんとかなるだろう。それ以外には難しい所はないと考えている。
死活管理は、直近の取得データだけで判断できるだけでもっと簡単だ。フォームに、データを表示して、設定されている閾値と比較してアラームを表示して、同時にメールを送信する。設定ファイルの読み込みも、メールの送信もライブラリを作成する。
共通するのは、APIから渡されるJSONの処理だが、これは頑張ってもらおう。ライブラリを使えばすぐにできるのだが、それは調べてもらおう。
仕様を固めつつ、作業量に差が出てしまっているのが気になった。
死活管理のプロジェクトの作業が少ない・・・。
特別授業の前に、戸松先生と津川先生に仕様書を送付して、問題点や作業量の差に関しての助言を貰う。
俺が考えていたテストで頑張ってもらう方法で問題は無いだろうという意見をもらえた。本体のテストを行う時に、手が足りなくなるだろうから、作業量の埋め合わせを行えばいいだろうと言われた。モンキーテストに必要だろう。勉強会のメンバーは、モンキーテスト要員だと考えておこう。
修正を行った仕様書を提出して、ライブラリの作成を行った。
ライブラリは、簡単に作成して、エラーチェックなどは入れていない。電脳倶楽部にソースごと渡して、あとは調整してもらう。開発支援と考えれば十分だろう。
特別授業で、勉強会のメンバーに仕様書を配布して、簡単に説明を行う。
開発を開始してもらう。
「十倉さん。安池さん」
リーダーの二人と、戸松先生を呼んで、リーダーにお願いしたい内容を説明する。
「そうすると、俺と、安池で、進捗を確認すればいいのだな」
「はい。進捗は、戸松先生にお願いします。もし、間に合いそうになくて、電脳倶楽部に余裕があれば回してくれます」
「わかった」「了解だ」
十倉さんも安池さんも納得してくれた。
「はい。その前に、お互いのチームの中では同じ様なフォームを作成するので、遅れそうな人のサポートをチーム内で行うのは可能だと思います」
「そうだな。仕様書を読むと、殆ど同じ画面だよな」
「はい。なので、皆で相談しながら作成していけば、問題は少ないと思います」
「わかった。その辺りの調整を、俺と安池がやればいいのだな」
「はい。お願いします。戸松先生も、いいですよね？」
十倉さんと安池さんも、戸松先生を見る。
「あぁ問題はない。電脳倶楽部から人を出すか？」
「最初は、必要ないと思います。書籍や情報が必要になるかもしれないので、特別授業の終わりに１０-１５分くらい打ち合わせをするのはどうですか？」
俺の提案に最初に発言したのは、十倉さんだ。
「そうだな。そうしてくれると助かる。相談ができるタイミングがあるのは嬉しい」
安池さんも同じ意見のようなので、今日から終了前の１５分を打ち合わせの時間に設定する。
「篠崎はどうする？」
「俺ですか？今日は、サーバのセキュリティチェックを行います。来週は、また考えますよ。開発支援に重点を置きます」
戸松先生と津川先生には、すでに伝えてある。
本番環境で利用するサーバの構築が終わって、すでに電脳倶楽部がセキュリティをチェックした。
俺がレポートにまとめて、戸松先生と津川先生に最終チェックを依頼する流れになる。
電脳倶楽部からは、構築を行うときに作成したメモを設計書にまとめてもらっている。
仕様書と実際の実装が同じになっているのか、設定に問題が無いのかをチェックしていく。
十倉さんも安池さんも作業に戻った。
チームを集めて説明を行っている。戸松先生も電脳倶楽部の面々に作業手順の説明を行っている。
「篠崎。どうする？現物での作業が必要だろう？」
「そうですね。ネットワークにはまだ繋げていないのですよね？」
「あぁまだ繋げていない」
「コンソールは？」
「余っていたディスプレイを繋げてある。ディスプレイは切替器を付けている。キーボードはUSBでつなぎ替える必要がある」
「そうですか、ハブは付いていますよね？」
「あぁ２つ付いている」
「それなら、俺の端末を繋げて、確認を行います」
「わかった。こっちだ」
サーバが置かれている場所は、教員室になる。
火が入っていても、静かだ。静音設計になっているのだろう。ハーフラックにしては重いと思ったら、下部にバラストが積まれていた。動かないように固定されているようだ。UPSも設置されている。ハーフラックなので、上にディスプレイを置いているので、立ちながら簡単な作業をすることは可能だ。
テストでネットワークに接続した名残が残っていたが、それ以外では、問題はなさそうだ。
仕様書の通りに構築されていた。起動するサービスも減らされている。今回は、サービスは４４３ポートだけの提供になる。ほぼ全てのポートが閉じられている。テストでは、野良SSLだが本番はSSLを正式に登録する。
起動のスクリプトに問題があったので、起動スクリプトは修正しておく、自動起動の順番に問題があった。大丈夫だとは思うが、設定を確認しているツールで指摘されたので、修正を行っておく。
他にも、使わないサービスの設定が残っていたので、サービスが起動してしまわないように、削除を行っておく。
次に、入っているモジュールのバージョンを調べて、最新版が公開されている物は、最新にしておく。それで、起動やサービスの提供に問題がないか確認していく。最後に、サーバにメジャーなハッキングツールで攻撃を仕掛ける。問題がなければ、これで公開の準備が終了する。
レポートを作成して、戸松先生と津川先生に提出する。
来週の特別授業の時に、お二人と一緒に最終確認を行って問題がなければ、ネットワークに接続して、アービス提供の準備に入る。
次からの特別授業では、戸松先生と津川先生と、十倉さんと安池さんからの要望を受けて、わからないことが有ったときに質問を受け付けるように待機する。
その場で答えが出ない場合には、翌週に答えることになる。簡単に言えば、QAデスクだ。
電脳倶楽部は、本番環境にデータやプログラムを移動させ始める。
テストサーバを使ってのテストが始められる状況になりつつある。
これなら、年明けにはテストが開始できそうだ。
終わりが見えてきて、俺が行っている、開発支援も出番がない日が増え始めている。
