「バリーくん」に会ってきた 自分たちが欲しいと思ったアプリを自分で作るITエンジニアの実像

バリーくんに会ってきた。システム障害に対応するエンジニアが開発したアプリ「Barry」のマスコット・キャラクターだ。インターネットイニシアティブ(IIJ)の基盤エンジニアリング本部でシステム障害に対応しているエンジニアが、「自分たちがほしいアプリを」と2年がかりで開発した。その動機は何だったのか。

f:id:itkisyakai:20191001085450j:plain

障害対応アプリ「Barry」のマスコットキャラ「バリーくん」

 冒頭のっけに「Barry」の由来を解説すると(というか、担当者が教えてくれたのだが)、IIJ は監視系のシステムに「犬」に関連する名前を付けてきた、という。ワンワンと吠えることで「何か問題が発生している」と知らせる番犬のイメージだ。「Barry」はスイスのベルナール修道院に所属(飼育)して山岳救助に活躍した犬の名前「バリー」(1800〜1814)に由来している。

 https://ja.wikipedia.org/wiki/%E3%83%90%E3%83%AA%E3%83%BC_(%E7%8A%AC)

エンジニア向け勉強会に門外漢がノコノコと

 先週の金曜日(9月27日)に続いて、30日の月曜日も東京・飯田橋インターネットイニシアティブ(IIJ)本社に行ってきた。そう言うと、「IIJのお抱え記者か?」の揶揄が聞こえてきそうだが、いやいや全くの偶然。9月27日はIT記者会の9月例会、30日はエンジニア向けの勉強会「テクニカル・ナイト」だった。

 エンジニア向けの勉強会に業界スズメがノコノコ出かけて行ったのか。これも「さすが古株の顔パス?」と揶揄されるかもしれない。古株どころか引退間際のロートルなのは否定しないが、顔パスなんてとんでもない。メールで届いた開催案内には「メディア関係者も歓迎」とあったし、「運用現場で常に隣り合わせの障害対応、IIJの出した答え」というタイトルも興味が惹かれた。

 エンジニア向け告知はコレ→https://eng-blog.iij.ad.jp/archives/3610

 なるほどITにかかわる記事を書いてはいるが、プログラムを書けるかと問われれば「ごめんなさい」と答えるほかない門外漢だ。1976年から5年間ほど、バッチ処理帳票の整理・配送にかかわったことがある程度、からくも「運用管理なかりせばシステムは動かない」ことを知っているに過ぎない。

 案内では「定員150人」、実際はどうか。

 目算で数えたら長机1つに2人ずつ、1列に机が8つmなので16人、それが8列なので計128人……。と思いきや、セッションが始まってから入ってくる人があとを絶たず、後ろの空間に机なしの椅子にざっと40人ほど。加えてWebのストリーミング中継を40人以上が視聴していたという。夜7時スタートだからこそ、現場で汗を流しているエンジニアが参加できるということだ。

f:id:itkisyakai:20190930190600j:plain

f:id:itkisyakai:20190930201528j:plain

セッション終了後、実際に操作して機能を確認できるのもこのイベントの特徴だ

f:id:itkisyakai:20190930203121j:plain

ピザとビール、コーラで懇談。写真右ジャケット姿が今回の仕掛け人・高山将孝氏。

エンジニアとして挑戦したかった

 プレゼンテーションで登壇した高山将孝氏(基盤エンジニアリング本部電気通信設備統括室)、田中義久氏(プロダクト本部SDN開発部ネットワーク基盤開発課)、浅野貴大氏(運用技術部運用システム開発課)の話を総合すると、「Barry」実用化にいたったのは以下のような経緯によっている。

 ネットがダウンしたりアプリケーション処理に誤動作が発生すると、その影響は一企業にとどまらない。障害の度合いによっては社会・経済に大きな影響を与えることになる。このため障害対応に従事するエンジニアは、24時間・365日、「待ったなし」の緊張を強いられる。夜間だろうと休日だろうと、トラブルが発生したらASP(As Soon as Possible)で対応しなければならない。

 IIJの障害対応は1チームが数人のエンジニアで構成されている。実践で鍛えられた猛者もいれば経験が少ない新人もいるし、得意とする技術分野にもバラツキがある。全員に業務用の携帯電話が貸与されていて、夜間や休日に障害発生の報告(アラーム)を受けたエンジニアが「自分一人では対応しきれない」と判断したとき、エスカレーションリストの上位から順番に、チームのメンバーの携帯電話を鳴らしていく。

 ※上司や同僚の判断・指示を仰いだり知恵を借りること=エスカレーション

 なぜ電話を使うかというと、①メールやSNSでは気がつかないことがある、②電話だとコール音を鳴らし続けることができる、③アルファベットの略語や通称は文字より話し言葉のほうが伝わりやすい、④文字を入力するより話したほうが早い——といったメリットがあるためだ。

 しかしデメリットもある。「誰が手すきかが分かればチャンチャンと対応が進むのに」という不満のほか、「手間と時間がかかる」「聞き間違えることがある」といった問題もあった。また、同時多発的ないし大規模な障害が発生した場合、1対1のエスカレーションでは対応できない。さらに中長期的に見ると、障害対応の経験値が蓄積されないという課題が横たわっている。

 既存の自動架電システムを使うという手もあるし、facebookやLINEのグループ機能、slackのような情報共有ツールもある。なのになぜ自社開発したのかというと、「自分たちの仕事の仕方にフィットしたアプリがほしかった」「障害対応に従事するエンジニアとして、新しいことに挑戦したかった」からという。

キャラクターの"ゆるさ"が緊張を解してくれる

 「障害対応に従事するエンジニアとして、新しいことに挑戦したかった」というコメントで重要なのは、太字にした「障害対応に従事するエンジニアとして」の部分だ。プレゼンで示された「運用担当者のつらさ」が、専用アプリを開発したそもそもの動機を語っている。

 障害に対応するエンジニアは24時間・365日の緊張を強いられ、高度な判断力や技術力が求められる。しかし何ごともないのが当たり前で、何かあったらボコボコに叩かれる。それを不平不満にとどめず、プロのエンジニアとして適正に評価されるには自分たちの仕事を見える化する必要がある、と考えたのだ(図1)。内向きの発想を外向きに転換した姿勢が素晴らしい。

 もう一つ、プロジェクトに関わったエンジニアが「挑戦」と口にするのは、システク開発に関わることが少ないためだ。システムの運用管理や障害対応に従事してはいても、ITエンジニアとしてWebやスマホアプリに関心がないわけではない。いつか機会があったら自分でも何か作って見よう、と"手ぐすね"を引いていたと言っていい。

 ただ、最初に「挑戦」した4人のうち2人は「モバイルアプリの開発経験ナシ」、1人は「この規模は初めて」。しかも本業が本業だけに、業務の合間や終業後の時間しか使っていない(図2)。それを続けることができたのは、「楽しかったから」だ。 

f:id:itkisyakai:20191001134612j:plain

図 1

f:id:itkisyakai:20191001134715j:plain

図 2

 初期段階、要素技術の検証では、ターゲットOSをiOSとAndroid、開発環境としてSwiftとKotlin、外部サービスにアマゾンSNSとFireBaseを設定した。第2段階のアルファバージョンでは改善案に対応するため、サーバー実装にGrphQL、Web/スマホアプリのAPIにReactを採用した。

 これを駆使するのにどのようなスキルが必要なのか筆者には分からないが、「楽しかった」のだけは理解できる。実証実験に社内の60人、ベータ版の試用に300人が参加して、"あーでもないこーでもない"とワイワイガヤガヤやったあげく、「バリーくん」というマスコット・キャラクターを生み出した。

  キャラクターの"ゆるさ"が厳しい障害対応の緊張をちょっとだけ解してくれる。メッセージ交換用に作ったスタンプは、「こんなのがほしい」の要望に応えていたら今は200種以上。『なるほど』『考え中……』『やるべきなのはわかってるんだ』『すまぬ』『あなたは神か』『進捗どうですか』『進捗ないです』といったコメント入りのスタンプが、LINEスタンプとして売られている(1セット40種類で120円)。

f:id:itkisyakai:20191001134918j:plain

f:id:itkisyakai:20191001134932j:plain

「楽しい」だけじゃなく仕組みもすごかった

 新しいことに挑戦したら楽しかった——では、子どものころの理科実験や夏休みの自由研究と変わらない。ここで忘れてならないのは、このアプリが図1「運用担当者のつらさ」に裏打ちされたニーズに基づいているということだ。そのニーズは「思いつき」ではなく、「こんなに頑張っているのになんで評価されないのか」という嘆き、怒りにも似た強い意思でもある。

 想像するに、最初は個人的な(ないし少数で意気投合した)プロジェクトだったのが、次第にのっぴきならなくなってきた。しかし新しいことに挑戦する面白さが、一歩ずつ着実に前進する推進力になった、ということではあるまいか。

 アプリ開発を「画面遷移」ととらえて、モックを作ったのも成功の要因だった(図3)。初期のプロトタイプをはるかに凌駕する様ざまな要件が複雑に絡み合う。要求を定義して仕様書を確定させるという旧来型の手法でなく、ビジュアルで臨機応変な開発は、流行り言葉でいえば「アジャイル」のアプローチということになるだろうか。

 現在のベータ版は図4の機能を備えている。それによってこれまでの障害対応は図5のように変わって行く。メール、電話、チャットといったツールが一本化できるうえ、チームで障害情報や対応状況を共有できるのが特徴だ。特に経験が少ないオペレータは「先輩/上司がサポートしてくれている」と意識するだけで、オドオドしなくて済む(もろん責任回避はいけないが)。

 図4の赤い点線は筆者が加えたものだ。「同件マージ」の機能が発展すれば障害のタイプや規模、対応方法などが整理されて行く。Barryをクラウド・アプリとして公開すれば、より多くの事例が集積されるに違いない。障害対応ツールとして販売するより、ライセンスフリーで利活用のパートナーを広げれば、障害対応知識ベースを形成すことができるだろう。そのほうが結果として、大きなビジネスになるのではなかろうか——などということを考えた。

f:id:itkisyakai:20191001142840j:plain

図 3

f:id:itkisyakai:20191001142923j:plain

図 4

f:id:itkisyakai:20191001144441j:plain

図 5

【この記事の関連URL】

https://eng-blog.iij.ad.jp/archives/3608

 https://eng-blog.iij.ad.jp/archives/3903

 

アクセスカウンター