プレゼン資料の作り方。

プレゼン資料の作り方研修を受けてきたらこれがなかなか良い研修であった。

・何故相手の心に刺さるプレゼンにならないのか。
・何故話がぶれてしまうのか

といった課題についてよい解決策を提示してくれていた。

忘れないように大事なところを自分でメモメモ。

プレゼンをつくる流れ

骨子を作る

骨子は相手がきになることで構成される。
そのため相手になったつもりでとにかく付箋に質問を書き出してみる。
そしてそのQに対するAをシンプルに同じ付箋に記載する。

ここでは相手の立場になって考えることが大事。
相手の立場で考えにくければ似たような立場の人に実際にヒアリングすると良い。

ストーリーを作る

骨子で出来たQとAを並びかえてストーリーを作る。
Q⇒A の連鎖でストーリーが出来るはず。またその途中で重要でないQは捨て、必要に応じてQを追加する。

各スライドを作成する

各スライドは1つのQに対応するように作成する。
各スライドの中はQである「論点」Aである「メッセージ」その理由でありサブメッセージである「Body」で構成される。

プレゼン実施

上記ながれでプレゼンを作成していれば論点もメッセージも明確になっている。

Q&A

最初の骨子で考えつくせていれば想定外のQAがくることは限りなく少なく出来る。
またQAは以下の流れで実施する。なぜならQAの質問は表面的事象を捉えて質問されることが多く、真の事象を探る必要があるからである。
1、真の論点を確認(復唱or言い換え)
2、答える
3、答えになっているか確認する

終わり

これで相手の関心事からスタートしたプレゼンが出来る。

IMEのENとJPの切り替えショートカット


IMEがふとした瞬間にENに切り替わってしまっていてマウスで直さないといけなくて不便だとおもっていたらショートカットで直せた!

[Alt] + [Shift] で切り替えられる

こりゃ便利だわー
今までなんで調べなかったんだろうか。

ちなみに[Ctrl] + [Shift]でIMEGoogle日本語入力 とか使用するIMEも切り替えられる。

SwaggerでAPIを定義してモックアップを作る

REST APIの仕様定義には色々ありますが、Open API Initiativeでも標準ツールとして採用されている SwaggerをつかってAPI仕様を記載しモックアップを作ってみましょう。
Swaggerはユーザが多いのもあって周辺ツールの充実と多言語対応が良いので今から採用するならオススメです。

Swagger.yamlAPI仕様を記述する。

SwaggerではAPIの仕様をswagger.yamlで記載しますが、
swagger-editorというツールが非常に便利です。
ツールとしてインストールも出来ますし、オンラインでも使えます。
http://editor.swagger.io/#/

まずはこんなyamlを書いてみます。

swagger: '2.0'
info:
  version: "0.0.0"
  title: サンプル api
# Describe your paths here
paths:
  # This is a path endpoint. Change it.
  /users:
    get:
      description: |
        メンバ一覧取得API.
      parameters:
        -
          name: size
          in: query
          description: Size of array
          required: false
          type: number
          format: number
      responses:
        # Response code
        200:
          description: ユーザデータ(List)
          schema:
            title: ArrayOfUsers
            type: array
            items:
              $ref: '#/definitions/User'
  /users/{id}:
    get:
      description: |
        メンバ取得API.
      parameters:
        -
          name: id
          in: path
          description: user id
          required: true
          type: number
          format: number
      responses:
        # Response code
        200:
          description: ユーザデータ
          schema:
            $ref: '#/definitions/User'
definitions:
 User:
  type: object
  properties:
    id:
      type: number
    name:
      type: string
    age:
      type: number

簡単に言うと、
「/users」で一覧が取得できて
「/users/{id}」でUserID指定のデータが取得出来るというものです。
またdefinitionsのところでUserデータ型を指定しています。

ソースの生成

これで、Springのソースを出力してみましょう。
SwaggerからはNode、GoServer、JAX-RSPythonRails等色々な言語の実装を自動生成できますが、SpringBootだと起動が楽なので今回はSpringでいきます。
「Generate Server」から「spring」を選ぶと出来たソースがZipで落ちてくるので解凍するとMavenプロジェクトになっています。
もうこれでサーバの基礎は動きます。
楽勝ですね。

それでは動かしていきます。
まずはPomを開いて42行目あたりの「provided」行を削除しましょう。

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
            <scope>provided</scope>       ←この行削除
        </dependency>

レスポンス内容をそれらしく作る

Swaggerで生成されるモックはレスポンス内容は空っぽで生成されます。
なのでレスポンス内容は自分でモックコードを書く必要があります。

ソースの中のio.swagger.api.UsersApiControllerを開いて「// do some magic!」と書かれているところにモックコードをこんな感じで書きます。

@javax.annotation.Generated(value = "class io.swagger.codegen.languages.SpringCodegen", date = "2016-11-08T06:41:55.099Z")
@Controller
public class UsersApiController implements UsersApi {
    public ResponseEntity<List<User>> usersGet(@ApiParam(value = "Size of array") @RequestParam(value = "size", required = false) BigDecimal size
    ) {
        // do some magic!
        User user1 = new User();
        user1.setId(BigDecimal.ONE);
        user1.setName("aaa");
        User user2 = new User();
        user2.setId(BigDecimal.TEN);
        user2.setName("bbb");
        List<User> list = new ArrayList<>();
        list.add(user1);
        list.add(user2);
        return new ResponseEntity<>(list,HttpStatus.OK);
    }

    public ResponseEntity<User> usersIdGet(@ApiParam(value = "user id", required = true) @PathVariable("id") BigDecimal id ) {
        // do some magic!
        User user1 = new User();
        user1.setId(BigDecimal.ONE);
        user1.setName("aaa");
        return new ResponseEntity<>(user1, HttpStatus.OK);
    }

これでOK。
あとは起動して、「http://localhost:8080/」にアクセスすればSwaggerUIがみれます。
f:id:GARAPON:20161108172530p:plain

TryItOutをおしてみると
f:id:GARAPON:20161108172537p:plain

こんな感じで動いていますね。

ダイバーシティとインクルージョンの関係

女性活躍推進法もありダイバーシティダイバーシティ言われてますよね。
それが単にダイバーシティではなく「ダイバーシティインクルージョン D&I」と呼ばれるようになったのでインクルージョンとは何のことか調べてみた。

ダイバーシティ

まず基礎となるダイバーシティ
「女性活用」と理解すると間違ってないけど正解じゃない。
ダイバーシティの意味は多様性。英語圏だと国籍の多様性の意味が強いそこから宗教や価値観の多様性。
いろんな人がいるよね。いろんな人がいてうまくやっていこうぜっていう意味でダイバーシティというのが
30年ぐらい前にアメリカで叫ばれ始めた。
んでラテン系とか、女性とか、LGBTとかの人たちの多様性を受け入れて、いろんな人が居て違ったものの見方ができる人が集まる組織が健全であり強いのだ
という流れになった。

それが日本に入ってきたときに日本ではまずは女性が注目されて話が始まりいつの間にか「女性活用」として誤用されるようになってしまった。
まあ間違っていないのだけど、本来もっと広い視点の話だと抑えておけばOK。

インクルージョン

英語の意味的には「内包」日本語で適した意味だと「受け入れる」という感じかな。
上記のダイバーシティで多様な人が集まるとどうしても緊張や対立が起こる。これはしょうがない。
ある会社Aが会社Bに吸収されたときに「元A社」と「元B社」で中が悪いとか対立だとかそういうのが起こるのを考えればすぐ分かると思います。

ここからどうやって多様性を活かしながら組織の力を発揮するか。
そこにおいてインクルージョンの考えが出てきたようです。それが2000年頃。
何がインクルージョンの正解かというのは答えがありませんが、「健全な本音議論を通して」多様性をもった力の発揮が行えるというのが主流の考え方のようです。

つまり表面的な数値目標の達成ではなく、ダイバーシティインクルージョンが本当に意味あるもので、そこから価値を得ることが経営戦略上重要であるというような強い確信を持って本気で議論をしていくことが大切のようですね。

オープンAPIとOpen APIととWeb APIとREST APIの違い。

なんか色々バズワード化してますよね。
言葉が色々あって不明瞭なので少し整理してみましょう。

定義の狭さから掲題とは逆順で説明していきます。

REST API

これは文字通り、RESTアーキテクチャに従って作られたAPIのことです。
RESTはアーキテクチャのため、RESTの考え方にしたがって作られているWebAPIを「RESTful API」と呼称します。

RESTが何かという話は
garapon.hatenablog.com

Web API

HTTP通信などのWeb技術を用いて構築されたAPI(サービスインタフェース)が「WebAPI」と呼ばれます。
そのため、「RSETful API」もWebAPIの1つで「SOAP」やgoogle社の「gRPC」、facebook社の「graphAPI」などもWebAPIに含まれます。

オープンAPI

先にカタカタの「オープンAPI」を説明します。
オープンAPIとは「ある企業が提供するAPIのうちサードパーティーがアクセス可能なAPI」の事を指します。
サードパーティの定義はEuro Banking Association*1では以下5段階に分けられており、Private以外を指します。
- Public:誰でもアクセス可能
- Acquaintance:一定契約のもと誰でもアクセス可能
- Member:コミュニティに属するメンバーのみがアクセス可能
- Partner:パートナーとの合意に基づきアクセス可能
- Private:グループ内のみ
一般的に言われる「オープンAPI」はAcquaintanceに含まれますね。GoogleMapsAPIとか。

OpenAPI

さて、わかりにくさの頂点英語で書かれる「OpenAPI」これはなにかというと「Open API Spesification」の略称。
これがなにかというと、RESTful APIインターフェイスを記述するための標準フォーマットを推進する団体「Open API Initiative」が、The Linux Foundationの協力のもとでマイクロソフトGoogleIBMIntuitPayPal、3Scale、Apigee、Capital One、Restlet、SmartBearらによって結成されてました。
んで、Swagger specifications が寄贈されOpen API Spesificationという名称に変更。Swagger specificationsは「Swagger」と呼称されていたのでOpen API Spesificationが「Open API」と呼称されてしまったりしている。
まじめんどい。
正式文書の中ではちゃんと「Open API Spesification」とかいてあるのだけど人によっては「Open API 2.0」とかかいてあるとろがありわかりにくい。
なので日本のドキュメントではカタカナと英字で書き分けられることが多いです。
全銀協の表記も「オープンAPI
「オープンAPIのあり方に関する検討会」の設置について - 全国銀行協会
ちなみに英語では上記の「オープンAPI」を示すときは「Open APIs」と書かれる

無限に繰り返すスライドショーの作り方

勉強会が始まるまでの案内用に無限に続くスライドショーを作ったのでメモ
※PowerPoint2016です。

以下のように設定して後は放置。

1、無限ループするよう設定
「スライドショータブ」
 ⇒「スライドショーの設定」
  ⇒「オプション」
   ⇒「Escキーが押されるまで繰り返す」をチェック
   
2、自動的に切り替わるように設定
全シートを選択してから
「画面切り替えタブ」
 ⇒「画面切り替えのタイミング」
  ⇒「クリック時」から「自動的に切り替え」に変更
   その後任意の時間を設定
   (シートの選択を解除してから個別のシートの時間を変更することも可能)
   
これでOK。

RESTとは何か。

簡単に言うと「RESTとは、Representational State Transferの略でソフトウェアアーキテクチャのスタイルのひとつ」しかしこれがまたややこしくしている。
なぜかというとよくセットで語られるSOAPは仕様。それに対してRestはアーキテクチャ。なのでRESTは細かいところを定めているわけじゃなくて
多種多様なものがRESTと呼ばれてしまっている。

RESTは、初めはアーキテクチャの原則と制約の集まり(後述)を指していたが、次第に、XMLやHTTPを使った簡易なウェブベースのインターフェイスのうち、WebサービスSOAPプロトコルのような MEP(Message Exchange Pattern; SOAPノード相互のメッセージ交換のパターンを確立するための雛型)ベースの特別な抽象化をしないもののことを、大まかに意味する用語として使われるようになった

REST - Wikipedia

なのでRESTといわれたら相手がどのようなRESTをイメージしているのか確認するといい。
RESTの定義には色々あるがマーチンファウラーが定義しているRESTful成熟度の3レベルモデルが相手の理解を知るにはよい指標となるとおもう。
martinfowler.com

  • Level 0 Plain Old XML(昔ながらの単純にXMLを返すやり方)
  • Level 1 URLでリソースを表すようにする(リソースを動詞でなく名詞で表す)
  • Level 2 HTTPメソッドGET, POST, PUT, DELETE等を正しく使い分ける
  • Level 3 レスポンスの中に関連するリンクを含める

Level3はNetflixAPIとか、API自体がハイパーメディアとして動作するようなもの。ほぼ見かけない。
今世界で言われている大半のAPIはLevel2。Level1だとWebで公開するとハテブとかでちょっとけちつけられる可能性がある。
でも上記にあってなくても使いやすければLevel1でも悪くないとおもうよ。だってちゃんとしたRestで考えると色々使いにくいから。。。

そんな使いにくさもありDropBoxがRestのサポートをやめたり、*1
GoogleAPIもHTTP2ではgRPCを主軸においてたり、今後Restから次のステージが模索されている。
とはいえ本家RESTも大事なのでちゃん仕様を統一しようてことでOpen API Initiative*2がSwaggerベースで仕様統一を検討し始めている。

RESTが誕生して16年。これからも目が離せませんね