「goo」の広報ブログ「gooの音」

「goo」広報担当が、みなさんにとっておき情報をお伝えしていきます!

【エンジニアに訊く】Alexaスキルの審査を通すために抑えておくべきポイントは?社内勉強会「アサレン」でAlexaスキルを開発したエンジニアに訊いてみた。

2018-08-31 | ★もっと知りたい!NTTレゾナント

NTTレゾナントでは、社内のスペシャリストが講師となり、業務に必要なスキルを習得する場として勉強会を実施しています。その1つが「アサレン」です。「アサレン」は、朝の時間を活用し、UI/UX、 プログラミング等といった、技術力の向上を目的に開催している勉強会です。

今回は、「アサレン」で講師を務めた伊東さん、アサレンに参加した若手エンジニア久澤さん、岩田さんにインタビュー。3名とも今回の「アサレン」で、Alexaスキルを1ヶ月ほどで開発し、リリースしたとのこと。開発で苦労したポイントや、審査を通すために抑えておくべきポイントなどを訊きました。

※今回の記事はスマートスピーカーのスキル開発(主にAlexaスキル)を検討されている方向けのものです。

左)メディア事業部 ポータルサービス部門 技術開発チーム 岩田 紘成
2018年、NTTコミュニケーションズへ入社、同年にNTTレゾナントに配属。「gooニュースアプリ」のバックエンドの開発業務などに従事。

中央)スマートナビゲーション事業部 サービステクノロジー部門 AIチーム 伊東 久
2008年、NTTレゾナントに入社。「goo AI x DESIGN(エーアイクロスデザイン)」や「教えて!gooのAIオシエル」など、NTTレゾナントの主要なAI案件に従事。

右)ソリューション事業部 サービス基盤部門 課金/IDチーム 久澤 大輝
2016年、NTTコミュニケーションズへ入社、同年にNTTレゾナントに配属。「goo」のID・決済基盤の運用に加え、社内インフラ整備などの情報システム業務や、スマートフォンアプリの管理業務などに従事。

 

 

個人の作り手は「コンテンツ持っていない問題」にぶち当たる

 

――今回はAlexaスキルについてお話をお聞きします。皆さんは今回のアサレンで初めてAlexaスキルを開発したそうですが、どのようなスキルを開発したのでしょうか?

伊東
私は「アニメトークイベントお知らせ」というスキルを作りました。このスキルは都内で開催されているアニメ制作陣によるトークライブイベントのスケジュールをお知らせしてくれるスキルです。

久澤
私が作ったのは、食品名を言うとその食品の100グラムあたりの糖質とカロリーの量を教えてくれる「糖質チェッカー」というスキルです。文部科学省の『日本食品標準成分表2015年版(七訂)』のオープンデータをコンテンツとして利用しています。

岩田
私は「川崎のゴミ係」というスキルを作りました。捨てたいゴミを発話すると、そのゴミの川崎市での分別方法を教えてくれるものです。


――皆さん、ご自分でスキルを企画されたとのことですが、スキル設計で悩まれたところってありますか?

伊東
スキルを作るにあたって、どういったものにしようかいろいろと考えましたが、個人として発信するためのコンテンツを持っていないことが大きな課題でしたね。Alexaスキルでよく使われているのって、フラッシュブリーフィングスキルといわれているもので、これはニュースやメディアの情報を音声で聞けるスキル。簡単に言うと「アレクサ、今日のニュースを教えて」といったら、Alexaがニュースを読み上げてくれるものです。

このフラッシュブリーフィングスキルを作るには、まず自分が発信するためのコンテンツを用意しないといけません。みんなが知りたいと思う有用なコンテンツを持っていないとこういったものができないのです。「伊東久の今日のニュース」を流してもしょうがないので(笑)

なので、コンテンツを持っていない個人がAlexaスキルを作ろうと思ったときには、「コンテンツに頼らないもの」「オープンデータを活用してコンテンツとするもの」「なにかしらの手法で情報をキュレーションする」のどれかになるかと思います。私が開発した「アニメトークイベントお知らせ」は、3つ目ですね。Web上にあるイベントのタイムテーブルのデータを取得してきて、いつどこでアニメイベントが開催されているのかを教えてくれるようにしました。

岩田
私も、コンテンツ持っていない問題に悩まされましたね。どうしようかと考えた結果、オープンデータを活用することにしました。神奈川県川崎市に住んでいるのですが、ゴミの分別方法がオープンデータとして公開されていて、それを利用しました。なぜ川崎市なのかというと、社会人一年目で川崎市に引っ越してきたばかりなのですが、ゴミの分別方法がよくわからなくなるからです(笑)。

 他の市町村で、すでにゴミ分別に関するスキルがあったけど、川崎市にはまだない!!
これは俺が作るしかねぇ!!と決めたとのこと。

 


Node.jsは非同期処理が辛い


――開発で苦労したことは?

久澤
Alexaスキルの多くがNode.jsかPython作られています。私は以前Pythonを使ったことがあったので、未経験だったNode.jsを選びました。初めて触る言語だったのですが、私が開発した「糖質チェッカー」ではスクレイピングはしないし、JavaScriptの経験はあったので、簡単だと思っていたのですが、実際は非同期処理という沼にハマりましたね。

伊東
私も、Node.jsを最初に選んだのですが、非同期処理で挫折しましたね(笑)。PythonはABCという処理を記述するとA、B、Cと順番通りに処理をするのですが、Node.jsはWebサーバーなどのサーバーサイドで動作させることを想定したJavaScript環境なので時間のかかる処理は処理が終わって値を返すことができる状態になったら返す(処理が速いものはすぐに返す)という動作になります。
例えば、ABCと記述しても、Bの処理が遅いと、A、C、Bとなり、Bの値が最後に返却されます。この非同期処理に慣れていない、私のようなプログラマーからすれば、かなりやっかいなんですよ。「Node.jsいけるっしょ!」っていうテンションで挑んだのですが、文字列を正規化するための関数を1つ書いただけなのに、「あれ?順番違うじゃん!やってられん!」となりましたね。結局、私は途中まで書いたNode.jsを全部捨てて、Pythonで書き直しました(笑)。

  

Node.jsでコールバック地獄に飲みこまれ、Pythonで息を吹き返したとのこと。

 


発話されやすいコンテンツを用意しよう


――みなさん、無事にリリースまでたどり着いたとのことですが、審査ではどういうポイントが指摘されましたか?

岩田
私は審査に何度も落とされました(笑)。スキルのエラーというよりも、ユーザーとの会話インターフェイスの部分で指摘を受けましたね。いかにユーザーが直感的に操作できるかが、重要視されているような気がします。
当初、オープンデータのテキストをそのまま使っていたんですが、それを人が発話するような書き方に直しました。例えば、元データでは「アイスクリームのふた(プラスチック製)」や「アイスクリームのふた(紙製)」という感じで分類されているんです。
ユーザはそんな聞き方をしないので「アイスクリームのふた」でまとめる、といった作業をひたすらやりましたね。ある程度は機械的にできますが、最終的には手作業で修正していく感じでした。これはスマートスピーカーのスキル開発ならではの作業かなと思います。

久澤
私もこの作業に結構時間がかかりましたね。日本食品標準成分表に記載されている食品名が「(えんどう類) さやえんどう 若ざや 生」みたいな絶対に人が発話しないような書き方なんですよ。

 

エクセルでゴリゴリ成形して、食品名のクリーニングを行ったとのこと。

 

あと、Alexaのシミュレーターは、実機と異なることを意識しておいたほうがいいですね。私の場合、シミュレーターではタイピングで文字を入力するのですが、発話だと音声で文字が入力されます。
具体例をあげると、シミュレーターで「はんぺん」と打つとちゃんと認識してくれるのですが、実機で試してみると「半片」と漢字に変換されてデータベースに飛んでいくんです。データベースには漢字の「半片」が登録されていないので、Alexaが「見つかりませんでした」と返答してしまうようになってしまって・・・。ですので、実機でも動作を確認しつつ、ひらがな、カタカナ、漢字でも対応できるデータベースにしないといけないんです。

また、審査を受けるときには、サンプルフレーズというものを用意しなくちゃいけないのですが、ここで指摘される人は多いのではと思います。私の「糖質チェッカー」というスキルの場合、自分でタイピングして打つときはシミュレーター上でAlexaがすでに起動しているので、「糖質チェッカーで唐揚げを調べて」で動作するのですが、実機の場合は、「アレクサ、○○して」というふうに、”アレクサ”をきちんとつけないといけないんです。ですので、ちゃんと”アレクサ”というウェイクワードをサンプルフレーズに入れなさいという指導が入りました。


――なるほど、シミュレーターと実機では動作が異なる場合があるのですね。

久澤
他にも注意しておきたい点がありまして、それがサンプル発話の準備ですね。アレクサがユーザーの発話を正確に認識できるように学習するための辞書のようなものです。サンプル発話には、「〇〇の糖質を調べて」「〇〇の糖質を知りたい」「〇〇の糖質を教えて」などユーザーのさまざまな発話に対して対応できるように辞書を用意する必要がありまして、これの数が10個以下だとおそらく審査で指摘されますね。

岩田
私はまさに、それを審査で指摘されました。Amazonのウェブサイトにサンプルはあるものの、スキルによってユーザーの発話方法がそれぞれ異なるので、そのまま転用することはほとんどできません。初めて申請される方の多くがここで指摘をされるのではと思っています。

伊東
私の場合は、Alexaスキルの説明欄に書く文章について指摘を受けました。申請時にこのスキルはこういうことができるという説明を書いたドキュメントを提出するのですが、その体裁について指摘を受けています。Alexaの標準機能と誤解させてしまうので、これがスキルであることを明示的に書いてくださいという指摘を受けました。最終的には説明文に”Alexa”という表現をしていたところをすべて”スキル”に直しました。

 

 

Alexaスキルをリリースするなら今がチャンス


――Alexaスキルって今が審査に通りやすいとの噂を聞くのですが、実際に体験してみていかがでしょうか。

岩田
私は何度も審査されましたが、実際はそれほど厳しいものではないと思います。指摘ポイントはある程度限定されていて、スキルの実装で指摘をされることはないですし。また、
Alexaはスキル数の拡大に力を入れているときで、キャンペーンなども積極的に実施しているので、それもあって今はスキル審査が通りやすい時期なのかなと思います。

久澤
岩田さんと同じく、それほど厳しくはないという印象ですね。Amazonが求めるユーザーエクスペリエンスに関する資料や審査のチェック項目があるので、それをきちんと見ていれば、大丈夫だと思います。

今がチャンスというのは、審査のスピード感からも伝わってきますね。私の場合は、日曜日の夜に出して、月曜日の昼に返ってきたのでかなりスピーディーだと思います。営業日的には半日くらいですね。次の日の昼に指摘されたポイントを改善して出したら、その日の夕方に審査通りました。

伊東
スキル開発に関する情報もネット上では充実しつつありますね。AmazonのAlexaスキル開発トレーニング、Qiitaの記事か、GitHubのサンプルコードなどが参考になるので、それらの情報をみれば簡単なものであればすぐに作れると思います。逆に書籍はいろいろと見ましたが、参考になるものはなかった(アサレン開始時 2018年6月の段階)ので、情報収集は基本的にウェブサイトで良いと思いますね。

今後は、各社がスマートスピーカーにディスプレイを備えたものを市場に提供してきますので、機能もよりリッチなスキルが作れるんじゃないかと思います。そういった意味でも、スキル開発の可能性が広がっている段階なので、今スキル開発を経験しておくことをおすすめします。 


――ありがとうございました!

NTTレゾナントでは、「goo」を一緒に作るエンジニアを募集中です!採用ページでは、実際のエンジニア社員へのインタビューや社内カルチャーを紹介していますので、ご興味があればぜひご覧ください。


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

プロアクティブチャットサポートで攻めのCSを実現 UX向上にも繋げているgooのチャットサポートとは

2018-08-21 | ★もっと知りたい!NTTレゾナント

企業がサービス・製品を提供する上で、ユーザーの窓口として欠かすことができない職種、カスタマーサービス(以下、CS)。ポータルサイトとして、メール、ポイント、ブログ、Q&Aなどさまざまなサービスを展開するgooにとっては、とても重要な要素です。

CSでは、近年のコミュニケーションツールの発展に伴いユーザーとのやりとりも多様になっています。特に、リアルタイムでのチャットサポートでの相談件数はこの1年で大きく伸びました。その中でチャットサポートでの知見を築き、88%の応対満足度を得ることができたのが、gooのCSです。今回は、チャットサポートを問題解決だけではなく、UX向上にも繋げたCS担当の町田さんに話を伺いました。

 

メディア事業部 ポータルサービス部門 CSチーム 町田 孝一郎

平成29年にNTTレゾナントに入社。
メディア事業部ソーシャルサービス部門CS担当に配属となり、お客さまの満足度向上を目的としたサポート業務やソーシャルメディアの運営業務を担当。



チャットサポートには向き不向きがある

 

――今回は、gooのCSで取り入れているチャットサポートについてのお話を聞きたいと思います。電話にはない「気軽さ」、メールにはない「即時性」の両方を兼ね備えているというイメージなのですが、実際はいかがでしょうか?

町田:はい、そのメリットは確かにチャットサポート特有のものですね。ユーザーもそのメリットを感じているようで、チャットサポートを始めてからメールのお問合せ件数は30%ほど減りました。

やはり、チャットサポートのほうがユーザーの課題を速く解決できるので、チャットサポートを使ったことのあるユーザーはまたチャットサポートでの問い合わせをしてくれるというデータもあります。

 

――チャットサポートの効果が数字として出ているのですね。その一方で、チャットサポートで対応する場合、向き不向きはありますか?

町田:チャットサポートに向いているのは、How toの部分。例えば「gooブログの新規開設の方法がわからないから教えて」などの質問はチャットサポートが向いています。一方でチャットサポートに向いていないものもあります。たとえば、ユーザーと同じ環境で検証が必要になるもの。そういったものはどうしてもリアルタイムでの回答が難しいので、メールで対応をしています。このメリットデメリットを踏まえて、チャットサポートを提供しています。

 


問い合わせする前に、サービスの利用をあきらめて、
離脱していたユーザーユーザーを救う


――チャットサポートはどういったタイミングで使われているのでしょうか?

町田:gooのチャットサポートはプロアクティブなものです。ユーザーの各ページにおける滞在時間などを見て、どこかで手詰まりになっていると判断した場合に、ポップアップを出して、こちらからチャットサポートを促します。

 

――チャットサポートといえば、ウェブページの端に常設しているイメージなのですが、なぜプロアクティブな仕様にしたのでしょうか?

町田:常設のものだと、ウェブページのデザインによっては、邪魔になってしまうこともあると考えています。例えば、ヘビーユーザーやリテラシーの高いユーザーからすればチャットサポートは必要とされていません。常設のものだと、それらのユーザーのユーザー体験を阻害させてしまうことにも繋がるのです。

本当に必要としている人に対してのみ、チャットサポートを提供したいと思い、プロアクティブな仕様を採用しました。

 

――プロアクティブなチャットサポートを導入して、その効果はいかがしょうか?

町田:応対満足度の数字は上がっています。それ以外のところでいうと、今まで問い合わせしないで離脱していたユーザーの問題を解決できているという実感があります。

チャットサポートの後でアンケートをとっているのですが、「なぜチャットを利用したのか」の回答では、「チャットに関するポップアップが出てきたので、聞くつもりはなかったが聞いてみた」の声があります。

こういったユーザーは今まで問い合わせする前に、サービスの利用をあきらめて、離脱していたユーザーです。このようなユーザーをプロアクティブなチャットサポートを導入したことで救うことができるようになりました。

gooブログで出てくるポップアップ。チャットサポートのポップアップが文字だけだと、
無機質なものに見えてしまうので、gooユーザーから親しまれているメグたんのイラストも出すようにしたのとのこと。


――チャットサポートでユーザーの離脱を救う。デジタルマーケティングのような側面も持ち合わせていますね。 

町田:そういってもらえると嬉しいですね。CSってどうしてもユーザーの問い合わせを待っている受け身なものに見られがちですが、gooのCSは能動的に動くことをスタンスとしています。ユーザーの潜在的な悩みを引き出し、それを解決することで、サービスのユーザー体験を向上させていく、ユーザーの伴走者としてgooを100%楽しんでもらうことがCSとしての目標ですね。

 


問題解決までのプロセスはメールと大きく異なる


――次はチャットサポートの課題について聞いてみたいと思います。チャットサポートならではの難しさってありますか?

町田:やはりスピードを求められてしまうことですね。チャットだと、何も応答が無い状態で30秒ほど待たされるだけで、ユーザーが「待たされている感覚」になってしまいます。問題解決をいち早くしたいユーザーからすれば、この「待たされている感覚」が不満に直結します。

 

――では、ユーザーを待たせないように工夫していることって何かありますか?

町田:回答スピードを上げることにはどうしても限界があるので、ユーザーの「待たされている感覚」を無くすことに注力しています。例えば、こちらがタイピングしている間にはユーザーのチャット画面には「回答入力中」と出るようになっていたり、長文になる場合は文章を細かく区切って送るようにしています。こうすることで、全ての回答を返すまでのスピードは変わらないですが、「いま対応しています」ということをユーザーに知らせることができるようになり、ユーザーの「待たされている感覚」を無くすようにしています。

 

チャットサポート時は、窓口の対応者がどのようなアクションをしているのか把握できるようになっている

 

ここはメールとは大きく異なるポイントですね。限られた時間の中だと、応対満足度向上のためには、メールはやり取りの数を減らすことが基本ですが、チャットサポートはその逆。やり取りの数を増やすことが応対満足度向上に繋がりやすいのです。

また、チャットサポートはログが残るので、アンケートで不満があったに回答したチャット対応などは、CSチームで見返すようにしています。「文章をここで区切って送ったほうがよかったね」や「これはチャットだと対応が難しいので、メールでの対応に切り替えたほうがいいね」などを話し合っています。リアルタイムでのコミュニケーションを振り返ることができるのは大きなメリットだと思っています。

 

――チャットサポートのログを見返すこともあるのですね。 

町田:量としてはかなり見返していると思います。チャットサポートのログは、ユーザーがサイトのどの操作がわからなくなったのかを可視化するものです。ですので、サービス改善にも繋がる大きな資産だと考えています。

チャットサポートのログを活用して、サービスのFAQページや、ユーザーに配信するメールをサービス担当者と一緒に設計しています。そうすることで、ユーザーが問い合わせをしなくてもよい環境づくりも進めています。

私としては、チャットサポートなどの問い合わせ窓口は最終的に存在しない方がいいと思っています。ユーザーが問い合わせする必要のないUI/UXやFAQページをサービス内で実現できていれば問い合わせ自体が必要ないからです。ユーザーにとってはそれが一番幸せな状況だと思います。gooのCSとして、問い合わせ情報をもとにサービス開発にも携わっていくことで、問い合わせ0件の実現を目指しています。


――ありがとうございました。


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

アプリ開発のプロ集団!10ヶ月で11本のアプリをリリースしたNTTレゾナントのアジャイルデザインチームの開発手法に迫る

2018-08-09 | ★もっと知りたい!NTTレゾナント

アジャイル開発に積極的に取り組み、10ヶ月という期間で11本のアプリを内製で開発したチームがNTTレゾナントにはあります。彼らは開発スピードを上げるために、どのような開発プロセスを進めているのでしょうか。今回はアジャイル開発チームのデザイナー呉さんにインタビューを行い、その開発プロセスに迫りました。

 

 スマートナビゲーション事業部
サービスデザイン部門 アジャイルデザインチーム
呉 宗翰 (ご ぞんはん)

2017年にNTTレゾナントに入社。アプリ開発をスピーディに行うアジャイルデザインチームでデザイナーを務める。人間中心設計の資格を持ち、UIデザインだけでなく、ユーザー調査を通じたUXデザインも担当している。

 

新規アプリを立て続けに開発するにはアジャイル開発がベストだった。

 

――呉さんのチームでは、アジャイル開発を取り入れているとのことですが、そもそもなぜアジャイル開発を採用しているのでしょうか?

呉:既存の開発手法であるウォーターフォール開発では、あらかじめ全体の機能設計を定義して、機能を実装します。仕様が決まっている分、進捗を管理しやすい利点があります。ただ、新しいアプリを開発するときは、開発段階の途中で仕様の変更や、コンセプトの再設計をするというのはよくある話です。リリースの日付が決まっている以上、スピーディかつ柔軟に対応する必要があるのですが、ウォーターフォール開発は手戻りすることを想定していない手法ですので、スケジュール通り進めることが難しくなります。

私達のチームのミッションはアプリを出し続けることで、市場のニーズを探り、市場に価値あるアプリを創出することです。ユーザーの反応を見てグロースできそうであれば、gooのサービスとしてリデザインして、将来的にはgooの接点を拡大していこうと考えています。そのためには、新規アプリを立て続けにリリースしていく必要があります。それを実現するために、既存のウォーターフォール開発ではなく、仕様変更に対してもスピーディかつ柔軟に対応できるアジャイル開発を採用しました。

 

――具体的にどういうプロセスでアジャイル開発を進めたのでしょうか?

呉:私達が採用しているのはアジャイル開発の中でも最もメジャーなスクラムという手法です。スクラムでは、長期間の緻密な計画を立て開発していく従来の手法に対して、短期間の開発サイクルを反復していきます。この1回のサイクルをスプリントと呼んでいて、私達のチームでは1回のスプリントの期間は1週間もしくは2週間と決めています。1つのアプリをリリースするまでに6回のスプリントを繰り返しています。

前半のスプリントでは、ユーザー調査やアプリのコンセプトの設計、モックアップの作成。後半でアプリの実装やブラッシュアップ、脆弱性の対策などを行います。スプリントごとにレビュー、振り返りを行い、状況によっては次回のスプリントでの開発内容を変更します。

 

――アジャイル開発ならではの苦労ってありますか?

呉:計画段階で厳密な仕様を決めていないため、開発の方向性が途中で変更することが多いことですね。

「結婚活動ノート」という婚活中やマッチングアプリを使っているユーザーが彼氏(彼女)候補とのやり取りを記録していくことができるアプリを7月にリリースしました。このアプリの主な機能は、婚活中に複数の候補者とデートしたときの印象やエピソードを記録していくことで、相性を視覚的に表示してくれることです。

実は、この機能は当初から考えていたわけではありません。実際にユーザーインタビューやコンセプトの見直しを並行して行ったのですが、1回目のスプリントでのUIと最後のアプリのUIでは大きく異なります。アジャイル開発では、良くしようと改善を繰り返し、仕様を追加していくことで、当初の計画からずれてしまうことがあるのです。

スプリント1回目のUI


リリース時のUI

 

当初は複数の候補者を比較する機能が特徴だったが、ユーザーインタビューの結果、比較することで候補者の悪いところに目がいきがちになることがわかり、機能を変更した。

 

――仕様が変わっていく中で、プロダクトのコンセプトやタスクに対する認識を合わせていくことが難しそうですが、何か工夫されていることはありますか?

呉:各スプリントの開始前に、そのスプリントではどういうタスクを処理すべきか、チーム共通のダンボールのボードに付箋を貼りながら決めています。そうすることで、お互いコミュニケーションを取りながらタスクを決められるので、「なぜこのタスクをするのか」がチームの共通認識になるのです。 

また、部屋の片隅にダンボールのボードをいつも置いているので、どういうタスクがあるのかもすぐ目に入ります。デジタルなタスク管理ツールもいろいろと試してみましたが、このダンボールのボードが私達には一番あっていますね。  

 

青線でタスクの優先度を区切りスプリントごとのアクションを決めている。

 

――アジャイル開発によって、短期間でのアプリリリースを続けられていますが、今、振り返ってみて、いかがでしょうか?

呉:アジャイル開発の書籍や、そのノウハウが書いてあるWeb記事などをいろいろと読んできたのですが、それがそのまま今の私達のかたちになっているわけではないと思います。アプリのリリースを続けるなかで、とにかく動いてみるという姿勢で試行錯誤しながらチームの文化にあったアジャイル開発を見つけることができたのだと思います。アプリの作り手として、作ったアプリだけを見直すのではなく、その作る過程についても考察を続けることで、ユーザーに良いアプリを届けられるようになりたいですね。

 

――ありがとうございました。

 

呉さんがデザインを担当した「結婚活動ノート」はこちらよりDLできます。

 


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

【開発者必見】Remote TestKitのAppium自動テストクラウドがMagic Podと連携可能に!~テストシナリオ作成から自動テスト実施までをフルカバー~

2018-08-08 | ★もっと知りたい!NTTレゾナント

こんにちは!広報担当の佐藤です!

今日は、NTTレゾナントが運営するクラウド型検証サービス「Remote TestKit(リモートテストキット)」の新情報のお知らせです。

 

【Remote TestKitとは?】

「Remote TestKit」は、スマホアプリやスマホ用Webサイトをクラウド上でスマートフォン実機を使ってテストすることができるサービスです。利用者は実機を購入する必要がなく、クラウド上にある約500機種以上のスマホ・タブレットを使ったテストを実施することができます。また、Appium(アピウム)を使った自動テストクラウドや複数端末の同時操作など、開発者を支援するさまざまな機能があり、検証における負担を軽減します。

 

6月にリリースした新機能「Appium自動テストクラウド」が更に便利になり、Magic Pod(トライデント社)で作成したテストシナリオをそのまま利用できるようになりました

 

 

テスト自動化導入を検討する際、「自動テスト環境を構築するのが大変」「シナリオを作るのが難しい」などの課題が挙がることが多いかと思いますが、自動テスト環境構築不要のRemote TestKitとテストシナリオ作成をAIが補助してくれるMagic Podを使うことで、簡単に自動テストを導入することができます。

 

モバイルアプリやサイトのテスト自動化を検討されている方は、ぜひこの機会にお問い合せください!


お問い合わせはこちら→https://appkitbox.com/testkit/test-consulting/


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

gooニュースアプリを大幅リニューアル! ニュースアプリ後発だからこそ、考えることができたユーザーへの価値とは?

2018-07-30 | ★もっと知りたい!NTTレゾナント

2018年1月にリリースしたgooニュースアプリ

アプリのコンセプトである「大好きをもっとそばに」の実現に向けて、ニュースの閲覧傾向を可視化する機能「インフォグラフ」、音声ニュース「皆藤愛子のgoo Today!ニュース」といった機能を追加してきました。さらに7月5日にはAndroid版のUIを大幅リニューアル(iOS版は8月実施予定)。ニュースアプリが乱立している中で、担当ディレクターの松本さんは「gooらしく尖った方法で目立ちたい」と語ります。今回のUIリニューアルの背景と効果、さらにgooニュースアプリの今後についてインタビューしました。

 

メディア事業部 ポータルサービス部門 ニュースチーム 松本 龍
2015年にNTTレゾナントに入社。gooニュースチームでブラウザ版gooニュース

のディレクターを務め、機械学習によるニュースレコメンド「マイニュース」の導入に携わる。現在はgooニュースアプリのディレクターを兼任。

 

「好きなキーワードをフォローする」ことにあった落とし穴 

――今回のリニューアルですが、どういった背景があったのでしょうか?

松本:
gooニュースアプリの大きな特徴として、「好きなキーワードをフォローすることで、そのキーワードに関するニュースを追い続けられる」というものがあります。例えば、ドラえもんが好きな人は、「ドラえもん」の関連ニュースが、阪神ファンなら「阪神タイガース」の関連ニュースが流れ続けるタイムラインを作るといった具合に。ですので、アプリをリリースした当初はユーザーがアプリをカスタマイズして、ユーザー自身がオリジナルのニュースアプリを作っていくことに重きを置いたデザイン設計をしていました。ただ、リリース後のユーザーレビューを見ていると、「どういうキーワードをフォローしていいかわからない」というコメントが複数あったんです。

 

――確かに、「好きなキーワードをフォローして」と言われても、どういうキーワードをフォローすべきなのか、すぐに思いつかないですね。

松本:
そうなんです。「好きなもの」をすぐに思いつく人って思っていたよりもいなかったんですね(笑)。ですので、キーワードをフォローしてニュースを読むという前提をまず見直すことに
しました。どんなユーザーでも、まずは“ニュースを読む”という体験をできるものにしようと。

 

――“ニュースを読む”とは具体的にはどういった改善を行ったのでしょうか?

松本:
アプリを開いたファーストビューでブラウザ版と同じく、プロの編集が集めたニュースをアプリでも見られるようUIを調整しました。リニューアル後では、アプリを開いた瞬間に、注目ニュースがすぐに見られるようになりました。

今回のリニューアルで想定していなかった効果もあります。それは、リニューアル後のほうが1人あたりのキーワードフォロー数が高いということです。

 

――キーワードフォローを前提としない設計にしたのであれば、1人あたりのキーワードフォロー数が下がりそうですが?

松本:
ニュースを読むこと自体が、気になるキーワードを見つけることに繋がっているのだと思います。そして、ニュースを読むうちに、「このニュースをもっと知りたい」と思ったユーザーがキーワードをフォローしていっているんじゃないかと。つまり、「大好きをもっとそばに」を実現するためには、そもそもユーザーに自分が大好きなものが何なのかに気づいてもらう必要があったんです。急がば回れですね。

 

速さは正義 

――UI以外での改善点はありますか?

松本:
先程の話したUIリニューアルは定性的な部分での改善ですが、定量的な改善として記事表示スピードを上げています。リニューアルしたAndroid版で3倍ほど表示スピードが上がっています。8月にリリース予定のiOS版のテストアプリでも同様のスピードが出ています。

 

――3倍はすごいですね!スピードの改善はどのように行ったのでしょうか?

松本:
APIの呼び出し回数を減らすことが一番大きな改善ポイントですね。以前はAPIを機能単位で呼び出していて、1つの画面を開くのに複数回のAPIを呼び出すことになっていました。リニューアル版では、このAPIの呼び出しを最小限にしています。基本的に1つの画面で1回のリクエストです。

また、アプリ内の情報はキャッシュしていくことを徹底しました。これによって、通信の無い状態でも以前に取得している情報を表示できるので、アプリ起動直後に記事が出るのをユーザーが待たないといけないという状態を無くしました。これで記事表示の体感スピードはかなり改善されたのかと思います。

 

――スピードの改善はユーザーにどういう影響を与えるのでしょうか?

松本:
スピードの改善は、アプリの使いやすさに直結します。特にニュースアプリは、ニュースの一覧ページと記事ページを行き来するのでページ遷移が多くなる性質です。ですので、そのスピードをどれだけ上げられるか、ニュースアプリを提供する各社が躍起になっています。

gooニュースアプリでは、リニューアル後、ユーザーの1日あたりのアプリ利用頻度が向上しました。スピードが上がることで、スキマ時間でも見てもらえるようになっていて、ニュースを小刻みに見てもらえるようになっているのではと思います。

 

UIリニューアル後、横ばいだった1ユーザーあたりの訪問回数が増加

 

他社とは違うパーソナライズを提供する

――今後、どのようにアプリを育てていきたいですか?

松本:
ニュースを通して、ユーザーが気づいていない発見を提供することができるアプリにしたいです。まだユーザーが知らないことを、ユーザーにあったかたちで伝えることをしていきたいんですよね。

各社のニュースアプリには機械学習よるパーソナライズが採用されています。今まで読んだ記事の傾向を学習して、この人はこういうニュースを読みたがっていると機械が判断して、ニュースを提示します。

gooニュースでもパーソナライズをやっていますし、今後も拡張していきたいんですが、他のニュースサービス?ニュースアプリ?とは違うgooらしいパーソナライズを考えています。

 

――gooらしいパーソナライズ?

松本:
はい。単にユーザーの好みだけに合わせたニュースのパーソナライズだと、芸能人の不倫騒動や炎上系のニュースばかり提示してしまうことにも繋がります。gooニュースは、メディアとして読者の世界が広がるようなファクトを伝えていけるようになりたいんです。 

gooらしいパーソナライズをアプリでかたちにしたのが、インフォグラフです。自分がどういうニュースを読んだのか、そして自分がどういうニュースを読むべきなのか。それを常に確認してもらうことができるようになっています。今回のリニューアルでも、インフォグラフのUIをより使ってもらいやすいように変更しました。

 

 

 

インフォグラフでは自分が読んでいるニュースの傾向と、
「経営者」「スポーツ選手」などが読んでいるニュースの傾向を比較できる。

 

gooニュースアプリは、ニュースアプリとしては後発です。すでに市場にいくつものニュースアプリがあって、ライバルたちは手強いです。でも、後発だからこそ、そこに勝ち目があるとも考えています。後発だからこそ、既存のニュースアプリにはない、自分がどういうニュースを読むべきなのかを伝えるというユーザーへの価値を提供できるのではと。gooニュースアプリはまだまだ成長過程です。gooらしく尖ったスタンスでユーザーに面白がってもらえるようなアプリにしたいですね。

 

――ありがとうございました。

 

リニューアルして、さらに速く、わかりやすくなったgooニュースアプリ。ぜひ使ってみてください。

Android版はこちら
iOS版はこちら


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

【エンジニアに訊く】OSSのCloud Foundryをgooのビッグサービスで導入するとどうなった?インフラエンジニアとサービスエンジニアに訊いてみた。

2018-07-17 | ★もっと知りたい!NTTレゾナント

※今回はITエンジニア(主にインフラエンジニア)の方向けのインタビュー記事です。

ヤフー、楽天といった国内のテックリード企業がこぞって導入を始めているOSS(オープンソース・ソフトウェア)のPaaS基盤Cloud Foundry。2017年7月からgooのビッグサービスの1つである「いまトピ」で導入を開始しました。今回は、Cloud Foundryの導入を決めたインフラエンジニアと、実際に導入を行った「いまトピ」「gooランキング」などを担当するサービスエンジニアにその効果を訊きました。

 

【Cloud Foundryとは】

オープンソースのPaaS基盤。アプリのコードをdeployするだけで、Webサービスが稼働する環境を提供できる特長があります。アプリの開発者はサーバーの管理や構築といった手間を省くことができるため、アプリのコードを書くことに集中できるようになります。CloudFoundryを導入することでサービスの迅速な開発が可能となり、ビジネス全体をより加速させることができると期待されています。NTTレゾナントでは、NTTソフトウェアイノベーションセンタとの協力の元、自社クラウドにCloudFoundryを導入しました。


右:ソリューション事業部 サービス基盤部門 大木 和也
2015年にNTTレゾナントに中途入社。gooを中心としたサービスを支える全社共通基盤の設計・構築・運用を担当。現在はNTTレゾナントのPaaS基盤として、Cloud Foundryの運用を担当。「Cloud Foundryなら任せろ!」が口ぐせ。

左:メディア事業部 ポータルサービス部門 熊谷 直也
2017年にNTTコミュニケーションズに入社。同年にNTTレゾナントに配属。「いまトピ」「gooランキング」のCloud Foundry化を対応。現在各gooサービスのCloud Foundryカットオーバーにも取り組んでいる。あだ名は「クマ」。

 


煩雑なインフラ管理からサービス担当を解放させる

 

――国内外で導入が進んでいるCloud Foundryですが、gooではちょうど1年ほど前に「いまトピ」で利用を始めました。まずはCloud Foundry導入の経緯を教えてください。 

大木:
サービス基盤部門では、プライベートクラウドとしてIaaS基盤であるOpenStack*1を2014年に導入、サービス担当にこれを提供してきました。

現在のNTTレゾナントのOpenStackでは、ミドルウェアなどのアプリ実行環境はサービス担当が自前で構築・運用する必要があり、サービスをよりスピーディーにリリースしていく上でこれが大きな負担になっていました。そこで、サービスの開発、リリースに関係のない部分は基盤部門で巻き取ろうということで、PaaS基盤であるCloud Foundryの導入を決めました。

*1: OpenStackは、オープンソースのIaaS基盤。仮想マシンとストレージ、ネットワークといった、低レイヤーのリソースを提供するクラウド環境が構築可能です。

 

――ヤフー、NTTデータなどはPivotalジャパン製のCloud Foundryを採用しているようですが、一方で、NTTレゾナントではOSSのCloud Foundryを採用しました。OSSならではのハードルはありましたか?

大木:
Cloud Foundry自体を理解することが一番の障壁でした。OSSのCloud Foundryを自前で導入し運用するということは、Cloud Foundryが動作する仕組みを自分達でしっかりと理解しないと、トラブルシュートや監視、機能改善などの基本的な運用ができないということです。Cloud Foundryは多くのマイクロサービスの集合体であるため、基本的な構成やサービス間のつながりを理解するだけでも時間がかかりました。また、開発が非常に活発なプロダクトですので、新しい機能や内部動作の仕様変更などが頻繁に発生し、常に最新の情報を追いながら開発・検証を進める必要があった点も苦労しました。

 検証をしっかりと行ったうえで導入することにしたので、導入にかかった期間は1年ほど。日本国内でもOSS版のCloud Foundryを導入している事例がそれほど多くないので、情報収集をするのも大変でした。

 

 まさに“雲”を掴むようだったとCloud Foundry導入当初を振り返る大木さん 

 


サービスのスケールアウトにかかる時間は “1週間” から “2秒” に


――gooとして、Cloud Foundryを初めて導入したのが「いまトピ」でした。「いまトピ」を選んだ理由は何でしょうか? 

大木:
Cloud Foundryの検証が完了した段階でgooのサービス担当に声をかけてみたんです。多くのエンジニアはOpenStackでのサービス開発に慣れていて、新しい技術であるCloud Foundryの利用には少し抵抗があるようでした。その中で、Cloud Foundryに興味を持ってくれたのが、熊谷さんが所属する「いまトピ」の開発チームでした。 

熊谷:
私は単純に入社したばかりで、OpenStackの開発にも慣れていない状況でしたので(笑)。エンジニアとして、スキルや知見を身につけていくためにもCloud Foundryの導入に興味がありました。

  

――Cloud Foundryの導入メリットで大きかったものは何でしょうか?

熊谷:
1つはサーバーの故障の影響を受けないということですね。OpenStackだと、サービスを乗せているサーバーがマシン故障などで動かなくなってしまい、サービスが止まってしまうリスクがあります。Cloud Foundryだと、サーバーに依存しないので、サーバーが故障しても別のサーバーで自動的にサービスが復旧するので、そこのリスクが無くなりました。 

もう1つはスケールアウトの手間ですね。OpenStackでサービスを新しく立ち上げたとき、どれだけユーザーが来るかわからないので、規模を予想してサーバーの台数を確保しています。これが難しくて、サーバーの台数が余ったり、逆に足りなかったり、みたいなことが多々あります。

大木:
OpenStackの場合でも、もちろんスケールアウトしてサーバーの台数を増やすことは可能です。ただ、サーバーを1台スケールアウトしようとすると、仮想マシンの構築や、ロードバランサーの設定、検証などで大体1週間ほどかかってしまうのです。 

熊谷:
この作業が、Cloud Foundryだと、コマンド一発、2秒です。欲を言うと、今後はコマンドを打たなくてもスケールを自動的に変えてくれるようにしてもらいたいですね。そうなると、もはや意識する必要すらなくなるので。 

大木:
なるほど。それは検証が難しそうですが、今後どこかのタイミングで取り入れていきたいですね。

 

 「Cloud Foundryで、アプリのサイジングの自動最適化を期待しています」と熊谷さん  



Cloud Foundryの攻略本を作りたい


――Cloud Foundry導入によるメリットが大きいようですね。一方で現状のCloud Foundryについて課題はありますか?

大木:
全社的に標準化された開発手法が確立されていないことですね。OpenStackで確立され、受け継がれてきた開発手法は、Cloud Foundryでそのまま利用できるものがほとんどありません。PaaS基盤というものの特性をしっかりと理解し、それに合わせた開発手法を確立する必要があります。

 Cloud Foundryの利用を社内に広げていくために、「とっつきにくい」という印象をとにかく変える必要があります。使いこなしていただくと、今よりも楽なのは間違いないので。「Cloud Foundry解体真書」みたいな攻略本を作りたいですね。

 

  

Cloud Foundryの攻略本(イメージ)

 

――今後、Cloud Foundryをどのように進化させていきたいですか?

大木:
現在のCloud Foundryの仕様上、画像サーバーやデータベースなどは取り扱えないので、OpenStackで管理することになっています。なので、今後はそれらも可能な限りCloud Foundryで巻き取っていきたいですね。また、gooではAIなど先進的な分野に取り組むにあたって、プログラミング言語も多様になってきています。現在NTTレゾナントのCloud FoundryはPHPにのみ対応していますが、今後はあらゆる言語でCloud Foundryが使えるように対応していきたいです。 



【広報のあとがき】

Cloud Foundryは、全社にも展開していく予定とのことでした。100を超えるWebサービスを運営しているNTTレゾナントにおいて、インフラ管理の負担軽減はかかせません。今回の「いまトピ」における事例は、今後の全社展開において、貴重な財産となりました。NTTレゾナントはこれからも新しい技術に対して好奇心を持ちながらチャレンジを続けていきます。

 


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

【エンジニアに訊く】脆弱性スキャナ一斉導入から1年経ったけど、その効果は?インフラエンジニアとサービスエンジニアに訊いてみた。

2018-06-26 | ★もっと知りたい!NTTレゾナント

ポータルサイト「goo」を運営するNTTレゾナントのサービス数は個人向けと法人向けを合わせるとその数は150。サーバーは4500台以上の規模となります。2017年7月、これら全てのサービス、サーバーに対して、新たに脆弱性スキャナVuls*1を一斉導入しました。今回はこのVuls導入を決めたインフラエンジニアと実際に脆弱性の対応をしているサービスエンジニアに、Vuls導入の経緯とその効果について訊きました。

*1: 脆弱性をスキャンするためのソフトウェア。サーバーの脆弱性情報を取得して、どんな脆弱性があるのかを検知する。読み方は「バルス」

 

右:ソリューション事業部 サービス基盤部門 白濱 將人
1996年に日本電信電話株式会社に入社。2004年にNTTレゾナントに配属。gooIDシステム、goo課金システムの開発を担当。直近では、経済産業省からのクレジットカード情報の取扱いに対する指針に従い、自社ECにおけるカード情報非保持化に対応するための決済システムを開発。Vulsのシステムを運用。

中央:ソリューション事業部 サービス基盤部門 渡邉 理恵
2012年にNTTコミュニケーションズに入社。2015年にNTTレゾナントに配属。主に社内クラウドにおけるPaaS(Platform as a Service)基盤を運用。Vuls導入における設計から開発までを担当。 

左:デジタルマーケティング事業部 広告営業部門  安田 つくし
2016年にNTTコミュニケーションズに入社し、NTTレゾナントに配属。gooの広告営業における技術的サポートを担当。広告レコメンドのためのデータ分析システム・業務自動化ツールの開発・運用を担当。また、サービス担当として、Vulsで検知された脆弱性対応にも取り組んでいる。

 

 



脆弱性の検知と対応状況の把握が課題だった

 

ーー本日は2017年7月に導入したVulsについてお話を伺いたいと思っています。早速ですが、Vulsを導入することになった経緯から教えてもらえますか?

 

渡邊
Vuls導入の大きな理由として、脆弱性の検知とその対応状況把握の効率化です。Vuls導入前の脆弱性の対応は、サービス担当者毎に管理・対応し、対応状況を基盤部門が一元管理のためにサービス担当者へ個別に状況確認をするという運用でした。
この運用だと、各サービス担当者が脆弱性の検知を個別に調べて対応しないといけないという課題があり、そこがサービス担当のストレスになっているということを感じていました。また、基盤部門としては対応状況を個別に連絡し、確認する手間が課題でした。
そこで、全社的に脆弱性を一元的に検知、報告すれば、各サービス担当と基盤部門の課題が解決できるということになり、Vulsの導入に至りました。

 

ーーなるほど。Vuls導入前は脆弱性対応のルールなどはあったのですか? 

白濱
サービスに対しては アプリケーションの脆弱性監査、ネットワークの脆弱性監査をルール化して運用していましたが、脆弱性への対応レベルをさらに引き上げるために、一斉に一元管理する必要性を感じていましたね。 

 

ーー脆弱性の検知以外にも対応レベルの把握も求められていたのですね。検知ツールはいろいろとあると思うのですが、なぜVulsを選ばれたのでしょうか。

渡邉
Vulsの大きな特徴は、導入にあたりサーバー側にソフトをインストールするなどの作業をほとんど必要としないということです。他社のツールでも似たような検知ツールがあるのですが、いろいろと導入に手間がかかりそうだという印象でした。またお金の面でもOSS*2なのでライセンス費用も発生しませんし、レゾナントの対応フローにあわせてカスタマイズできるということもありVulsにしました。

*2: オープンソースソフトウェアの略。無償で公開され、誰もが改良や機能追加をして、再配布が可能なソフトウェアを指す。(goo辞書より)

 

ーー具体的にはどういう部分をカスタマイズしたのでしょうか?

渡邊
Vulsは脆弱性を検知するのみなので、そこから各サービス担当者へ通知したり、通知の後の進捗管理は含まれていません。その通知や管理するというところは他のOSSなどと組み合わせて自社で開発しました。脆弱性を検知すると自動的にプロジェクト管理ツールのRedmineに起票されるシステムを作り、それで運用しています。 

 

ーー各サービス担当者へ通知するにはメールやコミュニケーションツールという方法もある中で、Redmineを選んだ理由は何かあるのですか?

白濱
サービスごとの脆弱性の対応状況を把握しておきたかったのですが、Redmineだとチケットのステータスを見ればすぐにわかるので、相性がよかったのです。また、もともと各サービスへの脆弱性以外のアラートをRedmineで通知していたので、サービス担当が慣れているツールをそのまま利用できるということも要因の1つではあります。 


 


脆弱性の検知から見えた課題とは

 

ーーVuls導入にあたって工夫された点はありますか?

渡邊
NTTレゾナントはプライベートクラウドを導入しており、サービスの新規開設や構成変更などがほぼ毎日行われています。このような変化が多い環境でも必要な情報を自動的に収集して管理できるようにしました。サービスの数は150、サーバーの数はおよそ4500台と大規模なのですがこれを毎日スキャンする必要がありその環境を作るのに苦労しました。4500台のサーバーに1台ずつスキャンすると1日でスキャンは絶対に終わらないことが分かりました。そこで大量のサーバーに対して並列してスキャンする仕組みを開発し、現在はVuls専用のサーバーを20台並べることで毎日スキャンすることが出来ています。 


ーー導入にあたって説明会を何度かされていましたが、サービス担当からの反応はどうでしたか?

渡邉
「フロントエンドとバックエンドとでは取り扱うデータや外部からのアクセス方法が異なり、同じ脆弱性であっても危険度が違うので、そこは分けて管理させてほしい」「お客様のサービスと自社サービスとでは対応する際の確認フローが違うので、そこはケアしてほしい」などの要望がありましたね。 

 

ーー導入後、サービス担当の反応は実際にどういう声が上がってきましたか?

白濱
「脆弱性の対応が辛い」って声が聞こえてきましたね(笑)。脆弱性の対応は何よりも優先して対応するべきものだということは、サービス担当もわかっていますが、対応は大変です。サービス担当の大変さもわかりますが、セキュリティという守らなければならないものではありますので、サービス担当者と対話をしながら迅速に対応できるようにフローの見直しなどをするようにしています。

 

脆弱性対応は運用フローもサービス担当と一緒に考えているとのこと
by 渡邊さん・白濱さん

 

ーーVuls導入してみて見えた課題はありますか?

白濱
検知した脆弱性への対応について、各サービス担当者ができない部分は私たちがサポートするようにしていますが、サービス担当の脆弱性対応に関する知識や技術レベルもあげることで、自立した対応フローにしたいと思っています。

これまでは、脆弱性対策の社内勉強会で参加するのは、エンジニア中心でした。今後は、エンジニアだけではなく、プロデューサーや営業担当にも勉強会に参加してもらうなど裾野を広げていきたいと思います。
脆弱性対応はトラブルが発生して初めてその対策の重要さに気づかされるんですよね。防災訓練と一緒なんですが、日頃からモチベーションを高く保って脆弱性対応に取り組んでいきたいですね。

 



サービス担当に寄り添いながら脆弱性に対応していくために

 

ーーそれでは、サービス担当の意見も聞いてみたいと思います。安田さんの所属する広告営業の技術チームではVuls導入前と後で何が変わりましたか?

安田
導入前は、セキュリティ担当からの周知や緊急に対応の必要がある脆弱性を自分たちで情報収集することをやっていました。ただ、この運用だと、対応する人が同じ人になってしまいがちで、脆弱性への対応が属人化してしまうことが課題でした。Vulsの導入後は、対応する人を私がアサインして対応のスケジュール管理をするようになったので、スピーディーかつ確実に対応することができるようになりました。脆弱性を知ることに週に数時間~半日ほど時間をかけていたので、それが無くなったことも大きいです。 

 

安田さんが対応者とスケジュールを決めて運用

 

ーー安田さんが脆弱性の対応者のアサインとスケジュール管理をしているのですね。具体的にはどういうフローで運用しているのでしょうか?

安田
Redmineに起票されるとアラートメールが私に飛んでくるので、それを見てチーム内に、対応の必要があるサーバーの一覧とアップデートするパッケージの一覧を共有しています。そのときに、対応者のアサインと対応スケジュールも決めて合わせて伝えています。脆弱性の対応が完了したら、Redmineのチケットが自動でクローズするので、それを確認するとすべての対応が終了する感じですね。例外的に緊急度が高いものや、影響範囲が大きいもの、対応に時間がかかるものは、チーム内の定例会議で細かく共有するようにしています。

 

ーー実際にVulsを入れてみて、良かったなと思うところと逆に悪いところはありますか?

安田
良いところは余計な心配をしなくてよくなったということが大きいですね。サービス担当としては、脆弱性を探す時間が減ったことと、きちんと対策することで、脆弱性に気を取られないで良くなったという心理的なストレスが大きく軽減されたように思います。サービスの開発業務に専念できることが助かっていますね。

悪いところは、余計な心配をしなくてよくなった代わりに脆弱性を深く考えなくなってしまっているなと思います。先程、モチベーションの話が出ましたが、「Vulsを入れたから安心」ではなく、しっかりと脆弱性の事件やニュースを自分で情報収集しないと、脆弱性への意識自体が薄れてしまうことになってしまいます。そこは気をつけないといけないですね。

 

ーー担当者として、Vulsにこういう機能が欲しいなどはありますか? 

安田
私達が管理しているサーバーは約100台あるので、どのサーバーのどのパッケージにどの脆弱性があるのかを把握するのが大変です。そんなときに、Vulsで検知された結果を一覧できるVulsrepoを使っています。Vulsrepoを見れば、サーバー、パッケージ、脆弱性ごとにソートできるので。今は、それをエクスポートできる機能が欲しいですね。今は、Vulsrepoの画面からコピペしてエクセルに貼り付けているんです(笑)

 

サーバー名やパッケージ名でソートできるのでVulsrepoはよく使っている by安田さん

 

ーーえ?エクスポート機能がないんですか?

白濱
ないですね。俺も欲しいくらい(笑) 

一同:
爆笑

「エクスポート機能は俺も欲しいんだよ~」と苦笑する白濱さん

白濱
エクスポート機能以外にも、Vulsrepoでは、数字として可視化している状況なのですが、ビジュアル的にももっとわかりやすくするためのダッシュボードを提供したいですね。

あとは、Vuls本体もバージョンアップしていきたいですね。今はサーバーにあるパッケージのログから脆弱性を検知しているのですが、もっと一般的な脆弱性情報から検知したりすることもできるようになります。検知の精度を上げていくという意味で、そこにもチャレンジしていきたいです。

 

【広報のあとがき】
Vulsにより脆弱性が迅速に見つかることによって、脆弱性検知に必要だった時間削減と脆弱性に対する心的ストレス改善に対して大きく効果が出ているようでした。ツールのさらなる改善と仕組みづくりでサービス担当者の手間を緩和していきたいと熱い想いを語ってくれました。サービス担当に寄り添いながら、より安心安全のサービスをともに作り上げていきたいという姿勢が感じられました。

 


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

【利用者の声】自分で選んでスキルアップ。「カフェテリア型研修」とは?

2018-06-21 | ★もっと知りたい!NTTレゾナント

NTTレゾナントでは、業務に役立つスキルを自らが選択して受講する「カフェテリア型研修」という制度があります。
カフェテリアで料理や飲み物を選ぶように、社員が自ら21企業700講座といった多くの研修プログラムから自由に選択して受講できる制度です。マネジメントやコーチング、プログラミングやデザインなど多岐に渡るコースを年間30万円まで好きに選ぶことができます。
今回は、実際にカフェテリア型研修制度を利用した藤本啓子さんに話を聞いてみました。

 

メディア事業部 ソーシャルサービス部門 藤本 啓子

2004年にNTT西日本に入社。
2010年7月よりNTTレゾナント勤務。gooサービスの運営や新規サービス開発、事業推進業務などを経て現在ターゲット編集担当。好きなものはビールといちご。

 

ーー現在のお仕事の内容を教えてください

藤本:
現在、メディア事業部にて特定ユーザー向けのメディアサービスを複数運営するターゲット編集チームに所属しています。ユーザー参加型のランキングサイト「gooランキング」や、gooとdmenuの膨大なログデータからトレンドを読み解く「goo+dランキング」の担当をしています。また、gooが20周年を迎えるにあたり開設された全社横断組織「ブランド戦略室」の一員でもあります。

 

ーー藤本さんは「カフェテリア型研修」でどういう研修を受講されたのですか?

藤本:
カフェテリア型研修は、必要だと思った研修があればすぐに参加できるので頻繁に使っています。最近では、UXブランディングに関する講座とインナー広報実践講座を受けました。ブランド戦略室では、gooのブランドを再定義することと、それを社内に浸透させていくことに取り組んでいます。マーケットの中でわれわれの大切な資産である「goo」をどう再定義するのかを自分たちで考えて実践しますが、新しいメソッドを学ぶことや、他社ではどういうアプローチをしているのかを講師の方、他の受講者の方とコミュニケーションすることなどを目的として受講しました。

 

ーー実際に受けてみていかがでしたか?

藤本:
ブランドを浸透させるにはそもそも何が大切か、「goo」として社内のみんなでどうそれを共有していくかという取り組みは私にとって初めてのことで、手探りで進めていました。研修参加により、知見を積んだ講師の方の知識から実践的なノウハウを吸収することもできました。また、他の受講者の方とも実践における課題点なども共有することができ、横のつながりもできました。同じような課題を持っている人とコミュニケーションして様々なケースに触れられたのはとってもよい経験でした。

 

ーー研修を受けた後、ブランド戦略室ではどのような活動を実施したのでしょうか?

藤本:
ブランド戦略室で再定義した「goo」の価値をサービスとして提供しユーザーのみなさまに認知していただくことが大切です。そのために、ブランドコンセプトである「gooがつくるしかないので( ー`дー´)キリッ」を実現している未来のサービスを映像化しました。さらに、社内で共通の認識として深めるために、この映像を社内向けに公開するイベントを開催しました。 

このとき、私はファシリテーターを務めたのですが、「まずは全体像をしっかりと把握してもらう」「参加者のモチベーションを引き出せる設計にする」など、研修での学びを実践し、活発な議論と共有が生まれました。今振り返ってみると、これらを意識したことで、参加者の満足度や理解度に大きく影響があったと思いますね。

「カフェテリア型研修」制度の利用は全社で積極的に推奨してもらっているので、これからも新たなナレッジ獲得のために研修に参加したいと考えています。

 

ーーありがとうございました。

 

NTTレゾナントでは、「goo」を一緒に作るエンジニアやデザイナー、プロデューサーを募集中です!採用ページでは、実際のエンジニア社員へのユーザーインタビューや社内カルチャーを紹介していますので、ご興味があればぜひご覧ください。

 


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

【エンジニアに訊く】創立1年目でメンバー5人のシリコンバレーのスタートアップにインターンシップ!? NTTレゾナントの「短期海外派遣プログラム」とは?

2018-04-02 | ★もっと知りたい!NTTレゾナント

NTTレゾナントは、最先端のサービスを作り出していくために、最先端のテクノロジーを体験できる環境を作り出しています。「短期海外派遣プログラム」という人材育成制度はその環境づくりにおいて代表的な制度です。「短期海外派遣プログラム」では、約3ヶ月間、シリコンバレーを中心とする企業でのインターンシップを体験します。これにより、社員が全く新しい環境で切磋琢磨しながら、IT業界の最新動向やテクノロジーへの知見を深めるとともに、将来的なキャリア形成の実現を目指しています。

今回は2017年10月にこのプログラムを使って、シリコンバレーのスタートアップ企業へインターンをしたエンジニアにインタビューを実施。その環境や体験について話を伺いました。

 

デジタルマーケティング事業部 コマース部門 松木 久幸
2013年NTTコミュニケーションズ入社。2013年8月NTTレゾナントも入社し、デジタルマーケティング事業部コマース部門 EC担当(当時:メディア事業部)へ配属。年間100億円を超える売上規模のECサイト「NTT-X Store」の開発・運用業務を担当。

 


シリコンバレーの会社に転職するのとほとんど変わらない!?

 

――今日はよろしくお願いします。まずは参加されたきっかけについてお話を伺いたいと思っています。どういうことがきっかけで参加することにしたのでしょうか。

松木:
このプログラムを使っていた先輩社員が帰国後の活動報告をしてくれたときに興味を持ったのが始まりですね。ただ、当時は担当していたサービスの改修作業と新人育成のトレーナーをしていて、なかなか行ける状況ではなかったので、興味を持ち始めてから実際に行くまでに少し時間がかかってしまいましたね。

2016年に、「来年は絶対に応募しよう」と思い、上長やチームに相談し始めました。

  

――「短期海外派遣プログラム」のどういうところに惹かれたのですか?

松木:
入社以来、NTT-X Storeのエンジニアとして仕事に対してやりがいを感じている一方で、当時は自分のスキルがどれくらいのものになっているのか知りたかったのです。その時にこのプログラムを知って「これだ!」と思いましたね。どうせスキルを試すなら、思いっきり外に出て実力を試せるこのプログラムが最適だと思ったからです。

 

――なるほど。このプログラムはシリコンバレーなどにある成長が著しいテクノロジー企業で就業体験をするところが大きな特徴の1つとなっていますが、実際にインターン先はどのようなフローで決められたのですか?

松木:
短期海外派遣プログラムの事務局が候補の会社を出してくれます。候補の企業は何十社もあるのですが、そこからHPなどを見て選びました。私の場合は、自分のスキルセットがサーバサイドのプログラミングなので、そこを考慮しながら、興味のあったECの分野に絞りました。


そして、書類審査が通った会社と現地で面接してインターン先を最終的に決めます。

自分で会社を決めて、現地に足を運んで、英語での面接など、フローとしてはシリコンバレーの会社に転職するのとほとんど変わらないと思います(笑)。

 

――たしかに、ほとんど転職みたいなものですね! 英語に対して得意意識はあったのですか?

松木:
実はものすごく苦手です・・・。技術書なども英語で読むので、readingは唯一得意ですが、speakingとlisteningは正直めちゃくちゃ苦手意識がありました(笑)。業務では、海外のベンダと仕事をしたことはありますが、打ち合わせは通訳の方がいたので、業務上での英語のコミュニケーションは今回がほぼ初めての体験でした。

行くと決めてから、スカイプ英会話などを利用して、とにかく英語でコミュニケーションをとる訓練をしましたね。

 

――え、そうだったのですか!? それはものすごく不安だったのでは…?

松木:
いやー、ほんとに不安でしたね。海外経験も旅行で数週間くらいなので。でも、英語が話せなくてもエンジニアとしてのスキルは共通なので、そこに勝算があると踏んでいました。

  


インターン先は創立1年目、メンバー5人のスタートアップ

 

――最終的に派遣先として選んだ会社はどういう会社だったのですか?

松木:
ECサイト向けにマーケティングツールを提供しているシリコンバレーのスタートアップです。創立1年目でメンバーは当時、社長を含めて5人でした。

 

――創立1年目でメンバー5人!?まさにスタートアップってかんじですね。

松木:
そうなのです(笑)。ただ、CEOが連続企業家として有名で、TechCrunch*1のイベントで登壇しているような業界でも地位のある人でした。その背景も知ったうえで勉強になると考え決めました。事実、創立1年目でも優良企業がお客様としてついていましたね。
*1: IT系のスタートアップを中心に取り上げるWebメディア。Disrupt SFなど大規模なイベントも主催する。

 

――具体的にどういうサービスを提供している会社だったのですか?

松木:
ECサイトのレビューなどの定性的なデータを分析できるツールを提供していました。ECサイトのレビューの内容は文章で書かれているので、ひとつひとつ時間をかけて見ていくことしかできなかったのですが、それをネガティブレビュー、ポジティブレビューなど、特徴レベルまでを言語処理によって見える化するツールです 

 

――ECサイトのレビューをまとめて見えるツールは確かにニーズがありそうですね。メンバー5人はどういう構成でしたか?

松木:
CEOを含むビジネスが2人、エンジニアが2人。あとはインターンが1人でした。リードエンジニアもIBMでWatsonを開発していたという雲の上の存在でしたね(笑)

 
派遣先企業のメンバー構成

  

――確かに、すごいメンバーが揃っていますね。スタートアップといえば昼夜通して働く先入観があるのですが、業務時間はどうだったのですか?

松木:
私も意外だったのですが、オフィスにいるのは10:00~17:00のみで、残業するメンバーはいませんでした。

 

――え!? むしろNTTレゾナントの業務時間よりも短いくらいですね!

松木:
「もっとガツガツやらないの!?」と当初持っていたイメージとはギャップがありましたね。ただ、この会社だけがそうなのではないのです。シリコンバレーでは時間に対してではなく、結果に対して給料が払われるので、夕方にはみんな帰宅していましたね。彼らは家族との時間を大切にしていて、夕食は必ず家族全員で食べていました。 

 

――シリコンバレーでは働き方改革が進んでいるのですね。

松木:
そうですね。日本企業よりもずっと進んでいるなと思いました。シリコンバレーの他のスタートアップ企業の人と話す機会があったのですが、そのときも「日本人は働きすぎだ」と言われたくらいです。 

 

――オフィスの雰囲気はどんな感じでしたか?

松木:
とにかくミニマムでした。PCは個人が持ってきて、オフィスにはデスクとモニター、ホワイトボードがあるのみでしたね。

オフィスの様子

 

意外だったのはコミュニケーションの取り方。タスク管理などツールが主体になっているかと思っていたのですが、意外と「みんなで話そう」という空気を大事にしていましたね。メンバーがそれぞれ独立している分、ゴールが揃わなくなってくるので、コミュニケーションは大切にしようというCEOの考えがあったのではと思います。

  


彼らは “テクノロジスト” ではなく “リアリスト”

 

――松木さんはインターン中どういう業務を行っていたのですか?

松木:
機能の設計から実装までエンジニアとしてはほぼ全て任せてもらえましたね。

ジョインした初日に、「このメニューが足りないからつくってほしい」というオーダーがあり、あとはよろしく的な(笑)。最初はかなり戸惑いましたが、とりあえず作ってチェックしてもらい、フィードバックを反映させて実装、また進んではチェックしてもらうといった感じで進めることにしました。プロダクトを完成させてから確認すると手戻りが多くなるので、まずは画面デザインをつくって相談、そのあと枠組みをつくって相談、こうやって進めていましたね。 

 

――確かに一貫して業務を任せられていますね。それでは、業務上大変だったことはありましたか?

松木:
英語以外で大変だったのはシステム環境ですね。開発言語は以前まで触ったことのないPython(パイソン)でした。この会社で働くことが決まったときに開発言語がPythonだと聞いたので1ヶ月弱で猛勉強しました。それが試せることの期待と、本当に大丈夫なのかなという不安が半々でした。3か月で複数の機能を1人でリリースするまでできたので、ある程度は使いこなせたかなという印象です。 

 

――業務のスピード感についてはどうですか?

松木:
スピード感は全員が意識していましたね。これまでの自分の感覚だと、バグがないことが良い品質だと思っていたのですが、現地では“動かさなきゃ始まらない”という考えで多少のバグがあっても、どんどんユーザーに見せていこうというスタンスでした。

すごいのは、出してからちゃんとフィードバックをもらって検証することです。どのメニューをどれだけクリックされたかは日本でもやっていますが、現地ではユーザーや投資家に何度も会ってフィードバックをもらっていました。サービスの規模がそれほど大きくないからこそできる、より実践的なユーザーインタビューだなと思いました。 

 

――以前、「教えて!gooのコードレビューをインタビューしたときに、バグが出てしまうとサービスの運営に大きな影響がでてしまうので、時間をかけてコードレビューを行っていると担当者が言っていましたが、それとは大きく方針が違うように感じます。コードレビュー自体はあったのですか?

松木:
コードレビューはありました。ただ、バグがあるかないかのチェックよりも、システムの保守性についてチェックすることが多かったように思います。私が短期でいなくなるというのがわかっているので、みんながメンテできるようシンプルにかいているかという観点でレビューしてもらっていたのだと思います。 

 

――「教えて!goo」のように、テストの自動化などにも取り組んでいましたか?

松木:
この会社ではやっていませんでしたね。私も、行く前はそういうことをバリバリやっているのだろうなと思っていました。しかし、行ってみると、そもそもエンジニアが2人体制なので、2人が目で見られる範囲で、コミュニケーションをとりながらプロダクトを作ろうという方針でしたね。

「教えて!goo」との開発方針の違いの大きな要因はフェーズの違いだと思います。「教えて!goo」はすでに多くのユーザーがついていて、ユーザーの信頼を失ってはいけないフェーズ。一方でこの会社のプロダクトはそもそもユーザーをつけないといけないフェーズでバグがあったとしても、それよりも大事なことがある、という考え方だったのかなと思います。

 

――シリコンバレーのエンジニアと交流してどういう印象を受けましたか 

松木:
この会社のエンジニアだけではなく、休みの日はシリコンバレーの他の企業が主催していたハッカソンなどにも参加したので、いろいろなエンジニアと交流できました。その中で大きく感じたのが、彼ら全員がビジネス目線を持っているということでしたね。

 

――ビジネス目線を持っている?

松木:
行く前までの印象は、技術レベルが高く、高度なものを突き進めていくっていうものでした。とにかく新しいものを取り入れていく、そういう人たちなのかと思っていたのです。それは実際に間違いではないのですが、それ以上に彼らは、彼らのリソースで今何ができて、何をするべきか、ということを考えて行動していたのです。

ロジックやアルゴリズムを追及するよりも、時間やコストを考慮してその中でどれだけ合理的な進め方ができるかということを意識しているといった感じですかね。そういう意味では、テクノロジストというよりもリアリストというイメージの方が強いです。

 

シリコンバレーのスタートアップに対する想像と現実の違い


 

シリコンバレーのスタートアップを知り、日本のテクノロジー企業を知る

 

――今回のプログラムに参加して一番の発見は?

松木:
やっぱり仕事の進め方ですね。ひとりひとりが自律しているけど、同じゴールを目指してやっているところに感動しました。

日本では、リーダーの指示に従ってメンバーがそれをやることが多いですが、「メンバーも考える」、そして「リーダーはメンバーをどうサポートするか考える」ことが大事だということを体感しました。事実、CEOはうまくいってないところを聞いてくれたり、生活面のことも相談にのってくれたり、いろいろ引き出そうとしてくれていました。「困っていたらオレが助けるよ」という雰囲気を出してくれていました。

日本に帰ってきてから、私もチームのメンバーがそれぞれ自律して考える場を作るように心がけています。定例の会議では、各々が先週うまくいったこと、いかなかったことなど共有しあい、それをどうすればもっとうまくいくか会話する時間を取るようにしました。こうすることで全員が課題に対して当事者意識を持つことができるようになりましたし、課題に対しての解決意識も統一させることができるようになりました。 

 

――当初の目的は「自分のスキルを試す」ということでしたが、ここはどうでしょう?

松木:
今回は初めて使ったPythonでしたが、事前に自習していたことで、自分1人で実装までやり切ることができたのでエンジニアとしてのスキルについても自信がつきました。また、Pythonはデータ分析に強いので、「NTT-X Store」でも導入して、営業担当のアクションを変えていければと思っています。 

 

――実際の現場でも経験を活かしていろいろと模索しているのですね。業務以外での発見はありましたか?

松木:
休みの日などは、シリコンバレーの技術勉強会にも参加しましたが、ここでは逆に日本の技術レベルもぜんぜん劣っているわけではないなと思いました。シリコンバレーのほうが新しいことをやっている印象はありましたが、レベルの差は感じませんでしたね。

その一方で、コンピューター工学の基礎知識がしっかりしているところはすごいなと感じました。エンジニアならコンピューター工学の知識があって当然だと考えられているようでした。就職の面接でもそういった基礎理論が重要視されると聞いたことがあります。そこは多くの日本企業とは違うように感じました。 

 

――なぜシリコンバレーのエンジニアはコンピューター工学の基礎知識が重視されるのでしょうか?

松木:
シリコンバレーのエンジニアの視点が、例えば実装する前にこのプログラムの処理時間はどれくらいのオーダーになるかっていうのを考えているからなのだと思います。また、それがベースにあると新しい言語やシステムに対しても強いですしね。 

 

――なるほど。それでは、最後に今回のプログラムで一番印象に残っていることを教えてください。

松木:
予想と違ったことを発見できたことですね。例えば、新しいツールをどんどん使っているかと思ったら、対面のコミュニケーションをとても重要視していること。また、新しいことを取り入れることが正義ではなく、ちゃんとビジネスを成り立たせることが正義というエンジニアの考え方など。今まで私がもっていた既成概念が全く違っていたことが非常に面白かったですね。あと、シリコンバレーになくて日本のテクノロジー企業にあるものもわかりました 

 

――シリコンバレーになくて日本のテクノロジー企業にあるもの?

松木:
はい。このプログラムがまさにそうなのですが、エンジニアを育成するという制度そのものですね。シリコンバレーには研修制度がありません。ランチやマッサージ施設も無料などといった福利厚生はあるのですが、それは即戦力を引っ張ってきたいからで、戦力とみなされない時点で切り離されてしまいます。 

そういう意味ではNTTレゾナントを含む日本のテクノロジー企業におけるエンジニア育成施策は充実しているなと思います。人の能力を伸ばす制度は日本特有のものでしたね。実際にシリコンバレーのエンジニアもこの制度の話をしたときに「めちゃくちゃいい制度じゃん!」とびっくりしていました(笑)。その面では日本は非常に進んでいると気づきましたね。

 

――ありがとうございました。

 

【広報のあとがき】
シリコンバレーの異文化に触れた松木さん。「ここで得た経験・成長を必ず会社に還元したい」と熱く語ってくれました。このプログラムに行く前から松木さんのことを知っていましたが、帰国後は以前よりもエネルギッシュさが増しているように感じました。当初は“スキルを試す”目的でこのプログラムに参加したとのことでしたが、帰国後は仕事の進め方やマインドも社内に発信していこうとしています。個人の成長はもちろん、チームや組織にとっても、松木さんのこのプログラムでの経験が、有機的に機能していくように思いました。

 


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

【エンジニアに訊く】「教えて!goo」の安定運用を続けるための「愛」のコードレビューとは?

2018-03-15 | ★もっと知りたい!NTTレゾナント

日本でインターネットの普及が急速に進んだ西暦2000年。ポータルサイトgooを代表するサービスのひとつである「教えて!goo」はその年に生まれました。昨年にはAIがユーザーの恋愛の悩みに答えてくれる機能を実装するなど、今もなお、進化し続けるサービスです。

約3,000万件のQ&Aデータを学習し、恋愛の悩みに答えるAI「オシエル」 


今回は、「教えて!goo」のエンジニアにインタビューを行い、サービスを安定して運用するためのコードレビュー*1の取り組みと、その開発文化に迫りました。
*1: ソフトウェア開発の工程で見過ごされた間違いをチェック・修正することを目的としている、ソースコードの検査を行う作業のこと

 

左:メディア事業部ソーシャルサービス部門 伊藤 恵吾
2003年にNTTレゾナントに入社。「gooニュース」をはじめ、gooの数多くのサービスの開発・運用に携わり、gooサービスの技術者を牽引。2015年からプライベートクラウド「Openstack」の導入など「教えて!goo」の開発・運用を技術リーダーとして担当。酒・旅・フットボールをこよなく愛する。

右:メディア事業部ソーシャルサービス部門 矢野 尊之
2016年にNTTレゾナントに入社。「教えて!goo」のエンジニアとして、Webサイト内の改善やアプリとのAPI連携等を開発。2017年5月にアプリ作成に携わり、iOSエンジニアとして訪日版「教えて!goo」のアプリをリリース。現在は、Web版、アプリ版の双方の開発を担当。

 


「教えて!goo」という大樹を育てるには

 

――今回は、サービス開始から18年経った今でも、AI導入や訪日向けサービス開始など、機能拡張を続ける「教えて!goo」がコードレビューに対してどのような取り組みを行っているのかを訊いてみたいと思っています。まずは、どのように開発を進めているのかを伺ってみたいのですが?

伊藤:
「教えて!goo」は運営開始から18年間機能を拡張し続けてきました。いまや、大小含め膨大な数の機能が枝分かれしている大樹のようなサービスです。

私たちはその大樹の枝をそのまま伸ばすような育て方をしていません。枝に不具合があれば、大樹の命に関わるシステムまで影響してしまうからです。そのため、枝のみを先に作ってしまい、それを接ぎ木していくようなイメージで大樹を育てています。こうすることで、枝と大樹を接合する際に、枝に不具合がないかを十分確かめることができます。

大きな1本の樹が「教えて!goo」のソースファイルの本流であり、私たちはそれを「trunk(トランク)」と呼んでいます。対して、接ぎ木するための枝が拡張する機能で「branch(ブランチ)」と呼んでいます。


――コードレビューはどのタイミングで行われるのでしょうか?

伊藤:
まさにbranchをtrunkに結合する前ですね。プルリクエストという他の開発者に変更を通知する機能を使い、他の開発者が変更された箇所に対してレビューを行います。

例外としてbranchがとてつもなく大きい場合は、プルリクエストより前にレビューを行います。これをプルリクエストの時に見てしまうと、レビューする範囲も膨大になってしまいます。また、そもそものシステム設計部分に問題があると、大きな手戻りになってしまいダメージもその分大きくなってしまうのです。

コードレビューのタイミングは接ぎ木をする直前

 

――コードレビューは人間が行っているのでしょうか?それとも自動化しているのでしょうか?

伊藤:
機械がチェックできる部分はなるべく自動化を進めるようにしています。「こういうコードの書き方はだめだよ」という指摘は今まで人間が行ってきたのですが、今はシステムが自動的に検知、指摘してくれるようにしています。自動化できない範囲を人間がレビューしていますね。


――なるほど。では、具体的にどういう部分を自動化しているのでしょうか?

伊藤:
自動化しているのは主にコード規約です。コードの書き方の癖や変数の長さなどを指摘してくれます。


――自動化を行うにあたり、何かツールを導入したのですか?

伊藤:
1年半ほど前から、WebアプリケーションのテストツールSeleniumを使っています。Seleniumはページ上のどのボタンをクリックするかなどを決めて、その動作を自動化することができ、その結果をチャット上に投稿してくれるツールです。

「教えて!goo」の本丸(最も重要な機能)は「質問する」「回答する」ということだと思っています。このSeleniumを使うことで、ブラウザで自動的に質問投稿や回答投稿ができるかという、まさに本丸の機能が正しく動作するのかを確認しているのです。Seleniumを導入してからは、「質問する」「回答する」という機能は一度も障害が起きていません。いまや、障害から本丸を守る真田丸*2のような存在です。
*2: 真田幸村が大阪城に築いた防御のための出城の名称

 


Selenium(真田丸)は本丸を守るツール

 


コードレビューとは「愛」である

 

――それでは、自動化されていない部分、人間がレビューを行う部分についての質問です。レビュワーになるには何か条件があるのでしょうか?

伊藤:
レビュワーになる基準はありません。全員がレビューしますし、全員がレビューされます。通常は、レビュワーは依頼して決めるのですが、みなさん忙しいので頼みにくいときもあります。また、レビュワーもセンスが問われ、属人化しがちになってしまいます。「この人に見てもらわないと気持ちが落ち着かない」みたいな状態になってしまうのです。
ということで、最近、苦肉の策でレビュワーをランダムで決めるチャットボットを作りました(笑)。「レビュワー募集」と打ち込むとランダムで人が決まります。当たった人が絶対にやるわけではないのですが。

インタビューの時にテストでレビュワー指名ボットを使うと、まさかの矢野さんが指名された(笑)。

 

――コードレビューの指摘は基本的にテキスト上で行うと思うのですが、テキストでの指摘だと高圧的に受け取られてしまうこともあると思っています。そこに対して配慮されていることはありますか?

伊藤:
コードレビューはおっしゃる通り、チャットサービス上で行います。やったこと、悩んでいることをテンプレート化しています。そこを重点的にレビュワーが見るようにしています。

特に指摘方法自体に具体的なルールを設けているわけではありません。例外として、お互いをリスペクトし合うということが唯一のルールということですかね。


――お互いをリスペクトし合うことがルール?

伊藤:
私の考えなのですが、コードレビューは「愛」なのですよ。


――愛…!?

伊藤:
そうです。「愛」です(笑)。

レビュワーも別の開発業務を担当しているのでもちろん暇なわけではありません。それなのに、時間を割いて他の人のコードを見なければいけません。レビュワーがその時間を割いてレビューしてくれるということ自体に、レビュイーはリスペクトを払わなければいけないと思います。

また、レビュワーも相手の成果物(コード)に対してリスペクトを払った上で、「こういう書き方の方が良いのではないでしょうか」とレビューすることが大事だと思っています。このお互いへのリスペクトこそが愛であり、愛こそが良い開発文化を醸成するのだと思っています。


――愛が良い開発文化を醸成する。まるで哲学みたいですね(笑)。それでは、昨年度にジョインしたばかりの矢野さんに質問です。前職のときもエンジニアだと伺っていますが、コードレビューはされていたのですか?

矢野:
いや、前職のときはコードレビューをする文化は無かったです。NTTレゾナントに来て初めてコードレビューというもの体験しています。


――コードレビューに対してどういうことを感じますか? 

矢野:
自分が書いたコードを相手に見てもらうことによって、技術向上に繋がっているという実感はあります。あと、「教えて!goo」のサービスは、開発段階でのバグが極端に少ないなという印象があります。開発段階での不具合はあるものの、ものすごく少ないというイメージです。  


――実際にコードレビューがサービスの安定運営に繋がっているのを実感されているのですね。

矢野:
そうですね。あと、プロダクトの品質保持だけではなく、副次的な効果も大きいと感じています。「教えて!goo」では全員がレビュワーであり、レビュイーなので、それぞれのシステムを全員が高いレベルで把握できています。


――なるほど。コードレビューがシステムの属人化を防ぐことに繋がっているのですね。では、逆にデメリットを感じることはありますか?

矢野:
デメリットは、やはり時間かかることでしょうか。自動化している部分のテストを私たちはユニットテストと呼んでいます。ユニットテストでは、機械が自動的にチェックできるようにするためのコードであるテストコードも自分で作る必要があります。慣れていないのもあって、そのテストコードを書くのにプロダクトコードの2倍弱ほどの時間がかかってしまうのです。



それでもコードレビューを行う理由


――2倍弱!?かなり時間がかかっていますね。

伊藤:
プロダクトコードとテストコードをきちんと書いた場合、一般的にその物量比はおおよそ1:2になります。単純にテストコードの方が長くなるわけで、当然、時間も大きくかかります。

プロダクトコードとテストコードの物量費

 

――時間がそれほどかかるのに、それでもコードレビューを続けるのは何故ですか?

伊藤:
コードレビューを行う理由は大きく3つあります。

1つは、バグがないかどうかの確認。「教えて!goo」のように、機能が多岐にわたり、ユーザーも多く抱えるサービスを安定運営するためには欠かせない取り組みだと考えています。

もう1つは、プロダクトの平準化です。誰がシステムを作っても一定の品質と規則が守られているものにするためです。
最後は、技術力の向上です。他の人が書いたコードを見ると、「この人はこういうコードを書くのか」「こういうコードの書き方があるのか」など、学ぶことはたくさんあります。

矢野さんがおっしゃっているように、自分が担当していないシステムも見ることになるので、チーム全体の知識レベル向上に繋がっていると思います。


矢野:
事実、私はコードレビューで自身の技術力の向上をとても感じていますね。

チーム内で技術力の高いメンバーが「こういう書き方の方がスマートですよ」と丁寧に教えてくださり、実際に自分のスキルにも繋がっているのを感じます。

多分、見る人が見るとまだまだだなと思われるコードを書いているときもあると思うのですが、皆さん親切に指摘してくれます。伊藤さんの言っていた「愛」を感じますね(笑)。 


――コードレビューが他のエンジニアの知見を吸収できる場も作り出しているのですね。コードレビューを行う開発文化というのはどのように作り出していけるのでしょうか?

伊藤:
そうですね。私たちエンジニアは生み出したプロダクトで評価される世界にいます。ですが、コードレビューというのは、プロダクトを作るための道具を作る作業です。

料理人に例えると、鍋磨きや、包丁を研ぐ作業ですかね。なので、そこに進んで時間を割こうという人は、なかなかいません。でも、実は良いプロダクトを作るためには、いい道具が必ず必要になります。そこに気がつけるかどうかですかね。 


――急がば回れのような考え方なのですね。矢野さんは、入社当初、コードレビューに抵抗は無かったのでしょうか?

矢野:
正直、色々と面倒だと思うことはありました。ただ、レビューされる度に、自分のコードの書き方に関する想いも変わってきているように思います。「動けばそれでいい」ではなく、「安定して運用するために」ということを意識するようになりましたね。知識も経験も豊富なプログラマーの方にレビューいただけたことで、考え方も変わってきましたなと思います。


――インタビューを通して、チームのコミュニケーションにもコードレビューが役立っているなと思ったのですが?

伊藤:
そうですね。何度も言いますが、コードレビューは決して楽な業務ではないです(笑)。なので、メンバーもできるだけ楽しんでできる雰囲気が生まれるようLGTM*3を使ったコミュニケーションも生まれていますね。
*3: looks good to me の略。コードレビューが終わった時に、その喜びを共有するためにノリの良い(バカらしい)画像を送りあうこと。

また、コードを管理するツールとしてGitHubを使っているのですが、その役割はコードの管理だけではないと思っています。私はエンジニア同士がコミュニケーションするためのツールだとも思っているのです。 


――なるほど。それでは、伊藤さんの想いとして、どういう開発チームになっていきたいですか?

伊藤:
メンバー間の信頼と個々の技術力を最大化させていきたいと思っています。メンバー間の信頼と個々の技術力はシンクロしていると思っていて、信頼しあえているチームの技術力は自ずと高くなり、技術力を上げていくことでお互いが信頼できる関係になると思っています。どちらが欠けても、「教えて!goo」という樹を枯らすことに繋がりますし、逆にどちらも伸ばすことで「教えて!goo」という樹が今よりもっと大きくなれるのではと思います。

 

――ありがとうございました。

 

 

【広報のあとがき】

コードレビューは「愛」と表現する伊藤さん。実際に「教えて!goo」の開発チームには優しい雰囲気を持った「愛」のあるメンバーが集まっています。彼らが開発している「教えて!goo」は、自分の知らない人が質問したことに回答するという「愛」から始まるサービスです。そのサービスを作っている開発チームの「愛」を、今回のインタビューで感じ取ることができました。

今後、「教えて!goo」という大樹がどのように育っていくのか、1人のユーザーとしても、とても楽しみです。



NTTレゾナントでは、「goo」を一緒に作るエンジニアやデザイナー、プロデューサーを募集中です!採用ページでは、実際のエンジニア社員へのユーザーインタビューや社内カルチャーを紹介していますので、ご興味があればぜひご覧ください。


  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする