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を使い続けることで事業スピードを上がるメリットもありつつ、完全に頼り切らない道を探ることもまたビジネス上のリスクヘッジにつながるでしょう。

改ざんを防止するJSONとして注目されているのがJSON Web Tokenです。署名することでデータの改ざんを防止しつつ、URLセーフな仕組みとなっています。JSON自体は誰でも閲覧できるのでセキュアな情報を送るのには適していませんが、改ざんしたとしてもそれを検証する仕組みが用意されていることで安心して利用できます。 そんなJSON Web Tokenがどういった場面で使われているのか紹介します。 セッション トークンの中にユーザIDであったり、ユーザ名、有効期限といった情報を持たせることで認証後のクライアントにセッションとして使ってもらいます。サーバ側ではセッションをデータベースで管理する必要がなくなります。 Cookieなどにデータを持たせておいて、アクセスの度にその内容をチェックすることで改ざんされていないか確認ができます。改ざんされていないのであれば、ユーザIDをそのまま利用できます。 セッションIDはユニークで単なる文字列なのが一般的ですが、その場合はセッションIDをデータベースに保存しておく必要があります。JSON Web Tokenを使うことでデータベースに保存することなく、安全なセッション管理ができます。 OAuth2トークン OAuth2トークンとしてJSON Web Tokenを使うことで、こちらもデータベースで管理する必要がなくなります。ただし有効期限だけを延ばすと言った操作はできないのでリフレッシュトークンを使ってトークン自体改める必要があります。 例えばGoogleのOAuthトークンはJSON Web Tokenになっています。公開鍵も配布されていますので、それを使ってトークンの検証ができるようになっています。 OpenID Connect OAuth2をベースにした認証プロトコルであるOpenID ConnectのIDトークンはJSON Web Tokenが使われています。ペイロード部分については任意の情報で構いませんが、ヘッダー部分については RFC 7515の中で決められています 。 メールアドレス確認 メールアドレスと有効期限をペイロードとしてJSON Web Tokenを生成し、メールアドレス認証用のURLとすればデータベースで確認コードを保存することなく、正しいメールアドレスであるという検証ができます。 改ざんはできないので別なメールアドレスを適用することはできませんし、自分のメールアドレスであればURLに含まれていても問題はないでしょう。また、JSON Web TokenはURLセーフになっていますので、URL中に含めるのも問題ありません。 JSON Web Tokenを使うことでこれまでデータベースに保存していた一時的なトークンや確認コードが不要になります。送られてきたデータを適切に検証すれば、その内容が正しいことが簡単に分かります。 なおJSON Web Tokenでは秘密鍵が重要になりますので、間違っても紛失しないようくれぐれも注意してください。また、BASE64デコードしているので情報はURLセーフである反面、含んでいる情報の1.5倍くらいに長くなってしまいます。あまり多くの情報を盛り込まない方が良いでしょう。

2018/2/27(火)に和田 卓人(@t_wada)さんに、テスト駆動開発(Test Driven Development, 以下TDD)の1日ワークショップを開催していただきました！ 本ワークショップは前半と後半で2部構成になります。 前半: TDDの講義およびライブコーディング 後半: TDDの実習およびt_wadaさん含む全員参加型のコードレビュー 特に後半の全員参加型のコードレビューはワークショップの特徴的な要素であり、なかなか無い機会です。人数が多いと参加者全員のコードレビューができない可能性があったため、今回は小規模(全14人)で開催しました。 以下でワークショップの内容を振り返り・議論となったポイントを記載します。 前半: テスト駆動開発とは？ 午前中は、テスト駆動開発についてt_wadaさんから説明いただきました。 講演の中では、まずはじめにKent Beck氏の著書"テスト駆動開発入門"の書き出しが引用されています： 「動作するきれいなコード」Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。動作するきれいなコードはあらゆる意味で価値がある。 TDDのゴールである、 動作するキレイなコード に行き着くためには、大きく2つ道のりがあります。 上段のオレンジの道は。すぐ動かさずに念入りに設計・検討をして、その後にコードが動作するように直していく道です。これまでのソフトウェア工学では、オレンジの道が推奨されていました。しかし、日々の実際の開発ではコードを書いて始めてわかることもたくさんあります。また、考えに考え抜いてきれいなコードを書けても、実際にうごかしてみたら遅かった、といったケースもあります。言い換えると、予測可能性が低いということです。 現代のシステム開発では、周囲の環境が高速で変化していきます。たとえば、OSもアップデートされますし、周囲のソフトウェアのエコシステムやプログラミング言語が変化していきます。現代のソフトウェア開発では、このような変化の側面を考慮しつつ開発していく必要があり、オレンジの道は実体として険しいということが分かっています。 そこで、現代(2018年)のソフトウェア開発では、青色の道を辿っていく開発があります。今回のTDDは青色の道に沿った開発手法なのですが、青色の道には心理面での罠が3つあります。罠とは以下の感情を持ってしまうことです： 堕落: 動くからいいじゃないか、と考えてしまう 焦り: 作るものはいっぱいあるから、きれいにする時間はない 恐れ: せっかく動くところまできているのに、きれいにするために触ったら壊れてしまうのではないか TDDは最後の難関である「恐れ」に対処するための技術です。TDDのサイクルは以下の流れとなります： 次の目標を考える その目標を示すテストを各 そのテストを実行して失敗させる(Red) 目的のコードを書く 2で書いたテストを成功させる(Green) テストが通るままでリファクタリングを行う(Refactor) 1-6を繰り返す 実際のTDDでは、上記のサイクルを繰り返してコードを書いていきます。 ワークショップでは、 FizzBuzz問題 を例に、TDDのライブコーディングで説明がありました。 後半: ペアプログラミング + TDD の実践kkk 後半(午後)は、実際に参加者同士でペアを組んで、TDD実習を行いました。 テーマは、 Semantic Versioning(semver) で、semverを表すオブジェクトの実装およびmajor/minor/patchのアップデート方法を実装していくというものです。後半のプログラムは"1-1.5時間程度の実装の後に、全員参加型のコードレビュー"を2サイクル回すという流れで実施します。実装言語は自由であり、今回の参加者は Python/Ruby/Node.js/Java を選択していました。 通常の開発では1-2名のコードレビューを受けるのはあるかと思いますが、参加者全員の目で、さらに異なる言語のレビューをするのはなかなか無い機会です。参加者からも、「別の言語での実装は参考になる」という声があがっていました。 以下で、実際のコードレビューの質疑の中で、参考になるものがあったので共有します: 値を設定するメソッドのテストについて Q: たとえば、setVersionのような値を設定するメソッドのテストはどうすればいいのか？ A: getVersionのような対となるメソッドを利用して、テストできる。基本的にはリフレクションを使わない。 Q: その場合、getVersion自体が壊れてしまった場合は、setVersionのテストも壊れるがそれはしょうがないのか？ A: YES。受け入れるべきリスクと考える。 例外のテストについて Q: 例外のテストの書き方は悩んだが、どのような方法あるのか？ A: 例外のテストの書き方はいくつかある。try/fail/catchパターンというのは1つで昔からある。メリットとして、catchした後のアサーションも書けるので、例外の中身自体のテストもできる。また、アノテーションを使って、ある例外が出たらテスト成功という書き方もある。 どこまでモックすべきなのか？ Q: たとえばデータベースような状態を保持してくれるソフトウェアや、外部APIのように3rd Party側が状態を保持するようなケースで、どこまでモックすれば良いのか？ A: 1つのポリシとして、1台のラップトップに入るものは全て実際のものを使うようにしている。したがってデータベースは実際のものを使うが、3rd PartyのAPIが外部のものなので、モックする。 参加者からの感想 参加者からは以下のような声が挙がっていました: TDDのアンチパターンである、Assertionルーレット等、テストを書く上でのアンチパターンに名前が付いているのが面白いし、覚える役に立ちそうでした。 プログラミングやテストを行う中で発生するジレンマや葛藤に対し、分かりやすい視点・解説で論理的に説明下さり、見通しが立ったように思います。メンテナンス性を確保するために、機能を細分化することの必要性や意義についても認識が深まりました。 これまで業務等でRuby/Golangのテストを実装したり、テスト駆動開発に挑戦したことはありましたが、体系的に学ぶことは初めてで、とても勉強になりました。 上記のコメントからも、非常に有用なワークショップであったことが伝わってきます！ おわりに NTTコミュニケーションズでは、ソフトウェア開発の内製に力を入れています。テスト駆動開発のような汎用的なソフトウェア開発スキルを学ぶワークショップは、エンジニアにとって刺激的で、そして非常に有用なものでした。今回は参加者数を絞っていましたが、参加を希望する社員も多くいるため、t_wadaさんに協力を依頼しつつ、ワークショップを継続的に開催し、エンジニアのソフトウェア開発スキルを向上させていきたいと考えております。

綺麗なAPIとは開発者にとって理解しやすく、使いやすいAPIです。さらに提供側にとってはメンテナンスしやすく、拡張性も担保されたものになります。そうしたAPIを設計するのは容易ではありませんが、幾つかのルールを設けておくことでも十分に綺麗に設計できるようになるでしょう。 1. モデル型かアクション型か URLを設計する際にRESTfulに作るのがデファクトになっていますが、その中でもURLの作り方をモデル（ユーザ、商品など）にするか、アクション型（購入する、出席するなど）にするかで分かれます。どちらを採用するにしても明確な基準が必要です。両方を満遍なく取り入れると、非常に分かりづらいものになります。 一般的には GET /users/1 でユーザデータに対する操作であるといった形にします。つまりモデル型です。 となると POST /purchase で購入するというアクションを定義するよりも POST /orders で注文データを作成するといった形の方が自然です。 またログインにおいてもセッションデータを作成するという意味で POST /session のがいいでしょう。セッションはブラウザごとに一つなので複数形ではなく単数形になります。 POST /login といったアクションベースではない方が良いでしょう。 2. RESTfulの原則に従う RESTfulの原則はURLが操作する対象のリソースを指定し、それに対するCRUD操作をHTTPメソッドで指定するというものです。その原則を尊重することでコントローラの機能を分離し、ソースコードの可読性も高まります。 一つのリソースが複数の状態を持つ場合、例えばタスク管理で考えてみます。 タスクの一覧（/tasks） アクティブなタスクの一覧（tasks/active） 期限の近いタスクの一覧（tasks/limit） 完了にしたタスクの一覧（tasks/done） とした場合、これらはすべてGETで処理されるものになります。これをRuby on Railsでハンドリングしようとした場合、ルーティングを設定することで一つのコントローラ（TasksController）で処理することもできます。しかし、管理が煩雑になっていくでしょう。 そこで以下のように分離して考えます。 タスクの一覧（TasksController#index） アクティブなタスクの一覧（Tasks::ActiveController#index） 期限の近いタスクの一覧（Tasks::LimitController#index） 完了にしたタスクの一覧（Tasks::DoneController#index） こうすることで一つのコントローラの中に実装されるコード量を減らせるのと同時に、対象になるリソースの限定とHTTPメソッドによる操作というRESTfulの原則が維持されます。それぞれの機能は似たようなもの（ステータスが違う程度）になりますので、実際のコードは共通化されたライブラリを活用することになるでしょう。 3. バージョンをURIに持たせない APIのバージョンをどこに持たせるかは常に問題になります。URIに入れた場合、多くは /api/1.0/users のようになります。これは多くの場合、2.0になった時に1.0で動作するライブラリをコピーする必要が出るでしょう。同じようなコードが氾濫することになり、管理が煩雑になります。開発者としても一部は1.0、一部は2.0を使い分ける時に共通したURLが /api/ しかなくなってしまうのは不便です。 そこでHTTPヘッダーやクエリストリングの中にバージョン番号を持たせるのはどうでしょう。よりフレキシブルに変更したいならばクエリストリングになるでしょう。HTTPヘッダーであればURLは共通で使えるようになります。 サーバ側としても既存のシステムがまったく別物に置き換わることはそうそうありませんので、プログラム中でバージョン番号を判定するだけで処理できるようになるでしょう。 4. レスポンスにHALなどを採用する 単なるJSONでは情報が不足するようになっています。そこで JSON API などメタデータを追加するJSONフォーマットが望まれるようになっています。その一つ、 HAL はAWSでも採用されているフォーマットであり、今後デファクトになっていく可能性があります。 HALを使うことでページネーションがある時に次のリンクを示すことができたり、追加のメタデータを付与できます。JSON APIもまた有名なJSONに情報を付与するフォーマットで、必要に応じて採用する方を決定すればいいでしょう。 APIのレスポンスを変えるというのはそうそう簡単ではありませんので、バージョン番号を使ったり、フォーマットを指定した場合などに採用するのがいいでしょう。もちろん、これから作るならばあらかじめ採用を決めておくのが最良です。 5. POST/PUTでもレスポンスボディを返す APIを使った開発においてよくあるのがPOST/PUTでデータを更新した時に、最新のデータをGETで取り直すというものです。これは2回APIアクセスする必要があってムダです。POSTで作った、PUTで更新したデータについて、その最新の状態をレスポンスに含めるようにしましょう。 特にサーバ側で処理されるデータがある場合、クライアント側ではデータがどういった値を持つかは分かりません。その結果、GETでアクセスする必要が生じてしまいます。ネットワークはボトルネックになりやすいので、クライアントからのアクセスを少なく済むようなサーバ側の実装を心がけましょう。 APIを実装する上でポイントになる部分はもっとたくさんあると思われますが、今回は主なポイントを5つ紹介しました。初期リリース時点では綺麗でも、更新を重ねていく内に破綻していくのはデータベース設計でもよくあることです。データベース管理者が将来的な拡張性も見込んでテーブル設計を行うのと同様に、APIにおいても更新を考えた上でメンテナンス性や論理的破綻を起こさないような設計を行いましょう。

SwaggerやOpen API Specification（以下OAS）はAPIのデファクトフォーマットになってきています。特にこれらのフォーマットでドキュメントを作っておくと、関連するライブラリやドキュメントが自動生成できるのが便利です。 Swagger/OASを使ったモックサーバであったり、テスト環境やエディタなどをまとめて提供してくれるのが SwaggerHub です。Swagger周辺のエコシステムを活用したい方はぜひ使ってみてください。 SwaggerHubについて SwaggerHubはSwagger/OASファイルの編集とプレビュー、ドキュメント表示などに加えてモックサーバを立ち上げたり関連するサーバ、クライアント双方のライブラリが生成できます。 設定は公開することもできるので、そのままAPIドキュメントとして開発者に使ってもらうことができます。 仕組みとしてはGitHub風で、組織を作成してその中にプロジェクトを追加する形になります。 新しいAPIをイチから作ることもできますし、インポートにも対応しています。 テンプレートも用意されており、さらにSwagger/OASのどちらかを選択できます。なお、OASの場合は幾つかの機能が未実装になっています。 編集画面です。左側がエディタで、編集内容が右側に反映されます。こちらはOASでの記述となっています。 日本語も問題なく使えます。 APIのモックサーバを立ち上げることもできます。 サーバ、クライアントのライブラリ生成機能はSwaggerの場合のみ有効です。多くのプログラミング言語に対応しています。 SwaggerHubではユーザの作成した定義ファイルが公開されており、API設計を行う上での参考にもなります。また、モックサーバの立ち上げなどSwagger/OASを使った開発サイクルをサポートしていますので、ドキュメント以外の要素においてもSwagger/OASを活用していきたい時に役立つでしょう。 新規でこれから作っていく場合はもちろんのこと、既存のファイルをインポートすることもできます。Swagger/OASのエコシステムを活用する際にぜひ使ってみてください。 SwaggerHub Powerful API Design Platform, Built for Teams

こんにちは、普段は SkyWay の開発・運用をしている岩瀬( @iwashi86 )です。 先日、クラウドアカデミー 1 という社内勉強会で、SkyWayのドキュメントに適用している継続的インテグレーション(CI)および継続的デプロイ(CD)について講演してきました。発表資料は以下になります。 オンラインドキュメントへCI/CDを適用している話 from Yoshimasa Iwase 内容の要約 内容を3行でまとめるとこんな感じです： MkDocsを使って静的WebサイトをMarkdownで書いて生成 textlintで文章をテスト CircleCIを使って、ドキュメントを継続的テスト＆デプロイ 実際の講演では、前半でそれぞれの項目について詳細化して説明し、後半でライブコーディング形式で実演しました。 発表後の質疑や感想など 発表後の質疑応答コーナーで、いくつかの質問をいただきました。そこで上がった質問の1つとして、「本フローが適用できない文書はあるか？」というものがあります。ポエムなどの詩的な文書には難しいかもしれませんが、 textlintでは任意のルールを作成可能 であるため、適用範囲は独自に拡大可能です。実際には拡大せずとも、(特に)技術系文書向けに既存のルールが多く存在するため、それらを活用するだけでも品質の底上げは十分に可能です。 より便利にルールを適用するために、ルールを複数まとめている、Presetも公開されています。たとえば、日本語の技術系文書では このPreset が活用できます。 また、終了後の参加者の感想として、「実際に自分のチームでも使ってみたい」などのコメントをいただきました。本勉強会に参加するのは、エンジニアだけではないため、普段からプログラムに触れるメンバ以外にも印象的だったようです。 まとめ クラウドアカデミーという社内勉強会で、ドキュメントにCI/CDを適用する話を講演してきました CI/CDにはMkDocs/textlint/CircleCI 活用しています textlintは様々な文書に適用可能です みなさまも、文書の品質改善にCI/CDのフローを適用してはいかがでしょうか。 Enterprise Cloud に関わるメンバが開催している社内勉強会 ↩

皆さま、明けましておめでとうございます。2018年になりました。個人、企業ともに新しいチャレンジを行っていく計画を立てるのに良い時期です。そこで、APIという視点において今年はどんな年になるのか紹介したいと思います。 ECサイト オンライン決済において、PCI DSSへの準拠が求められています。これは商品売買に限らず、クレジットカードを入力するような決済処理全般において対応が必要です。これは2018年03月までに対応が必要になります。 PCIDSSとは｜日本カード情報セキュリティ協議会 従来、購入者がWebサイト上でクレジットカード情報を入力し、サーバサイドで決済を行うのが一般的でした。しかし、昨今の情報流出やセキュリティインシデントの発生に伴ってクレジットカード情報を受け取る場合にはPCI DSSの高いレベルでの準拠が求められるようになります。これは中小規模なECサイトでは負担が大きい仕組みと言えます。 そこで最近ではクレジットカード情報をAPIで決済サービスへ送信して、一時的に使えるトークンに置き換え、そのトークンと購入額で決済を行う仕組みが提供されています。StripeやSquare、PAY.JPといったAPIで提供されている仕組みを使うことで、ユーザビリティを損なうことなくセキュアな決済が実現できます。 2018年前半まではECサイトはPCI DSSへの対応に追われるでしょう。 銀行API 2017年05月に改正銀行法が成立し、APIを提供する努力義務が銀行業界に課せられることになりました。本来、APIで安全にアクセスすべきなのですが、銀行業界は閉鎖的であったり、技術的なイノベーションが遅れることもあって、スクレイピングによるデータ取得が横行していました。これは行儀の悪い仕組みであり、Webサイトのデザイン変更によってサービスが止まってしまうといったリスクもあります。 現在、銀行では特定企業と契約を結びながらAPIを利用できるようになっています。さらにマネーフォワードではみずほ銀行、三井住友銀行、住信SBIネット銀行に対して送金が可能になっています。これもAPIを使っています（ ついにメガバンクが「更新系API」を提供開始、マネーフォワードが経費精算振込で連携一番乗り | TechCrunch Japan ）。 2018年においても、この傾向はさらに強まっていくと考えられます。銀行のAPIは個人情報や資産に関係してくるので一般開放は難しいかも知れませんが、企業提携などによって使えるサービスが増えていくことでしょう。 GraphQL RESTfulの課題が幾つも散見されるようになってきました。それに対する答えの一つとしてGraphQLに注目が集まっています。RESTful APIをすべて置き換える存在ではありませんが、GraphQLを取得系APIとして公開するケースは増えています。 GitHub Universe 2017において、GitHubもGraphQLを公開しました。今後もこの流れは広がっていくと考えられます。 GraphQL | A query language for your API Open API Specification Swaggerを継承し、APIドキュメントフォーマットとしてOpen API Specificationが2017年07月にローンチしました。2.0と3.0には互換性がありませんが、コンバータは存在します。今後、ソフトウェアやサービスがOpen API Specificationに対応していくと考えられます。 APIドキュメントについては他にも幾つかのフォーマットが存在しますが、Open API Specificationが最もデファクトに近い存在になってきていると言えます。ツールや関連サービスなどのエコシステムが整ってきていますので、APIドキュメントをOpen API Specificationに対応させておくことで広がりを持たせられることでしょう。 Home - Open API Initiative OpenID Connect OpenID ConnectはOAuth2をベースにした認証技術となっています。IDトークンとアクセストークンの発行両方に対応しています。OpenIDは認証情報を引き回すことができ、アクセストークンを使えば外部サービスのデータを許可した部分においてだけ利用できます。 現在、多くのサービスにおいてOAuth2だけでなくOpenID Connectも提供されるようになっています。提供側としては両方を、利用する側としては必要な方を選ぶといいでしょう。2018年においてもこの広がりはさらに早くなっていくと考えられます。 OpenID Connect | OpenID JSON JSONの事実上、最後と言える仕様が2017年12月に公開されました（ 事実上最後のJSON仕様「RFC 8259」と「ECMA-404 2nd Editon」公開。UTF-8エンコード必須に － Publickey ）。ECMAとの統一も行われ、今後はUTF-8エンコードが必須になるということが決まりました。APIにおいてほぼデファクトになってきているフォーマットだけに、仕様が固まったのはAPI利用側/提供側双方にとってメリットがあるでしょう。 JSONをイチから作るケースはそうそうないかと思います。多くの場合、各プログラミング言語についているライブラリを利用することでしょう。JSONの仕様が固まったと言える状況なので、各ライブラリも最終版と言える状態になってくるのではないでしょうか。 APIのデータフォーマットにおいてはJSONの他、XMLやProtocol Bufferなど様々にあります。しかし最も扱いやすく、人に対してもある程度可読性が確保されているフォーマットとしてJSONは今後も利用が増えていくと思われます。 JSON APIを提供する、利用するのが当たり前になりつつある現在、2018年もAPIのエコシステムがますます広がっていくと思われます。金融系のような固い業界においてもAPIが浸透してきていますので、今年も多くの企業がAPI公開に踏み切ることでしょう。

APIを公開して新しい収益軸にしたいと考える企業が増えています。しかし、その際に何からはじめれば良いか分かっていない方も多くいます。今回はAPI提供の企画段階から考えていくべきポイントを紹介します。 自社だけの資産を見つける API公開する上で肝になるのが自社独自の資産です。独自性が強ければ強いほど、価値があり他社がおいそれと参入できないものになります。デジタルよりもリアル、その資産を取得するのに時間がかかったり、特殊な技能が必要、十分なお金がなければならないといった特徴があると有利でしょう。 例えば寺田倉庫では倉庫を持っているというのが最大の利点になります。Amazonは倉庫はもちろん、Amazonという超巨大Eコマースサービスを持っていること、他にも古物商や弁護士資格が必要な技能をAPI化するのも良いでしょう。 最小単位での利用を実現する 次にそれらの資産を細分化し、なるべく細かい単位で使えるようにしましょう。単位が大きい場合、それは月額の予算も大きくなりがちです。そうなると契約の締結なども大事になり、結果として大企業同士の提携レベルになってしまいます。それであればAPIという形をとるメリットが薄くなります。APIはロングテールビジネスとして考える方が分かりやすいはずです。 とは言えFinTech系では企業同士の提携によってプライベートAPIを公開しています。APIの特性によっても変わってくる点ではありますが、ターゲットを広く取るのであれば、利用単位はなるべく小さくすべきです。 前述の寺田倉庫であれば段ボール1個、1ヶ月単位での課金になります。AWSでは1万単位でのアクセスで数円であったり、少なく利用するユーザからは少なく、大規模に利用する企業からは十分に収益をあげるモデルになっています。 業務フローを自動化する 実際の業務はアナログで行うとしても、そこに至るフローをなるべく自動化しなければAPI化のメリットはありません。APIというインタフェースを用意したのであれば、その後のデータの流れも自動化していきましょう。APIをコールされるとメールが来て、それから普段の業務フロー…というのはナンセンスです。 APIを公開している企業において、社内フローが従来のままというのはよくあるケースです。これではAPIによる依頼増に対応できず、業務がパンクしてしまいます。API公開を計画するならば、現状業務の最適化についても検討すべきでしょう。 24時間対応できる部分を考える APIは24時間365日稼働しているのが基本です。リクエストは常時発生します。すべてのリクエストをリアルタイムに行っていく必要はありませんが、なるべくキューに貯めすぎない仕組みが必要です。クラウドソーシングを活用するなど、時間に依らない運用体制を確立すべきです。 人の手による作業が入る場合、その作業状況を返すAPIを用意したり、Webhookで完了を通知する仕組みを用意するのが良いでしょう。人の手で行っている作業がAPIとしての付加価値につながる場合もあります（サンサンの名刺管理など）。 標準技術を積極的に取り入れる 日本企業はオリジナルの仕組みが大好きです。しかしことAPIについてはオリジナルの仕組みは喜ばれません。今であればOAuth2やOpenID、RESTful API、CRUD操作というのが標準であり、使っていくべき仕組みです。 APIは自社でももちろん使いますが、基本的には他者が利用するものです。そうした人たちにとって標準技術の方が取り入れやすいですし、問題があった時の解決も早いでしょう。 内部の仕組みが整っていないままにAPIを公開したとしても、業務の負荷が増すだけです。まず社内のフローを見直し、API公開に対応できる自動化を推し進めなければなりません。 とは言え、APIは企業のIT化を進める上でも重要な観点になります。自社の資産を見つけ、それを新しい収益源に展開しましょう。

APIを新しいビジネスとして、新たな収益源にしたいと考えたとしましょう。通常のWebサービスであれば利用する度に課金したり、月額課金モデルなどが有名ですが、APIにおいてはまた別な観点で戦略を考える必要があります。 今回はそうしたAPI事業化に対する懸念点、調査すべき点を紹介します。 販売戦略を立てる どのような事業であってもゴールや販売戦略が必要です。特にAPIの場合、開発者でない人たちに対してその良さをアピールするのは非常に難しいという問題があります。そのため、営業担当者が積極的に売りづらい商材になりがちで、なかなか利用が伸びなかったりします。 そういった事態にならないよう、あらかじめどう販売するか入念に考える必要があります。特にAPIは利用する側に開発を強いるものです。できあがった製品を購入するのとは違うので、そういった点からもどう売っていくかを考えなければなりません。 APIファースト APIを戦略の軸において考えるならば、そのサービス全体がAPIで提供されているくらいの形で進めましょう。特にユーザ向けの管理画面では表示できる情報はすべてAPIでも取得できるべきです。そのためにはAPIファースト、APIありきで開発を行えば良いでしょう。 このような進め方はスマートフォンアプリであれば当たり前です。APIファーストによって、デバイスのUIという縛りをなくして、データ利用ができます。 ペルソナ 通常のマーケティングであればペルソナといえば個人ですが、APIが対象にするのはコンピュータになります。そのため、対象企業の事業や業種がペルソナになってきます。出版社や個人向け保険などであったり、決済やメール送信など機能単位で考える場合もあります。 ライバル調査 APIの場合、一度稼働しているものに対して乗り換えるニーズは強くありません。飛び抜けて安い、または使いやすいといった特徴が必要です。複数APIを織り交ぜることもできますが、それは希でしょう。 APIについては市場の独占化が強く行われるので、強力なプレイヤーが存在する市場は新規参入が困難です。 料金体系 日本企業においては予算を稟議にかけて承諾されると、その範囲内での出費が求められます。海外では1アクセスごとの課金など、運用してみないと予算がいくらになるか分からないものが多いですが、日本の商習慣に合っていないと言えるでしょう（現在は幾分認知されていますが）。 月額固定金額で利用できるのが日本企業にとっては理想と言えます。しかし、API提供側としては取り過ぎたり、逆にマイナスになる可能性も秘めています。なお、手数料型ビジネスである決済においては1トランザクションごとの課金が認知されています。向き不向きがあるかも知れません。 バランス型よりも特化型 ことAPIについて求められるのは単機能で分かりやすいものです。Webサービスのように様々な機能があって、ユーザが選択しながらサービス提供を行うのはAPIには向いていません。固定化された使い方をシステム連携で常時行っているのが一般的です。 将来的にAPIが増えていくのは構いませんが、最初については多くない方が良いでしょう。その単機能が市場に求められているかどうかで成否を決められる分、開発工数も抑えられますし、失敗時のリスクも下げられます。 APIは自動化されて動くので、料金を青天井にするのは利用側、提供側にとって大きなリスクになります。アラートを出したり、あらかじめ制限をかけておいて使えるようにするのが良いでしょう。 手数料型ビジネスが一般的に受け入れられているジャンルもあれば、そうでないジャンルもあります。自社で提供するAPIがどこにマッチするかを適切に判断しましょう。