4回ほど情報危機管理コンテストに参加した話
さて、今年もこの季節になりました。
関西には和歌山県の白浜という町があります．海と白砂がとても綺麗なところです．
今回はそんな白浜の町で毎年5月に行われている「サイバー犯罪に関する白浜シンポジウム」というシンポジウム内に併設されているコンテスト 「情報危機管理コンテスト」について書いていきたいと思います．
情報危機管理コンテストとは？
今年で13回目の開催になるそうです．参加者は同じ学校・大学の2~4名でチームを組み，情報セキュリティのコンサルタントまたは情報システム部門の社員になりきり，各予選・決勝に挑みます．コンテストについての詳しい情報は下記公式サイトにて．
今年度のコンテストはなんと今日4/7が締め切りです！
悩んでいる方はぜひ応募してみてください．
（一次予選を2人チームで乗り切って二次予選までにもう2人集めるという方法もありますよ）
私と情報危機管理コンテストとの関わり
私は情報危機管理コンテストに過去4回参加させていただきました．学部3年〜大学院2年の期間ですね． そのうち，学部4年〜大学院2年の回は，運良く決勝に出場させていただくことができました．
各回での所属したチーム名と戦績は下記になります．
- 学部3年：KobaOSとして出場．二次予選敗退．
- 学部4年：KobaICとして出場．プログレス賞受賞．
- 大学院1年：KobaIPSとして出場．文部科学大臣賞と個人でJPCERT/CC賞受賞．
- 大学院2年：KobaIPとして出場．ベストフォーメーション賞受賞．
チーム名に必ず Koba が入る理由ですが，指導教員のお名前から拝承しております:)
あとの2~3文字は適当です．弊研究室から出る他のチームもたいていこの命名規則に従ったチーム名になっております．
二次予選以降の各回でのチーム構成です．今度はチーム名で書きます．
役職について
基本的にはこういった認識で書いています．
- トラブルシューター：インシデント解決へ向けてサーバ等を操作するメンバー
- オペレータ：電話・メールなど顧客と直接やりとりするメンバー
- ロガー：各時間でのインシデント対応の状態遷移を記録するメンバー
- マネージャ：チームの指揮をとり方針を定めるメンバー
KobaOS
学部4年の先輩が3名と学部3年の私という構成でした．
役職は基本的にトラブルシューター2名，オペレータ1名，ロガー1名というもので，トラブルシューターの先輩が基本的に指揮をとられていました． このチームでは私はロガーを担当し，ログをとるものがなければ先輩方といっしょにインシデントの原因究明を行なっていました．
KobaIC
大学院1年の先輩が1名，学部4年が1名（私），学部3年の後輩が2名という構成でした．
役職はトラブルシューター2名，オペレータ1名，ロガー1名と昨年を引き継いだもので，トラブルシューターの先輩がマネージャを兼任されていました． 私はトラブルシューターを担当しながら，オペレータの様子を見守っていました（？）．
KobaIPS
大学院1年が1名（私），学部4年が2名，学部3年が1名という構成でした．
役職はトラブルシューター2名，オペレータ1名，ロガー1名というまあまたかという感じで，私はオペレータ兼マネージャとして参加しました． （トラブルシューター2名が学部4年，ロガー1名が学部3年のメンバーです）
KobaIP
大学院2年が2名（私含む），学部3年が2名という構成でした．
この回は色々あって二次予選と決勝で役職を変更しています．
- 二次予選：トラブルシューター3名，オペレータ兼ロガー1名．私はオペレータ兼ロガー兼マネージャとして参加．
- 決勝：トラブルシューター2名，オペレータ1名，ロガー1名．私はオペレータとして参加．
所感
なんだかんだで一番バランスがよかったのがKobaIPSだなと思うと、今までで一番いい賞を取れたのも頷けるなと。
弊研究室と情報危機管理コンテスト
弊研究室のチームは毎回情報危機管理コンテストに参加させていただいており，毎回決勝に出場しています． （そしてこの記録を止めないようにというプレッシャーも引き継がれていきます...）
弊研究室のチームの特徴として，そのほとんどが縦割り構成であるというところがあげられます．（そのせいか毎回運営の方に「勝ちに来ていない」と言われてしまうのですが，毎回ちゃんとやる気あるんですよ...！）
いろいろ理由はあるのですが，先輩のテクニックを後輩へ引き継ぐための一手段として同じコンテストに同じチームで出るということを年々やっているのかなあというところです．あと，同じチームで出るとだいたいは仲良くなれるので，将来的に後輩が研究でつまづいたときに，過去同じチームでコンテストに出ていた先輩に聞きやすくなるという研究上のメリットもあります．（私も年上の人と話すのが苦手というところがあったのですが，コンテストのおかげで緩和できたところもあります）
2017年度にいただいた文部科学大臣賞にはこういった背景があります．
また，複数チームで出ているというのも特徴の一つですね．過去4回において弊研究室が何チームつくったかのリストです．（参加希望者は全員参加させてあげたいという思いがあり，特に人員を絞るということはしないためですね...）
- 2015年度：3チーム（うち3チーム二次予選出場，1チーム決勝出場）
- 2016年度：4チーム（うち3チーム二次予選出場，1チーム決勝出場）
- 2017年度：4チーム（うち3チーム二次予選出場，1チーム決勝出場）
- 2018年度：4チーム（うち2チーム二次予選出場，1チーム決勝出場）
チーム構成の決め方
とはいえ，縦割りといっても割り方は様々です．新しい2回分についてはメンバー割り振りに関わっていたので，どういう割り方をしたか書いておきます．
2017年度
過去のコンテスト出場経験，決勝出場経験，UNIX系OS使用経験，プログラミング経験，学年，そもそもコンピュータにどれくらい慣れているか等をシビアに点数化して，各チームの合計点数が同じくらいになるように調整しました．あとは，「仲良くなれるか」というところも見ました．一部メンバーの「この人と一緒に出たい」という意見や，研究分野による得意分野の違いを見た方が良いという意見も取り入れました．M2の方は恐れ多くて点数化できない...！ということでマジックカード的扱いになってました（すみません）．
- 良かった点：コンテスト後も各チームの人員はある程度仲が良いように見える（主観です），どこのチームも同じくらいの技術力だったため後から出る不満は少なかった
- 悪かった点：各メンバーのコンテスト周辺のスケジュールを見ていなかったために忙しすぎるチームができた，ネットワーク系の技術（物理switch触れるか等）を考慮していないチーム構成だった
2018年度
昨年ほどシビアな点数化は行なっていないです．前年度の失敗を考慮してネットワーク系の技術があるかどうかについてもポイントに入れました．例年暗黙の了解で年上がやることになっているマネージャを希望制にしてチャレンジできる環境になりました．それに伴い，マネージャをやりたい人から見てやりやすいメンバーかというところも考慮に入れました．また，「やる気」というところも見ようという意見があり，絶対に出たい人と枠が余れば出たい人のバランスを考慮しました．（決勝を目指すチームとお試しでコンテストに出てみたいチームができました．）
- 良かった点：初マネージャな人からはやりやすかったという意見がもらえた．
- 悪かった点：この回ではそこまで研究分野を見れていなかったため，分野が固まった．マネージャのことは考慮できていたが，マネージャ以外の人に意見を聞けていなかった．文章力も見るべきでは？という意見が出た．
チーム構成についての所感・次組むなら？
どうしても院生がいるチームが勝ち残る状態で，学部生のみの構成のチームが勝ち上がったところも一度見てみたいです．（他の大学のチームは普通に学部生のみの構成のところが多いように思うので．）
チームについて，うまくいったように思うチームでは，一次・二次・決勝問わず，全員が問題に対して同じだけの情報を持ち，同じ方針に向かって対応を進められた（そういう時間が多かった）ように思います．
- 情報共有力（いわゆる報連相も含む）
- マネージャの人員割振力や決定力（これには必ず他のメンバーの協力が必要．マネージャだけ頑張っても空回りになる）
- それらを下支えする根本の技術力や問題解決力（そもそもトラブルシュートできないとね，，）
これらが必要ですね...こういった力を問題なく揮えるようなチーム構成である必要があるわけですが，それにはある程度 "相性" というものがあるのでしょうね．
"相性" というとすごくアバウトですし，「そんなの技術力が高い人間4人揃えればいいだけでしょ」と言われかねないですね... 技術力は高いに越したことはないのですが...
技術力が高いチームを弊研究室で何回か見ましたが，技術力だけが高いと暴走を始める（アグレッシブ賞というものがありまして...）こともありましたし， 逆に，技術力がなくて基本的なトラブルシュートが怪しいけれど，顧客対応でやらかさないことに注力したチームも見たことがあります． どっちも良いとはいえないですが，どっちかに寄るのが弊研究室の傾向のようです...うーん... （弊研究室は全回決勝出場してますか優勝したことは一度もありません...）
これはあくまで私の主観ですが，事態を"俯瞰"できる人と一つの事象に"集中"できる人のバランスは見た方が良いように思いました．浅く広くの人か，狭く深くの人かですね．そして俯瞰できるマネージャが集中できるトラブルシューターに仕事を割り振り（これにはマネージャの技術力も必要ですね），俯瞰できるロガーが作業をロギングしつつ足りてないものがないかマネージャと確認できれば良いのかなと思います．
もし次組むのであれば，そのあたりの見極めをやってみたいところですね．あとは後輩に任せます．
あと何を書けばいいのか...
ぶっちゃけあと何を書けばいいかわからないので（すみません），これ書いてなどのリクエストがありましたらTwitterやコメント欄でご連絡ください...
