第2回全体ミーティング（合宿！③）
■チームディスカッション 全体ミーティング2日めは、気持ちよい朝の空気のなか、ホテル向かいにある奥武山公園でのラジオ体操から始まりました。その後、参加者は朝食とチェックアウトを済ませて、前日に続くチームディスカッションと最終テーマ表明のために会場へと向かいます。 開始予定の8時が近づき、会場に参加者やメンターが集まり始めました。深夜まで議論がおよんだのでしょう。まだすこし眠そうな表情をした参加者もいて、やや緊張感に欠けた空気が流れています。そんななか、ちょっとした事件が発生しました。8時を過ぎても、数名の参加者が会場に姿を表さないのです。 結局、5分ほど遅れて、無事に全員がそろいました。この出来事に対し、事務局から「社会に出ると時間厳守を求める上司に巡り合うこともある。そのときは、すこしの遅刻が自分の運命を大きく左右しかねない。気をつけるように」と、厳しいながら愛情のこもったアドバイスがなされました。 この時点で、チームディスカッションに残された時間は2時間しかありません。各チームはこの時間を使い、取り組む理由、背景、独創性、有用性、期待される効果、貢献度などの点で説得力を持ち、かつ、実際にシステム化が可能なテーマをまとめ上げます。 メンターを交えて熱心に議論する参加者の様子には、昨日のチームディスカッションと明確な違いがありました。それは、各チームが議論のために描いている図が、格段に細密さを増している点です。内容こそチームによって違いますが、大きくは「何が必要か」を考える段階から「どのような機能を、どう実装するか」を考える段階に移っています。ミーティングが佳境を迎えるなか、それぞれのチームは確実にブレークダウンを進めているようです。 そのアイディアを体系的なテーマとして取りまとめたら、会場のメンターや他チームメンバに意義や優位性を理解してもらえるよう分かりやいプレゼン資料を整えて、いよいよこのミーティング最大の山場であるテーマの最終表明に望みます。 ■テーマ最終表明 テーマの最終表明は、ミーティング冒頭で行われたテーマ表明と同じ要領で、各チームの持ち時間を12分に設定し行われました。このミーティングで行う2回めのプレゼンテーションであり、そして、ここまでの議論でテーマに対する理解と自信が深まったせいでしょうか。会場の雰囲気は和やかで、発表者の表情にはいくらかの余裕が感じられます。 「九州濃厚ラボラトリ」のテーマはそのまま変わらず「OpenStack間ネットワーク接続の自動化」です。このテーマでは「OpenStack環境の自動構築」と「OpenStack間の自動ネットワーク接続」の実現を目指します。最終発表では、より踏み込んだ解決策が新たに示されました。それによると、対災害性の向上のために、異なる拠点間にOpenStack環境を構築し、それらのOpenStackを自動でVPN接続して、VPNで拠点間の通信を実現し、片方拠点の災害時には他方拠点に自動切り替えを行うということです。また、耐障害生の向上のために、OpenStack自体の冗長化も行われます。この他、システム利用者像を想定した機能の明確化を図り、さらにシステム構成の概念図も示されました。この発表に対してメンターからは、想定するアプリケーションを聞く質問（チームは社内DNSの分散と回答）や、シナリオを提示すると分かりやすくなる、といったアドバイスが送られました。 最初の発表でテーマを絞り切れていなかった「オープン北陸」は、その後の議論と検討において、まず、候補の2テーマを4つの指標（課題レベル、ニーズ、効果、費用）で再評価しました。そして、この評価で評点の高かった「検証環境構築」を基に、より現実的な規模へのスケーリング（大規模化が見込まれるNGN網を対象から除外）、得られるメリット、システム規模、利用シナリオの明確化などの視点を加えて、最終的なテーマを「テストベッドのエンタープライズ適用」に決定しました。このテーマでは、GUI操作や自動構築機能を積極的に取り入れることで、スキルが高くない人でも担当レベルの検証に手軽に使えるような、身近なテストベッドの開発を目指します。メンターからは、業務に直結したリアルな課題で全社的なビッグプロジェクトになる可能性を秘めている。これは第1ステップと考えて、より広い観点を意識して発表するとよい、と応援の言葉が贈られました。 「Weed」は最初のテーマ表明から変わることなく「ネットワークエンジニアへの近道 ～トラブルシューティングを用いて～」に取り組むことを表明しました。このテーマに対しては、システムイメージを早期に固めたほうがよい、取り扱うトラブルシナリオを明確にすべき、とのコメントがメンターから出ています。チームはそれを議論に反映したようで、最終プレゼンテーションでは、具体的なトラブルシナリオ、出題文、想定するトポロジなどの例が示されました。またシステム構成案や使用するプロダクトの名称も挙げられており、システム化に向けて構想が着実に前進している様子がうかがえました。メンターからは、教育では振り返りが重要なので記録機能があるとよい、VMを活用すると構成の組み換えを効率化できる、故障のトリガーや対応策は幅広い観点を考慮することが望ましい、といったコメントが寄せられました。 「Mckee」もテーマに変更はなく、最終表明テーマを「クラウドAPIを用いた社会問題へのアプローチ」のままとしました。しかし発表内容の随所にブラッシュアップされた様子が見て取れました。なかでも大きな変化が、ポケモンGOのプレイヤー向けに危険警告を発するモデルであったものを、メンターコメントを受け、プレイヤーと非プレイヤーの両方に各種情報を提供するモデルに変更した点です。これと合わせて、両者にとっての利点（プレイヤー：ポケストップの音声案内、道路渋滞個所の予測／非プレイヤー：道路渋滞個所の予測、人ごみの回避）が明確化されました。またTwitterの情報を参照してある個所の混雑時間帯を推定する機能なども追加するということです。まだ漠然とした部分もあるようですが、機能や動作イメージのブレークダウンは着々と進んでいる様子でした。メンターからは、全体を1度に作ろうとせず、まずポケモンGO APIを使う部分を作り、つぎのステップでTwitter連携を行うなど、アジャイル的なアプローチをしたほうがよい、とアドバイスがなされました。 取り組む項目の優先順位を変更した「ごま苺」は、微調整を施したテーマ名「クラウド環境導入を簡単に！！運用を簡単に！！」を掲げてテーマ最終表明を行いました。一般に、クラウド環境の構築は一筋縄でいかないものですが、彼らは、1枚のDVDをセットするだけで空のサーバへ簡単にクラウド環境を構築できる仕組みの確立をまず目指します。似たような既存技術のJujuはOSが入っていることが前提なのに対し、この仕組みではOSすら入っている必要がないため、うまくいけばクラウドハードウエアをひんぱんに更改する組織などから注目を集めそうです。そしてつぎに、その仕組みを使って構築するクラウド環境のなかに、Web画面を操作するだけでVMの払い出しやWordPressの自動構成などが行える仕組みを作り込むということです。これに対して、2～3台でクラウド基盤を作るときはどうするのかとメンターから質問が寄せられ、チームはアジャイル的に拡張を続けるなかでの対応を考えている旨を回答しました。 「SecLab」は当初のテーマそのままに「情報流出を低減させるための検疫ネットワーク」と題して今後の検討や開発を進めていくことを表明しました。発表に用いた資料には、チームディスカッションでの議論や検討の結果が大きく反映されおり、昨日の資料にはなかった、より具体的な動作イメージが示されました。動作イメージの説明にはモデルネットワークが定義され、そのなかで、(1)信頼度が高いクライアントが要求セキュリティの高いサーバにアクセス、(2)信頼度が低いクライアントが要求セキュリティの高いサーバにアクセス、(3)マルウエアに感染したクライアントが要求セキュリティの高いサーバにアクセス、(4)マルウエアに感染したクライアントが要求セキュリティの低いサーバにアクセス、といった場合の動作が紹介されました。またアドバイスがほしい課題として、通信内容に基づいたクライアント信頼度評価アルゴリズム、暗号化された通信の解読手段や通信の秘密との関わりへの懸念などが示されました。これに対しメンターからは、いまは暗号化が多用されるので外から見える情報でいかに評価するかは1つのポイント、信頼度評価はステートフルに行うとよく、端末の信頼度と個別パケットの信頼度をかけあわせた評価が実用的、とアドバイスが贈られました。 「なんとなくメガネ」はテーマ名を「リンク切断に対処可能なOpenFlowコントローラを開発する」にリファインしましたが、取り組み内容は大きく変えず、リンク故障発生時にOpenFlowで代替経路を設定する方式の検討、検証、高度化を行います。この最終テーマ表明では、取り組みにおけるSTEP1～3の各段階のうち、自分たちで必須と位置づけるSTEP1と2について、基本的な処理方針をより明確にし、実装にまで踏み込んで実現の道筋を整理しました。このうちSTEP1では、Port Statusメッセージでリンク断を検出し、あらかじめLLDPで検出しておいたトポロジを基に、切断したリンクを経由する経路をすべて再計算して代替リンクを設定します。しかしこの方式はリンク復旧に時間を要するため、STEP2において、事前に予備経路を用意しておき、リンク切断時にはOpenFlowスイッチが持つGroup TableのFast Failover機能を用いて高速に経路を切り替える方式の実現を目指します。メンターからは、聞く人に取り組みの意義を納得してもらうには、実装だけでなく、取り組みを行う理由、背景などにも触れた方がよい、とアドバイスがありました。 ユニークなテーマ名を付していた「Stone Hill」は、新たにテーマ名を「IoTにおけるセンサ・アクチュエータ間連携の問題をSDNを用いて解決」に変えて、最終テーマ表明に挑みました。当初のテーマ表明では課題としてデータ共有管理の煩雑さを挙げましたが、新テーマでは、それに加え、センサで取得したデータをアクチュエータへ迅速に反映することも課題の1つに位置づけました。発表ではおおまかなシステム構成（センサとアクチュエータの近隣にOpen vSwitchを置き、外部コントローラでそれを一括制御）や動作イメージが示されました。また課題として、センサデータをアクチュエータで受理可能な形式へ変換する機能をOpen vSwitchに配置する方法、途中にNAPTを挟む場合の透過性確保などを挙げました。この課題への答えとして、メンターからOpen vSwitchの間に置いたネームスペースにデータ変換ロジックを置けることが示されたほか、発表スライドの構成や表現方法にもっと工夫が必要なことが伝えられました。 最終テーマ表明を締めくくる「まんぼう」は、取り組みの出発点となる問題意識や、解決に向けた方針（ユーザ近隣に設置したエッジサーバの介在により、不安定なインターネット接続下でも安定したWebアクセスを実現）はそのままで、テーマ名を新たに「分散型サービス基盤システムの構築」としました。当初の発表に比べ、システム構成やミニプログラムコンテストに向けた工程の詳細化が図られており、チームディスカッションの成果が反映されている様子がうかがえました。また、テーマ名の変化から見て取れるように、最終的に目指すシステム像が、より汎用性の高さを意識したものとなりました。発表後の質疑応答では、エッジサーバ同士は同期しないのか？との質問がメンターから出ました。これに対しては、まずは避難所に設置する災害掲示板のようなものを想定するが、機能としてはエッジサーバ同士の同期も提供したい、との旨を回答しました。
すべてのチームの最終テーマ表明が終わり、第2回全体ミーティングもそろそろエンディングです。最後に佃から、8月26日に開催されるミニプログラムコンテストの実施要領が発表されました。これは、12月第2週に開催されるプログラムコンテストの前哨戦に当たるもので、今回決めたテーマに沿ってプログラム開発などを進め、その実施状況やデモなどを発表する最初の機会になります。その説明に耳を傾ける参加者たちの目には、つぎの目標に向けた新たな情熱が秘められているように見えました。 スペシャリスト育成プログラムの参加者は、同じプログラムに参加する仲間であり、そして、力を競い合うライバルです。今回のミーティングで長い時間を共にして、気持ちの壁がすっかり取り払われた参加者たちは、つぎのマイルストーンに向けて互いの健闘を誓いながら、この会場を後にしました。
