「Web API: The Good Parts」読書メモ ~ その 3 ~
tl;dr
どうも私です。
前回に引き続き「Web API: The Good Parts」についてのアウトプットその 3 です。
3 章では「レスポンスデータの設計」について触れられています。
目次
Web API: The Good Parts
3 章 : レスポンスデータの設計
要点
データフォーマット
世の中的なデファクトスタンダードが JSON である。
そのため、JSON にデフォルトとして対応し、
必要に応じて XML 等の別のフォーマットに対応する方針で良い。
データフォーマットの指定方法
別のフォーマットをサポートしたい、もしくはしなければならない場合に、
クライアント側にどのようにフォーマットを指定させるのか？
一般的には以下のような方法が使われる。
- クエリパラメータを使う方法
- 拡張子を使う方法
- リクエストヘッダでメディアタイプを指定する方法
このうちどれを使用するのかは、かなり「好みの問題」である。
HTTP の仕様を最大限活用するならば、
リクエストヘッダで指定することになるが敷居は高い。
実際のサービスを調べると、クエリパラメータを使う方法が多い。
クエリパラメータを使う方法もしくは、 複数の方法に対応しておくことがおすすめとのこと。
データの内部構造の考え方
API のアクセス回数がなるべく少なくなるように、
API それぞれのユースケースをきちんと考えることが重要である。
1 つの作業を完結するために複数回のアクセスが必要な API 設計は
「Chatty (おしゃべりな) API」と呼ばれ様々な弊害が生じる。
- クライアント側の処理が煩雑になる
- HTTP のオーバヘッドが上がり、レイテンシーが低下する
- サーバの負荷上昇につながる
エンベロープは必要か
エンベロープとは日本語で「封筒」を意味する。
API の文脈では「すべてのデータを同じ構造でくるむこと」を意味する。
以下のように「header」と「body」をレスポンス構造に持ち、
実際のデータを「body」に、共通のメタデータを「header」に持っている。
{ "header": { "status": "success", "errorCode": 0 }, "body": { "hoge": "xxx" } }
こうしたすべての API が同じデータ構造を返すために、
実際のデータをくるむための構造をエンベロープと呼ぶ。
結論としては「エンベロープ」は冗長であり、やるべきではない。
Web API は基本的に HTTP がエンベロープの役割を果たしている。
HTTP にはヘッダがあり、そこに様々な情報を入れることができる。
エラー判定もステータスコードを利用することで実現可能である。
そのため、レスポンスヘッダの書き方を全 API で共通化した方が、
クライアント側の実装も抽象化できるため有益である。
データはフラットにすべきか
Google の JSON Style Guide には以下のような記載がある。
「なるべくフラットにした方が良いが、階層構造があった方がわかりやすい場合もある」
住所を例に挙げているが、この場合は階層構造があった方がわかりやすいとのこと。
階層構造化する場合は慎重な判断が必要であり、
利便性による恣意的なグルーピングではなく、
意味的に有益なグルーピングを行った方が良い。
配列とフォーマット
配列をレスポンスとして返す場合に以下の 2 パターンが考えられる。
- 配列をそのまま返す
[ {"id" : 1}, {"id" : 2}, {"id" : 3} ]
- オブジェクトで包む
[ "animals" : [ {"id" : 1}, {"id" : 2}, {"id" : 3} ] ]
どちらも JSON としては問題ないが、
以下の理由から筆者としては「2. オブジェクトで包む」がおすすめとのこと。
- レスポンスデータが何を示しているかわかりやすい
- オブジェクトのキーから何のデータかひと目でわかる
- レスポンスデータをオブジェクトに統一することができる
- セキュリティ上のリスクを避けることができる (
最も重要)
各データの名前
エンドポイントのデザインと同様に以下のポイントが重要である。
性別のデータをどう表すか
いくつかのサービスが「性別のデータ」をどのように表すかを確認した際に、
数値(e.g. 0 or 1)ではなく、文字列(e.g. male, female)で表すことが圧倒的に多い。
SSKDs 向けの API であれば「数値」も選択肢として考えられるが、 LSUDs 向けの API であれば「文字列」を選択した方がベータである。
日付のフォーマット
日付の表現方法には様々なものがある。
| 形式名 | 例 |
|---|---|
| RFC 822 (RFC 1123 で修正) | Sun, 06 Nov 1994 08:49:37 GMT |
| RFC 850 (RFC 1036 で廃止) | Sunday, 06-Nov-94 08:49:37 GMT |
| RFC 3399 | 2015-10-12T11:30:22+09:00 |
| Unix タイムスタンプ | 1630503271 |
筆者の結論としては「RFC 3399」を採用するのがベターとのこと。
理由としては、これまでのフォーマットの問題を解決し、
使いやすいものを目指してインターネット上の標準形式として決められたものだからである。
タイムゾーンはサービスと使用者の性質によって統一して使用するものを選択する。
大きな整数と JSON
クライアント側によっては大きな整数を扱った際に問題がおこるため、 レスポンスデータとして大きな整数(e.g. bigint)を返す場合は注意が必要である。
- クライアントが 64ビット整数を 32ビットで処理している場合
- 桁溢れが発生してしまう可能性がある
- クライアントが大きな整数を正しく扱えない言語を使用している場合
- e.g. Javascript : 誤差が発生してしまう
回避策として「 こうした数値を文字列で返す 」という方法がある。
Twitter は id の他に id_str と型を文字列にしたものを返している。
エラーの表現
なるべく多くの情報をクライアントに返し、
クライアントが問題を解決して API を利用できるようにした方がベターである。
そうしなければ「使いづらい API」という烙印を押されてしまう。
また、間違ったアクセスが増えサーバの負荷を増やす要因になる可能性もある。
そのため、以下の 2 点に気をつける必要がある。
- ステータスコードでエラーを表現する
- エラーの詳細をクライアントに返す
1. ステータスコードでエラーを表現する
適切な HTTP ステータスコードを使用することが重要である。
| ステータスコード | 意味 |
|---|---|
| 1xx 系 | 情報 |
| 2xx 系 | 成功 |
| 3xx 系 | リダイレクト |
| 4xx 系 | クライアントサイドに起因するエラー |
| 5xx 系 | サーバサイドに起因するエラー |
世の中の API によってはエラー時にも「2xx系」を返している場合もあるが、
これは使い方として正しくなく、また問題も引き起こす可能性がある。
汎用的な HTTP のクライアントライブラリには、
ステータスコードを見て処理を分岐しているものが多く、
こうした用意された処理をそのまま利用できなくなってしまう。
2. エラーの詳細をクライアントに返す
ステータスコードだけでは不十分であり、エラーの詳細を返すことが重要である。
エラーの詳細を返す方法は以下の 2 パターン考えられる。
- HTTP のレスポンスヘッダに独自定義したヘッダ項目を用意する
- レスポンスボディにエラー用のデータ構造を用意する
多くの API はクライアント側の利便性から「2」を採用していることが多い。
そのため、特に理由がないのであれば「2」の方法を採用して問題ない。
エラーの詳細としては、以下のような情報組み合わせて返した方がベターである。
- エラーメッセージ
- e.g. {"message" : "Bad Authentication token"}
- 非開発者向け(エンドユーザ)と開発者向けでわけるという方法もある
- エラーの詳細コード
- e.g. {"code" : 1000}
- HTTP ステータスコードのようにルール化し管理しやすくすると便利である
- 詳細情報へのリンク
- e.g. {"documentation_url": "https://domain/developer/document/xxx/yyy"}
- API ドキュメントが存在するなら(LSUDs 向け?)
感想
個人的には「API 全体としての統一感」や「省略形を使用しない」という点は強く同意でした。
同じサービスの API であるのにもかかわらず、
統一感のないレスポンス構造やフィールド名を採用している場合、
クライアントはもちろん API 開発者も開発スピードが減少するため、
お互いに良いことなし、、だと思うんですよね。。
また、エラーの表現についても同様だと思います。
クライアントがエラーの原因を解決できるようにするだけでなく、
API 開発者が問い合わせを受けた際に、つまり運用の際に、
何が起きたのかヒアリングしやすい仕組みも「エラー表現」に繋がるのだと個人的には感じました。
「Web API: The Good Parts」読書メモ ~ その 2 ~
tl;dr
どうも私です。
前回に引き続き「Web API: The Good Parts」についてのアウトプットその 2 です。
2 章から具体的な「美しい設計」の方法について触れられていきます。
目次
Web API: The Good Parts
2 章 : エンドポイントの設計とリクエストの形式
用語
要点
API として公開する機能を設計する
設計のポイントは以下の通り。
その際に注意しなければならない点がある。
- SQL 文をただ包んだだけの設計では決して使いやすい API とはならない
- データごとの内部仕様やリレーションを理解していないと利用できない
- 内部仕様やリレーションを外部公開することはセキュリティリスクとなる
API の設計は SQL を単純にラップしたではなく、
少し高い次元での機能を表現するように設計する。
API エンドポイントの基本的な設計
良い URI 設計における非常に重要な原則は以下の通り。
覚えやすく、どんな機能を持つ URI なのかがひと目でわかる
「覚えやすく」をさらに細かく言語化すると次のようになる。
1. 短く入力しやすいURI
- 「短く入力しやすい」ことは「シンプルで覚えやすい」ことに繋がる
- e.g. (bad) https://api.example.com/service/api/search
2. 人間が読んで理解できる URI
- その URI を見れば何を目的とした API かある程度わかること
- e.g. (bad) https://api.example.com/sv/u/
- 「sv」も「u」も使用者にとっては意味がわからない
- 短くを目指した結果、かえってわかりづらくなっている
- e.g. (bad) https://api.example.com/sv/u/
そのためのには以下の 3 点に気を配る。
- むやみに省略形は使わない
- 標準化されているものは例外 (e.g. 国コード)
- API での頻出英単語を利用する
- 世界的な共通言語である英語を使うのが適切である
- e.g. 製品 (products, productos, seihin)
- 頻出英単語は共通認識があることが多い
- e.g. 探すという意味を持つ「search」など
- c.f. ProgrammableWeb
- URL だけを見て意味を理解することの手助けとなる
- 世界的な共通言語である英語を使うのが適切である
- スペルミスをしないこと
- e.g. リクエストヘッダの Referer
- 実際の API のミスかドキュメントのミスか利用者が困惑する
3. 大文字小文字が混在していない URI
- 基本はすべて小文字を使用する
- 大文字小文字の混在は URI をわかりづらく、間違えやすくする
- 標準的に選択されているのが「小文字」である
4. 改造しやすい (Hackable な) URI
- Hackable とは？
- URI を修正して別の URI にするのが容易であること
- e.g. https://domain/v1/items/12345
- 「12345」がアイテムの ID であると直感的に理解できる
- 他のアイテムにアクセスする際は ID を変えると予測できる
- 開発の際にいちいちドキュメントを参照するような作りは NG
- 利用者の開発速度やストレスに影響が出る
- ドキュメントの見落としによるバグが発生しやすくなる
- サーバ側のアーキテクチャとは？
- 反映されていないとは？
- 利用者が意識する必要のない情報が URI に含まれていないこと
- e.g. https://domain/cgi/get_book.php?id=1
- 反映された URI にはセキュリティリスクがある
6. ルールが統一された URI
- クライアント実装側が混乱しトラブルの原因となる
- e.g. ID の指定方法がエンドポイントごとに異なる
HTTP メソッドとエンドポイント
URI とメソッドの関係は「操作するもの」と「操作方法」の関係である。
Web API では以下のメソッドを利用するケースが多い。
| メソッド名 | 説明 | 備考 |
|---|---|---|
| GET | リソースの取得 | 原則、リソースの変更は発生しない |
| POST | リソースの新規作成 | - |
| PUT | 既存リソースの更新 | リソースを完全に上書きする |
| DELETE | リソースの削除 | - |
| PATCH | リソースの一部更新 | リソースの一部を変更する |
| HEAD | リソースのメタ情報取得 | - |
1 つの URI エンドボイントに異なるメソッドでアクセスすることで、
リソースをどう扱う(取得、更新、削除、etc...)のかを分離して扱うことができる。
エンドポイント設計の注意点
注意点は以下の 4 つである。
- 複数形の名詞を利用する
- 利用する単語に気をつける
- スペースやエンコードを必要とする文字を使わない
- 単語をつなげる必要がある場合はハイフンを利用する
1. 複数形の名詞を利用する
- HTTP の URI はリソースを表すものである
- HTTP の メソッドは動詞を表すものである
- その上でリソースの「集合」をどう操作するのかを表現する
2. 利用する単語に気をつける
- 「探す」を例に挙げても 2 つの単語がある
- search : 探す場所を目的語にとる
- find : 探すものを目的語にとる
- 迷った場合は他の類似の API を調べてみる
3. スペースやエンコードを必要とする文字を使わない
4. 単語をつなげる必要がある場合はハイフンを利用する
- 単語をつなげる方法はいくつか存在する
- チェインケース (ハイフンでつなぐ)
- スネークケース (アンスコでつなぐ)
- キャメルケース(単語の先頭を大文字としてつなぐ)
- その他ケース (ドットでつなぐなど)
- API の URI 設計について実は
決定的なものはない - もっともベターなのは...
- 単語のつなぎ合わせを極力避けてパスとして区切ること
クエリパラメータとパスの使い分け
判断基準は以下の通り。
- 一意なリソースを表すのに必要な情報かどうか
- 省略可能かどうか
1 を満たす場合には「パス」に情報を入れる。
2 を満たす場合には「クエリパラメータ」に情報を入れる。
SSKDs と API デザイン
今までの検討はどちらかといえば LSUDs 向けである。
SSKDs 向けにおいても重要ではあるが、
エンドユーザにとってのユーザ体験がより重要になる。
ブログアプリのホーム画面を例に挙げる。
ホーム画面には以下の情報が表示されている。
- 新着記事
- 人気の記事
- おすすめ記事
- ユーザランキング様々な
今まで検討した内容で API を組み立てると、
情報ごとに 4 つの API を作成するかもしれない。
しかし、アプリ側からすると 1 つの画面を表示するだけで、
4 つの API をリクエストする必要があり、非効率である。
また、画面を表示するまでに時間がかかるかもしれない。
良いユーザ体験が損なわれる可能性がある。
そのため、必ずしも汎用的という観点から美しい必要はない。
LSUDs 向けの API であっても同様であり、
クライアントのユースケースを想像して設計する必要はある。
HATEOAS と REST LEVEL3 API
異なるアプローチの API 設計の提唱。
Martin Fowler 氏の「Richardson Maturity Model」という記事内で、
すばらしい REST API に至るまでを 3つのステップに分解して解説している。
- REST LEVEL0 - HTTP を使っている
- REST LEVEL1 - リソースの概念の導入
- REST LEVEL2 - HTTPの動詞 (GET/POST/PUT/DELETEなど) の導入
- REST LEVEL3 - HATEOAS の概念の導入
REST LEVEL3 に相当するのが「異なるアプローチ」である。
HATEOAS (Hypermedia as the Engine of Application State) とは、
API の返すデータの中に、次に行う行動、取得するデータ等の URL を含めることで、
そのデータを見れば次にどこにアクセスすれば良いのかわかるような設計。
例えば、ユーザ一覧を返す API の場合、
ユーザごとのリソースを取得するための URL が含まれる。
また、現在のデータとの関連性を rel の中に含める。
{ "userss": [ { "name": "satou", "link": { "uri": "https://domain/v1/users/111", "rel": "users/detail" } }, { "name": "suzuki", "link": { "uri": "https://domain/v1/users/222", "rel": "users/detail" } } ] }
以下のようなメリットがある。
しかし、採用するか否かは慎重な検討が必要である。
(2014年段階では) HATEOAS は人口に膾炙しているとは言い難いため、
クライアント側の実装をかえって難しくしてしまう可能性はある。
感想
今回のアウトプットではあえて記載していないのですが、
「検索とクエリパラメータの設計」周りの話はかなり勉強になりました。
また、ログイン周りのお話も同様ですので興味のある方は是非購入を(笑)
クエリパラメータとパスは油断するとイケてない設計になることが多いので、
考える上での基準点を明文化して知ることができたのは大きかったです。
「Web API: The Good Parts」読書メモ ~ その 1 ~
tl;dr
どうも私です。
お久しぶりです。
前回の投稿から 約2年半ほど間が空きました。
このブログをどう使っていこうか見切り発車だったのですが、
自身の備忘録を兼ねたアウトプットの場として使っていこうと思います。
インターネットのデブリとならないように頑張りたい所存です。
さて、今回は「Web API: The Good Parts」についてのアウトプットその 1 です。
今更ながらに書籍をちゃんと読んだのですが(苦笑)、
自身の中で感覚的に理解してた API 設計の知識が整理されました。
目次
Web API: The Good Parts
1 章 : Web API とは何か？
要点
開発者が Web API を設計する機会は？
開発者が Web API を設計しなれればならない機会は様々である。
上記の例のように目的は様々ですが、平たく言ってしまえば、
「異なるシステムやサービス同士を繋ぐ」際に Web API を設計する機会が発生する。
なぜ API を公開するのか？
そのサービスができることをすべて API 経由でできるようにすることで、
サービスの「価値」を自社のアプリケーションで利用可能にするだけでなく、
他社のアプリケーションでも利用可能にすることができる。
Web API がその橋渡し役となり、サービスの「価値」の拡販に繋がる。
また、優先度を下げた機能や新しい発想の機能を API 利用者が作成してくれる可能性がある。
なぜ Web API を美しく設計しなければならないのか？
「美しさ」とは以下に挙げるような完成度の高さを表す。
- よく考えられている
- わかりやすく整理されている
- 無駄がないこと
Web API を美しく設計しなければならない理由は次の通り。
設計の美しい Web API は使いやすい
設計の美しい Web API は変更しやすい
- サービスの進化にあわせて API にも変更が発生する
- いかに利用者に影響なく変更可能とするかが大切である
- e.g. 不特定多数の第三者に利用されているケース
- e.g. バージョンの異なるアプリに利用されているケース
設計の美しい Web API は頑強である
- セキュリティの問題に対してきちんと考慮して設計が必要である
設計の美しい Web API は恥ずかしくない
- センスの疑われる API を通し、サービス開発者の技術レベルも疑われる
- その結果、開発者の採用に悪い影響がでる可能性がある
「美しくする」にはどうすればいいのか？
大きく以下の 2 点が大切である。
- 仕様が決まっているものに関しては仕様に従う
- 仕様が存在していないものに関してはデファクトスタンダードに従う
その際、注意すべきがある。
- 思考停止で人の真似をするわけではないこと
- なぜそういう仕様、デファクトスタンダードなのかを理解すること
- 基礎を知った上で、自身がより良いと思った仕様を試すこと
対象となる開発者の数が API 設計に与える影響とは？
Netflix 社 Daniel Jacobson 氏の記事内で、
「対象となる開発者の数」と API 設計のアプローチについて触れられている。
- LSUDs (Large set of unknown developers)
- SSKDs (small set of known developers)
対象となる開発者が異なれば想定するユースケースも異なる。
また、何が対象の集団にとって使いやすいかを考える基準も異なる。
転じて、「美しい設計」という定義も異なってくる。
感想
第 1 章では「美しく設計する」という点について、
前提知識を共有したり読者の目線を合わせることに注力していた印象です。
個人的には LSUDs と SSKDs という概念が新鮮でした。
感覚的には両者を分けていたのですが、
名前が与えられたことにより両者の境目が明確になったと思います。
SSKDs における REST API では対応しきれない要求については、
オーケストレーションレイヤーを採用するという考え方に触れているのですが、
これが「BFF(Backends For Frontends)」へと発展していくのでしょうか？
『Backlog World 2019 プロジェクトマネージメント × 働き方改革』に参加してきました！
Backlog World 2019 プロジェクトマネージメント × 働き方改革
- Backlog World 2019 プロジェクトマネージメント × 働き方改革
- tl;dr
- アメニティ
- タイムテーブル
- (11:00〜11:15) 開会式
- (11:20〜11:50) 基調講演「田舎の木材工場で起きた奇跡」と、その後。
- (12:00 ~ 13:00) ランチタイム
- (13:00〜13:25) 「連絡板」が支える、Backlog嫌いなクライアントとのコミュニケーション
- (13:25〜13:50) 小さなチームの全員マネジメントな日常
- (14:00〜14:25) Backlogでわかる炎上の見分け方、消し方
- (14:25〜14:50) エンジニア約1%の集団で働きやすい環境を作るために半年でやった10のこと
- (15:00〜15:50) 辻ちゃん・ウエちゃんのアクセシビリティPodcast「Backlogのアクセシビリティを斬る！」
- (16:00~16:50) スペシャルセッション「スーパーマリオで学ぶプロジェクトマネジメント」
- まとめ
tl;dr
どうも私です。
「Backlog World 2019 」に参加してきました！
12月にチケットを購入したので早期チケット1000円というお得感溢れるイベントでした(笑)
イベントの内容については次の引用を参照ください。
Backlog Worldとは・・・
100万人以上が利用する、日本最大級のプロジェクト管理ツール”Backlog(バックログ)”。 Backlog Worldとして2回目の開催となる「Backlog World 2019」は、 Backlogのユーザーコミュニティ”JBUG(ジェイバグ)”が運営します。 今年は「プロジェクトマネジメント×働き方改革」というテーマで、 数々のセッションやワークショップ、情報共有の場、Good Project Award(表彰イベント)などで
プロジェクト管理に関する知見を相互に高め合うイベントです。
この記事では聞いてきたセッションについてざっくりまとめます。
アメニティ
こういったイベント恒例のステッカーに
衣類の圧縮袋からウエットティッシュにコースター、
企業さんの折り込みチラシと色々といただきました。
タイムテーブル
赤色で囲まれた箇所のセッションを聞いてきました！
(11:00〜11:15) 開会式
朝から賑わってました！
(11:20〜11:50) 基調講演「田舎の木材工場で起きた奇跡」と、その後。
タイムテーブルから引用
宮崎県にある、とある木材工場。この工場で働く従業員の平均年齢は48歳。 タブレットはもちろんスマホも使ったことがない方ばかり。 そこの社長から「工場の未来のためにIT化が必要。何とかして欲しい！」というご依頼。 「IT化なんて無理。」そんな空気の現場でIT化プロジェクトをどのように進め、何が起きたか? Good Project Award 2017最優秀賞受賞プロジェクトの裏側とその後について紹介します。
登壇者情報
登壇者 : 西 武史 さん
所属 : diffeasy(ディフィージー)
内容 & ヒトコト感想
宮崎県の2×4の木材パネル工場の社長さんから
「iPad でシステムを作りたいという」という漠然とした依頼に対して、
プロジェクトをどのようにして成功に導いたかという話でした。
依頼してきた会社ですが平均年齢48歳で社員数 20名がほぼガラケーという、
ITリテラシーがとっても低い会社！
登壇者の西さんもはじめは思わず「大丈夫かな ?」と思ったそう(笑)
そのため、「開発メンバーが現場で全員からヒアリングすること」 からスタート！
ユーザーにまずスマホを使わせることで、フリック入力が苦手だということがわかり、そこで、システムはできるだけ入力を行わないシステムにする方針とした。
— オムそば @マネジメントは技術 (@teamomusoba) 2019年1月26日
まさに要求分析...素晴らしい。
#backlogworld
そして「家一軒につき、500枚」もある紙の設計書を
iPad で見れるようにメモが取れるようにしてペーパーレス化を図ることに。
そのときの工夫したのは次の通りとのこと。
- 機能を詰めすぎない
- メニューボタンとは色分けした
- 現場では「赤色のボタン押して」と言うだろうと予想
ペーパレス化してから 2, 3ヶ月後に西さんが会社を訪れると。。
お客さんがタブレットのミラーリング機能で会社のディスプレイに映すように。
現場のITリテラシーに進歩が！！！
しかもらにその後。。
新工場が完成( 2×4 しては国内最大規模)！
超イケイケなてるHP(株式会社ビッグハウス )が作成されるように(笑)
よく見るとエンジニアも募集している(笑)
IT化後に起きた変化は次の通り。
- 残業時間の大幅改善
- 作業状況が共有される
- 生産枚数などで個人の得意な作業がわかるように
- 知識の共有ができるように(用語集 / 設計書の共有)
- 属人化からの脱却
- 社員数も増加(20 -> 40)
- 設計チームがリモートワーク可能に
この工場に行くと、耳にタッチペンを挟んでいる職人さんが見れます
— オムそば @マネジメントは技術 (@teamomusoba) 2019年1月26日
#backlogworld
「うまいった要因」として次のように分析されてました。
- 小さな成功を積み重ねる
- 色々とIT化したいものがあったが一気にはやらなかった
- 出荷管理・生産性管理・設計書の管理...
- ITリテラシーが低い現場ですべてを一気に浸透するのは大変....
- まずはタブレットでLINEを使って見る
- 現場の社員たちにタブレットに慣れてもらう
- そこからまずは「設計書のペーパーレス管理」へ
- 真の課題へのアプローチ
- 出荷のQR管理
- 誤配送が多かった
- 出荷素材の置き場のルールがなかったことが問題
- であれば無理にITせずにまずは「ルール化」をしよう
- 関係者全員ストーリーを共有
- PM、開発者、社長、従業員がやりたいことや問題を共有
- 社長のリーダーシップ
- 社員と開発メンバーの橋渡しを率先して
- 作業を止めさせてでも言いたいこといわせる
最後にまとめとして「PMとは？」というお話に。
- PMとは？ (引用 : エンジニアリング組織論の招待)
- プロジェクト？
- 主に納期の不確実性に対応
- プロダクト？
- 主にマーケットの不確実性に対応
つまり、、、
「プロジェクトをファシリテートして関係者全員でプロジェクトを成功に導くこと」 という流れに！
(12:00 ~ 13:00) ランチタイム
「とんかつ まい泉」のお弁当が出てました。 早期割で 1000円チケット勢としてはもう満足(笑)
(13:00〜13:25) 「連絡板」が支える、Backlog嫌いなクライアントとのコミュニケーション
タイムテーブルから引用
H2O spaceは、オフィスを持たない、完全リモートワークの Web制作会社です。 すべてのプロジェクトで Backlogを活用し、社員、クライアント、 パートナーのすべてのメンバーが、Backlogを通じてコミュニケーションを行ないます。 しかし、これを確立するまでにはさまざまな試行錯誤がありました。 本セッションでは、そんないくつかの工夫について紹介していきます。
登壇者情報
登壇者 : たにぐちまこと さん
所属 : H2O space
内容 & ヒトコト感想
バックログをなかなか使ってくれないクライアントさんに対して、
どのようにしたらバックログを使ってくれるようになるのか、
試行錯誤しながら工夫したというお話でした。
仕事の内容としては「大学サイトの構築」が多いらしく、
クライアントさんはあまり積極的にITを使うタイプではなかったとのこと。
まず完全リモートワークな会社であるため、
コミュニケーション手段についてのお話になりました。
それぞれのコミュニケーション手段には長所と短所があり、
それをいかに使い分けていくのかがやっぱり鍵みたい。
- コミュニケーション手段
長所と短所はそれぞれだなーと。。
ただ、たにぐちさん自身は「電話爆発しろ」というぐらいの電話嫌い(笑)
それは私もすごいわかるなと思いました。
喋るのが嫌いなんじゃないんですよ。
相手の集中した時間を無視するのや記録が残らないのが嫌なんです。
電話で会話するぐらいだったら会ってちゃんと話をしたい(笑)
銀の弾丸はないように、バックログにも相手次第でやっぱり短所(?)はあるようです。
Backlogの「3ない」。タスクを整理してくれない。見てくれない。使ってくれない。
— オムそば @マネジメントは技術 (@teamomusoba) 2019年1月26日
#backlogworld #Room2
そして流れで「ダメなバックログ活用事例」のお話に。
- 『クライアントとデザイナーさんとの直接結びつけている』
- ディレクターが間に入らないことによりデザイナーの心理的負担が増える
- 本当にやるべきことであるのかが判断しずらい
ディレクターが通訳やクッションになること が重要とのこと！
そのために「バックログを2つ用意した」そうです。
あわせて「スケジュールも内部向けと外部向けで使い分け」とのこと。
色々と工夫してみたのですが。。。
クライアントがなかなか使ってくれない！！！
そのため、さらに次の手を打ったそうです。
- 「連絡板」というなんでも放り込めるタスクをつくった
- ディレクターがそこからタスクと質問を切り分けていく
- 課題のコメントで変更依頼を禁止して課題側の内容を編集するようにした
結果、困っていることを描いてくれるようになったそうです。
面倒臭いじゃん。いやいや、だんだんと担当者が慣れてくれるようになるんです。
バックログこわくない。使っていってというとっかかりが重要とのこと。
まとめは次の写真をどうぞ！
(13:25〜13:50) 小さなチームの全員マネジメントな日常
タイムテーブルから引用
このセッションでは自律的なチームを目指している私達のチームがどのように変化し続けているかをお話しします。 私達はNORELというクルマのサブスクリプションサービスの開発チームです。 限られた人員リソースで新機能の開発や運用、カイゼンをしていくために、私達はスクラム開発を導入し、生産性の向上を目指しています。 カイゼンを重ねる中で、全員で自分たちのチームをマネジメントしていく「全員マネジメント」が重要であることに気づきました。 「全員マネジメント」は、チームが抱える問題に対する課題設定、及びその課題の解決方法を各自が自発的に考え、 協調して実践とふりかえりを行い、継続的に改善していくという意味を込めています。
登壇者情報
登壇者 : 守屋 慧 さん
所属 : 株式会社IDOM
内容 & ヒトコト感想
SpeakerDeck に発表資料がありましたので詳しい内容はそちらを！
現在進行形でアジャイルな開発をしている私としては、
あるあるネタのような、経験したなみたいな内容が出てきて、
やっぱりみんな困ったりつまずいたりするところは似てるんだなと(苦笑
荒廃しているプロジェクトって、backlogにないタスクをメンバーが作業していることが多い気がします。
— みやひろ＠webディレクター (@hiro_38) 2019年1月26日
全然チケットが片づかない、なのにみんな残業している！みたいな。#BacklogWorld #Room2
問題にぶち当たらないと、人は変わろうと思わないよね。羨ましい経験をしているなぁ。
— オムそば @マネジメントは技術 (@teamomusoba) 2019年1月26日
#backlogworld #Room2
物理カンバンだろうがツール使用のカンバンだろうが、荒廃するときはすんすよね。。
スクラムマスターが言うからやるとかじゃなくて、チームとしてやる！
チームとして最適なツールを模索してブラッシュアップしてくってのが大切なんですよ。
「カイゼンしよう」「よりよくなろう」っていうチームがやっぱり強いし、
そういうチームでいる、そういうメンバーがいるってのはとても幸せだし、
みんなで考えて行動してカイゼン経験がつめるのはハッピー なこと(笑)
(14:00〜14:25) Backlogでわかる炎上の見分け方、消し方
タイムテーブルから引用
株式会社オルターブースでは、受託開発を行う際、 その時点でのできる限りの粒度で課題を作成し、スケジュールを組んでいきます。 場合によっては500以上のチケットを最初に登録し、消化を見ていきます。 課題作成という作業からみえる、
・タスクの粒度
・顧客とのコミュニケーション
・仕事の進捗の確認方法
といった話をさせていただきながら、炎上の見分け方、消し方、 もっというと炎上する前にボヤをけすには？などお話させていただければと思います。
登壇者情報
登壇者 : 藤崎 優 さん
所属 : 株式会社オルターブース
- 自社サービス
内容 & ヒトコト感想
タイムテーブルを見たときにすごく気になっていたタイトルでした(笑)
受託開発で顧客とともにアジャイル開発を行うために、
プロジェクトのスタート段階で Backlog に課題を大量に登録するそうです。
(チケットの登録自体は手で入れるのではなくスプレッドシートでインポート)
目的としては、 作業量の全体をお客さんに提示するため とのこと！
3人月の案件でだいたい「620課題！？」も登録するようです。
ただ、そのときは詳細に内容を記載せずにタイトルレベルで作成するとのこと。
いやいや、そうですよね。。中身まで書いてたら辛すぎる(苦笑)
感覚的にはプロダクトバックログを作る作業に似ているのかなと。
- 案件の作業量の見える化の作業
- 最初は箱だけ作成
スケジュールオーバーするとしてもそこはまずは許容してとにかくタスクをあげる
案件の作業量の見える化の作業の目的
- ゴールまでにやるべき作業を仮につくる
- スタート時点でのゴールを教諭できる
初期の段階で開発機能の調節ができる
炎上がおこる要因
- 受託と発注側のゴールがずれる
- スケジュールが見えない(遅れてるのかオンスケなのかが見えない)
顧客とともに...
- ゴールの認識合わせ
- 追加変更は起こるもの
- トレードオフは許容されるもの
これだけしておくと、、、炎上が防げる(?) とのことでした。
私としては炎上の見分け方や消し方というよりも、
どちらかというと炎上しないために努力する方法といった感じに捉えました。
確かにクライアントさんともめたり、
クライアントさんの機嫌が悪くなってしまったり、
そうやって徐々に信頼貯金を使い切った負のスパイラルパターンに陥るのって
「ゴールがずれてしまっていたり」「オンスケなのか分からなかったり」
「やることやらないことを明確に提示できていない」場合が多い気がするので、
事前にこうやって石橋を叩いておくのって重要だなと思いました。
(14:25〜14:50) エンジニア約1%の集団で働きやすい環境を作るために半年でやった10のこと
タイムテーブルから引用
IMAGICA Lab.には開発エンジニアが従業員の1%という環境で現在40弱のプロダクトがアクティブに稼働しています。 そのプロ学とは社内外の効率化ツールかクラウドプラットフォームまで多岐に渡っており、それらの課題や要望の管理は煩雑化していました。また、エンジニア自身のタスクも肥大化し、それがブラックボックス化されていました。 そのため、プロジェクト管理ツールの導入とタスクの可視化を目的にこの半年て行ったあらゆる取り組みについてお話しします。
プロジェクトの課題、非エンジニアからの要望、バグを全てBacklogで管理
Backlog APIを使って各人のタスクとその量を可視化
52インチのモニターでタスクとサーバー監視状況を常に表示
Daily Scrumの導入による各人の進捗の共有
ふりかえりの導入による課題とアクションの明確化
ファイブフィンガーによる各人の体調やメンタルの可視化
インセプションデッキの作成によるプロジェクトの方向性のすり合わせ
立って仕事ができるデスクの導入による疲労の軽減
モブスペースの導入によるモブワークの推進
10.部署内月間MVPの実施によるモチベーションの向上
登壇者情報
登壇者 : 蜂須賀 大貴 さん
所属 : IMAGICA Lab.
内容 & ヒトコト感想
SpeakerDeck に発表資料がありましたので詳しい内容はそちらを！
忙しい人向けにざっくりとスライドの内容を箇条書きで書き出すと次のような感じです。
- バックログで課題管理
- バックログのAPIを使って各人のタスクを可視化
- 常に目に入る仕組み作りを構築
- デイリースクラムで進捗確認
- 定例会議をふりかえりに変更
- プロジェクトの方向性を可視化
- インセプションデッキを作成
- 価値観ババ抜き
- ドラッガー風エクササイズ
- 立って作業できるスペース確保
- すぐに集まれるモブスペースの導入
- 月間MVPで感謝を伝える
- 何かをしてくれてありがとうを相手に伝える
- PJに対するモチベーションを落とさないようにする取り組み
- 総務も現場も看板を導入
「バックログのAPIを使って各人のタスクを可視化」ってのが面白いなと。
パッと一枚の画面でメンバーがどれだけタスクを抱えているのか見れるのはいい！
あとは「プロジェクトの方向性を可視化」の話も面白かったです。
「プロジェクト自体の説明の前に、チーム個人とチーム全体がどのような人たちなのかという話から入る」
ってのがチームファーストで働く人をちゃんと見ているなと。
こういったところから信頼感や安心感が生まれるんだよなあと思いました。
仕事の可視化だけにとどまらず、モチベーションを保つ方法も同時に行わないと。上から与えられたタスクとして考えず、自分事としてとらえることが大切なのだなと。
— ヤマタソ・ブログ運営中 (@yamatasoweb) 2019年1月26日
最終的には、良いコミュニケーションは良いチームから。結局人ということですね。
「働きやすさはつくれる！」#BacklogWorld #Room3 pic.twitter.com/Jew1xa5EjV
ドラッガー風エクササイズ という手法を知れたのも嬉しかったです。
相手を知って、自分を知ってもらうってのも大切なんですが、
「チームメンバーは自分にどんな成果を期待していると思うか？」
というのをお互いにちゃんと伝えあうってのが前々から重要だよなと思っていたので。
この点については「Don't think, Feel.」はベターじゃないというのが私のスタンスです。
(15:00〜15:50) 辻ちゃん・ウエちゃんのアクセシビリティPodcast「Backlogのアクセシビリティを斬る！」
タイムテーブルから引用
Backlogが、スクリーンリーダー向けアクセシビリティの改善に着手したことをご存知ですか？ このセッションでは、Backlogのアクセシビリティがどのように改善されたのか、 今後どのような課題があるのかを、スクリーン・リーダーによる操作デモを交えながら語り尽くします。 8年の時を経て奇跡の復活を果たし、ますますパワーアップした迷コンビ 「辻ちゃん・ウエちゃん」の軽妙なトークをお楽しみください。
登壇者情報
登壇者 : 辻 勝利さん, 植木 真 さん
所属 : 株式会社ミツエーリンクス, 株式会社インフォアクシア
内容 & ヒトコト感想
スクリーンリーダーの存在は知ってたのですが、
どんなものかは知らなかったので新たな扉を開けにいきました。
まずは会場のみなさんに質問が。
- 目の見えない人がPCを使ったことをみたことがある方
- 会場ではちらほら手が挙がり
- スクリーンリーダーって知ってる？
- 会場の半数の方の手が挙がり
スクリーンリーダーを実際に使いながらの発表になりました。
まず驚いたのが「詳細読みあげ」というスクリーンリーダーの機能。
「その単語がどの漢字で構成されているのかを読みあげてくれる」という機能があるそうで、
「総務省」であれば「統べるソウの務めるムの省くショウ」と読み上げられる(うろ覚えなので少し違うかも)。
おー。すごい。そして確かにその機能がないと同音異義語や誤変換は分からないなと！
スクリーンリーダーで新旧バックログページを実際に使いながら、
旧バックログページではどういったことに困っていたのか、
そしてそれがどのようにして改善されたのかを知りました。
旧バージョンと現行バージョンのBacklogのアクセシビリティ（読み上げ）の比較チェック。これは興味深い #BacklogWorld pic.twitter.com/yybEvSBq4R
— 馮 富久/FUON Tomihisa (@tomihisa) 2019年1月26日
ページの中の見出しを読み上げてジャンプしていくことが多いため、
「h1, h2, h3要素」がしっかりと使われていないと正しくジャンプできない。。。
bottun 要素でないとフォーカスが向かないためボタンが押せない。。。
CSS で要素が書き換えられたりするとリーダーが正常に動けないため、
わざわざ 開発者モード等で CSS を OFF にしないとだめになる。。
htmlはラジオボタンなのに、CSSが余計なことをしてラジオボタンでなくなっている。スクリーンリーダーでラジオボタンに移動できない。。。なのでいつものCSSをOFFする。。。#BacklogWorld #Room1
— takeshi.furusato (@t_furusato) 2019年1月26日
それらをクリアしなければならず、課題を1つ追加するだけでも一苦労。。。
スクリーンリーダーは HTML 要素と強く結びついてるんだなと。。
今まで意識したことのない領域からの気づきだったので、
個人的にとても新鮮なセッションでした。聞けて良かったです！
(16:00~16:50) スペシャルセッション「スーパーマリオで学ぶプロジェクトマネジメント」
タイムテーブルから引用
スーパーマリオのユーザー体験がどうデザインされたか考えたことはありますか？ そもそも「体験デザイン」とは何なのか、そしてプロジェクトマネジメントと 「体験デザイン」の深い関係についてお話しします。
登壇者情報
登壇者 : 玉樹 真一郎 さん
所属 : わかる事務所
内容 & ヒトコト感想
控えめに言って最高なセッションでした！！
セッションの内容もさることながら、
資料の質やストーリーの持って行き方、話し方に言葉の選び方、
アイスブレイクの仕方、魅せ方すごく勉強になりました。
スーパーマリオのユーザー体験がどうデザインされ、
そしてそれがどうプロジェクトマネジメントに関わってくるのか、
という深い知見と洞察に触れることのできるセッションでした。
ですがご本人が仰っていた通り「話好きの気」が出てしまい、
肝心のプロジェクトマネジメント話はまさかの「懇親会で」の延長戦へ！
私は別件関係で懇親会に出てないのでそこは聞けずじまいでした(涙)
せっかくなので(←)臨場感のあるノー編集なメモをなるべく載せてきます(笑)
玉樹さんご登壇ですー リラックスタイムのご提案 #BacklogWorld pic.twitter.com/GA9gdZXIEy
— beppu01 (@beppu01) 2019年1月26日
はじめに体験の定義からはじまりました。
- 体験とは？
- 「身体が動いていなくても、脳が動いて感じれば、それは体験」
<< 1. 直感のデザイン >>
- デザインは「理由のある表現」
- アートは「心が動けばいい」
「このゲームは何をすればゴールなの？」
コインを集めること？
クッパを倒すこと？
ピーチを助けること？
一番最初の画面(ステージ)にそれが表現されていなければならない。
じゃあ、目立つものってなんでしょう？
赤い服着た。オーバーロールのおじさんがいますね。
そう。マリオ！
このマリオが目的を語っている。でないとでデザインとしてはおかしい！！
デザイナーならこれがわかる。デザイナーはこれを意図してデザインしている。
主人公なのになんで左端にいるの？
なんで、正面を向いてないの？
よく見ると右を向いているぞ！
座ってない、たっている、歩きそう。。
「さて、、、このゲームは何をすればゴールなの？」
"右に行くことが目的(ゴール)"
だからクッパを倒すときも斧が右端にあるようにデザインされている。
クッパを倒す方法はパンチやキックでもなく、あのデザインでなければならない。
最初に示したルールを最後まで守ることが大切！
スーファミ時代の私はちゃんと説明書読む勢でした(笑)
ぺらっぺらのほとんど情報の載ってないあの説明書が好きだったりします ←
「スタート」して「面白くなる」までの間、「わかる」の段階ではユーザは面白くないのに遊んでいる！
ここから次の方程式が！
「わかる」 > 「商品の良さ」
ここでさらに会場に問いかけが。
「なぜクリボーは正面を向いているの？ (マリオは横を向いているのに)」
玉樹さんいわくこれの答えはちょっと「おやっとなる」とのこと。
正解は。。。
怖い顔を見せたいため。
敵だとわかってもらいたいため。
そういったデザインになっている。
ユーザはクリボーが出てくると喜ぶ。
なぜ？
右に行って 「正解」なんだと喜ぶ から。
自分のとった行動が正しいと証明されたから。
「自分のとった行動」 == 「右に行くことがゲームの目的なんだと仮説を検証すること」
ユーザ自身が持った仮説に対して正解か不正解かの結果が返ってくる。
【予知させて】→【当てさせる】
— JBUG(Japan Backlog User Group) (@jbugofficial) 2019年1月26日
そんな直感の体験のデザインをし、繋げていくことが面白いを生む。小石を蹴り続けるような体験。#BacklogWorld #room1 pic.twitter.com/hqN3s9Thed
<< 2. 驚きのデザイン >>
時間がなくてこっから端折られます(笑)
マリオが右行く話だけで30分。すげーwww #BacklogWorld
— 馮 富久/FUON Tomihisa (@tomihisa) 2019年1月26日
さらにここから絵ではなくて普通にドラクエ画像が(笑)
そのためコンプラ的にその画面の写真はアップがNGに！
「なぜドラクエはシリアスな冒険に下ネタを入れたのか？」
ユーザがゲーム内で考えた仮説を検証して行く。
けれど。。。
直感の体験が続くと「学ばされっぱなし」になる。
つまり飽きちゃう。
ドラクエは直感のデザインの連続→学ばされっぱなし。
— 馮 富久/FUON Tomihisa (@tomihisa) 2019年1月26日
→疲れ・飽きが来る
→だから、ぱふぱふ
// 納得した！ #BacklogWorld
学びに対する飽きを「ぱふぱふ」が癒してくれる ←
すべてのコマンドについて学びが終わった段階で「ぱふぱふ」がでてくる。なんと！
まさかドラクエの"ぱふぱふ"に会場が「へぇー」で満たされるとは・・・！
— はち (@PassionateHachi) 2019年1月26日
#BacklogWorld #room1
そういった、飽きを癒すためのデザインになっている。
この飽きを癒す装置としてはタブーのモチーフが使われやすい。
「直感のデザイン」でユーザを学ばせて発生してしまった飽き。
「驚きをデザイン」するこことで「予想が外れるタイミング」をつくり解消させてあげる！
<< 3. 物語のデザイン >>
物語をどうデザインするのかというお話に。
e.g. 「風ノ旅ビト」「ラストオブアス」
- 環境的ストーリーテリング
- ナラティブ(物語/narrative)
- 物語内容(story)
- 物語言説(discourse)
- ナラティブ(物語/narrative)
ナラティブ・物語は、物語内容と物語言語でできている。物語のデザインにも型がある。 #BacklogWorld #room1 pic.twitter.com/V97hwMKfHB
— JBUG(Japan Backlog User Group) (@jbugofficial) 2019年1月26日
ユーザーに物語らせる。
「成長させる ---> 命のやりとり・未知の体験」を通してユーザが意思を持つ。選択する。
最近のゲームのトレンド：ユーザーを翻弄し、ゲームの中で成長させ、最終的に未知の体験をさせる（例：命のやりとり）。その体験を通じてユーザーに主体的に選択を行ってもらう。体験デザインに話が帰結しようとしている。#BacklogWorld #room1
— 北道路@ウェブマーケター (@pdr1987) 2019年1月26日
苦しい旅路の結果、主人公はスタート地点戻った。
「なぜデザイナーはスタート地点にゲームの主人公を戻すのか？」
「スタート前」と「スタート後」の自分を同じ立ち位置において比較させたかった。
体験前と体験後のプレイヤーの比較をさせるため、スタート地点に戻す。同じ画面を見ていても自分の見え方が変わっている。そのギャップこそが「ゲームの価値、意義」である。 #BacklogWorld #room1
— 北道路@ウェブマーケター (@pdr1987) 2019年1月26日
そして「体験デザイン」へと繋がっていく。。。
良い体験のデザインは記憶に残る #BacklogWorld #room1
— beppu01 (@beppu01) 2019年1月26日
公演時間的にはここでタイムアップでした(笑)
あれ？ プロジェクトマネジメントのお話は？
となったのですが、それ以上に濃いセッションでした。
まさに、イマ、おもしろい体験をしているなと！
こっからは私は参加できなかった延長線です(笑)
スーパーマリオで学ぶプロジェクトマネジメント、延長戦が始まりました！！✨#BacklogWorld pic.twitter.com/oPxJdccjAr
— JBUG(Japan Backlog User Group) (@jbugofficial) 2019年1月26日
うおー超参考になるー！！#BacklogWorld pic.twitter.com/0IcDoQ22t7
— オムそば @マネジメントは技術 (@teamomusoba) 2019年1月26日
まとめ
「Backlog World 2019」参加して良かったです！
バックログに関するお話というよりもプロジェクトマネジメントに関するお話が多く、
いい気づきを多く得ることのできた1日だったなと感じました。
ツールはあくまでツールで、それをどう目的を持ってどう使って行くのか。
それが一番大事なんだなと(大事MANブラザーズバンド←)
チームとプロジェクトは生物(ナマモノでありイキモノ)で、
その時々でカイゼンを目指して取り組んでいく、
それもスピーディに小さく正しい失敗を繰り返しながら。
銀の弾丸はないのです。
いやー、おもしろい体験を積めました！！
本日はご参加ありがとうございました！懇親会も楽しみましょう🎶 #BacklogWorld pic.twitter.com/hf7ysTvlE3
— JBUG(Japan Backlog User Group) (@jbugofficial) 2019年1月26日
実は写真だけはちゃっかり参加している私でした(笑)
