てくなべ (tekunabe)

ansible / network automation / 学習メモ

『カイゼン・ジャーニー / 「一人から始める」を始める。』に参加してきました

■ はじめに

2018/04/04、書籍「カイゼン・ジャーニー」の第1部「一人から始める」をテーマにしたイベントに参加してきました。

  • イベント開催ページ

devlove.doorkeeper.jp

www.shoeisha.co.jp

著者の新井剛さん、市谷聡啓さんのぞれぞれの経験をもとにした発表と、事前のアンケートで寄せられたお題をもとにした座談会(5人程度のグループディスカッション)という構成でした。


■ 新井さんパート

speakerdeck.com

当たり前のことを当たり前にやった、ちょっと勇気を持ってやっているのかも、という点が印象的でした。 最近、当たり前のこと向き合う意味、難しさ、他の真似だけではだめ・・などなど考える事があったため、勇気をもらいました。


■ 市谷さんパート

www.slideshare.net

「これからはソロの時代」「所属から提供へ」という言葉が印象的でした。 私自身もちょっと人と違うことをすることを好んでしている節があるので、そういう意味では自ら進んでぼっちになっているのかもしれません。 ですが、それを誰かに伝えて表現することで、ひょっこり同じことしてくれる人が出てくるということを感じているので、こういうのも悪くないなと思っています。


■ 座談会パート

ぼっちからのはじめ方、巻き込み方、組織風土などをテーマにディスカッションしました。 他のグループや、著者への質疑応答含めて気になったものは以下です。

  • 物理的な本を人目につくところに置くとおくと話のきっかけになる。
  • 巻き込むときはアーリーアダプターにターゲットを絞ったほうが良いのでは。
  • 無理して巻き込まなくても、自分でどんどんやっちゃえば良い。新たな風景が見えてくる。そのうちついてくる。
  • アジャイルのプラクティスを導入するときは、プラクティス名を言わずに、課題に向き合って取り組むべき。プラクティス先行だと警戒される。


■ 気づき・まとめ

参加者含めて、非常に熱のある集まりだと感じました。 一方で、このような社外のコミュニティだけでなく、もっと身近な自社にも自分が知らないだけで、同じような思いの人がいるのではという問いかけを自分にしました。 偶然、翌日に似たようなテーマで同僚と話すこと機会があり、色々共感を得られたのがとても嬉しかったです。 今後は社内にも目を配ってみようと思いました。

ansible Ad-Hoc コマンドの callback plugin の指定時は bin_ansible_callbacks = True も必要

■ はじめに

Ansible には callback plugin という仕組みがあり、結果出力の形式を変更したりすることができます。

ansible-playbook コマンドでは、ansible.cfgstdout_callback の指定を、ansible コマンドではこれに加え bin_ansible_callbacks = True という指定が必要です。

この記事では、それぞれの例をご紹介します。


■ ansible-playbook コマンドの場合

例えば、 json という callback plugin を指定して ansible-playbook コマンド実行する例を見てみます。

設定ファイル(ansible.cfg)

stdout_callbackjson を指定します。

stdout_callback = json

なお、環境変数として設定する場合は export ANSIBLE_STDOUT_CALLBACK=json を実行します。

設定の確認

念のため ansible-config コマンドで設定を確認します。

[vagrant@centos7 vagrant]$ ansible-config dump | grep CALLBACK
DEFAULT_CALLBACK_PLUGIN_PATH(default) = [u'/home/vagrant/.ansible/plugins/callback', u'/usr/share/ansible/plugins/callback']
DEFAULT_CALLBACK_WHITELIST(default) = []
DEFAULT_LOAD_CALLBACK_PLUGINS(default) = False
DEFAULT_STDOUT_CALLBACK(/etc/ansible/ansible.cfg) = json    ← json になった

実行結果

ここでは junos_command モジュールで show version を実行する Playbook を実行します。

[vagrant@centos7 vagrant]$ ansible-playbook -i inventory junos_test.yml
{
    "plays": [
        {
            "play": {
                "id": "525400da-a710-c40b-4624-000000000008",
                "name": "junos"
            },
            "tasks": [
                {
                    "hosts": {
                        "172.16.0.1": {
                            "_ansible_no_log": false,
                            "_ansible_parsed": true,
                            "changed": false,
                            "invocation": {
                                (~略~)
                            },
                            "stdout": [
                                "Hostname: vsrx1\nModel: firefly-perimeter\nJUNOS Software Release [12.1X47-D15.4]"
                            ],
                            "stdout_lines": [
                                [
                                    "Hostname: vsrx1",
                                    "Model: firefly-perimeter",
                                    "JUNOS Software Release [12.1X47-D15.4]"
                                ]
                            ]
                        }
                    },
                    "task": {
                        "id": "525400da-a710-c40b-4624-00000000000a",
                        "name": "show version"
                    }
                }
            ]
        }
    ],
    "stats": {
        "172.16.0.1": {
            "changed": 0,
            "failures": 0,
            "ok": 1,
            "skipped": 0,
            "unreachable": 0
        }
    }
}

このように、JSON 形式で結果が出力されます。


■ ansible コマンドの場合

ansible コマンド(ad-hocコマンドとも呼ばれる) でも、callback plugin を指定する場合は、stdout_callback 以外にも bin_ansible_callbacks という設定も必要です。

設定ファイル(ansible.cfg)

stdout_callbackjson を指定するのに加え、 bin_ansible_callbacksTrue に指定します。

stdout_callback = json
bin_ansible_callbacks = True

なお、環境変数として設定する場合は export ANSIBLE_LOAD_CALLBACK_PLUGINS=True を実行します。

設定の確認

念のため ansible-config コマンドで設定を確認します。

[vagrant@centos7 vagrant]$ ansible-config dump | grep CALLBACK
DEFAULT_CALLBACK_PLUGIN_PATH(default) = [u'/home/vagrant/.ansible/plugins/callback', u'/usr/share/ansible/plugins/callback']
DEFAULT_CALLBACK_WHITELIST(default) = []
DEFAULT_LOAD_CALLBACK_PLUGINS(/etc/ansible/ansible.cfg) = True    ← True になった
DEFAULT_STDOUT_CALLBACK(/etc/ansible/ansible.cfg) = json

実行結果

ここでは junos_command モジュールで show version を実行する ansible コマンド を実行します。

[vagrant@centos7 vagrant]$ ansible -i 172.16.0.1, all -m junos_command -a "commands='show version'" -c netconf -u root
-k
SSH password:  (パスワードを入力)
{
    "plays": [
        {
            "play": {
                "id": "525400da-a710-ece8-5deb-000000000007",
                "name": "Ansible Ad-Hoc"
            },
            "tasks": [
                {
                    "hosts": {
                        "172.16.0.1": {
                            "_ansible_no_log": false,
                            "_ansible_parsed": true,
                            "changed": false,
                            "invocation": {
                                (~略~)
                            },
                            "stdout": [
                                "Hostname: vsrx1\nModel: firefly-perimeter\nJUNOS Software Release [12.1X47-D15.4]"
                            ],
                            "stdout_lines": [
                                [
                                    "Hostname: vsrx1",
                                    "Model: firefly-perimeter",
                                    "JUNOS Software Release [12.1X47-D15.4]"
                                ]
                            ]
                        }
                    },
                    "task": {
                        "id": "525400da-a710-ece8-5deb-000000000009",
                        "name": ""
                    }
                }
            ]
        }
    ],
    "stats": {
        "172.16.0.1": {
            "changed": 0,
            "failures": 0,
            "ok": 1,
            "skipped": 0,
            "unreachable": 0
        }
    }
}
[vagrant@centos7 vagrant]$

無事に ansible コマンドでも json 形式で出力できました。


■ まとめ

json callback plugin を利用する場合を例にまとめます。

ansible-playbook コマンド

  • ansible.cfg で設定する場合
[defaults]
stdout_callback = json
export ANSIBLE_STDOUT_CALLBACK=json

ansible コマンド

  • ansible.cfg で設定する場合
[defaults]
stdout_callback = json
bin_ansible_callbacks = True
export ANSIBLE_STDOUT_CALLBACK=json
export ANSIBLE_LOAD_CALLBACK_PLUGINS=True

Ansible の ios_command の出力結果でパスワードが ******** でマスクされる

■ はじめに

Ansible には Cisco IOSshow コマンドを実行できる ios_command モジュールが用意されています。 このモジュールは設計上、コマンド実行結果にパスワードで指定した文字列が含まれる場合、パスワードに関係ない箇所でも******** でマスクするという動作をします。(例外あり、後述。)

この記事では動作の確認と対応案をご紹介します。

  • 動作確認バージョン
    • Ansible 2.5.0
    • Ansible 2.4.3


■ 現象

詳細は以下の issue に記載されています。(設計上の動作のため closed )

github.com

例えば、cisco99 というパスワードを指定していいて、かつ、パスワードに関係ない箇所にも cisco99 という文字列が含まれているコンフィグ想定して、どのような時にどのようにマスクされるかを見ていきます。

  • 想定事前コンフィグ抜粋
interface Loopback0
 description hogehogecisco99hogehoge

以下のように、 ios_config モジュール内の providerpassword オプションでパスワードを指定すると、コマンド実行結果にそのパスワードと文字列が ******** でマスクされます。

Playbook

- hosts: ios
  gather_facts: no
  connection: local

  tasks:
    - name: show
      ios_command:
        commands:
          - show run
        provider:
          username: cisco
          password: cisco99        # パスワード
      register: result

    - name: debug
      debug:
        msg: "{{ result.stdout_lines[0] }}"

出力結果例(抜粋)

パスワードと同じ文字列である cisco99 がマスクされます。

interface Loopback0
 description hogehoge********hogehoge

このように、パスワードが平文でコンフィグに書かれている場合にマスクすることを意図した設計のようですが、パスワードが同じ文字列が、description などパスワードと関係ない箇所に現れる場合でもマスクします。


■ 対応案

パスワードと同じ文字列をコンフィグに含めない

パスワード認証を利用する場合は、まずはこれが原則かと思います。

鍵を利用する

冒頭で紹介した issue のコメントでも提案されている方法です。鍵利用した認証に変更することで、そもそもPlaybookや変数でパスワードをしなくなるので上記のような現象は起こらなくなります。

ansible_ssh_pass 変数を利用する

ios_config モジュール内の providerpassword オプションでパスワードを指定するのではなく、どこかしらで ansible_ssh_pass で変数で指定するとマスクされません。

Playbook

- hosts: ios
  gather_facts: no
  connection: local

  # 今回は見通しが良いようにPlaybook内に変数定義
  vars:
    ansible_user: cisco
    ansible_ssh_pass: cisco99        # パスワード

  tasks:
    - name: show
      ios_command:
        commands:
          - show run
      register: result

    - name: debug
      debug:
        msg: "{{ result.stdout_lines[0] }}"

出力結果例(抜粋)

パスワードと同じ文字列である cisco99 がマスクされず、そのまま出力されます。

interface Loopback0
 description hogehogecisco99hogehoge

Ansible 2.5 の場合

Ansible 2.5 では network_cli という新しいコネクションタイプの利用が推奨されています。netowrk_cli では、そもそもモジュール内の privider オプションで指定した認証情報は利用せず、ansible_useransible_ssh_pass などの変数を利用します。

Playbook

- hosts: ios
  gather_facts: no
  connection: network_cli

  # 今回は見通しが良いようにPlaybook内に変数定義
  vars:
    ansible_user: cisco
    ansible_ssh_pass: cisco99    # パスワード
    ansible_network_os: ios      # network_cli 固有の変数

  tasks:
    - name: show
      ios_command:
        commands:
          - show run
      register: result

    - name: debug
      debug:
        msg: "{{ result.stdout_lines[0] }}"

出力結果例(抜粋)

パスワードと同じ文字列である cisco99 がマスクされず、そのまま出力されます。

interface Loopback0
 description hogehogecisco99hogehoge


■ まとめ

セキュリティを考慮した設計上の動作ではありますが、状況によっては副作用的な動きとなります。上記であげた対応案が参考になれば幸いです。

なお、本件は 2018/03/24 に参加させていただいた Ansible Workshop #3 2018 Spring で小耳に挟んだ話でした。気になったでので確認してみました。

Ansible ネットワークモジュールのプチ社内勉強会をしました

■ 目的

本日、社内でAnsibleのネットワークモジュールのプチ勉強会をしました。 本当にプチと言う感じで参加者は数人、資料もほとんど既存資料のリンク集でした。

初めての人には、実際にAnsibleを他人が動かしてるところを見たり、自分で動かしたりすることで、雰囲気を掴んでもらうことを狙いました。

すでに少しかじっている人には

  • 聞くまでもないけど地味に困っていることを聞ける
  • 操作を見せ合うことによって新しい発見を得る

という場になるように意識しました。

ペアプログラミング、モブプログラミングを少し参考にして、ハンズオンの時は操作端末は1つにしました。

利用した資料は以下の通りです。(機密情報なし)







本日の内容

  • Ansible 2.5 におけるネットワークモジュールのトピック(30分)
  • 仮想ネットワーク機器環境の準備の仕方(5分)
  • プチハンズオン&フリータイム(25分)

Ansible 2.5 におけるネットワークモジュールのトピック

仮想ネットワーク機器環境の作り方

プチハンズオン

  • junos
    • コンフィグバックアップ
      • 実行コマンドは show configuration
    • 設定変更
      • 実行コマンドは set system ntp server 10.0.0.1
  • ios
    • コンフィグバックアップ
      • 実行コマンドは show run
    • 設定変更
      • 実行コマンドは ntp server 10.0.0.1

参考資料


Ansible もくもく会 (第2回)に参加してきました #ansiblejp

f:id:akira6592:20180328180131j:plain

■ はじめに

Ansible ユーザー会主催の、Ansible もくもく会 (第2回)に参加してきました。 ブログ枠で参加したわけではないですが、せっかくなので、やったことや感じたことなどを簡単にまとめます。

ansible-users.connpass.com


■ やったこと

Ansible Lightbulb に沿って

Ansilbe Lightbulb というハンズオン資料の中の、Ansible Tower に関する箇所をハンズオンしました。

  • Ansible Tower の概要、用語を知る
  • Ansible Tower インストールする
  • Ansible Tower の各種設定、ジョブ実行する

利用したPlaybook(Apacheのデプロイ)は予め用意されたものを利用する手順になっていたため、特にPlaybookは自分で作成することなく、Ansible Towerの操作に集中できました。

ネットワーク機器にも

別途自分で用意した用意した、AWS上の Cisco IOS-XE インスタンスに対して show version コマンドを叩くことも試してみました。

作成したPlaybookは以下の通りです。

- hosts: all
  connection: local
  gather_facts: no
  
  tasks:
    - name: show
      ios_command:
        commands:
          - show version
      register: res
      
    - name: d
      debug:
        msg: "{{ res.stdout_lines[0] }}"

Ansible Tower からのジョブ実行結果は以下の通りです。 f:id:akira6592:20180328180555p:plain


■ 成果発表LT

私は成果発表LTという枠で、参加させていただきました。 LTといっても、特に資料の作成は必要はなく、やったことや気づきなどの振り返りを口頭で発表する感じで行いました。 一般枠は埋まりやすいですが、成果発表LT枠であれば登録しやすいので、参加登録に出遅れた場合は成果発表LT枠を検討してみてはいかがでしょうか。


■ 感じたこと

Ansible Tower には、Ansible Engine にはない、プロジェクト、テンプレートなどの概念があります。 それぞれがどういう役割のもので、どういう組み合わせで利用されるものなのかをきちんとおさえることが、最初に一歩だと思いました。


■ 他の参加者から

みんなで書き上げる Etherpad

Etherpad というツールを使って、各種案内やTips、Q&Aなどを講師、参加者みんなで書き上げていきました。 その内容は以下のQiitaの記事に転記していただいたようです。ありがとうございます。

qiita.com

参加ブログ

@Tocyuki さんの記事です。 tocyuki.hatenablog.jp

■ まとめ

レッドハットの方や、講師役の方がいらっしゃったので、不明な点はいつでも聞けるという点で心強かったです。 また、環境はAWS EC2 のインスタンスが各自に割り当てられていたので、大変助かりました。 まだまだ触り足りないので自分の環境でもハンズオンをやりつつ、次回もぜひ参加させていただきたいと思います。

(各種ノベルティもありがとうございました!)

StackStorm の st2 run コマンドで AWS EC2 インスタンスの状態を取得する

■ はじめに

イベントリブンな自動化ツールである StackStorm は、aws pack(拡張機能)をインストールすることによって、AWSを連携して様々な操作ができるようになります。

この記事では、StackStormのコマンドの実行によりEC2 インスタンスの情報を取得する例をご紹介します。


■ 準備

StackStorm のインストール

今回は、ansible でインストールした環境を利用します。

(参考)

tekunabe.hatenablog.jp

Pack のインストールなど

以下のページを参考にして、Pack のアクセスキーなどの設定を行います。

GitHub - StackStorm-Exchange/stackstorm-aws: st2 content pack containing Amazon Web Services integrations.

アクセスキーなどの認証情報の取扱いには十分ご注意ください。


■ st2 run コマンドで情報取得

それでは、いくつかの例で EC2 インスタンスの情報を取得してみます。

対象リージョンのすべての EC2 インスタンス

特にフィルターを指定せず、対象リージョンのすべてのインスタンスの情報を取得する場合は、以下のようなコマンドを実行します。

・実行コマンド

st2 run aws.ec2_describe_instances 

・情報取得結果例

id: xxxxxxxxxxxxx
status: succeeded
parameters: None
result: 
  exit_code: 0
  result:
  - Reservations:
    - Groups: []
      Instances:
      - AmiLaunchIndex: 0
        Architecture: x86_64
        BlockDeviceMappings:
        - DeviceName: /dev/xvda
          Ebs:
            AttachTime: '2018-03-12T13:22:08+00:00'
            DeleteOnTermination: true
            Status: attached
            VolumeId: vol-xxx
        ClientToken: 'xxx'
        EbsOptimized: false
        EnaSupport: false
        Hypervisor: xen
        ImageId: ami-77152012
        InstanceId: i-xxx
        InstanceType: t2.medium
        KeyName: xxx
        LaunchTime: '2018-03-20T00:29:23+00:00'
        Monitoring:
          State: disabled
        NetworkInterfaces:
        - Attachment:
            AttachTime: '2018-03-12T13:22:07+00:00'
            AttachmentId: eni-attach-xxx
            DeleteOnTermination: true
            DeviceIndex: 0
            Status: attached
          Description: ''
          Groups:
          - GroupId: sg-xxx
            GroupName: Cisco Cloud Services Router -CSR- 1000V - AX Pkg- Max Performance-16-7-1-AutogenByAWSMP-
          Ipv6Addresses: []
          MacAddress: 02:30:07:xx:xx:xx
          NetworkInterfaceId: eni-xxx
          OwnerId: xxx
          PrivateDnsName: ip-172-31-6-206.us-east-2.compute.internal
          PrivateIpAddress: 172.31.6.206
          PrivateIpAddresses:
          - Primary: true
            PrivateDnsName: ip-172-31-6-206.us-east-2.compute.internal
            PrivateIpAddress: 172.31.6.206
          SourceDestCheck: true
          Status: in-use
          SubnetId: subnet-xxx
          VpcId: vpc-xxx
        Placement:
          AvailabilityZone: us-east-2a
          GroupName: ''
          Tenancy: default
        PrivateDnsName: ip-172-31-6-206.us-east-2.compute.internal
        PrivateIpAddress: 172.31.6.206
        ProductCodes:
        - ProductCodeId: xxx
          ProductCodeType: marketplace
        PublicDnsName: ''
        RootDeviceName: /dev/xvda
        RootDeviceType: ebs
        SecurityGroups:
        - GroupId: sg-xxx
          GroupName: Cisco Cloud Services Router -CSR- 1000V - AX Pkg- Max Performance-16-7-1-AutogenByAWSMP-
        SourceDestCheck: true
        State:
          Code: 80
          Name: stopped
        StateReason:
          Code: Client.UserInitiatedShutdown
          Message: 'Client.UserInitiatedShutdown: User initiated shutdown'
        StateTransitionReason: User initiated (2018-03-20 00:58:19 GMT)
        SubnetId: subnet-xxx
        Tags:
        - Key: Name
          Value: xxx
        VirtualizationType: hvm
        VpcId: vpc-xxx
      OwnerId: xxx
      ReservationId: rxxx

    (略) 2つめ以降のインスタンス情報が続く

    ResponseMetadata:
      HTTPHeaders:
        content-type: text/xml;charset=UTF-8
        date: Tue, 20 Mar 2018 14:38:03 GMT
        server: AmazonEC2
        transfer-encoding: chunked
        vary: Accept-Encoding
      HTTPStatusCode: 200
      RequestId: xxx-xxx-xxx-xxx
      RetryAttempts: 0
  stderr: ''
  stdout: ''

実行中の EC2 インスタンスのみ

実行中(instance-state-namerunning)のインスタンスの情報を取得する場合は、以下のようなコマンドを実行します。

・実行コマンド

st2 run aws.ec2_describe_instances Filters='[{"Name":"instance-state-name","Values":["running"]}]'

その他のフィルタ

その他のフィルタについては、以下のコマンドを実行して確認します。

st2 action get aws.ec2_describe_instances 

(抜粋)

|     "Filters": {                                             |
|         "type": "array",                                     |
|         "description": "One or more filters.    affinity -   |
| The affinity setting for an instance running on a Dedicated  |
| Host (default | host).    architecture - The instance        |
| architecture (i386 | x86_64).    association.public-ip - The |
| address of the Elastic IP address (IPv4) bound to the        |
| network interface.    association.ip-owner-id - The owner of |
| the Elastic IP address (IPv4) associated with the network    |
| interface.    association.allocation-id - The allocation ID  |
| returned when you allocated the Elastic IP address (IPv4)    |
| for your network interface.    association.association-id -  |
| The association ID returned when the network interface was   |
| associated with an IPv4 address.    availability-zone - The  |
| Availability Zone of the instance.    block-device-mapping   |
| .attach-time - The attach time for an EBS volume mapped to   |
| the instance, for example, 2010-09-15T17:15:20.000Z.         |

例えば、インスタンスID i-dummy1i-dummy2 の情報を取得る場合は、以下のようなコマンドを実行します。

st2 run aws.ec2_describe_instances Filters='[{"Name":"instance-id", "Values":["i-dummy1", "i-dummy2"]}]'

JSON 形式で出力する

-j オプションを使用すると、JSON形式で出力できます。

・コマンド実行例(Fitlers などの他のオプションとも併用可)

st2 run aws.ec2_describe_instances -j


■ まとめ

StackStorm で EC2 インスタンスの情報を取得することができました。

aws pack ではほかにも様々な機能があります。 aciont の一覧は st2 action list -p aws で確認することができます。 今回は、手動でのコマンド実行で操作しましたが、StackStormが持つイベントドリブンな仕組みを活用することで、利用用途が広がると思います。

「カイゼン・ジャーニー」で学んだチームビルディングで大切にしたいこと

■ はじめに

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで』という本を読みました。 www.shoeisha.co.jp

本書は開発の現場において、アジャイル開発のプラクティスをベースに改善していく物語と解説なのですが、私はチームビルディングの物語として読みました。 読み終わった後も、チームビルディングの物語として解釈しました。 本書で学んだことをまとめたいと思います。


■ なぜチームビルディングの物語と解釈したか

理由は第12話で出てきます。第12話では「組織の成功循環モデル」がというモデルが紹介されています。 行動の質は、思考の質によって決まり、思考の質は関係の質によってきまる。というようなことを示すモデルです。

f:id:akira6592:20180318000342p:plain

関係の質こそがすべての起点となり、関係の質を上げるためにチームビルディングが必要な要素だと考えました。


■ 大切にしたい3つのこと

個人的な拡大解釈も含みますが、チームビルディングにおいて大切にしたいと感じたのは以下の3つです。

  • 自分から始める
  • 心理的安全性を確保する
  • HRT(謙虚:Humility、尊敬:Respect、信頼:Trust) を大切にする

これらを大切にすることで、本書に出てくる様々なプラクティスも活かされるのだと思います。

例えば、第1話の解説にある、他社のやり方をそのまま持ち込まず、自分たちの状況、制約の下でどうするべきか捉えなおさないといけないという件。 「自分」ではなく「自分たち」です。自分たちの状況を知るためには、周囲の人の本音を聞く必要もあります。 周囲の人が本音を話してくれるような良好な関係を保つためにはHRTの精神が必要ですし、本音を言ってもよいと安心してもらうために心理的安全性を確保する必要があります。

また、(どのページに書いてあるか失念してしまいましたが)案外他の人も改善したがっているという件。 協力者を得るためには、自分から動き、周囲の人の本音を聞く必要があります。

      f:id:akira6592:20180318000522p:plain


トークイベントにも参加しました

2018/03/15 ジュンク堂池袋本店で開催された刊行記念トークイベントにも参加させていただきました。 著者の市谷聡啓さん、新井剛さん、ゲストの角谷信太郎さん、及部敬雄さんがいらっしゃいました。

みなさんのアツいお話がたくさん聞けました。 市谷さんがイベントで使用された資料がありましたので掲載します。

www.slideshare.net

・公式サイトによるレポート(2018/03/19追記) kaizenjourney.jp

・一谷さんによるレポート(2018/03/19追記) papanda.hatenablog.com

細かいところですが「バリューストリームマップは、(単なるアウトプットではなく)みんなで一緒にプロセスを整理するためのコミュニケーションツール」とおっしゃっていたことが印象に残っています。


■ さいごに

純粋にやってみたいと思ったプラクティスは、モブプログラミング(モブワーク)と、期待をすり合わせるドラッカー風エクササイズです。 ですが、これらをやって意味のある関係性であり続けることや、目的・理由をはっきり持ち続けることも忘れずにいたいと思います。 本書やイベントでいただいた勇気を燃料にして、私もジャーニーしたいと思います。