カイゼンジャーニーを読んだ

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

読みました。以下は自分用のまとめ。

状況の見える化

• タスクマネジメント
• タスクボード
• 朝会
• ふりかえり

ふりかえり

• KPT
  • Keep: 続けたいこと/やってよかったこと
  • Problem: 問題点/気にかかっていること
  • Try: 次に試したいこと
• YWT
  • やったこと
  • わかったこと
  • つぎにすること

朝会

• 昨日やったこと
• 今日やること
• 困ってること

1 on 1

• 上司と部下が1対1で行うコミュニケーション。定期的に行う

タスクマネジメント

• タスクの情報を洗い出す
  • 誰から依頼されたのか
  • 次は誰に渡すのか
  • 期日はいつか
  • どれくらい作業時間がかかりそうか
  • どうなったらこのタスクは終わるのか
• 分割統治する
• 緊急・重要のマトリクスで優先度をつける
• タスクボードでタスクを見える化する
  • タスクボード運用
    • ステージに分ける(TODO/DOING/DONE/ICEBOX...)

スクラムの基本

• スプリント
• スプリントプランニング
• デイリースクラム
• スプリントレビュー
• スプリントレトロスペクティブ

スクラムのチーム構成

• プロダクトオーナー
• 開発チーム
• スクラムマスター

スクラムの作成物

• プロダクトバックログ
• スプリントバックログ
• インクリメント

スクラムの理論と精神

• 透明性
• 検査
• 適応

スクラムとウォーターフォールの大きな違い

• スクラムは経験主義。小さいスプリントで振り返りながらカイゼンしていく経験主義が根本思想。Fail Fast(早く失敗する)の精神で、漸進的に開発していく。

インセプションデッキ

• 以下の10の問いに答えることで、プロジェクトのWhy,Howを明確にする
  1. われわれはなぜここにいるのか
  2. エレベーターピッチ
  3. パッケージデザイン
  4. やらないことリスト
  5. 「ご近所さん」を探せ
  6. 技術的な解決策
  7. 夜も眠れない問題
  8. 期間を見極める
  9. トレードオフスライダー
  10. 何がどれだけ必要か

Working Agreement

• チームで決めたチームのルール
  • ex. デイリースクラムは10時から15分以内でタスクボードの前で立って行う

成功循環モデル

• bad cycle
  • 結果の質: 成果があがらない
  • 関係の質: 対立、押し付け、命令
  • 思考の質: 面白くなく受け身
  • 行動の質: 自発的・積極的な行動が起きない
• good cycle
  • 結果の質: 成果が得られる
  • 関係の質: お互いに尊重し一緒に考える
  • 思考の質: 気づきがあり面白い
  • 行動の質: 自分で考え、自発的に行動する

ドラッカー風エクササイズ

• チームビルディング手法の一つ。以下の4つの質問に答える。
  1. 自分は何が得意なのか
  2. 自分はどうやって貢献するつもりか
  3. 自分が大切に思う価値は何か
  4. チームメンバーは自分にどんな成果を期待していると思うか
• 上記をチームで確認した後に、5番目の質問。
  1. その期待は合っているか

ファイブフィンガー

• 「個人個人が本当はどう思っているか」を5本の指で表明するプラクティス

クネビンフレームワーク

• リーダーが適切な判断を下すための意思決定フレームワーク

リファインメント

• プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすること

狩野モデル

• 顧客の求める品質についての分析モデル

むきなおり

• むきなおりは、進むべき先を捉えて現在を正す作業。
  1. ミッション、ビジョンを点検する
  2. 評価軸を洗い出し、現状を客観的に見定める
  3. 評価軸ベースで「あるべき姿」と「現状の課題」を洗い出す
  4. 「課題解決」のために必要なステップを「バックログ」にする
  5. 「バックログ」の重要度と、一番効果の高いものを決める
  6. 時間軸を明らかにし、期限も明確に決める

合宿

• メリット
  • 集中
  • リードタイム短縮
  • 高揚感

星取表(スキルマップ)

• チームメンバーがどのようなスキルを持っているかを見える化して、俯瞰するための道具

チームビルディング三種の神器

• インセプションデッキ
• ドラッカー風エクササイズ
• 星取表(スキルマップ)

モブプログラミング

• チーム全員が一箇所に集まって、全員で同じ画面、一つのPCで作業する
• PCを操作できるドライバーは一人、他はナビゲータとなる
• ナビゲータはドライバーに指示する
• 全員が交代でドライバーをする

バリューストリームマッピング

• プロダクトの価値が顧客の手に渡すまでの仕事の流れを見える化するためのプラクティス

ECRS

• 業務改善の方法論。Eliminate/Combine/Rearrange/Simplify の頭文字を取ったもの

ポストモーテム

• プロジェクトを振り返って行う「事後検証」

タックマンモデル

• 組織づくりにおける発展段階モデル。4段階で構成される。Forming/Storming/Norming/Performing

モダンアジャイル

• 4つの基本原則で構成されいる概念

プランニングポーカー

• 見積もり技法の一つ。早期にプロジェクトに導入可能なシンプルな見積もりプラクティス

パーキンソンの法則

• 仕事の量は与えられた時間を満たすまで膨張する、という法則

CCPM(Critical Chain Project Managememt)

• 各タスクに個別のバッファを持たずに抑えた見積もりをして全体としてのバッファを持ってプロジェクト管理をする方法

スクラム・オブ・スクラム

• デイリースクラムを、複数のスクラムチームから代表を集めて実施するミーティング

コンウェイの法則

• アーキテクチャは組織に従う。組織はアーキテクチャに従う

デイリーカクテルパーティー

• 「リーン開発の現場」で著者ヘンリック氏が紹介している

デザイン制作プロセス

• おおよそ以下の流れで制作は進む
  1. サイトの全体像
  2. スケッチ
  3. ペーパープロトタイピング
  4. ワイヤーフレーム
  5. ビジュアルデザイン
  6. コーディング

ユーザーストーリー

• 3段階構成
  • Who
  • How
  • Why
• INVEST
  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

ギャレットの5段階

• Surface: 視覚的デザイン
• Skelton: インフォメーション/インターフェースデザイン、
• Structure: インフォメーションアーキテクチャ
• Scope: コンテンツ要求/機能要件
• Strategy: ユーザーニーズ/サイトの目的

ジョブ理論

• 顧客はやり遂げたい何かがあり、そのためにプロダクトやサービスを「雇用」していると考える

仮設キャンバス

• 顧客の目的、課題解決達成のためのソリューションを得るためのフレームワーク。本書の付録参照。

ユーザーストーリーマッピング

• 時間の流れに沿ってユーザーの行動を洗い出し、左から右にその変遷を可視化していくワーク

MVP(Minimum Viable Prodcut)

• 「ユーザーにとって価値があり、かつ最小限の機能性を持った製品」のこと
  • プロタイプ型
  • ハリボテ型
  • 動画型
  • コンシェルジュ型

ユーザーインタビュー

• ユーザーの声を聴くための直接的な手段

ラポール空間

• 相手との間に安心感や信頼関係を構築するためのテクニック

SL理論

• リーダーシップ条件適応理論。SL(Situational Leadership)

ハンガーフライト

• 組織の中に新しい場作りを行うための活動。勉強会など

感想

本書は、主人公の失敗から成功までを追体験できる構成になっている。

単なる技術本と違い、ストーリーがあり単純に読み物としても面白い。読んでみて、ああ、こういう現場あるよなぁ、という感じだった。

色々なテクニックはあるんだけど、やっぱり最後は現場の人のモチベーションだと思う。

大概、実際の現場は問題だらけでカイゼンする前にうんざりすることも多い。

一人でもカイゼンサイクルを回して、周囲を巻き込んでいくだけのモチベーションを維持するためには、 その開発/プロダクトに対して、そもそもカイゼン努力するだけの報酬や価値を自分の中で見出してないと厳しいなと思う。

本書に示されているように、まずは小さく始めて負担にならない範囲で継続していくのがいいんだろうな。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

GitHub個人/組織アカウントのリポジトリを一括cloneする

準備

curl、jqが必要なので未インストールならインストールをする

• macOSでbrew経由の場合

$ brew install jq curl

実行方法

リポジトリのクローンを保存するディレクトリへ移動し、以下のコマンドを叩く。

• 個人アカウントの場合

$ curl https://api.github.com/users/{PERSONAL ACCOUNT}/repos | jq .[].ssh_url | xargs -n 1 git clone

• 組織アカウントの場合

$ curl https://api.github.com/orgs/{ORGANIZATION ACCOUNT}/repos  | jq .[].ssh_url | xargs -n 1 git clone

解説

上記ワンライナーの解説

• curl

cURL*1はURLシンタックスを用いてファイルを送信または受信するコマンドラインツール。 今回はGitHub API にリクエストを投げるために利用する。

• https://api.github.com/users/{PERSONAL ACCOUNT}/repos

GitHubが提供するAPIエンドポイント*2。 GET methodなのでパスの{PERSONAL ACCOUNT} を個人アカウント名に変えてブラウザで叩けばjsonが返ってくる。

例: https://api.github.com/users/tic40/repos

• jq .[].ssh_url

jq*3 はコマンドラインjsonプロセッサー。 APIレスポンスのjson配列の中から "ssh_url" の値を取り出す。

• xargs -n 1 git clone

xargs*4 はUnixコマンドの一つ。 xargs -n 1 で1つの引数を受け取る。受け取った引数はその後に続く git clone の末尾に追加される。

感想

git clone ssh_url/*.git でいけるのかな〜とか思ったら、まあそんな簡単にはいかず。意外と面倒だった。

あと、privateリポジトリも含める場合はGitHubのAPI token取得する必要があるのでご注意。

*1:https://curl.haxx.se/

*2:API詳細はこちら: https://developer.github.com/v3/repos/#list-user-repositories

*3:https://stedolan.github.io/jq/

*4:https://en.wikipedia.org/wiki/Xargs

CentOS 7 + PHP7 + mysql 5.7 環境をdocker化する

構成

|- docker-compose.yml
|- Dockerfile

docker-compose.yml

version: '3'
services:
  web:
    build: .
    ports:
      - "8080:8080"
    volumes:
      - .:/repo
    depends_on:
      - db
    tty: true
    privileged: true

  db:
    image: mysql:5.7
    command: mysqld --character-set-server=utf8 --collation-server=utf8_unicode_ci
    ports:
      - 3306:3306
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: root

Dockerfile

FROM centos:7

# update yum
RUN yum -y update
RUN yum -y install yum-utils
RUN yum clean all

RUN yum -y install epel-release
RUN yum -y groupinstall "Development Tools"
RUN yum -y install wget git vim zsh curl

# install remi repo
RUN wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
RUN rpm -Uvh remi-release-7*.rpm
RUN yum-config-manager --enable remi-php70

# install php7
RUN \
  yum -y install \
    php php-common \
    php-mbstring \
    php-mcrypt \
    php-devel \
    php-xml \
    php-mysqlnd \
    php-pdo \
    php-opcache --nogpgcheck \
    php-bcmath

# application directory
RUN mkdir /app
WORKDIR /app

# install composer
RUN curl -sS https://getcomposer.org/installer | php && \
  mv composer.phar /usr/local/bin/composer

# timezone setting
RUN cp /etc/localtime /etc/localtime.org
RUN ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

EXPOSE 8080

CMD ["/sbin/init"]

github.com

js勉強会用資料

ちょっとした勉強会用に書いたやつ

太古のコード

See the Pen jzNaoa by tic40 (@ccpzjoh) on CodePen.

特徴

• DOMの状態管理がない
• DOMを手作業で直接更新
• DOMの状態を毎回把握しないといけない

データバインディング

See the Pen dmbJPy by tic40 (@ccpzjoh) on CodePen.

特徴

• モデル(js object)の更新に伴って、ビュー(DOM)に変更が反映される
• 手作業でDOMを更新する必要がない

データバインディング + コンポーネントベース

See the Pen yKBpwr by tic40 (@ccpzjoh) on CodePen.

特徴

• DOMはほぼjs側で生成する
• コンポーネント化することで、コードの再利用性が高まる
• コンポーネントごとに単一の責任を負わせることで副作用が減る
• テストが容易

Hugoにgoogle analyticsを設定する

config.toml に以下を追加

googleAnalytics = "{your tracking code}"

Hugoはgoogle analytics用のテンプレートをすでに用意している。 テンプレートファイルに以下の一行を追加だけで良い。

{{ template "_internal/google_analytics_async.html" . }}

これでビルドすればgoogle analyticsコードが埋め込まれる。

参考: Internal Templates | Hugo

dockerコンテナで起動したPHPビルトインサーバにアクセスできない

適当にdocker コンテナを走らせる。-p で8080ポートを指定。

$ docker run -it --name {container-name} -d -p 8080:8080 {image-name}

docker コンテナ内でphpファイルを作成し、php ビルトインサーバを以下のように動かした。

$ echo "<?php echo 'hoge;" > index.php
$ php -S localhost:8080

ブラウザで http://localhost:8080 にアクセスしてみる

見れない。

localhostを0.0.0.0 にしてビルトインサーバを再起動してみる。

$ php -S 0.0.0.0:8080

見れた。 localhost ではなく、0.0.0.0を指定することでアクセスできる。

Hugoでポートフォリオサイトを作る

経歴書、毎回pdf出力して送ったりするの本当にだるいので、もうgithubにあげとこう

— tic40 (@tic40) 2018年2月24日

github pagesを使って自身の経歴を公開するポートフォリオサイトを作ろうと思い立った。 今回、Hugoという静的サイトジェネレータを使って構築したのでその手順を記しておく。

使用するツール

Jekyll と Hugo 両方使ってみてHugoの方が簡単だったのでHugoで構築する。

github.com

The world’s fastest framework for building websites.

世界最速

できあがったもの

完成イメージはこちら

https://tic40.github.io/

構築方法

前提

• github pages を使って無料で公開する
• ユーザページとして公開する (https://.github.io/)

手順

• github に公開用のリポジトリ {USERNAME}.github.io を作成。 https://github.com/tic40/tic40.github.io

• プロジェクト用のリポジトリ を作成。名前はなんでもいい https://github.com/tic40/hugo-tic40.github.io

• プロジェクト用リポジトリをcloneしておく

• hugoをインストールする

$ brew install hugo

• hugo コマンドで新規サイトを構築。プロジェクト用リポジトリディレクトリに入れておく

$ hugo new site <site name>

• テーマを設定。submodule として登録しておく

$ cd <site name>
$ git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\
$ echo 'theme = "ananke"' >> config.toml

• public ディレクトリを作成。submoduleとして登録する。

$ git submodule add -b master git@github.com:{USERNAME}/{USERNAME}.github.io.git public

こうしておくことで、public/ の変更をpush したときに、公開用リポジトリに変更をpushされるようになる。

• ローカルで動作確認

$ hugo server -D

*-Dオプションをつけるとドラフト状態の投稿も表示されるのでつけておくといい

デフォルトだと、1313ポートでローカルサーバーが立ち上がるので、ブラウザで確認できる。

http://localhost:1313/

• デプロイ

1コマンドでリリースできるようにスクリプトを作っておく

$ vi deploy.sh
#!/bin/bash

echo -e "\033[0;32mDeploying updates to GitHub...\033[0m"

# Build the project.
hugo # if using a theme, replace with `hugo -t <YOURTHEME>`

# Go To Public folder
cd public
# Add changes to git.
git add .

# Commit changes.
msg="rebuilding site `date`"
if [ $# -eq 1 ]
  then msg="$1"
fi
git commit -m "$msg"

# Push source and build repos.
git push origin master

# Come Back up to the Project Root
cd ..

スクリプトに実行権限を付与

$ chmod +x deploy.sh

スクリプトを実行して公開

$ ./deploy.sh

githubにアクセスしてページが表示されればOK

https://{USERNAME}.github.io

記事を投稿する

記事ファイルの作成

$ hugo new posts/{title}.md

上記で作成されたファイルを編集して、deploy.shを実行すれば公開される。 *上記で作成した記事は、ドラフト状態(draft: true) になっているため、そのままでは本番に反映されない。公開時は draft: false にしておく

最新の詳しいドキュメントはこちらを参照

https://gohugo.io/documentation/