はじめまして、技術開発部の小倉です。 9月18日にNTTグループのエンジニアが技術交流を行うNTT Engineers' Festa #3を開催しました。 今回はその開催背景や当日の様子についてご紹介したいと思います。 NTT Engineers' Festaとは NTT Engineers’ Festaは、NTTグループのエンジニアたちが一堂に会して技術交流を行うためのイベントです。 NTTグループ内には、各社の様々な案件でアプリケーションやシステムの開発・運用を行うエンジニアやOSSのコミッタ、メンテナ、コントリビュータなどを担う多様なエンジニアが所属しています。 本イベントではエンジニアたちがもつ技術の（無駄遣い含む）ノウハウや悩みを共有・議論しあうことで、参加者ひとりひとりがエンジニアとして成長することを目的としています。 本イベントはNTTグループのエンジニア有志によって運営され、場所やNWについて会社から支援を得るという形で開催しており、今回で3回目の開催となりました。 開催の背景 もともとは3年前からNTTグループのエンジニアと外のエンジニアが交流するNTT Tech Conference（以下、TechConf）というイベントの開催を行っていました。 ^1 ^3 TechConfのアンケートは毎回すべて目を通していますが、NTTグループの参加者から「NTTグループ内でしか話せない内容を相談したい」などの声が複数ありました。 また、スタッフのイベント運営慣熟のため、練習としてNTTグループ内で行ったTechConf#0というイベントが参加者に好評だったこともあり、TechConfとは別のイベントとしてNTT Engineers' Festaの開催を昨年からはじめました。 当日の様子 当日はNTTグループ15社から合計約150名が参加しました。 発表では「 SpinnakerでBlue-Green Deploymentやってみた 」をはじめ、コンテナやKubernetes、NW、セキュリティ、Deep Learningなど多岐にわたる技術トピックや、エンジニアのはたらきかたについての発表などが行われ、それぞれで発表と質疑が行われました。 （発表資料については発表者に公開をお願いしておりますが、公開できないものもありタイトル等伏せております。） また、NTTグループに限定したイベントということでグループ内の人事にお声がけし、エンジニアのそだてかたについて人事とエンジニアが簡易なOST（Open Space Technology）形式で5つのテーマを出し、議論と発表が行われました。 当日は弊社の経営層も参加し、質疑や議論を行い発表者や参加者と意見を交わしていました。（下記証拠） NTT Engineers’ Festa #3ってのを今日やってて 、懇親会で他社の人から「コムの発表者と年配の男性が激論してるのが面白かった」って言われて「あれコムの副社長」「ふぁっ！？」ってなったのが面白かった。最近経営幹部が草の根なイベントに出てきてくれるようになってとても良い。 — ゆやりん (@yuyarin) September 18, 2019 まとめ NTT Engineers' FestaはNTTグループのエンジニアによって開かれ、エンジニアたちが交流し、成長するイベントとして今後も続けて行きたいと思います。 また、この冬にNTT Tech Conference #4の開催を計画しています。この記事をお読みのみなさまとも交流できればと思いますので、興味のある方はぜひご参加ください！

技術開発部セキュリティユニットの星野です。 前回の 「Black Hat USA 2019 / DEF CON 27に参加してきました」 では、それぞれのイベントの概要とおすすめの歩き方についてご紹介しました。 今回は、そのうちBlack Hat USA 2019の詳細な内容についてご紹介します。 前回も述べたとおり、Black Hatの中で行われるイベントは主にトレーニング、ブリーフィング、ビジネスホールの3つがあります。その3つのうち、私が参加したトレーニングの内容と、聴講したブリーフィングの一部をご紹介します。 トレーニング内容の紹介 私は、 “Advarsary Tactics: Red Team Ops” という4日間のトレーニングを受講しました。 https://www.blackhat.com/us-19/training/schedule/#adversary-tactics---red-team-ops-14189 このトレーニングは主に座学と実践という二つの内容で構成されています。座学では、Red Team 1 のための「インフラ構築」「攻撃テクニック」「ツールやPost-Exploitフレームワークの活用方法」等を学びます。実践では、ラボ環境に模擬的な企業の環境が用意されており、座学で学んだ内容を元にRed Team活動、つまりは攻撃を行います。 ラボへの攻撃に関してはチーム戦でした。同じ卓に座った受講者がチームとなり、攻略したホスト、奪ったクレデンシャルなどに応じて得点が得られる、いわゆるCTFのような競技形式になっていました。言い換えると、ラボ環境はチームで共通のものを使用する形式となっていました。これはRed “Team”であることを意識した計らいであると考えられます。 ここからはトレーニングのポイントをいくつかご紹介します。 熟練のトレーナー・スタッフ このトレーニングでは、かなり専門的な内容を学ぶことができます。それもそのはず、このトレーニングを提供するSpectreOpsという組織には、数ある有名なRed Team向けOSS・ツール・ライブラリの開発に関わった人が多数在籍しているのです。PowerPick、PowerShell Empire、BloodHoundなどのツールを聞いたことがある人は多いのではないでしょうか。このトレーニングでは、長年に渡りRed Team的なセキュリティ業務に携わってきたトレーナーが直々にそのノウハウを教えてくれるわけです。 熟練の受講者??? トレーニングの内容、トレーナーのキャリアもさることながら、特筆すべきはその受講者たちです。「あなたは本当にこのトレーニングを受ける必要があるのですか？」、そんな”熟練の受講者”が散見されました。 実は、座学と実践は、交互ではなく同時に進行していました。どういうことかと言うと、座学を聞く必要が無いと判断した受講者は、次々にラボ環境へ攻撃をして良いことになっていたのです。実際、私の隣に座っていたチームメンバーは、トレーニング開始と同時に攻撃を仕掛けていました。彼こそが熟練の受講者です。私が攻撃を始める頃には、彼がラボ環境で暴れまわっており、そこには最初は存在しなかったであろう端末・クレデンシャル情報が無数に列挙されていました。もはや初期状態がわかりません。その侵入の速さに絶句していたのも束の間、「君のために権限昇格したコネクションを用意しておいたよ」と今後の人生で言われることのないであろう言葉をかけられ、どこからツッコめば良いかわからない状況でした。聞いたところによると、彼はRed Team的な業務に長年携わっており、今回使用したツールの利用にもかなり長けていたようです。 洗練されたラボ環境・監視システム トレーニングのRed Team活動では、主としてCobalt Strikeというツールを使いました。Cobalt Strikeは、多機能な有償のペネトレーションテストツールです。PsExecやWMI 2 を使ったリモートでのペイロード実行や、PowerShell.exeを使わないPowerShellスクリプト実行（いわゆるPowerShell without PowerShell）の機能を有しています。PowerUp, PowerSploit, PowerViewなどのライブラリをインポートし、それらのコマンドレットを感染端末上で使うこともできます。侵入した端末をビジュアライズしたり、抜き取ったクレデンシャルなどの情報をリスト化するような機能もあります。これらの機能を使い、脆弱なサービス設定を悪用した権限昇格、SYSTEM権限でクレデンシャルダンプ、そのクレデンシャルを使い横展開、ドメイン管理者の特定、ドメイン管理者が利用している端末の特定、キーロガーによるドメイン管理者のクレデンシャル窃取、DCへのログイン、などのように攻撃を進めていきました（あくまで一例で、いくつかの侵入経路が存在します）。ここまでのラボ環境の構築だけでもかなり大変だと思うのですが、さらに倍ほどの端末が用意されており、非常に洗練して作られた模擬企業だったと言えます。 もう一つ目を見張る点は、お手製の監視システムです。運営側が用意した監視システムが、各チームの攻撃を監視していました。攻撃したことがバレやすい、イケてない攻撃をすると、以降の攻撃が成功しなかったり、その旨がチャットで通知されたりします。ただ攻撃させるだけではなく、隠蔽の必要性も考慮したラボ環境を用意している点はこのトレーニングならでは、だと感じました。 残念ながら最深部まで侵入を進めることはできませんでしたが、よくできたラボ環境で有償ツールを用いた攻撃を試行することができるこのトレーニングは、非常に価値のあるものだったと感じています。 ブリーフィングの紹介 ブリーフィングは、講演のことです。なお、Black Hatの講演で使われたスライドは一部を除いてBlack Hat公式サイトの各講演詳細ページにアップロードされています。 MITRE ATT&CK: The Play at Home Edition https://www.blackhat.com/us-19/briefings/schedule/index.html#mitre-attck-the-play-at-home-edition-15035 MITRE ATT&CK自体の活用方法にフォーカスした唯一の講演だったと思います。ATT&CKを組織で活用する術をストーリー仕立てで説明するといった内容でした。この講演のポイントは2点あり、一つは企業・チームが抱えているであろう問題点とATT&CKの効果が分かりやすく説明されている点です。もう一点は、解決にあたり使用できる・参考にできる、ATT&CKに関連するツールやブログ等の情報源が紹介されている点です。脅威から組織を防御するためには、新しい脅威を見逃さないための継続的な対応が必須であることを主張し、そのための考え方や活用できるツールについて説明していました。 （出典： http://i.blackhat.com/USA-19/Wednesday/us-19-Nickels-MITRE-ATTACK-The-Play-At-Home-Edition.pdf ） Fantastic Red-Team Attacks and How to Find Them https://www.blackhat.com/us-19/briefings/schedule/#fantastic-red-team-attacks-and-how-to-find-them-16540 Atomic-Red-TeamとEQLという二つのツールについて、それぞれの開発者がその活用方法を紹介しています。Atomic-Red-TeamはRed Team的な侵入テスト用のOSSで、MITRE ATT&CKで定義されるテクニックベースでシンプルに攻撃を自動化することができます。EQLはsysmonのログ等のイベントの検索を行うためのPython実装のツールです。この講演では、Atomic-Red-Teamを使った攻撃をEQLを使ってログの中から見つけ出すためのノウハウを、デモや実際のログを見せながら解説していました。攻撃と防御双方のノウハウを説明しているわけです。これは筆者の意見ですが、どちらか一方が欠けてしまうとそれぞれの結果を評価できなくなりますので、この観点は大切だと思います。 Black HatのKeynoteで、自分の解析能力を何倍にも高める梃子となるツールを持つことが重要であるといった話がありました。筆者もこの考えに同感で、この講演で紹介されたものに限らず、セキュリティチームとして流行りのツールやOSSをウォッチすることは非常に重要だと思います。 （出典： http://i.blackhat.com/USA-19/Thursday/us-19-Smith-Fantastic-Red-Team-Attacks-And-How-To-Find-Them.pdf ） Dragonblood: Attacking the Dragonfly Handshake of WPA3 https://www.blackhat.com/us-19/briefings/schedule/#dragonblood-attacking-the-dragonfly-handshake-of-wpa-15991 Dragonflyと呼ばれる、WPA3のハンドシェイク方式に関する脆弱性の話題です。いくつか問題点はあるようですが、中でもハンドシェイク時のパスワード生成アルゴリズムへのサイドチャネル攻撃の説明が非常に分かりやすく印象に残っています。パスワード生成時に特定の値が取れるまでiterationする部分がありますが、その値の計算に任意に変えられる値が使われているため、様々な値を取らせた状態でiterationの処理時間を計測してサイドチャネル攻撃を仕掛けることができます。ちなみに、講演者はもちろんDragonbloodを発見した研究者本人です。また、WPA2の脆弱性であるKRACKsを発見した研究者でもあります。そのご本人に直接お目にかかれるのも、講演に参加する大きなメリットと言えるかもしれません。 （出典： http://i.blackhat.com/USA-19/Wednesday/us-19-Vanhoef-Dragonblood-Attacking-The-Dragonfly-Handshake-Of-WPA3.pdf ） まとめ 星野が参加したトレーニングの内容と聴講したブリーフィングの内容についてご紹介しました。 トレーニングについては、他のメンバーが参加したトレーニングも面白そうなものばかりでした。非常にクオリティが高いです。今年は各トレーニングにSKILL LEVELというのも示されていたので、来年のトレーニングの参加を検討している方はそれを参考にするのが良いかもしれません。 ブリーフィングについては、他にも数え切れない程の講演がありました。興味が湧いた方は是非公開されている発表資料をご覧いただくか、来年のBlack Hatへの参加を検討してみると良いと思います。 次回はBlack Hatとはまた一風変わった、DEF CONに関する内容を、同じチームの後藤より紹介いたします。 実際の攻撃と同等の手法で攻撃シミュレーションを企業・組織に行うことで、それらの実施しているセキュリティ対策が正しく機能しているかを評価することを目的としたチーム。 ↩ いずれもMicrosoft正規のツール・技術である。リモート端末でプログラムを実行する機能を有しており、攻撃者が悪用することが知られている。 ↩

技術開発部 セキュリティユニットの小林です。 8月上旬にアメリカ・ラスベガスで開催された Black Hat USA 2019 および DEF CON 27 へ参加してきました。その模様をレポートしつつ、初めての方向けのアドバイスも添えてお送りします。 Black Hatとは Black Hatは1997年より開催されているコンピューターセキュリティに関する世界有数のカンファレンスで、レギュラーイベントとしては毎年アメリカ (USA) 、ヨーロッパ (Europe) 、アジア (Asia) の3地域で行われています。今回参加したUSAはBlack Hatの中でも最も長い歴史を持ち、また参加者の数も最大です。USAの会場は例年ラスベガスのマンダレイ・ベイホテルのコンベンションセンターで、今回は世界112カ国から2万人を超える参加者が訪れました 1 。 ちなみに本来このイベント全体を指してBlack Hat Briefingsといいますが、よくBlack Hatと略されてますので本稿でもそれに倣います。 イベントは大まかにトレーニング、ブリーフィング、ビジネスホールの3つに分かれています。8月3日から8日までの6日間の会期のうち、最初の4日間でトレーニング、残りの2日間でブリーフィング・ビジネスホールが催されます。 トレーニングはセキュリティベンダーの社員などが提供する講義で、今回は延べ120コース以上開催されました。2日間コースと4日間コースがあり、スタイルも座学とハンズオン、グループワークなど様々です。私はOSINTに関するハンズオンベースのトレーニングを受講してきました。今年からは受講者に対して受講証 (Digital Certificates) が発行されるようになりました。 ブリーフィングはBlack Hatのメインイベントとも言え、セキュリティベンダーやソフトウェアベンダーの社員、研究者らがそれぞれの成果を発表する場です。21のジャンルから、新たに発見した脆弱性や攻撃手法、防御のためのベストプラクティスなど、120を超える発表がありました。日本のニュースサイトでも話題になった、WPA3の脆弱性 "Dragonblood" もここで発表されました。 ビジネスホールは端的に言えば見本市で、ベンダーが製品紹介や小さなプレゼンテーションをしたり、ワークショップやミニCTFが行われていたり、あるいは採用活動を行っていたりと、盛りだくさんの内容です。その一角にアーセナルと呼ばれる会場があり、85以上のオープンソースツールの実演が行われました。ブリーフィングよりも発表者との距離が近く、内容について議論している風景も見られました。 DEF CONとは DEF CONもBlack Hat同様歴史あるイベントで、今回で27回を数えます。ただ色合いはBlack Hatとはまるで異なり、言うならば「ハッカーのお祭り」という雰囲気です。今年の会期は8月8日から11日までの4日間で、今年の会場はホテル4軒にまたがっていました。 内容はBlack Hat以上に多種多様で、大雑把にジャンル分けしても昼間はプレゼンテーション、コンテスト、ワークショップ、ツール・製品のデモなどが行われているほか、夜になると映画の上映会が始まったり音楽イベントが始まったりと賑やかです。特筆すべきイベントとしては、期中にDEF CON CTFの決勝戦が開催されることが挙げられます。CTF自体の説明はほかに譲りますが、世界最高峰の大会として名が知られており、毎年5月のオンライン予選を勝ち上がったチームが本戦に臨みます。 会場内にはビレッジという仕切られたエリアが各所にあり、ある特定のテーマに関する展示、プレゼンテーション、ワークショップが行われています。一例を挙げるとAI, Block Chain, Cloud, IoTなど技術分野や、Blue team, Red team, Social engineeringなどセキュリティ分野、変わり種ではBio Hacking, Car Hacking, Lock Pickなども見られました。興味深かったのはAviation Villageの一角でアメリカ国防総省のDefense Digital Service ( https://dds.mil ) という部局が人材を募集していた点で、DEF CONのようなカジュアルな場にも出展して人的リソースを確保しようとしているところに日本との違いを感じました。 会場を歩いていると、謎のQRコードが書かれたポスターが張られていたり（中身は謎のバイナリ）、いきなりクイズを渡してくる人がいたり、必死に何かCTFを解いている人がいたりと、本当にいろいろな人、物に出くわします。ただ散歩しているだけでも楽しいですが、訪れた際にはぜひ何かHackしてみるのをお勧めします。私は休憩所でCrypto & Privacy Villageで配られていたパズルを解いていたところ、隣の席にやってきたトルコ人の青年に「何をHackしてるの？」と声をかけられ、1時間ほどいっしょに解いてくれるという素敵な体験がありました。 ちなみにバッジですらハックできるそうです。組み込み方面で腕に覚えのある方、ぜひデバッグ機材をお持ちになってお越しください。 参加するには Black Hatは参加登録が必要です。早期割引があるので、参加すると決めたら早めに登録するのがよいでしょう。パスは何種類かありますが、ブリーフィングパス、またはブリーフィング＆トレーニングパスをお勧めします。ビジネスパスは安価なものの、ビジネスホールにしか立ち入れません。 とりわけ、トレーニングを受けたい方はとにかく早く登録しましょう。席数がかなり限られているため、4月時点で売り切れ間近となっているコースも見られました。 https://www.blackhat.com/us-19/training/schedule/index.html DEF CONには早割などはありませんが、Black Hatの参加登録時に同時に購入できるのでそちらがお勧めです。その場合Black Hatの会期中に、 Black Hat会場内の カウンターでDEF CONバッジ（入場証）と引き換えることになります。DEF CONのみに参加したい場合は、会期中に会場の受付窓口で参加費を払えばOKです。 おすすめの歩き方 とにかくまずRegistrationを済ませる 参加登録のことではなく、現地での参加受付のことです。これを済ませないとどこの会場にも入れません。本人確認があるのでパスポートをお忘れなく。 Black HatのRegistrationではバッジ（入場証）のほかバックパックがもらえました。DEF CONのバッジを引き換えた（上述）際には、バッジ、ステッカー、ノートと会場案内の小冊子がもらえました。この会場案内の小冊子がWebサイトを見るよりもよほど良くまとまっていますので、引き換えが始まったら早めに入手しておくことをお勧めします。 スタッフに聞く Black Hat, DEF CONとも会場が広く、また案内も不十分なので、目的地がわからなくなったらスタッフに聞きましょう。どちらのイベントでもスタッフは同じTシャツを着ており、そこかしこにいます。 身軽な装いで Black Hat, DEF CONとも会場が大変広く、相当な距離を歩くことになります。動きやすい服装に履き慣れた靴で臨むことをお勧めします。ただ会場の冷房がけっこう強めなので、羽織り物が1枚あるとよいでしょう。またBlack Hatのトレーニングやビジネスホールを訪れる場合、けっこうな量の配布物をもらうことになるのでエコバッグがあると便利です。 Black Hatはアーセナルに注目 Black Hatでのブリーフィングの内容は (1) 後日スライドが公開される (2) セッションの録画が販売される――ものの、アーセナルの発表ではそのような手当てがありません。ブリーフィングとアーセナルは同時進行で行われているため、もしアーセナルに気になる内容があればそちらを優先することをお勧めします。Black Hatで発表された内容はDEF CONでも同じ内容で発表されることがあるので、DEF CONのスケジュールにも注目です。 DEF CONの無線LANに注意 DEF CONは会場で無線LANによるインターネット接続サービスを提供していますが、適切に暗号化されたSSID (DefCon) のほか、まったく暗号化されていないSSID (DefCon-Open) が飛んでいます。前者は安全に使えるものの、後者は何をされるか分からないので、接続したければそれ専用に「まっさらなラップトップ」を持参することをお勧めします。 会場では、DefConという名の「暗号化されていない」アクセスポイントを実際に観測しました。これはユーザーを騙して（暗号化されていると勘違いさせて）通信を横取りしようとするものと思われます。私も危うく接続しかけたので、多少気を引き締めねばと思いました。一部の危険な無線LANはPacket Capture VillageのWall of Sheepにつながっており、Webサービスやメールのユーザー名・パスワードを送信しようものならここで晒し上げられてしまいます（さすがにパスワードは一部がマスクされますが）。 最後に 次回は、Black Hatで見聞きしてきたテクニカルな内容を、同じチームの星野より紹介します。 なおBlack Hatのクルーが撮影した写真アルバムはこちらからご覧になれますので、併せてご覧ください。 https://www.flickr.com/photos/blackhatevents/albums/72157710161031186 Black Hat USA 2019 Closes Out Another Record-Breaking Event in Las Vegas ↩

こんにちは、技術開発部 セキュリティユニットの田中です。社内のセキュリティエンジニアのメンバーで、サイバーセキュリティ関係の話題を書いていきます。初回となる今回は「ラテラルフィッシング」についてお送りします。 ラテラルフィッシングとは？ 皆さんは、最近ネットでも取り上げられるようになってきた、「ラテラルフィッシング」(Lateral Phishing)というセキュリティ脅威をご存知でしょうか？ ラテラルとは横方向へ、を意味し、サイバー攻撃では、攻撃者が内部ネットワークに不正侵入後、感染を拡大する行為を「ラテラルムーブメント」（横方向への移動）と呼び、ご存知の方も多いと思います。 「ラテラルフィッシング」は、攻撃者が組織内のメールアカウントを何らかの手法で乗っ取り、その組織の正規アカウント（ドメイン）からフィッシングメールを送るものです。正規の内部アカウントからのメールなので、現在の攻撃検知の想定外のため、一般に検知が困難で、攻撃の実態もよくわかっていないのが現状でした。 ラテラルフィッシングの実態と対策に関する論文発表 この「ラテラルフィッシング」に対し、大規模なデータセットで実態を明らかにし、防御手法を提案・評価した、非常に質の高い研究論文発表が先月8/15に行われたので、本ブログで皆さんに紹介したいと思います。 セキュリティの学術系国際トップカンファレンスは、ゴルフ界やテニス界のように、4大メジャー大会が存在します。その1つが毎年USで夏に開催されるUSENIX Securityで、この難関カンファレンスに採択され（採択率16%, 2019）、かつ、Distinguished Paper Award Winnerに選ばれた優れた論文です。 ちなみに今年のUSENIX Securityは、28回目、サンタクララで開催され、何年ぶりかに日本人がファーストオーサの論文が採択されるなど話題になりました。 ラテラルフィッシングの実態は？ Detecting and Characterizing Lateral Phishing at Scale[1] と題して、92組織の113Million(1.13億）ユーザのOffilce 365のメールを解析したところ、7つのうち1つの組織で「ラテラルフィッシング」が行われている実態が明らかにされました。92組織は、16業界からなり、多いものから、Real-estate, Technology, Education, Industrials, Healthで、データセットは十分な規模であると思われます。 実際、Office365への不正アクセスは各社SOCでも多く検出して、インシデント対応をしているということで、同様に信頼性が高いデータセットと言えます。 また、「ラテラルフィッシング」では、標的型攻撃で用いられる、標的を調査し、巧妙なメールを用いるケースは、全体の7%にすぎず、93%は、このドキュメントを見ておいて、このリンクをクリックして等、シンプルなものですが、信ぴょう性を高めるため、あのメール見てくれた？等催促したりと応答をすることも特徴です。 検知手法は？ このようなメールを特定するのは、シンプルな機械学習で誤検知を少なく検知できるという内容です。特徴量としては以下の3つを使います。 Lure：メール内にphishyな単語を入れているか Exploit：メール内にレアな（通常ではないような）URLを入れているか Targeting：標的型のような特殊な偽装をしているか 実際に「ラテラルフィッシング」が起きた110インシデントのうち、同手法で実験を行ったところ、106インシデントを検知できたとのこと。110インシデントのうち49インシデントは、ユーザから報告が上がってこなかったもので、これを見つけられたのは実務的にも非常に効果が高いと言えます。またFalse Positiveは0.0004%と非常に低いという凄さです。 もちろん、セキュリティ業界はいたちごっこな点は否めないので、永続的にこの手法で検知できるという保証はありません。 まとめ まだ、情報が少ない、「ラテラルフィッシング」(Lateral Phishing)について紹介させていただきました。データセットでは、16業界をカバーしていたのですが、どの業界でこの攻撃が多いか等の情報はありませんでした。おそらく学術界の発表は、倫理問題も最近は気にする必要が背景にはあるからかもしれません。この点については、コマース界のBarracuda Networksが今後発表をすることも予想されます。また日本で「ラテラルフィッシング」が起きているのかについても、情報公開の限界もあり、なかなか実態がわからないのが現状です。 また、今回の論文発表は、Office365の大規模データから分析をしているということで、Office365のセキュリティ対策やインシデントへの備えも重要と言えます。 この論文がAwardを取ることができた背景には、4大メジャー大会の中でも特に、理論の完成度に加えてフィージビリティも重視する、USENIX Securityならではと思います。 92組織から1.13億のメールを入手するには、研究者だけの力ではなかなかできないので、企業とのコラボが必須になります。今回はUC BerkeleyとBarracuda Networksの産学連携ですが、USENIX Securityからは、この連携により優れた技術が生まれ、スピンオフしたセキュリティ系ベンチャー企業も多くあります。 学術系カンファレンスは集客力の高い商業系カンファレンス（例 Blackhat）と比べると、数%の集客規模ですが、また一味違う興味深さがあります。USENIX Security自体についても、機会がありましたら、紹介させていただきたいと思います。 参考文献 [1] Grant Ho and Asaf Cidon and Lior Gavish and Marco Schweighauser and Vern Paxson and Stefan Savage and Geoffrey M. Voelker and David Wagner. Detecting and Characterizing Lateral Phishing at Scale. In Proc. of 28th Usenix Security, 2019. https://www.usenix.org/system/files/sec19-ho.pdf

こんにちは、 NTT国際通信株式会社 ICTインフラサービス部 クラウドサービス部門の北澤です。先日NTTグループの国内事業再編に伴い、NTTコミュニケーションズ株式会社 クラウドサービス部 から所属が変更になりました。 先日新会社になってすぐに、チーム内にて Kubernetes 1day 勉強会を実施しました。今回はその様子をお伝えします。 背景 私たちのチームは SREs (Site Reliability Engineers) として GKE (Google Kubernetes Engine) を運用しています。また週に1度、 Kubernetes に関する勉強会を実施することで自分たちの扱う技術に関する知識を深めています。 しかしながら GKE はマネージド Kubernetes サービスであるために Kubernetes クラスタを利用者としてしか使用できません。そのため、 Kubernetes が Pod をどのように立ち上げているか、そのステートをどのように管理しているかなどの仕組みの部分を実感する機会がありませんでした。 この度、チーム全体における Kubernetes の理解を深める事を目的として、Kubernetes クラスタを 1 から手動で構築する勉強会を開催しました。 実施内容 今回の勉強会では、事前に Kubernetes 構築用のドキュメントを用意し、当日は GCE (Google Compute Engine) 上の VM にログインしドキュメントを読みながら構築作業を行う方式をとりました。 今回構築した構成は以下のようになります。 Kubernetes を 1 から手動で構築する手順として、 kubernetes-the-hard-way が有名ですが、今回は各コンポーネントの仕事をきちんと理解してもらうことを目的に、Kubernetes の各コンポーネントにどのようなオプションを指定するか調べながら構築してもらうような構築手順を新しく作成しました。 以下に勉強会の流れの一例として kube-apiserver のみ構築後の話をします。Kubernetes は各コンポーネントが http(s) で kube-apiserver というコンポーネントと通信を行うことで動作します。そのため、kube-apiserver だけあればクライアント (kubectl) からの通信を受けることが可能です。しかしながら kube-apiserver のみ構築した状態で kubectl get node コマンドを実行しても No resources found. といった Kubernetes クラスタ内に Pod を建てる対象の Node が存在しないという意味のメッセージが返ってきます。Kubernetes の Pod として動作するコンテナは kubelet というコンポーネント経由でコンテナランタイムが立ち上げます。そのため次に kubelet とコンテナランタイムである Docker を構築することで、 kubectl get node で Node が取得できるようになることを確認できます。 このように各コンポーネントの構築後に Kubernetes の動作を都度確認することで、各コンポーネントがなぜ必要なのかを意識しながら Kubernetes の動きを理解してもらうことを狙いました。 実施風景 勉強会開始直後、 Kubernetes の各コンポーネントがどのように動作するかという説明を行い、その後はひたすら構築作業を行ってもらいました。 また、作業の進捗は Slack のリアクション機能を用い確認しました。これをみて構築に手詰まってる人などのフォローを頻繁に行うことができました。 昼食の :sushi: と :pizza: まとめ 今回の勉強会にて実際に Kubernetes クラスタを構築することで Kubernetes の理解を深められたのではないかと思います。また、開催側としても事前の構築検証や当日の質問を通じて学ぶことがたくさんありました。 以降も機会があれば勉強会等を実施し、 Kubernetes に関する技術力の底上げやコミュニティの活発化に貢献ができればと思っています。 なお、勉強会にて使用したリポジトリは GitHubで公開 しています。 Kubernetes 構築用のドキュメントや動作確認用のマニフェストファイルの他に GCP 上に勉強会の環境を構築するためのスクリプトもおいてあるので、Kubernetes の構築を 1 からやってみようと思っている方に参考程度になれば幸いです。

こんにちは、 SkyWay の開発・運用をしている岩瀬（ @iwashi86 ）です。 今回の記事では、弊社の研修内容の一部を公開します。 研修の狙い 毎年200名超の社員がNTTコミュニケーションズグループに入社しています。 入社いただいた社員の中には、もともと高い技術力を持っている社員も多くいます。 今年度より、ソフトウェアエンジニアリングのスキルの高い社員（今回は35名）を対象として新たな研修 1 を実施しています。 研修の主な狙いは以下の2つです。 即戦力レベルのスキル習得 実際の現場で有用となる技術・開発スキルの習得して、現場ですぐに活躍できるように ネットワーキングの強化 / コミュニティ形成 同期だけでなく、講師・メンタを含む先輩エンジニアとのネットワークを形成し、互いに影響を与え合い成長できるように なお、2点目について補足すると、今回の研修では社外のエキスパートによるプログラムに加えて、開発の最前線に立つエンジニアが講師を担っています。 最前線に立つエンジニアだからこそ、実務で使われる技術が分かっており価値がある研修を提供できると考えているためです。 先輩エンジニアと触れ合うことによって、もしかしたら新入社員自身のロールモデルも見つかるかもしれません。 プログラム全体像 本研修は5日間で構成されており、概要は以下の通りです Day1: テスト駆動開発ワークショップ Day2: アジャイル開発、スクラムワークショップ Day3: IaaS、カオスエンジニアリング、障害注入型ISUCON Day4: CaaS、docker、kubernetes、GKE Day5: FaaS、AWS lambda、Serverless framework Day1-2は社外のエキスパートの力を借りて、Day3-5は社内のエンジニアが講師・メンタを担当しています。 各日程の概要・資料 以下で簡単に各日程の内容を紹介します。 Day1: テスト駆動開発ワークショップ 和田さん にご協力いただき、テスト駆動開発のワークショップを実施いたしました。 研修資料へのリンク ]( https://speakerdeck.com/twada/tdd-live-and-workshop-2019-spring ) Day2: アジャイル開発、スクラムワークショップ アトラクタ社の 永瀬さん 、 吉羽さん にご協力いただいて、アジャイル開発およびスクラムのワークショップを実施いたしました。 (こちらは資料公開無し) Day3: IaaS、カオスエンジニアリング、障害注入型ISUCON Day3以降は社内のエンジニアが講師・メンタを担当しています。IaaSは本記事執筆者の岩瀬が担当しています。研修資料は以下のとおりです。 2019年度 IaaS ワークショップ @ NTTコム from Yoshimasa Iwase なお、以下の研修現場画像を見ていただければピンと来るかもしれませんが、IaaSでは ISUCON を参考にしています。 ただ、ISUCONとは1点だけ大きな違いがあり、それは ベンチマーク実行中に障害(VMがランダムで1台再起動)が恣意的に引き起こされる という点です。 現実のサービス開発・運用では、予期せぬ事象によってあるVMがサービス提供できなくなることは想定されます。 そこで、クラウドの特性を活かした構成にすることによって、サービスを継続して提供するという内容にしてあります。 なお、ISUCON定番の茶番（？）的な前振りも実習開始前にしています 2019年度 IaaS 実習イントロダクション @ NTTコム from Yoshimasa Iwase Day4: CaaS、docker、kubernetes、GKE CaaSコースでは、Day3で実施したWebアプリと同様のシステムを、コンテナを利用して組み上げていく内容になっています。研修資料は以下のとおりです。 2019年度 CaaS ワークショップ @ NTTコム from TomoyaTakegoshi Day5: FaaS、AWS lambda、Serverless framework FaaSコースでは、Day3-4と同様の仕様をAWS Lambda + Dynamo DBを使って組み上げる内容となっています。研修資料は以下のとおりです。 FaaS研修資料へのリンク ]( https://gitpitch.com/nttcom/2019-sw-training?p=faas/presentation#/ ) IaaS/CaaS/FaaSのソースコード Day3-5の研修で使っていたソースコードは GitHubで公開 しています。 まとめ 本記事では、NTTコミュニケーションズグループで実施している研修の一部(ソフトウェアエンジニア向けコース)を公開いたしました。NTTコミュニケーションズでは、今後もソフトウェアエンジニアの育成に力を入れていきます！ 参考: ソフトウェア以外にも、たとえばネットワークエンジニア向け研修なども実施 ↩

こんにちは、 SkyWay のエンジニアの岩瀬( @iwashi86 )です。 NTTコミュニケーションズに新しい拠点が完成しました。名前は Lean Agile Base (略して LAB) と言います。 本記事では、 LABの概要・狙い どうやって作り上げていったのか？ の2点を紹介いたします。 概要 まずはどんな感じか見ていただくのが早いので、いくつか新オフィスの写真を載せておきます。 複数人でモブプログラミングする場合は、全員が同一方向を見て作業できると身体的負荷が軽減され、快適に作業できます。そこで、ソファで囲むようにして作業できる環境を用意しています。 モブプログラミングだけではなく、ペアプロ/ペアワークに便利なデスクも配置しています。このデスクは、高さが電動で変更できるため、座って作業するだけでなく、スタンディングでの作業も可能です。 打ち合わせをする場合や、チームで固まって作業が必要な場合に作業できるスペースも用意しています。 また、作業内容によっては、一人で集中したいこともあります。そのためのスペースとして高い仕切りが併設されたデスクも用意してあります。 気軽にリフレッシュできるスペースもあります。例のソファも置いてあるので、そのままの姿勢で仕事モードに入ってしまうことも。 狙い このオフィスを作った狙いとして、主に次の2点があります。 組織を横断した、エンジニア同士 1 のコミュニケーションを促進したい リーン、アジャイルに試行錯誤するプロダクトを増やしたい 弊社には多くの組織があり、どうしても組織と組織をまたぐとコミュニケーションが減ることがあります。一方で、組織やチームが違ったとしても、同じような技術エリアに取りくんでいるケースも多くあります。会社・組織として全体のスキルを高めていくためには、雑談から生まれるようなノウハウの共有が効果的です。もちろん、Slackなどのオンラインコミュニケーションも併用していますが、Face to Faceでの情報帯域に勝るものはありません。そこで、LABではコミュニケーションが生まれやすい場を提供しています。 また、プロダクトやサービスの成功率をあげるために、様々なフィードバックをもとにした試行錯誤が効果的です。新オフィスの名称として、 Lean Agile Baseをつけたように、 Leanに & Agileに に挑戦していくプロダクトやサービスのメンバが集まる場を狙っています。 どうやって作っていったのか？ 実際のオフィス設計は、 ヒトカラメディア 様にご協力いただきました。 弊社から要件を端的に伝えてオフィスを設計してもらうのではなく、複数回のワークショップを経て、「どのような働き方をしたいのか？」「どのような想いがあるのか？」「どうやったらチームの開発の腕があがるのか？」といった、より根源に近い要求からオフィスを設計していただいています。 実際のワークショップの様子を以下に何枚か貼っておきます。 皆でブレストして、 イメージを具体化し ドット投票しつつ重要な点を絞り込んでいきます。 また、オフィス構築終盤では、一部DIYして仕上げをしていきました。 本オフィスは、常にWork In Progressの状態だと考えており、今後も必要に応じて常に改善していきたいと考えています。 まとめ 本記事では、NTTコミュニケーションズの新オフィスであるLABを紹介しました。気軽に遊びにきてください！ わかりやすくエンジニア同士としていますが、エンジニア以外も本オフィスは利用していきます。たとえば、プロダクトマネージャ、デザイナなど。 ↩

ネットワークサービス部 初開発合宿開催！！ こんにちは。ネットワークサービス部テクノロジー部門の嶋です。そろそろ暖かくなってきた先月、2月25～2月27日にかけて、ネットワークサービス部テクノロジー部門のエンジニアが集まって、伊東温泉（静岡県）で開発合宿を行いました。今回はその様子をお伝えします。 開発合宿を行ったきっかけ 先日、ComCTFが開催されました。ComCTFとは、NTT Com内で実施しているセキュリティに関するテクニックを競い合うコンテストのことです。そのとき、「惜しくも予選突破できなくて悔しい」という意見や、「本選で実力不足を感じた」など、さまざまな意見がありました。また、「まとまって勉強できる時間がなかなか確保できず厳しい」という意見もあり、「どこかで勉強できたらいいよね」ということになって開発合宿を計画しはじめ、その後、合宿に参加する有志7人が集まり、“開発合宿にオススメ！旅館5選”に選ばれている山喜旅館にて2泊3日で内製開発強化を目的とした開発合宿を開催することになりました。開催するにあたって協力していただいた皆さま、ありがとうございました。 開発合宿中の様子について 合宿は以下のスケジュールで進みました。 1日目 o 朝: 各自電車移動 (新幹線 or 踊り子) o 10：00 山喜旅館ロビー集合 → 環境準備 o 11：00 開会宣言、 自己紹、 やること宣言 2日目　自由開発時間 3日目 o 12：00 チェックアウト後、会議室へ移動 o 14：30～16：00 LT的に成果報告 o 17：00 会議室 撤収 個人的な感想も含みますが、合宿期間中は本当に自由に開発することができました。集中力がなくなったら目の前が海ということもあり、散歩や漁港に泳いでいる魚を眺めに行くことができました。開発場所としてきれいな会議室が確保されていて、そこで開発してもいいし、旅館の部屋で開発してもいい、としてあったのでストレスフリーで作業することができました。また温泉地ということもあり、夜は温泉など、リラックスできるものがたくさんあったので、楽しみながら開発することができました。 開発ネタについて 今回の開発合宿では各自が自分で持ってきたネタを実装する形式をとりました。何人かのネタをここでご紹介したいと思います。 Batfish + inet-hengeでconfigテスト + トポ図自動生成 ansible nw module, gitlab でCICD化 SOプログラムのpython置き換え 100万pps送信する自作ツールに再チャレンジ これらは1部ですが、さすがネットワークサービス部ということでネットワーク周りのプログラミングが多かったように感じます。 またopenstackなので仮想基盤系のネタもあり、クラウド系のネタに挑戦するメンバーも多くいました。またお互いに不足している知識や経験を補い合うような場面もあり、討論が盛り上がる場面も多々、見られました。 最終発表に使った資料の一部をご紹介します。 →　 https://gitpitch.com/take4mats/201902techcamp#/ 合宿形式の有用性について 開発合宿という、普段とは異なった環境で開発するのは普段、オフィスで働くのと、どう違うのか？について、全員の感想をご覧いただきながら解説します。 　＜全員に聞いた感想＞ ・やる気のある人が集まって取り組むだけで、完成までのモチベーションが持続する ・途中、アイデアや実装に詰まっても他の人の意見をもらえ、解決の糸口になることもある ・事務作業にほとんど触れず、プログラミングだけに集中できる ・もくもくやる人が目の前に集まっているだけでやる気が持続する ・もくもくやる一方で、たまに独り言からの会話が解決につながることがあり、とても良かった ・改まった質問と独り言ではハードルがぜんぜん違う ・しゃべると頭が整理される（1人で考え込むより良い） ・余計な interrupt がないのにはすごく感謝（特に自分は普段ひどいため） ・寝食をともにしていると、作業時間以外での会話も良い影響になる（ナレッジ共有、アイデア議論、親睦） ・リモートワークは2日までに制限されているが、1つのPoCを集中して仕上げるには3日間の合宿が適切だと思った ・慣れない分野で1つの成果を生み出すために断続的に計3日間リモートワークとるより、合宿で3日間連続して取り組む方が効率が良いと実感 意見として多かったのは、質問のハードルの低さや目の前で頑張っている人がいるだけでもう少し頑張ろうと思える、ということです。あとはモチベーションについての意見も多く、普段の環境よりもモチベーションの持続性が全然違うと口をそろえて言っていました。エンジニアリングにおいて、モチベーションの維持というのは結構重要な位置を占めるものです。開発合宿というのはそのための新たな働き方の1つになるのではないでしょうか？ もう1つ大事だと感じたのは、テーマ選定や事前の環境準備です。事前に参加者同士で集まってテーマ候補を話し合うようにしましたが、そのテーマにどんなアプローチで取り組むか、いくつかの案を練っておくことも重要です。 せっかくの機会なので、無策で臨んで成果ゼロ……というようなことにはないように準備が大切です。決められた短期間でアウトプットを出す訓練としても有用だと思います。 今後の開発合宿について 今後も継続的、定期的に開発合宿が開催できるように努力していきたいと考えています。 最後に伊東温泉での美味しかったご飯（伊東温泉名物「うずわめし」）と旅館の部屋をご紹介して終わります。

NTT Com Tech Night #1を開催しました! (レポート) こんにちは、クラウドサービス部の堀内です。 普段は、Enterprise Cloud 2.0のベアメタルサーバー・専用ハイパーバイザーの開発をしています。 2018/12/18(木)に、NTT Com Tech Night #1を開催したので、その様子をお届けします。 NTT Com Tech Nightとは? 社内のエンジニアが集って、ビールを片手に技術を語り合う夜会です。 業務や趣味で技術的に挑戦したことや、サービスの裏側について、部署の垣根を越えて技術を共有し、各自の幅を広げることが目的です。 これまでも各部署内で勉強会が開催されたり、 NTT Tech Conference のような対外的なイベントは開催されたりしていました。 ただ、「もっとテクニカルな話をしたい」「もっとカジュアルにやりたい」「もっと社内でわいわいしたい」という想いがあり、「 Pepabo Tech Friday 始まってます! - ペパボテックブログ 」に触発されて、開催に至りました。 #1の様子をご紹介 今回は弊社の新オフィス(大手町プレイス)の「ガレージ」と呼ばれるお洒落なオープンスペースを使ってみました。 初回にもかかわらず約50人ものエンジニアが集まり盛り上がったので、その様子をお伝えします。 発表者は社内で分野を問わずに募り、バリエーションに富んだ内容となりました。 Batfish を使ったネットワークのテスト Macchinetta の紹介 OpenVINO でIntelの様々なデバイスを使って推論させてみた ThingsCloud で使っている Angular のお話 レガシーコードと仕様化テスト GCP/Azure/AWSの学習済みAPI比較 UXデザイナーによるプロトタイピングツールの紹介 それぞれ5〜15分程度で、デモンストレーションを交じえながら発表して頂きました。 特にBatfishの話はSlackの実況チャンネルで盛り上がっていたり、Angularはもくもく会の企画が持ち上がるなど、部署の垣根を越えたエンジニアの交流といった意味でも、良いイベントになったと思います。 また、当日はエンジニアイベントらしく、会社からピザが用意されました! 反響・今後に向けて イベントに参加したエンジニアからは 色々なジャンルの話があり、普段聞けない話が聞けて良かった 気軽に業務後に来られるので良かった。派生イベント等があったら是非参加したい。 といった声が寄せられました。 また、今回集まったエンジニアの所属部署は クラウドサービス部 ネットワークサービス部 技術開発部 経営企画部 (IoT推進室、デザイン組織) NTTコムソリューションズ が中心でしたが、もっと広げていければ良いなと思っています。 今後も継続して開催し、社内のエンジニアコミュニティを活性化していきます! 今回は時間の都合で溢れた発表もあり、1月に#2を開催予定です。

楽天の及部さん(@TAKAKING22)さんに、モブプログラミングの1日ワークショップを、2018/9/20(木)に開催していただきました！ モブプログラミングとは？ モブプログラミングとは、シンプルにチーム全員で、同じ仕事を、同じ時間に、同じ場所で、同じコンピュータでプログラミングすることです。 元々はHunter Industries社が始めた開発手法で、日本でも徐々に広がり始めています。Hunter Industries者の実際のモブプログラミングの様子は、 こちらの動画 から確認できます。 今回のワークショップでは、最初にモブプログラミングについての簡単な説明があった後に、自動販売機の実装をテーマに、参加者が4チームに分かれてモブプログラミングを体験しました。 実際のモブプログラミング中の様子は次のとおりです。 参加者の学びの声 ワークショップの最後には、まとめおよび振り返り時間があり、実際にモブプログラミングを体験した参加者からは、以下のような声があがっていました。 知らない知見が得られた モブプログラミングは、プログラミング以外のタスク整理などにも活用できる メンバの理解レベルが揃う テスト駆動開発(TDD)と相性が良い 詰まる前に助け合えるので、ストレスがたまらない。ただし超疲れる 分からないことを、分からないということが大事 心理的安全性が必要 「やったー！」「わーい！」という明確なリアクションで、具体的な満足感が得られた 特に最後の声は、今回のワークショップの特徴的な要素です。他の研修では、なかなか出てこない意見であるためです。 実は、今回のワークショップのグラウンドルールとして、小さな達成をするたびに喜びの声をあげる、というルールが設定されていました。実際に、「やったー！」という声があがると、メンバに自然に笑みがこぼれ、初めて組んだチームであるにもかかわらず、チーム内の心理的安全性が確保されていったように見受けられました。 最後に NTTコミュニケーションズでは、今回のモブプログラミングに限らず、 テスト駆動開発ワークショップ や スクラムワークショップ を通じてソフトウェアエンジニアの育成に力を入れています。今後もさまざまな取組みを通じて、エンジニアの開発スキルを向上させていきます。

本記事前半では、4年を越えて継続的に開催している社内ランチ勉強会であるTechLunchを紹介します。後半では、TechLunchの最新回について紹介いたします。 社内勉強会 / TechLunchとは NTTコミュニケーションズではランチを食べながら、気軽に参加できる社内勉強会としてTechLunchを不定期開催しています。主に技術的なトピックを扱いますが、社内ハックのような裏話がトピックになることもあります。 誰でも気軽に参加できること、を重要視しているため、開放感のある場所で開催しています。開催模様はこんな感じです。 TechLunchは2014年の6月から始まっており、現時点（2018年9月）の段階で開催回数は60回を越えており、継続的に勉強会が続いています。目的としては、 気軽に最新の技術や、基礎的な技術を学べること 分からないことを気軽に聞ける人を見つけること を挙げています。 特に後者は組織が大きくなってきた場合に効果的な目的です。組織が大きくなると、全員が同じ情報を知っているのは不可能かつ非効率であるため、「誰が何を知っているか」（トランザクティブメモリと呼ばれる）が重要です。TechLunchでは実際に、さまざまなチーム・部署のメンバが登壇しており、ちょっとした疑問を聞く際のネットワーキング強化にTechLunchは一役買っています。 社内のメンバが講演するだけではなく、社外からもゲスト講演いただくケースもあります。TechLunchの最新回はゲストにお越しいただいており、以下でその模様について紹介いたします。 TechLunch最新会から - アジャイル、リーンについて LINE株式会社のアジャイルコーチで omoiyari.fm のパーソナリティでもある横道さんにゲストスピーカとしてお越しいただいて、「アジャイル、リーン」をテーマに講演いただきました。 以下で内容について簡単にご紹介いたします。 セッション概要としては、これまでもバズワード化してきたアジャイルという言葉について改めて考えてみようという、聴講者も参加するタイプのセッションです。 アジャイルという言葉は、さまざまな文脈で用いられており、意味の解釈が人それぞれであるケースもあります。本講演では、原点であるアジャイルソフトウェア開発宣言（Agile Manifesto）に立ち返りつつ、話が進められました。 講演の中では具体的に、「アジャイルとは価値観」である、という説明がなされました。 アジャイルマニフェストの12原則 を、ビジネス価値・マインドセットと捉えて説明もなされていました。 では「アジャイルである」とは何なのか？というと、これらのアジャイルの価値観に共感して改善の行動がとれていれば、「アジャイルである」ともいえます。HOWに固執するのが重要なのではなく、共感した原則に沿って行動し、組織やチームを継続的に改善することが重要です。 一方で、組織やチームによって確立した文化があるため、実際に原則を適用して改善しようとしても難しいケースもあります。講演の中では、 sli.do を用いて、実際の参加者からアンケートをリアルタイムで取り、難しい点についてディスカッションするスタイルで進みました。(この内容については、会社特有の内容もあるため、紹介は割愛させていただきます） 講演の最後には、 アジャイルの価値観 個人の価値観 会社の価値観 のそれぞれの関係性や共通点、そしてどのように歩み寄れるか、という課題提起があり参加者にとって非常に有意義な講演となりました！

2018/6/25(月)に、吉羽龍太郎氏( @ryuzee )・永瀬美穂氏( @miholovesq )にお越しいただいて、1Dayスクラムブートキャンプ(ワークショップ)を開催していただきました！ ワークショップ内容の詳細なレポートは、内容のネタバレになってしまいますので、本レポートでは序盤にワークショップ概要を述べ、主にブラックボックス的に、参加者がスクラムブートキャンプを通じて得た学びを中心に記載します。 ワークショップの概要 ワークショップ全体は以下のような構成でした。 あるお題に対して複数回のスプリントをチームで実施 スプリントからの学びを全体で振り返り★ 座学によるスクラム全体の知識習得 + 質疑応答★ 習得した知識のアウトプット 座学でプロダクトバックログについての学習 + 質疑応答 この中から、★でマークしている振り返りで出てきた参加者の意見、および座学後の質疑応答を紹介いたします。 午前のワークショップから得られた学び 午前中はあるお題に対して、4-5名でチームを組んで、短期間スプリントを複数回まわしていく、というプログラムを実施しました。 スプリント後の振り返りでは、参加者からに以下のような学びが生まれていました。 技術の大事さ 設計中は技術が不安定になる点 共通のゴールを自律的に目指す 繰り返しによるゴールの洗練 プロトタイピング タイムマネジメントの重要性 ペア作業 共通理解の重要性 リリースが重要である点 リーダを決めればよかった 普段のコミュニケーションが大切 無駄な作業の見直し 成功体験の積み重ねの有効性 検証はもっと早くすべき(全てが整うのを待たない) 短時間のスプリント演習でしたが、アジャイル開発で重要となる要素が多く含められており、実体験として学べることがわかります。 質疑応答の中から紹介 プログラムの中では、座学や実習の後に適宜、質疑応答の時間が取られます。以下で、質疑応答で上がっていた内容をいくつか紹介いたします。スクラムはフレームワークに過ぎないので、具体的な進め方（実装）は各々のチームに委ねられており、その辺りも質問に上がっていました。 Q: 残業時間は、見積もり時に考慮すべきか？ 含めないのがオススメ 普段の時間の6-7割程度しか開発に使えないはずなので、それで見積もりするのが良い 持続可能なペースで仕事できるスケジュールにして、スコープ(機能など)で調整していく Q: プロダクトの企画側が予算を決めてくる環境でどう進めればいいか？ 本来はプロダクトを作っている期間は、開発チームとプロダクト側が一緒にやるのがいい 半年先を考えても当たらないので、「一緒に継続的に効果測定しませんか？」と誘うのが良い また、作った機能についても、メトリクスを取れるように仕込んでおくと、プロダクト側と一緒に確認できる 基本的には、開発とプロダクト（企画）の距離感を近ければ近いほど良い Q: アーキテクチャはいつ決めるのか？ 早い段階で決めた方が良い 開発言語に何を使う、サーバに何を使う、といった間違えると取り返しがつかないやつは先に決める アジャイルではなんでも後回しにするのではなくて、今やらなきゃまずいものは今きめる Q: 銀行系の基幹系はアジャイルで作れるのか？ ウォータフォールでやるしかない あまりに大きすぎて、あちこちを勝手に変化すると、どこかが壊れる。設計はある程度、密になる 基幹系をリプレースする案件だったら、アジャイルはオススメしない UI部分だけだったらアジャイルでやるのはアリ そもそも、規模が大きいシステムはウォータフォールにしろ、アジャイルにしろ非常に難しい スケールさせるなら、理想形はチーム間はAPIだけで話すようにする(AWSで実施されている開発のように) また、小規模アジャイルの経験無しに、大規模アジャイルはやらないこと。絶対に失敗するので まとめ 本記事では、スクラムブートキャンプにおける参加者の学びを中心に紹介いたしました。 NTTコミュニケーションズでは、ソフトウェアエンジニアの育成に力を入れています。今後も継続的にエンジニア向けワークショップなどを通じて、ソフトウェアエンジニアの育成に力を入れていきます。

こんにちは、普段はSkyWayの開発・運用をしている岩瀬(@iwashi86)です。 前回の記事 では、マネージャから見た分報の価値について紹介しました。本記事では、前回記事で予告していたプロダクトオーナ 1 から見た分報の価値について紹介いたします。大きく以下の2つの価値について述べます。 短期的な視点: タスクの大変さを類推可能に 長期的な視点: スキル的に、メンタル的にも強いチームを作るために 短期的な視点: タスクの大変さを類推可能に SkyWayの開発ではスクラムを採用しており、今後開発する機能などをプロダクトバックログで管理しています。プロダクトバックログの責任者はプロダクトオーナであり、特に優先順位に責務を負います。 プロダクトオーナは限られた開発リソースの中から、どれを優先していくか（どれが顧客価値の最大化につながるのか）を常に考える必要があります。その考える材料の1つとして、ある開発タスクをこなす場合の大変さ（どのぐらい難しいのか、どれぐらい時間がかかるのか）というものがあります。 開発タスクは、実装が主な部分を占めるため、その実装内容の大変さを最も理解しているのは、プロダクトオーナではなく開発チームのメンバになります。 仮に分報がなければ、必要に応じてプロダクトオーナが、開発チームのメンバに質問して大変さを知ることになります。しかし、分報があると状況が少し変わります。 開発チームの作業を分報(個人のchannel)に書かれているから読み取り、ある程度、想像を働かせることが出来るようになるのです。もちろん、未知の技術分野の実装タスクなどは想像が難しいのですが、ある程度、似ているタスクがすでに実施済みなのであれば、次のタスクの作業内容も想像ができます。また、見積もり時の想定よりも大きなタスクになっていないか、についても確認できます。こちらは遅延の早期発見につながります。 結果的に、プロダクトオーナからすると、将来の予想・プロダクトバックログの優先度付けの材料を、各自の分報から入手できるわけです。これがプロダクトオーナから見た価値です。 長期的な視点: スキル的にも、メンタル的にも強いチームを作るために プロダクトオーナ 2 の役割として、長期的な視点として「スキル的にも、メンタル的にも強いチーム」を作ることも重要です。なぜならば、良いプロダクトは強いチームから生み出されるからです。 そのための情報源として分報を活用します。具体的には以下の点を確認します。 各メンバが疲労していないか 分報を導入すると、各メンバが取り組んでいる内容だけではなく、感情を含む独り言を書くようになります。タスクの進捗が悪い、また他の何らかの要因などで疲れが溜まってくると、愚痴がこぼれることもあります。そのような状態を早めに見つけた場合は、次スプリントでモチベーションの上がるストーリーや、タスクを含めるようにして、疲労回復を狙います。 各メンバの成長につながっているか スクラムにおける開発チームは、機能横断的チームなチームを目指します。各人がプロダクトに必要なスキルを備える必要はありませんが、メンバの趣向などによって特定の分野に高い専門性が出てくると、全体として強いチームになっていきます。 そこで、分報における各メンバのアウトプットから、アサインされているタスクが大変であっても成長につながる楽しいタスクになっているか、を確認します。そして、プロダクトバックログを考えるにあたり、条件として考慮していきます。 まとめ 本記事ではプロダクトオーナら見た、リモートワークにおける分報の別のメリットについて紹介いたしました。 SkyWayでは開発にスクラムを採用しており、本記事で述べるプロダクトオーナはとは、スクラムにおけるプロダクトオーナを指します。 ↩ SkyWayのプロダクトオーナは、プロダクトマネージャも兼務しています。2つ目の視点は、ややプロダクトマネージャの視点に近いかもしれません。 ↩

こんにちは、普段はSkyWayの開発・運用をしている岩瀬(@iwashi86)です。 先日、 後から気づいたSlackでの分報がもたらすメリット を掲載したところ、SkyWayチームの マネージャ および プロダクトオーナ から、「別のメリットもあるよ」とコメントをもらいました。面白い観点だと個人的に感じましたので、本記事ではまず マネージャから見た分報の価値 について紹介いたします。 オフィスワークとリモートワークの情報量/仕事の理解度の逆転 昔からある従来の職場であれば、同じチームのメンバは一箇所に集まって仕事をするケースが多いかと思います(本記事ではこれをオフィスワークと呼びます)。マネージャは、集まっているメンバと会話し、仕事の進捗状況・困りごとなどをヒアリングして、必要であれば解決にあたります。職場によっては、定例の会議のようなイベントを設けて、情報共有をしているかもしれません。マネージャは、これらを通じて情報を集め、部下の仕事を理解します。 一方で、リモートワークが増えて、かつ分報が普及しはじめると、オフィスワークよりも情報が集まるケースもあります。言い換えると、「分報あり、リモートワーク」と「分報なし、オフィスワーク」だと、前者のほうが部下の仕事を理解できるという、逆転現象が起きます。分報における各メンバのチャネルには、常にタスク内容や、そのときの感情がアウトプットされているためです。 もちろん、分報はフロー的な情報が流れるので、仕事の理解度は浅いものになりがちですが、実際には対面での1on1なども併用すれば、仕事の理解度は非常に深まります。 マネージャのタイプにも依存するので、「分報あり、リモートワーク」と「分報なし、オフィスワーク」での理解度の逆転現象が一概に100%発生するとは言い切れませんが、マネージャ・チームのタイプによっては1つの観点としてあると思います。 執筆者個人の感想としては、マネージャがチームメンバに権限を委譲するタイプ、また自己組織化されたチームを作りたいタイプ、である場合に発生しやすいと考えています。 リモートワークの許可に伴う潜在的な恐怖心からの開放 マネージャには、「リモートワークを許可すると、社員が仕事をサボるのではないか？」という潜在的な恐怖心があります。分報を使うと、管理を強化することなく、その恐怖心を克服できます。 製造業の工場では、「作業場にいる = 仕事をしている」が成り立ちます。しかし、オフィスワークでは、「席に座っている = 仕事をしている」「パソコンを操作している = 仕事をしている」が必ずしも成り立ちません。やろうと思えば仕事をサボることができます。知的労働にある程度の息抜きや昼寝の時間は必要ですが、オフィスワークでは、息抜きが度を超えてもわからないことが多いです。 分報やプルリクエスト駆動開発を導入すると、メンバー間でお互いにアウトプットが丸見えになります。これが適度な緊張感を生み出します。息抜きが度を超すことは少なくなるでしょう。この効果は、オフィスワークとリモートワークに共通しています。だから、分報を導入するとマネージャは「社員が仕事をサボるのではないか？」という恐怖心から開放され、安心してリモートワークを許可できるようになるのです。 まとめ 本記事ではマネージャから見たリモートワークにおける分報の別のメリットについて紹介いたしました。次回の記事では、プロダクトオーナから見た価値について紹介いたします。

こんにちは、普段は SkyWay の開発・運用をしている岩瀬( @iwashi86 )です。 SkyWayチームでは、普段のコミュニケーションツールとしてSlackを活用しています。SkyWayチームでは、リモートワークを積極活用しているので、非同期で気軽に連絡が取れるSlackは重要なコミュニケーション基盤となっています。　 Slackの使い方としては、いわゆる 分報 を導入しています。分報とは具体的には、個人のpublic channelを用意しておいて、「今やっていること」「困っていること」「今の気持ち」など、普段考えていること・思っていることを各メンバが積極的にアウトプットするという方法です。 この分報は、当初は「仕事の進捗共有」・「学びの共有」・「課題の共同解決」が主なメリットだと考えていたのですが、分報を続けるにあたり、最初に気づけていなかった他のメリットが見えてきました。 以降、本記事では、先にSlack・リモートワークで失われる点(デメリット)を最初に説明した上で、分報が解決する点(メリット)について説明します。 Slack、リモートワークのデメリット とは Slackでは、Direct Message(DM)というプライベートなチャット機能があります。DMは非常に気軽に使えるため、ちょっとした問い合わせに便利です。たとえば、「社内システムの使い方が分からないけど、Aさんなら知ってるから聞いてみる」といったケースで、DMで問い合わせするようなケースがあります。本ケースではメンション範囲もAさんに限定されるため、良いと思われるかもしれません。 しかし、一方でデメリットもあります。そのデメリットとは、「誰が何を知っている」「誰と誰が話をしている」という点が隠蔽されるという点です。 誰が何を知っている とは 1人の人間がすべての業務・技術などを把握するのは不可能です。そこで、実際にスムースに業務を進めるためには、ある分野に詳しい人に質問をして、助けてもらいながら業務を進めることが不可欠です。これは、日常で業務を進めるにあたり、誰しもが自然にやっていることかと思います。 仮にSlackが無い状態で、1つの場所に集まって業務を進めている場合、漏れ聞こえてくる会話を耳から得ることで、「あぁ、Aさんはhogeに詳しいんだな」という情報を知ることができます。 同様の問題に困った場合は自分が問い合わせできるように、また同僚が同じ問題で困ってるのを見つけた場合には、自然とリダイレクトできるようになります。 SlackのDMで問い合わせが閉じてしまう場合は、この「誰が何を知っている」が隠蔽されてしまいます。 誰と誰が話している 先ほどは会話が漏れ聞こえてくる場合のケースでしたが、遠方で音が届いてこない場合であっても、有用な情報があります。それは、誰と誰が話している、という視覚情報です。たとえば、自席から遠くでAさんとBさんが話している、といったケースです。 このとき自身は、「あぁ、AさんとBさんは仕事の関連がある、または、雑談をする関係であるんだな」と理解します。これは、何気ない情報なのですが、実際に重要な情報になることもあります。たとえば、自身とBさんは直接のつながりがなくても、Aさん経由でつながりがある場合は、最初の仲介だけお願いしておくと、その後のコミュニケーションが円滑になることがあります。 SlackのDMが増えてくると、「誰と誰が話している」という情報が見えなくなるため、上記のような情報を落としている場合があります。 なぜ分報が上記のデメリットを解決するのか？ 分報の導入によって個人用のPublic channelができると、DMではなく、そのchannelにちょっとした問い合わせ・雑談を書くようになります。 たとえば、こんな感じです： 非常に単純な一瞬のやり取りですが、誰が何を知っている・誰と誰が話をしている、というのが可視化されます。結果として、前述したSlack＆リモートワークのデメリットが軽減できます。このデメリット軽減が、分報を導入して後から気づいたメリットです。 その他の細かいメリットとして、分報チャンネルに非メンションでメッセージを書くと、たとえば休暇中などに相手に通知を飛ばさなくて済む(気にしなくても済む)、という点もあります。不急の用事だけど、忘れないうちに書いておく、といった使い方ができます。 最後に 執筆者の私見ですが、「情報は透明であるべき(隠蔽されるのではなく、オープンにされるべき)」と考えています。情報が隠蔽されると、そこに権力が生まれてしまい、業務のブロッキングになるからです。 分報は情報を透明にする1つの手法として効果的です。試しに導入してみてはいかがでしょうか？ おまけ / 参考値: 分報を導入しているチームでの例 Slackは毎週、チームでやり取りされているメッセージ数（Public channel、Private channel、DMの割合)を、管理者に通知してくれています。たとえば、SkyWayの開発・運用で使っているSlack Teamは以下のようになっています： public channelの割合(上のSkyWayチームの例でいうと94%)が透明性のバロメータと言えます。

前回 に引き続き、和田 卓人(@t_wada)さんに、テスト駆動開発(Test Driven Development, 以下TDD)の1日ワークショップを2018/3/22(木)に開催していただきました！ TDD ワークショップの開催概要などは前回の記事で述べているので、本記事では視点を変えて、TDDワークショップを活用するためにどのような準備/工夫をしたら良いか、という運営側視点での一風変わった内容を扱います。全員が対象となるわけではありませんが、特にTDDワークショップを運営としてこれから開催する皆様に役立つ情報になると思います。もし、TDDワークショップに参加者として参加する場合は、運営にこの記事のURLを送っておくと、より良い会になるかもしれません。 以下、運営における準備/工夫について述べます。 事前: 周知文言にテストフレームワーク/スイートに関する準備を含める ワークショップに参加するメンバが、全てテストを書き慣れているわけではありません。実際、弊社における一部の参加者にも普段はコードを書いていないマネージャ(管理職)も参加しています。参加の狙いとしては「TDD/ペアプロ/コードレビューをやってる、開発チームの気持ちがわかる/コンテクストが理解できる/話が通じるようになる」という点だったようです。このような参加者がスムースに、午後の演習に入れるように、参加者向け事前連絡の文言に 「何らかのテストフレームワーク/テストスイートを使えるようにしておくこと」 という一文を入れておきました。これで、経験が浅い参加者は事前に準備できるようになります。 事前: 周知文言にペアプログラミングについての学習資料を載せておく 午後の演習では、ペアプログラミングでテストケースなどを書いていきます。本ワークショップはペアプログラミングのワークショップではなく、TDDのワークショップでなるため、ペアプログラミングについての知識は先に案内を出しておき、参加者に予習してもらうと良いです。いかに、実際にt_wadaさんからいただいた参考資料を掲載しておきます。 WEB+DB PRESS Vol.102 の特集1「はじめてのペアプロ／モブプロ」 ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Programming 事前+当日: Slack & 専用のchを用意する 参加者が既に同じSlackにジョインしている場合はほぼ準備不要ですが、特定のSlackワークスペースに、TDDワークショップ用のチャンネルを用意しておくと良いです。なぜ便利かというと、たとえば 午前の講義: 疑問に思った内容をchannelに書き込んでおいて、後でt_wadaさんに拾ってもらって回答いただける。最後に挙手する場合は、忘れてしまう場合もあるがそれを防げる。また参加者間でリアルタイムで質問をシェアできる。 午後のコードレビュー: 参加者からコードレビューのコメントを挙手制で出すのが通常ですが、参加人数が多いと手を挙げにくい、また時間内にコメントが出きらないという可能性もあるため、Slackで非同期でレビューコメントを集めるようにしました。 ワークショップ終了後: 後述するアンケートのURLをそのSlackで流します。これで、アンケートの回収率を高めることができます。 事前+当日: ディスプレイ持参OKとしておく ペアプログラミングをする場合、同じ画面を見る状況を作るのが大切です。とても些細なことに思えますが、実際に指を指して「ここ」とコードの場所を示せるのは、同じ画面を物理的に共同所有できているからこそ可能な作業であり、ペアプログラミングの効率を高めてくれます。ラップトップ単体でももちろんできますが、大きめのディスプレイの持参をOK（特にワークショップ開催場所が、参加者の居室と近い場合）としておくと、ペアプログラミングの効率を引き上げてくれます。 当日: ペア数分の紙とペンを用意しておく ワークショップ後半には、実際にペアプログラミングでTDDを実習していきます。このときに役立つのが、紙とペンです。参加者は自分のラップトップなどを持っているから、それを使えばいいのでは、と思われるかもしれませんが、紙とペンは非常に偉大で、「こういうイメージで修正したいです、こういうデザインにしたいです」というのを圧倒的に早く伝えることができます。そこで、午後の演習が始まる際に、運営から紙とペンを配っておくとワークショップが効果的になります。 当日: アンケート記入時間をプログラムに入れる このようなワークショップでは、終了後のアンケートが運営側のモチベーションの1つになります。勉強会のアンケート回収率は、失敗してしまうと非常に低いものとなってしまいます。たとえば、30人参加して5人分しか集まらなかった、といったようにです。そこで、アンケート記入時間をプログラムの中に入れてしまいましょう。WS終了後にアンケート記入時間を5-10分程度とって、記入が終わり次第、退出というようにすると回収率が非常に良くなります。 当日: アンケートはオンラインで アンケートは紙の形式も考えられますが、今回のように自分のマシン・端末を持ち込み前提のワークショップでは、電子版の方が圧倒的に早く済みます。オンラインのアンケートを作るサービスがいくつかあります(たとえば、Google Form)ので、それを使うのがオススメです。 事前+当日: 参加者に和田さん執筆書籍を持参してもらう 本ワークショップの特典として、昼休みやワークショップ終了後に、t_wadaさんから書籍にサインしてもらえるという点があります。テスト駆動開発や、SQLアンチパターンといった書籍を持っている参加者もいるので、こちらも案内しておきましょう。参加者のモチベーション向上の一助になります。 おわりに NTTコミュニケーションズでは今年度、2度のTDDワークショップを開催しました。次年度以降も引き続き、ソフトウェアエンジニアのスキルアップにつながるワークショップやセミナーなどを開催し、ソフトウェアの内製開発に力を入れていきます。

Webサービスを多数使っていると、片方のサービスで変化があったら別なサービスに通知して欲しいと思うことはよくあります。Gmailで受信したら別なサービスに添付ファイルを転送して欲しいであったり、最近流行のスマートスピーカーと連携させるといった具合です。 そうした時に便利なのはこれから紹介する連携サービスです。それぞれ特徴がありますので、目的に合わせて使いこなしてください。 IFTTT helps your apps and devices work together - IFTTT この手のサービスとしては最も有名でしょう。50種類近くのカテゴリに分かれて、数百のサービス同士が連携できるようになっています。何かのサービスにアクションがあると、別なサービスを呼び出すという形式になっています。特にIoT系の連携に強いようです。 IFTTT helps your apps and devices work together - IFTTT Explore All Integrations | Zapier Zapierは1000以上のサービスが登録されており、サービスの数だけで言えば一番多いようです。また、複数ステップでの連携もサポートされています（有料版にて）。 Explore All Integrations | Zapier プロセスとタスクの自動化 | Microsoft Flow Office 365やYammerなどMicrosoftの持つサービス同士の連携はさすがに容易なようです。複数ステップでの連携も行えます。 プロセスとタスクの自動化 | Microsoft Flow Integromat - The glue of the internet 他のサービスに比べて連携データがJSONになっていることで連携が容易だったり、よりプログラマブルな連携を行える印象があります。フィルタやイテレータなど条件の追加も用意です。 Integromat - The glue of the internet Pipes この手のサービスの先駆者として知られるYahoo! Pipesを再現したサービスになります。ビジュアルプログラミングができ、ブロックを連携して一つのサービスを作り上げます。 Pipes Gmail Productivity Tools | Sync and Back up - cloudHQ クラウドサービス同士を連携します。Gmailを同期したり、バックアップするような使い方が考えられます。対応サービスは多くありませんが、クラウドストレージ系サービスと連携させる分には十分でしょう。 Gmail Productivity Tools | Sync and Back up - cloudHQ こうしたサービスもAPIがあればこそ連携ができるでしょう。多くのサービスは定期的にデータを取得するようになっており、リアルタイム連携ではありません。無料の場合は15分程度に1回実行されるようです。そうしたタイムラグも加味しつつ、連携サービスを作ってみると良いでしょう。 Slackに情報集約が進んでいるのと同様に、サービス同士を連携させることで手作業で収集していたようなストレスから解放されるはずです。

モバイルネットワークはアプリ、IoTなど様々な分野において必須の技術となっています。今回はそんなモバイルネットワークを支えるSIMをAPIベースで操作できるサービスを紹介します。 Welcome | SORACOM Developers SORACOMはIoT用に最適なSIMを提供しており、APIベースで開設や停止、速度などを変更できるようになっています。企業内のIoT案件での利用はもちろん、自社サービスの基盤としてSORACOMを採用しているケースも多々あります。 Welcome | SORACOM Developers SIM管理API技術仕様｜モバイルM2M SIM管理API サービス仕様書｜仕様書｜ナレッジセンター｜サービス｜モバイルM2M 【NTTPC】 M2M用のSIMを管理するためのAPIです。SIMを指定してデータ通信を開始したり、逆に停止できます。プランの変更もできます。 SIM管理API技術仕様｜モバイルM2M SIM管理API サービス仕様書｜仕様書｜ナレッジセンター｜サービス｜モバイルM2M 【NTTPC】 REST API: SIM Usage Records - Twilio SIM情報の取得とステータスの確認、さらに利用情報の取得ができます。更新には対応していません。 REST API: SIM Usage Records - Twilio API Documentation - AT&T IoT Marketplace SIMの情報を取得したり、一部の情報を更新できます。速度を変更したりするような更新はできないようです。API経由でのSMS送信に対応しています。 API Documentation - AT&T IoT Marketplace モバイルアクセス卸 API | NTT Communications Developer Portal 契約しているSIMカードの制御、情報取得が可能なAPIです。回線の追加チャージ、クーポンのON/OFF、プラン変更などもAPI経由でできます。 モバイルアクセス卸 API | NTT Communications Developer Portal SIMのAPI制御についてはSORACOMが群を抜いているようです。多くは情報を取得するまでに留まっていますが、更新もすべてAPI化することで自動化が実現できるようになり、新しいモバイルネットワークやIoTサービスが実現できるようになるでしょう。

JSON Web Tokenは署名されたJSONで、改変を防止できる仕組みになっています。さらにBASE64エンコードされていることで、URLセーフな仕組みです。 すでに多くのサービスで使われているJSON Web Tokenについて、明示的に紹介されているサイトについてリストアップしました。 JSON Web Token（JWT）の紹介とYahoo! JAPANにおけるJWTの活用 - Yahoo! JAPAN Tech Blog Yahoo! IDを使って認証を外部サービス化する際、Yahoo! JapanではJSON Web Tokenでレスポンスが返ってきます。これはOpenID Connectの仕様に則って行われています。 JSON Web Token（JWT）の紹介とYahoo! JAPANにおけるJWTの活用 - Yahoo! JAPAN Tech Blog ユーザープールのトークンの使用 - Amazon Cognito Cognitoの認証後のトークンはID、アクセストークンともにJSON Web Tokenになっています。有効期限は1時間となっています。 ユーザープールのトークンの使用 - Amazon Cognito SORACOM Endorse で発行されたトークンを検証する | Getting Started | SORACOM Developers SORACOM EndorseはSORACOMが認証プロバイダとして、デバイスの認証サービスを提供します。この時発行される認証トークンがJSON Web Tokenになっています。 SORACOM Endorse で発行されたトークンを検証する | Getting Started | SORACOM Developers JWT(JSON Webトークン)を使用したシングルサインオンの設定 – Zendesk Support Zendeskが提供するシングルサインオン機能を使って、社内システムが取得したログイン要求をZendeskが信頼できるようにする機能でJSON Web Tokenが使われています。 JWT(JSON Webトークン)を使用したシングルサインオンの設定 – Zendesk Support JWT 認証 ‒ Qlik Sense Qlik SenseはBIツールを提供するQlikの一機能になります。この認証機能においてJSON Web Tokenが使われています。 JWT 認証 ‒ Qlik Sense Twilio API: Access Tokens - Twilio Twilioのボイス、チャット、ビデオといった機能においてTwilioのアクセストークンがJSON Web Tokenになっています。 Twilio API: Access Tokens - Twilio サービス間認証  |  Cloud Endpoints  |  Google Cloud Platform Googleの認証はOpenID Connectに則っていますので、そのIDトークンはJSON Web Tokenになっています。 サービス間認証  |  Cloud Endpoints  |  Google Cloud Platform Local and Remote Notification Programming Guide: Communicating with APNs Appleのプッシュ通知において、有効期限をなくしたProvider Authentication TokensはJSON Web Tokenになっています。 Local and Remote Notification Programming Guide: Communicating with APNs ウェブアプリにLINEログインを組み込む LINEログインはOpenID Connectをサポートしています。IDトークンがJSON Web Tokenで取得できますので、デコードして検証できます。 ウェブアプリにLINEログインを組み込む JSON Web Tokenは主に認証目的で利用されていることが多いようです。既存のセッションやIDトークン、アクセストークンを置き換える存在として注目に値します。また、OpenID Connectでは標準技術として採用されていますので、OAuth2も合わせて提供する場合にはJSON Web Tokenベースにするのも良さそうです。 ぜひ他社の導入事例を見つつ、自社でもJSON Web Token導入に取り組んでください。

先日、TwitterがAPI利用に対する締め付けを突然厳しくしました。元々規約にあった、複数のアプリケーションキーを一つのサービスで利用している問題に対するものですが、利用していないはずの開発者も凍結対象になってしまったようです。 よく知られたところではTogetterもその凍結対象になったサービスの一つで、数週間に渡ってアカウントが停止されていました（現在は復旧済み）。規約違反があればもちろん問題ですが、警告なしに突然凍結するのはあまりにも乱暴と言えますし、問題ないはずのアカウントを凍結するのは開発者に対する裏切りとさえ言えるでしょう。 こうした点からAPIをビジネス利用する上でのリスクが幾つか見えてきます。 規約を十分に確認する まず利用規約を十分に読み込みましょう。個人がプライベートで作るものについてはあまり関係ありませんが、企業で事業として利用するのであればその内容をきちんと精査しておく必要があります。商用利用について細かく規定されているケースや、利用する上での注意点についても明記されているはずです。 多くのAPIでは個々の企業利用について契約をカスタマイズすることはありません。API提供側からの条件をそのまま承諾することになりますので、自分たちの利用フローが規約を守れるかどうかは注意しなければなりません。 SLAを確認する サービスレベルが保証されていないサービスを利用するのは危険です。突然の終了であったり、メンテナンスが行われる可能性があります。オンラインサービスの場合、常時アクセスがあるのでAPIが突然利用できないのはリスクになります。しかし、100%のSLAというのは事実上不可能なので、99.8%などでも十分と言えるでしょう。 なお、多くのサービスではSLAを下回った場合にその課金額を上限とした保障となっています。つまり、APIの停止に伴って巨額の損失が発生したとしても、月額利用料程度しか保障は受けられません。そのため、APIが一時停止した場合でもサービスが継続できるような仕組みを設けておくべきでしょう。 有料プランを採用する APIによっては商用利用を前提として有料プランを提示しています。ビジネスで利用する場合には利用量に応じたプランを適切に選択しましょう。実際には複数人や複数のプロジェクトで使っているにも関わらずアカウントを共有していたりすると適切な保障を受けられないケースがあります。 無料枠の中で使うという手もありますが、無料枠の場合は保障がなかったり、レスポンスが悪い場合もあります。無料プランと有料プランの違いを適切に判別し、商用サービスを提供するのであれば、APIも有料プランを使うようにしましょう。 他サービスとの並列利用 APIは一つのサービスに頼り切るのではなく、類似サービスを複数利用するのがお勧めです。例えば決済においても一つではなく、複数サービスに対応しておくことで万が一APIが一時停止した場合においても切り替えが容易になります。 APIの突然の停止はよくあることです。一ヶ月後に停止されると分かって慌てて開発するのではなく、あらかじめ複数サービスに対応しておくことで乗り換えが容易になります。突貫の開発ではリソース不足になったり、バグが入り込む可能性があります。あらかじめ複数の選択肢を持っておくことで、リスクヘッジできるようになります。 キャッシュ APIによってはキャッシュを禁止している場合もあるので注意が必要ですが、データ取得系のサービスについてはキャッシュを使うことで一時的なエラーを回避できるようになります。TwitterやFacebookなどのソーシャルサービスでも有効です。 APIは常にネットワークを使うのでデータベースに比べるとレスポンスが悪くなりがちです。キャッシュを使うことでユーザ体験を向上できます。 サービス利用者にキーを登録してもらう TwitterのようにAPIのコンシューマキー一つに対して10万ユーザまでしか認めていないケースもあります。そういった限界を超えるために、利用者が自分のコンシューマキーを登録してもらうという方法が考えられます。 他にもAPIキー単位でアクセス数を制限している場合も、APIキーを変えることでさらにアクセスできるようになります。APIの利用数が多いサービスで、利用者が開発者であればこういった方法も選べるでしょう。 APIキーを利用しないでも取れるデータを確認する APIキーは誰がアクセスしているかを特定するために使われます。そのためAPIキー単位でアクセス制限されることになります。しかしAPIによってはAPIキーを使わなくともアクセスできるものもあります。そうしたAPIにおいてはキーを指定しない方がアクセス制限にとらわれなくなります。 自社開発の道を探る 膨大なデータを持っているサービスを自社システムで置き換えるのは難しいですが、機械学習や画像変換など機能を提供するAPIであれば自社開発することもできるでしょう。初期についてはAPIを使うことでリリーススピードを向上させ、サービス規模が大きくなる際に自社開発にリプレイスする方法があります。 API提供側としては、規模や利用量が増えても使い続けてもらえるコストメリットが打ち出せなければなりませんが、利用側としては自社開発に乗り換える方がコストダウンにつながることもあるでしょう。 APIに依存したサービスは必然的にリスクが高くなります。かつてFacebookアプリの仕組みを使って急成長したZingaはFacebookのAPI制限が強まるのに合わせてヒット作を生み出しづらくなっていきました。また、Twitter向けに作られたURL短縮サービスの多くはTwitterは公式短縮URLサービスをリリースしたことで市場が縮小しています。 APIを使い続けることで事業スピードを上がるメリットもありつつ、完全に頼り切らない道を探ることもまたビジネス上のリスクヘッジにつながるでしょう。