はじめに
1月29日、
登壇者は以下の3名になります。
- タワーズ・
クエスト （株） 取締役社長 和田卓人氏 （株） 鳥居剛司氏バスキュール - JAXA
（宇宙航空研究開発機構） 成田伸一郎氏
“ガチ系” の2人に切り込む
このセッションはモデレーターを務める和田氏いわく
- 和田氏
テレビと連動して行うバックエンドのエンジニアリングやテストを行っている鳥居さん、
そしてロケットなど宇宙開発にまつわるテストを行っている成田さんの仕事は一般から見て “一発勝負” の極みです。その中で、テストの価値判断や優先順位づけは変わります。Web系で言えば、 個人情報とかセキュリティあたりに重きが置かれます。テレビ連動型サーバならどうか、 宇宙開発ならどうか、 そのあたりの業界別の違いを教えてください。
- 鳥居氏
同僚のテクニカルマネージャーによれば、
案件による部分と汎用的な部分があると思いますが。あるトラブルに対してどのくらい経済的なリスクがあるか、 という表をつくります。エラーの発生確率、 仮にエラーが発生した場合の損害コスト、 そもそもエラーが発生したら企画が成立するのかしないのか、 その対処方法や軽減策、 および軽減策にかかる実工数、 さらに軽減効果からの費用対効果などを出します。それらを表に起こしてソートし、 上から順に潰していきます。どこまでやるかは案件の予算や企画の特性にもよります。たとえば、 テレビと連動したゲームならサーバが止まってしまったら企画が成立しません。そのあたりの限界をディスカッションし、 テレビ局の人や開発チームメンバーと共有していきます。
- 和田氏
費用対効果の高い順からつぶしていくということですね？ では、
その費用対効果の出し方は経験だったりするのでしょうか？ - 鳥居氏
はい、
そうですね。知見がたまるにつれ、 質が高まると思います。 - 和田氏
続いて、
成田さんお願いします。 - 成田氏
鳥居さんと同じく、
企画提案時と運用時があります。企画提案時は内容を詰めます。コスト、 マネージメント要員、 どんな世界に先駆けた素晴らしいミッションか、 どんな内容かで決まります。それは、 その単発ミッションが成す目的、 さらに成功した場合にどのような波及効果が生まれるかと言う将来意義、 拡張性で見られます。そこで2、 3個の案があればそこで戦いになるんですけど。それはもはや可能性の範囲なので。たとえば、 論文が何本出ましたと言ったことは事後評価なので、 どうしてもフロンティアな世界ではあります。 運用時にはだいぶ実際の技術的な部分が入ってきます。たとえば、
バッテリーが潰れたらこういうミッションが出来ませんね、 というわかりやすいフローに落ちるんですけど。たとえば、 はやぶさがイトカワ （小惑星） にサンプルリターンするために、 まずランデブーして軟着陸までしました、 と。1回目はリハーサルです。しかし、 どうも思わしい状況ではなかったとします。その場合、 2回目の軟着陸はしないで帰ってくるという選択肢があります。この場合、 ミッションが2つあり、 1つは “地球と往復する” ということ、2つめは “サンプルを採ってくる” と言うこと、この戦いになるのです。もし着陸を試みたが、 宇宙機が全損したら戻ってこれない。でも、 サンプルも取りに行かなければいけない。結局、 （目的達成率） 50％を目指すのか、 100％を目指すのかというところになるんですが。それはそのときの探査機の状態 （ヘルスチェック） をみながら決めます。前者の手法はレビュー、 後者は担当者の技術的な実績をもとにプロジェクトリーダーの決断というところです。
- 和田氏
判断をするのはレビュー、
および技術面での下支えがあったうえでリーダーが決断するということですか？ - 成田氏
そうですね。
- 和田氏
実にプロジェクトのスケールが大きすぎますね
（笑）。判断は開発責任者であったり、 金額によっては経営だったりするのでしょうか？ - 成田氏
はい。おっしゃるとおりですね。
一度きりのテストだからこそのエピソードとは？
続いて、
- 和田氏
Web系なら
「一度限りならテストは噛まさない」 という判断をすることもあります。一度きりのものに対してテストをして、 さまざまなものをやっていくきっかけになったこと、 エピソードなどをお聞かせください。 - 鳥居氏
実際に案件をやってみると、
いろんな要素が絡んできます。ユーザ登録しつつも、 一定期間なにかのAPIを叩きつつ、 それをブロードキャストで受け取ってdispatchするみたいな。そのような複合要素が絡んだときに、 最初は問題が出ました。で、 そのあたりをどうにかしなくちゃと思っていて。それでにツールを使いました。Node. jsを選んだのは単純にJavaScriptなのでブラウザと同じ動作を書きやすいからです。まず、 シナリオを記述し、 プログラムを書き、 大量のサーバから一気にメールを出してサーバーに負荷をかけ、 案件全体としての負荷テストを行ったんです。 - 和田氏
まず失敗があったのでそれを繰り返さないために負荷テストを行ったんですね。
- 鳥居氏
そうです。
- 和田氏
成田さんはどうですか？
- 成田氏
我々にとってみると、
宇宙に飛ばすこと自体がテスト。かっこいい言葉でいうと “チャレンジ” や“フロンティア” という言葉になります。技術的な話をすると、1つは一発勝負でやみくもに打ち上げてはいけないので解析、 予測をします。一部は地上でも予測できます。大きな電子レンジと冷蔵庫と真空ポンプが一緒になった真空チャンバーみたいなものがあるんですけど。その中に入れて真空と温度条件を合わせてやります。でも、 放射線などいろんな外来要因、 複合的な状況というのは軌道上に飛ばしてみないとわからない。我々はそれを “テスト” とは呼ばす“デモンストレーション” 、日本語でいうと “実証” と呼んでいます。そういったことができたら、そういう未来があったらいいな、 というアプローチの仕方をしています。 - 和田氏
地球上で再現できるものは可能なかぎり行い、
その先は実環境、 いわゆる宇宙に行かないとわからないこともある、 と。 - 成田氏
そうです。どうしても残ります。
- 和田氏
一定数ある。どうして飛ばしてみないとわからない、
からの備えは？ - 成田氏
それはもう、
実績数です。すごく新しいものでも、 実績数がないものはダメです。どんなローテクでもロシアのコンポーネントでも100回、 200回と実績があれば信頼性が高い。そういう評価です。 - 和田氏
未知のことが起こりそうな状況になればなるほど、
実績を重んじるという感じでしょうか？ - 成田氏
実プロジェクトになるものはだいぶローテクですね。
- 和田氏
新しい技術を取り入れて行くのは？
- 成田氏
それは、
“ミッション と（mission）” “バス になります。たとえば（bus）” 「小型軽量バッテリーのような新しい技術を積みます」 というのはそれがミッション内容になっていて、 それを実現する通信の電力などにはローテクを使っている。こちらが “バス” です。たとえば、
ツーリングに行くとき、 行った先で何をしますか？ というのがミッション、 車がバスです。車がないとツーリングに行けないですからね。
まとめ
一度限りのテストだからこそ、