ゆるい感じのプログラムを書きたい。

プログラムの敷居を下げて、多くの人が開発出来るように色々書いていきます!

コンテナ開発の環境構築

利用する環境

1.DockerDesktopを利用する場合

  • dockerDesktopを利用

Windows,Macのお使いの方は以下のサイトからダウンロード

ダウンロード先:Docker Desktop

AppleSiliconのMacbookをお使いの方は以下のサイトからダウンロード

ダウンロード先:Docker Desktop for Apple silicon


2.DockerDesktopを利用しない場合

  • Dockerをインストールする

Dockerのインストール

1.Dockerのインストールの前準備をする。
  • 以下のDockerのインストールページを参照にインストールを行う。

【公式】Dockerインストールマニュアル


1-1.必要なパッケージをインストール
sudo yum install -y yum-utils device-mapper-persistent-data lvm2


1-2.リポジトリ追加
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo


1-3.yumのパッケージインデックスを更新
  • DockerのINSTALLやUPGRADEの前に一回実行することが推奨されている
sudo yum makecache fast   


1-4.インストール可能バージョンを調べる
yum list docker-ce.x86_64 --showduplicates | sort -r


2.Dockerのインストールを行う。

2-1.バージョン指定してインストール
  • Dockerをバージョン指定してインストールは以下のコマンドで行う。
$ sudo yum install docker-ce-17.06.0.ce-1.el7.centos
  • Dockerの最新バージョンのインストールは以下のコマンドで行う。
sudo yum install docker-ce


2-2.サービス起動
  • Deamon化したDockerを以下のコマンドで起動させる。
sudo systemctl start docker.service


2-3.起動確認
  • Docker起動の確認が行われたのか、以下のコマンドを実行して確認する。
systemctl status docker

#実行結果は以下の通り
● docker.service - Docker Application Container Engine
   Loaded: loaded 

#以下省略


3.Dockerのproxy設定

3-1.docker.serviceをコピー
  • プロキシサーバを設定している場合
  • 以下のファイルdocker.serviceをコピーする
  • コピー場所は/etc/systemd/system/のフォルダにコピー
sudo cp /usr/lib/systemd/system/docker.service /etc/systemd/system/


3-2.コピーしたdocker.serviceを開く
  • ファイルをコピー後、ファイルを開く
cd /etc/systemd/system/
vi docker.service

## 以下のプロキシ設定を追加
Environment="HTTP_PROXY=http://xx.xxx.xx.xxx:xxxx"


3-3.docker.serviceのExecStartコマンドの直前にProxyの設定を追加
  • ファイルdocker.serviceExecStartコマンドの直前に以下の内容をコピーし保存
## 以下のプロキシ設定を追加
Environment="HTTP_PROXY=http://xx.xxx.xx.xxx:xxxx"


3-4.設定を再読込 & Docker再起動
  • docker.serviceファイルの設定後、再読込のため 以下のコマンドでデーモンをリロードし、Dockerを再起動する。
## デーモンをリロード
systemctl daemon-reload
## Dockerを再起動
systemctl restart docker


kubernetesのインストール

下記の公式サイトにもインストールの詳細が記載されております。

公式サイト:kubectlのインストールおよびセットアップ


Linuxkubernetesをインストール
1.curlを使用してLinuxへkubectlのバイナリをインストールする
  • 以下のコマンドにてkubernetesのモジュールをダウンロード
curl -LO "https://dl.k8s.io/release/$(curl -LS https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

特定のバージョンをダウンロードする場合 コマンドの$(curl -LS https://dl.k8s.io/release/stable.txt)の部分を特定のバージョンに書き換えてください。

  • Linuxへv1.27.0のバージョンをダウンロードする場合
curl -LO https://dl.k8s.io/release/v1.27.0/bin/linux/amd64/kubectl

$(curl -LS https://dl.k8s.io/release/stable.txt)v1.27.0に書き換える。


2.kubectlバイナリを実行可能に変更
chmod +x ./kubectl


3.インストールしたバージョンが指定したバージョン、もしくは最新バージョンであることを確認
kubectl version --client


macOSkubernetesをインストール
1.curlを使用してMacOSへkubectlのバイナリをインストールする
  • 以下のコマンドにてkubernetesのモジュールをダウンロード
curl -LO "https://dl.k8s.io/release/$(curl -LS https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

特定のバージョンをダウンロードする場合 コマンドの$(curl -LS https://dl.k8s.io/release/stable.txt)の部分を特定のバージョンに書き換えてください。

  • Linuxへv1.27.0のバージョンをダウンロードする場合
curl -LO https://dl.k8s.io/release/v1.27.0/bin/linux/amd64/kubectl

$(curl -LS https://dl.k8s.io/release/stable.txt)v1.27.0に書き換える。


2.kubectlバイナリを実行可能に変更
chmod +x ./kubectl


3.インストールしたバージョンが指定したバージョン、もしくは最新バージョンであることを確認
kubectl version --client

リーン開発_第10章_旅立ち

どこに行きたいのか?

「次に何をしたらいいですか?」とよく聞かれる。

第7章では、次の2つの問に答えるところからリーン活動に着手するように勧めた。

  • 1.どのように顧客価値を作り出し、利益を上げようとしているのか?
  • 2.現時点の最大の問題は、具体的には何なのか?

これに、さらに2つの問を加える。

  • 3.今後の存続を脅かすのは何か?
  • 4.人について、何を本当に信じているのか?


車輪をつけたコンピューター

  • 同業他社は、人件費を減らすために自動車工場を最新鋭に自動化していたが、 トヨタは、実験の結果、自動化しても総コストを考えれば採算が合わないという結論を出した。

  • 競合他社は、コンピュータによるスケジューリングシステムやクロスドッキングの自動化に重点的な投資を行ったが、 トヨタは、生産プロセスの中心には人がいるべきであり、シンプルな手作業によるシステムのほうがうまく機能すると考えた。

  • トヨタの経営層は、従来、物流や生産スケジューリングに情報システムを用いる事を認めてなかった。

  • 情報システムの利用にそれほど注意深かった企業が、生産プロセス、開発プロセス、そしてその製品に対して、情報システムを活用するリーダーになったことは特筆に値する。


長期的な展望

教会、軍隊、大学などは何世紀も存続する。 どうして、大企業は、早く倒産したり、買収されたりするのだろうか?

  • さらに重要なのは、どうして優秀な企業は、何世代もの経営者にわたって存続し続けられるのかと言う点。
  • そういった企業は、創業期を乗り越え、成長の痛みに耐えただけではなく、大規模な多国籍企業になった。


しかし世界が変わり、成功していた企業の多くは、新たな現実に順応出来なかった。

  • 一方、成功した組織は、急成長を遂げるなか、市場に十分な需要があるうちに、習慣を確立する傾向にある。


しかし、最終的には、すべての成長要因が勢いをなくし、過去の成功が将来の成長へ道しるべとならなくなってくる。

  • そうなった場合、学習能力、適応能力を身につけた組織のみが生き残る。
  • 手遅れになる前に将来に適応できるような構想を描くのは、マネージャーの能力であると考えている。


しかし、残念ながら、マネージャーは過去の栄光にこだわりたがり、未来に対して鈍感になりやすい。

  • この実績のあるマネージャーほど将来を見通せないという考え方は、クレイトン・クリステンセンも著者のなかで繰り返し主張している。
  • 彼は、利益を維持するために高級志向に行こうし、利益率の低い大衆志向の市場を 競合他社に譲る企業は「破壊的技術」によって追い抜かれていく場合が多い。


そのような企業は、現在の顧客を非常にうまく満足させているために、将来のリスクや利益の低下などを想像する動機が、まったくと言ってよいほどない。

  • コンピュータ業界では、小型化、高速化、省エネ化されたハードウェアが、大型の利益率の高い装置に取って代わっているように、常に破壊的技術にさらされている。
  • ソフトウェア業界では、安価のソフトウェアパッケージが高額の人数比例料金契約に取って代わりっている。
  • IT業界のように動きの早い業界では、将来の構想を立て、それに適応できるようにしておくことが生き残りを左右する。
  • 組織が長期的な存在を望むなら、常に洞察に満ちた将来の展望を描いて、その長期的なビジョンに基づいて決定を下さなくてはならない。


人を中心に置く

科学者ならば、効果的な問題解決の第一歩は、ものごとが実際にどのようなしくみでうごいているのかを深く理解し、それを反映するための概念的な枠組みの中に問題を置くことだという。

現場での技術の活用法に関しては、2つの考え方がある。

  • 1つ目は 作業を遂行するために必要とされる人数や、必要とされるスキルレベルを低く抑えるため、既存の作業を自動化すべきという考え方。

  • 2つ目は 作業者の能力を高めるために技術を利用すべき。

トヨタでは2つめの後者の考えに基づいて動いている。


1つ目は何が悪いのか?

  • 繰り返し行われるタスクは、自動化すべきではないだろうか?

実際、8章で記載下通り、ビルドや導入のプロセスを繰り返し行われるタスクお自動化すれば、ばらつきがなくなり、確実で一貫した結果が得られる。 しかし、あるプロセスから人を除去すれば(あるいは、人に、あるプロセスを機械的にこなすように求めれば)、そのプロセスでは、もはや何の変化も生まれず、適応も、発見もなくなる。


例えば、製薬会社では

何十億ドルもの資金を、繰り返し行われる薬物研究作業の自動化につぎ込んだ。研究室の技術者たちをロボットで置き換えて、
技術者たちが成し得たよりも、はるかに多数の薬物調合をテスト出来るようにした。

そうすれば、はるかに多くの超大型新薬が生まれるはずだと考えたのだが、まったく期待はずれに終わった。 多くの人の推測によれば、それは、新薬実験という仕事の「単純作業化」と、人という要素の排除によって、探索すべき領域を企業が暗黙に想定してしましい、予期せぬ結果に気づき新しい実験を試して見る人ならではの能力を生かさなくなったため。


製薬会社でのテスト自動化と、ソフトウェア開発でのテスト自動化との違い ソフトウェアでのテストの効果的な自動化は、テスト技術者の「技能向上」につながったという点である。

  • 決まりきった繰り返しテストを自動化したのは、テスト技術者を解放し、開発プロセスのポカヨケの実現、ユーザにとって使いやすいソフトウェアの制作、探索的テストや特性テストの実施に集中させるため。
  • 一言で言えば、単純作業化は交換可能な人を生み、技能向上は思考力のある人を生むということ。


プロセスにどのような態度で取り組んでいるか、考えてみよう

  • きちんとドキュメン化され、誰もが質問することなく従えるようなプロセスが、正しい道だと考えているだろうか?
  • プロセスを標準化するのは、その作業をする人に、疑問に思ったり変更したりするための土台を与えるためだろうか?


リーン原則は確実に、後者の考え方に根ざしている。

自分がスケジュールとどう向き合っているのか?

  • 開発チームが時間内で何が出来るのか、自分たちで決めて、それをマネージャーに伝えるように」と言われたら、 マネージャー側に決められる場合よりも、不安に感じるだろうか?
  • 作業のアサインについてはどう向き合っているだろうか?
  • 自分たちで次に何をするかを考えるのは、それを指図されるよりも不自然に思えるだろうか?

リーンを成功させるには、作業を行っているその人本人が、その作業のやり方を最もよく知っているのだ、という基本信念を、あなた自身の人に関する概念的枠組みに取り込まなくてはならない。


プロセスから人を排除したり、作業に必要なスキルレベルを下げたりする自動化は、注意が必要。 職場での獅子決定に何度もの(あるいは、一度でも)承認が必要となるなら、それをおかしいと思わなくてはならない。


問題を解決するには

本当に、作業を行う人たち自身に、トレーニングを行ったり、ツールや権限を与えたり、支援をしたりして、
自からの問題を解決し、プロセス改善できるようにするのが最善の手法だということを信じる。


リーン以前の改善活動から学ぶこと

何かを変えようとする前に、すでに存在する有益なアイディアを調べて、そこから何か学べるのかを確認するのは良いこと。


シックスシグマとTOC(制約理論)の2つの活動について

シックスシグマ

シックスシグマの初期段階における問題は、製造に適したプラクティスを、開発プロセスに適用したことにある。

開発では、ばらつきが善であり、失敗した実験からも成功した実験と同等の学習効果があることがわかり、企業は、ソフトウェア開発にはシックスシグマの改良版であるDFSS(設計開発のためのシックスシグマ)が適しているということを理解した。

顧客の声の発掘とデータ駆動型の問題解決に重点をおくDFSSは、開発チームに多くの利点をもたらす。


プロセスリーダーと現場の作業チームのリーダー

シックスシグマとトヨタ生産方式の違いは、変革推進者の役割

シックスシグマ 労働力の約1%を「ブラックベルト」と呼ばれるラインの責任を持たないプロセスリーダーとして訓練することを推奨

トヨタ生産方式 プロセスリーダーや変革推進者ではなく、現場の作業チームのリーダを重点的に訓練することを推奨

<理由>

作業のチームリーダこそ、作業チームを率いるべきであり、成果に責任を持たすべきと考えているため。

リーンでは、トヨタ生産方式を踏襲すべきであり、プロセスリーダーよりも、現場の作業リーダーの訓練を重視すべきである。

ツールと成果
  • ある向上で、劇的に改善が見られたが非常に低い評価しか得られなかったケースが有る。
  • それは、「不可欠」と見なした、企業内で認定済みのプロセス改善ツールを採用しているという証拠を支持しないまま、優れた結果として出したため。
  • すべてのツールは、特定の問題を解決するために作り出されたものである。

あるツールが、当面の問題を解決するのに最善と言えないのなら、そのツールは使うべきではない。 作業チームやそのリーダーは、経験に基づいて問題を解決するように訓練されるべき。

今抱える最大の問題の解決に、適したツールを採用出来るだけの権限が与えられるべき。


TOC(制約理論)Theory of Constraint

TOCという言葉を生み出したエリヤフ・ゴールドラット技術では、何かの制限を軽減しない限り(制約を取り除かない限り)、何の利益も生まない、という命題を掲げている。

  • 制約を新技術を導入するだけで、排除すべき制限が取り除かれるとは限らない。
  • その制限に対処するために作り出された適用手段(accomodation)は、企業にあまりにも深く染みついて、認識すらされていないから。

例えば

  • ISPが一般的に電子メールサービスを提供するようになっても、大企業が自社の電子メールを外部に開放するまでに何年もかかった。
  • 家庭では、家から外部に対して電子メールを送れるようになってから、かなりの時間を用いいてようやく会社の電子メールシステムを使って、ベンダーとコミュニケーションを取れるようになった。

制限を取り除く上で、難しいのはその制約を乗り越えなくてはならないだけではなく、その制約に対処するために作った過去の適用を認識して(これは難しいタスク)それからその手段を除去し、最後に新たなルールに置き換えなくてはならない。


新技術を導入するために、ゴールドラットは次の4つの問に答えなくてはならないと言っている。

  • 1.その新技術には、どのような威力があるのか?
  • 2.その新技術には、どのような制限を軽減するのか?
  • 3.その制限に対処するために、そのようなルールが役に立ったか?
  • 4.その制限が置き換えられたら、どのようなルールを採用すべきか?


ERP(統合業務ソフト)を例に考えてみよう。

  • マネージャーが、適切に意識決定を行いやすいように、大量の情報へのアクセスを可能にしたかつての新技術。

ERPが存在する以前は システム全体に関する決定を行うためのデータがなかったため、部分最適を生み出すルールに基づいて決定が行われた。

例えば

  • 製造のマネージャーは機械の効率を最適化しようとしていた
  • 営業のマネージャーは製品の価格を決定するために、原価計算式を用いていた

上記のように、そうするしかなかった頃は、部分最適化に元で浮いて決定を下すは、最適な手法で、きまぐれな決定に比べれば、はるかによい成果を生み出した。


しかし、ERPによって システム全体を見渡したうえで、より適切な決定をくだせるようなデータが得られるようになったのなら、部分最適のためのスルールを捨てなくてはならない。

  • そうしないとERPの実力が発揮できない。
  • ERPが失敗した原因の多くは、ERP以前に使われていた手段の撤廃やルールの見直しができなかった点にある。


クリティカルチェーン

クリティカルチェーンとは、ゴールドラットTOCプロジェクトに適用する際に使用した言葉。

  • プロジェクトの重要な制約は、見積もりが確約と見なされた時に生まれる。
  • プロジェクトに携わる人達は、それぞれの活動に必要となる作業量を見積もるように指示される。
  • プロジェクトはそれぞれ1回限りの取り組みで、見積もりは憶測になる。
  • プロジェクトは未知の要素でいっぱい
  • 見積もりを出す人は、万一の場合に備えて大量の「ゆとり」を含めようとする
  • ただ、上手く言った場合も、結局は見積もった時間をすべて使い切る、何故なら見積もりを出した側は、過剰な見積もりをしたと思われたくないから。

見積もりをあくまで見積もりとしてとらえて、個々の見積もりに加えられたゆとりを除去し、プロジェクトバッファとして一括管理することを推奨 この手法によって、はるかに素早く完了し、プロジェクトバッファを使って、あらゆる変動を吸収することができるようになる。


注意しなくてはならないこと

目標と報酬のメカニズムに組み込まれた過去のプラクティス(日常的な活動)への適応手段を変えないかぎり、プロジェクトバッファがプロジェクト全体のスピードアップにつながらないという点

クリティカルチェーンを機能させるためには、上級管理者から見積もり作業を行う人達まで、全員がこの期待をすてないと、結局、個々の見積もりにバッファを含めることになってしまう。


クリティカルチェーンをソフトウェア開発に適用する際の注意点

開発を完了させるのに必要な全ての活動が事前にわかっていて、その活動間の依存関係を明らかにしなくてはならない、という想定があるが。 これは殆どのソフトウェア開発では不適切な想定になる。

何よりもまず、開発作業が始める時点ですべての欲求が出揃っているべきだという考えを捨てなくてはならない。 依存性を解消するために最大の工夫を行う。

上位レベルにおいては、クリティカルチェーンのプロジェクトバッファは有用かもしれないが、詳細レベルでは、それは過去への適応手段になる。

依存関係を解消し、少しづつ動くソフトウェア開発する専属チームを出来ることが出来たら、クリティカルチェーンが解決しようとしていた問題は存在しなくなる。


適応手段(accommodation)

ラクティスやプロセスやルールには、現実の、あるいは想像上の制約への適応手段がいくつも組み込まれている。 ただ、実践しているプラクティスの多くは、すでに古かったり、実際には起こり得ない問題の対処するために導入されることが多い。

例えば

  • コスト、スケジュール、スコープを早期に定義し、プロジェクトの始めにはすべての資金を 確定させるというプロセスがあるとする。


しかし、たいていの新製品開発の場合みたいに、 プロジェクトへの資金調達が段階的に行われるのであれば、プロジェクトを始める前に確定させる必要はない。

  • 開発環境ですら、年数が経つと異なってくる。
  • 当初は、限られたメモリー領域や処理能力、コミュニケーション手段、選択できるソフトウェアの対応を行うために作り出した適応手段も、すでに適切ではない。
  • そのように急速に変化を続ける環境においては、既に存在しない、古い制約のために、対処法を作り続けないよう、警戒が必要。


リーン開発を着手するため仮設を立てる

リーン開発に着手する、最も有効な手法は以下の通り

  • (変革推進者よりも)チームリーダーと監督者を訓練する。
  • (ドキュメントよりも)実地の思考を重視する
  • (多くのデータを計測するのではなく)要となる少数の指標を計測する。


訓練

チャールズ・アレンという科学者は、マサチューセッツ州ニューベッドフォードで産業教育プログラムを開発していた。 チャールズ・アレンは、訓練の大部分は実地で行われるべきだと考え、監督者に作業者の訓練方法を教えることに重点を置いた。

  • 監督者は自分の監督する作業に関して、高度な技術を備えている必要があると考えた。
  • あれンの訓練プログラムでは、準備、実演、適用、試験の4段階に分けて、監督者に知識を伝達する方法を教えている。
  • アレンは造船監督に作業者と協力し合って問題を解決するように言っている。
  • 彼の哲学は「学習する側が学習しないのは、教える側が教えていなかったことであえある」というもの

1940年にアメリカの軍需生産委員会で、監督訓練(TWI)を開発した この訓練プログラムでの骨子は、次のようなもの


■教える技能(JI=Job Instruction) この訓練プログラムでは、ベテラン作業者が作業は非常に的確に行えるものの、その作業のやり方をほとんど教えてことがないという前提で作られている。

監督者は

  • 1.作業者に準備させ
  • 2.業務を実施し
  • 3.作業者に業務をやってみせ
  • 4.頻繁にチェックし、質問を促し、作業者が熟練していくにつれて徐々にコーチングを減らすようにフォローする


■改善する技能(JM=Job Method) この訓練プログラムは、作業者本人が改善に関する優れたアイディアを数多く持っているのだが、そのアイディアに沿った行動を必ずしも取れないという前提に立って作られている。

監督者は、作業差が

  • 1.作業ブレークダウンし
  • 2.細部を吟味し
  • 3.同僚とともに新たな手法を作り出し
  • 4.その手法を広く受け入れさせ、承認を取ってそれを適用できるように手助けすること。


■職場の人間関係(JR=Job Reliations) この訓練プログラムは、監督者が作業者を個人として扱い、彼らが「人間関係」の問題を効率よく公平に解決する手助けとなるように、と教えている。

監督者は

  • 1.全体像をつかみ
  • 2.問題に優先順位をつけて結論を急がず
  • 3.責任転嫁せずに自ら行動を起こし
  • 4.フォローアップをして結果をチェックする


思考

  • 大抵の改善前活動では、ドキュメントを必要以上に重視しすぐていて、各人に常に自分の作業環境の改善方法を考えさせることに、あまり重点を置いていない。
  • ほとんどの企業が、社員に十分改善について、考えさせていると思っているが、いいアイディアがあればそれを書き留めて提出できる提案システムを作業者に用意しているが、おの提案活動も改善という点から見れば、ほとんど効果はなかった。
  • ソフトウェア開発では、振り返りを使って変更すべき点を書き出したりするが、同じ内容が何度も繰り返しで出てくることが多い。
  • 提案活動やブレインストーミングで出されたアイディアの多くは、誰かに引き継がれて、評価されたり、ときには実現されたりするのは間違ったやり方
  • アイディアを持っているチームメンバー自身が、自らのアイディア実現すべきで、他の人が実現することを前提に、提案システムにアイディアを出させても意味がない。
  • 優秀なアイディアの長いリストに、自分のアイディアをただ付け足しているだけではだめ。
  • 改善に関する優れたアイディアが、誰か別の人の問題として手渡されたら、発案者はそのアイディアを自分で推し進めようとしなくなる。
  • その問題についての暗黙知もまた、発案者の頭の中に残されたままになる。
  • すべての作業者が自分たちの現在行っているプロセスのシクミに、常に疑問を感じるべきであり、新しいアイディアを試したり、うまくいくアイディアを実現したりするために、効果的な問題解決テクニックを積極的に使うように推奨されなくてはならない。
  • この問題解決プロセスの基盤として、ドキュメントが存在すべき。
  • このドキュメントは、作業チームが作って、使い、保守し、手軽に変更できるようでなければならない。


<考えを変えないといけない部分>

  • やる気と思考力のある人材に価値があると考えるなら、ドキュメントのにもとづいたプロセス評価を見直す必要がある。
  • 通常、そのような評価は、組織が、ドキュメント化された手続きに従っているかどうかで、その組織の成熟度を計る。
  • 一見、この目的は無害に見えるが、実際には、評価プロセスは組織にドキュメントを凍結するように強いるのが常なので、そのプロセスを変えさせまいと圧力もかかっている。
  • その結果、困ったことに、第一線の作業者たちから「考える権利」を奪ってしまう。
  • 作業者はドキュメントに書かれている通りにやるように促される。


<変えるためには>

  • 作業者は、ドキュメントに書かれている内容に、常に疑問を持つように促されるべきである。
  • ドキュメント重視のプロセス評価は、ドキュメントの安定性を重視しがち。
  • 実際は、ドキュメントの頻繁な変更こそ、その組織が思考できるようになった証拠だと考えるべき。


計測

開発チームを効果的に計測するの方法を見つけるのは難しい。 なぜなら、開発作業が終了してからしばらく立たないと、その効果が目に見えない場合が多い。

  • そのため、プロセスの各部分が最適化されれば、プロセスの成果物も最適化されるという前提から、計測を増殖させることになる。
  • この前提は「システム」としてのものの見方からすれば、根本的に間違っている。
  • まったく制御不能なプロセスをスタート地点とするのであれば、プロセスを部分毎に最適化しても利益はある、だた、部分最適化によって、システム全体の最適化を妨害することになる。
  • 誤った計測を改善しようとしても、間違った誘因を作り出すことになり、多くの場合は意図しなかった結果につながる。

例えば

  • プロジェクトマネージャーがよく、アーンド・バリューに基づいて計測される。
  • しかし、アーンド・バリューを検測すれば、計画通りに進めたかどうかを計測することになる。
  • つまり、その計画が望まれた結果を達成するための最善の方法で合ったかどうかという点は、まったく無視されてしまう。
  • これが予定通り、予算内で計画通りのスコープを完成させた形でソフトウェアを提供しても、やはり顧客に不満を抱かせる理由になる。


では、どのような計測基準を採用すればいいのか。

  • 計測点を増殖させるのではなく、計測対象を減らし、サブシステムレベルでの正しい行いを促すようなシステムレベルでの計測点をみつけるのが良い。

リーンな組織では、何を計測すればよいか?


サイクルタイム

サイクルタイムが一番基本的な計測基準になる。

  • コンセプトがキャッシュとなるまで、あるいは、顧客の「注文」がソフトウェアの導入に至るまで、平均でどれだけの時間がかかるのかを計測する。
  • プロセス性能がシステムレベルで計測でき、システム内のあらゆるムダが露呈する。
  • 不足しているスキルや、稼働能力低さ、欠陥の多い実装が、サイクルタイムを長くしている。
  • 一度にあまりに多くのことに対処しようと頑張ると、複雑性や不要な依存性、変更の容易性の欠如と同様に、サイクルタイムを長くする。


サイクルタイムを計測する際
  • システム内での最短のサイクルタイムを計測してはいけない。
  • どれだけ、上手に応急処置が取れるかを計測しても意味がない。
  • リーンな開発環境では、応急処置は必要でなかれば、好ましいものでもない。
  • 重要なのは、どれだけ早く提供できるかではなく、どれだけ速く、繰り返しかつ確実に、新たな機能を提供したり、顧客要求に応えたり出来るか。


開発組織の目標
  • 作業分類ごとに、繰り返し、確実に提供できるサイクルタイムを確立すること。
  • 継続的な改善によって、そのサイクルタイムを短縮すること。
  • サイクルタイムだけを計測することによって、組織の全領域でのすばらしい振る舞いを引き出す。

上記のよって、全員が正しいトレードオフを行えるようになる。


タイムサイクルの短縮を重視すれば

全員が価値を付加する活動に一生懸命になる 共同作業が促され、世界最高水準の品質へと近づき、標準化も進む。

それ以外の計測対象すべて(締め切りに間に合わせる能力、完成させる作業量、 そして利用率さえも)がサイクルタイムの短縮に伴って改善させれる。 しかし、その逆は当てはまらない。サブシステムの計測結果を最適化しようとしても、サイクルタイムは短縮されないでだろう。


どのようなサイクルタイムを計測すべきか 例:

  • 欠陥リストに欠陥が加えられたら、その日付を控える
  • 上記の欠陥が解決したら、この欠陥がリストに乗っていた期間を計算
  • 期間を記録し、解決した欠陥の平均サイクルタイムと標準偏差、欠陥リストにあった期間の平均を出す。
  • ある項目が製品のバックログに入ったら、その日付を控える。
  • その項目が小項目に分割されたら、それぞれの小項目にもともとの日付を付ける
  • 2つの項目が組み合わさって新たな項目にになったのなら、新しい項目に古い方の日付を付けておく
  • ある項目が導入されたら、導入日からそれが作られた日付を引く
  • 上記はタイムサイクルになる。
  • 平均サイクルタイムと、項目の各リリースでの標準偏差を計算する
  • また、バックログにある項目の平均待ち時間も計算する。


バックログに大規模な項目が追加し、対応に膨大の時間が掛かるため、誰も時間を割いて無く、顧客も「依頼」とは考えてない場合。

上記の場合、バックログの項目を3つのカテゴリに分けて考える。

  • A.顧客が「依頼」と考える機能、あるいは、計測可能な時間をすでに掛けた項目
  • B.アーキテクチャーについて考えたり、全体のスケジュールを見積もったりするために出す必要のある項目
  • C.本当に必要な製品ロードマップに載せる項目

バックログ項目は、A,B,Cの順に見ていき最初に当てはまるカテゴリに入る。 つまり、ロードマップ項目で待ち望んでいる顧客がいるのであれば、それはAに入る。

  • バックログに入るもの全てに日付を付ける
  • 項目がCからBに移動したら、新しい日付をつけ加える
  • それが、Aに移動したら、もう一度日付を加える。

項目を分け終わったら、3つのカテゴリのサイクルタイムを計算する。

次の数字を出す。

  • 1.カテゴリAに振り分けられてからの経過時間
  • 2.カテゴリBに振り分けられてからの経過時間
  • 3.カテゴリCに振り分けられてからの経過時間

リリース毎に、3つのカテゴリの平均サイクルタイムと標準偏差を算出する。


上記の数字が何を語っているのか、考えてみよう。
  • 別のカテゴリ分けをする必要があるだろうか?
  • バックログに残ったカテゴリAの項目は、そこに追加されてから平均して、どのくらいの時間がたっているだろうか?
  • リリースに含まれているA項目の平均サイクルタイムは、リリース1〜2回分に収まるだろうか?
  • A項目が追加されてからの平均経過時間がリリースサイクル2回分よりもはるかに長いようなら、作業を許容量までに制限していないということである。


財務上の成果

  • 開発作業は、「投資対効果検討書」に基づいて資金を得る
  • 開発の成功を計るのなら、投資対効果検討書の実現度を計測することをお勧めする。
  • 現実的な投資対効果検討書だけを開発の正当化に利用すべきであり、実際の結果を計測した結果、投資対効果検討書を修正する必要も生じる。
  • 投資対効果検討書を実現するためには時間もかかる、他にも影響を与える要因もあるはず。
  • 基本原則として、本当に手に入れたいと考えている対象を計測すれば、それが手に入りやすくなるものである。

  • 開発の最終目的が高い収益が得られるの製品を作ることなら、開発チームは製品の損益(PL)モデルを理解しなければならない。

  • そうすれば、収益が最高となる製品を生み出せるように、お互いの作業を噛み合わせることが出来る。
  • 社内開発、請負開発、非営利目的の開発のいずれの場合でも、チームは適切な投資対効果(ROI)を実現したり、ほかのビジネス指標(例えば、スループットなど)がその投資を正当化するかどうかを見極めたりするように、務めなくてはならない。

  • ほとんどの企業では、開発作業の財務上の意味合いを、開発チームには知らせない。

  • しかし、どのようなチームも、自分たちの作業の財務上の目的を理解し、その目的を念頭においてトレードオフを行い、その目的達成によって得られる達成感に、喜びを感じるもの。

  • 開発チームを結成する際の最初のステップは、何が成功になるかという点について、明確で魅力的なメッセージを伝えることである。

  • 最終ステップは、その成功(失敗)を計測し、目に見える形にすること。


顧客満足度

リーン開発の目標は、顧客の状況を深く理解し、問題を完璧に解決することによって、 顧客を喜ばせる方法を見つけることでなくてはならない。


ブラッド・ライクヘルドは以下のことを言っている。 著書『顧客ロイヤルティを知る「究極の質問」』

  • 顧客を喜ばせる企業は、持続的な競争優位を得る。
  • 顧客をいらだたせる企業は、より魅力的な選択肢が出てきた時点で顧客を失う。

顧客が喜んでいるかどうかを見極めるために、ひとつだけ簡単な計画を行うように提案している。


それは「推奨者の正味比率」の計測

  • 顧客に次の簡単な質問をしてみよう 「あなたの製品を、どれだけ薦められますか?」

顧客には以下の点数をつけてもらう。 0(薦めない)〜10(絶対に薦める)

その回答を以下のようにグループ分けする。 0〜6:批判者 7〜8:中立者 9〜10:推奨者

  • 推奨者の正味比率を算出するには、推奨者の割合(パーセント)から批判者の割合を引く
  • マイナス100%からプラス100%までの数字が出る。
  • 平均的な企業なら、点数は10%戦後
  • マイナスになったら、深刻な問題につながると思ったほうが良い。

推奨者の比率が、ひとつの数字だけで顧客満足の概略を表すものであるとし、マーケットシェアと収益性の両方に深く関わっているという証拠を示している。


ロードマップ

1.今いるところからはじめる。  どのように価値を生み出し、利益を出しているだろうか?

2.最大の制約を見出す。  価値を生み出し、利益を出す能力の足かせとなる、最大の問題は何なのか?

3.最大の脅威を思い描く  長期的に見た場合、価値を生み出し続け、利益を出し続ける能力に最大の脅威となるのは何か?

4.文化を評価する  第一線にたつ作業者やパートナーに対して、深い敬意を抱く文化を確立し、強化する。技術へのプライドを持つことを邪魔すものを排除する。

5.訓練する  チームのリーダーや、監督者、マネージャーに、統率の仕方、教え方、それに、作業プロセスの改善のために規律ある手法を作業者に使わせる方法を訓練する。

6.最大の問題を解決する  最大の制約を作業チームが自由に変えられるようにする。いろいろな試みを繰り返し、最終的に解決への道を見つける。

7.制約への過去の適応手段を排除する  制約に対処するために出来たルールを見つける。新たなルールはどのような内容にすべきかを決定する。

8.計測する  最初から最後までのサイクルタイムや、実際の収益性、実際の顧客満足度が改善されたかどうかを見極める。

9.実現する  成果に裏付けされた変化を取り入れる。

10.サイクルを繰り返す  最大の問題を解決されたら、何か別の問題が最大の問題になる。それを見出し、問題解決のサイクルを繰り返す。

リーン開発_第9章_パートナー

相乗効果

パートナーシップを結ぶのは、コスト削減のためでも、リスク軽減のためでも、また能力向上のためでもない。 パートナーシップが必要となる最大の理由は、相乗効果、人(や会社)が協力し合えば、個人が別々に取り組むよりも、優れた成果が出せる。

オープンソース

オープンソースプロジェクトには、たいていリーダがいる 全てのオープンソースオブジェクトに、「コミッター」がいる。

  • コミッターとは、新しいコードをコードベースにコミットする権限を持つ、信頼された中枢をなす人たち


オープンソースの新しいプロジェクトにボランティアを募集するには、 プロジェクトリーダが魅力的なアイディアを持ち、優れた取り組みをする必要がある。

  • ボランティアを夢中にさせておくには、そのリーダー(後になれば、コミッターのコミュニティ)が出来の良さを認め、感謝し、拍手を送らなければならない。


「いい仕事」とは、非常に小さな単位でシステムにコミットさせる。

  • 簡潔で読みやすいコードをもって、問題を解決すること
  • オープンソースの開発者たちは、ぐちゃぐちゃになったり、壊れたりしたソフトウェアを相手に、時間をムダにしたりはしない。
  • 誰一人として、オープンソース開発者に指図を出していない。
  • 規律のある有能な開発チームとっては、尊敬や信頼、喝采を超える報酬はない。



グローバルなネットワーク

グローバルなネットワークや、分散した作業グループは、 ただ「チーム」という呼び名をつけるだけでチームになるわけではない。

  • チームメンバーが別々のタイムゾーンにいる場合十分にコミュニケーションを取り合えるような手段を用意するのは、非常に重要だが、それだけで作業グループをチームに変えることは到底出来ない。
  • 地理的に離れていようと、同じ場所にいようと、人と人の間で相乗効果を生み出すのが難しいことには変わりはしない。
  • 何よりもまず、チームメンバーが共通の目標の達成に関して、互いに約束し合っていなくてはならない。
  • 互いに約束し合うだけでも難しいが、グローバルなチームの場合、チームメンバー間で効率的なコミュニケーションが取りにくいという、別次元の問題が加わる
グローバルな作業グループから、グローバルなチームへ

地理的に遠く離れた作業グループ同士で、約束を交わし合い コミュニュケーションを取りやすくするために役立つテクニック


頻繁な結合

  • 地理的に隔たりがある小さなチームをいくつか集めて、作業グループを組み立てることは非常に多い。
  • チームの役割がシステムの機能上のアーキテクチャどおりに分割されているのであれば、チームは、ある程度独立して、別々のモジュールに取り組める。
  • これが非常に効率的な構造となることもあるが、入れ子にした同期を行って、作業の成果を頻繁に結合しなくてはならない。
  • 定期的かつ頻繁に統合を行えば、結束が強まったり、知識の共有データベースが作り出せたりと、いろいろなメリットが生まれる。
  • コードベースを通じて、知識を早く伝達すれば、それだけコードがわかりやすくなり、プログラマテストで各ローカルチームの意図がうまく伝わるようになり、それを組み合わせた成果もより優れたものになる。


人の交換

  • ある国のひとつのチームが、システムの開発に必要な、すべての技術力を持っていることがよくある。
  • 彼らへの「要求」は、遠く離れたタイムゾーンで書かれたドキュメントというかたちで、大きなバッチで送られてくる。
  • 要求の到着から数週間後、あるいは数カ月後、アプリケーションが完成してみると、予想通り、それは顧客が本当に必要としたものではない。
  • 顧客やアナリストと、実装チームとの間に(壁越しのコミュニケーションによる)大きな隔たりがある場合、うまくいくことはめったにない。
  • このような状況に対処するには、一方のチームのメンバー何人か、もう一方のチームに送って、長期的に一緒にやるのがいちばん。
  • メンバーを交代で行かせると、さらに望ましい。
  • 顧客を理解するチームメンバーを何人か、開発チームにつかせてもいいし、開発メンバーを何人か、顧客を理解する人たちにつかせてもよい。
  • 送り込むメンバーを交代させれば、はるかに効率が良くなる。


テストを交換する

  • チーム間で要求を引き渡す際、離れたチームに要求ではなく、実行可能なテストを送り合って対処した例がある。
  • 顧客を理解する人たちは、コードが通るべき詳細なテストを作った。
  • 彼らはそのテストを離れたチームに送り、コードがそのテストを通れば、機能していると見なせる。
  • それでも、毎週イテレーションを完了させて顧客の現場でテストを行わなければ、距離という障害は大きすぎて、離れたところにいるチームが流されてしまい、顧客が本当に欲しがっている物を提供できない。


窓口(Proxy)

  • ある分散チームでは、1人の人物を通してコミュニケーションを取り合って、非常に上手くいっていた。
  • 遠隔地の職場から誰かを出し、中核となっているチームのメンバーになって、離れた職場に残っている人たちの窓口の役割を果たす
  • この人物が毎日、遠隔地のチームに電話をかけて、やるべきことを説明したり、質問に答えたり、完了した成果物を受け取ったりする
  • そして、明確に定義された大量の作業に対する責任を負い、遠隔地にいるチームにそれを送る。
  • このようにして、遠隔地のチームは中核のチームにいる一人の人物と、十分なコミュニケーションをとる
  • また、中核のチームは、遠隔地のチームを数人分の作業を受け持つ。


動き回るチームリーダー

  • あるケースでは、サブチームの置かれた場所ごとに大部屋(戦術ルーム)が1つあり、そこにはプロジェクトの進捗状況と懸念事項を示す大きな図が貼られていた。
  • 進捗図は、世界中の4つの部屋それぞれで、まったく同じように保守されていた。
  • プログラムリーダーが、各地で進捗ミーティングを額て、部屋を一つずつまわる、他の場所のチームは、そのミーティングに電話で参加した。
  • すべてのチームが共通の目標に向けて、新たな約束を交わし合う。


差別の撤廃

  • 他のメンバーは母国語を使っているのに、チームの一部が自分たちの母国語でない言語を使って作業をしなくてはならない場合。
  • あるいは、あるグループは下請けで、ほかのグループは元請けである場合。また、あるグループにほかのグループよりも明らかに高い報酬や地位が与えられている場合。
  • 人は簡単に、あるグループがほかのグループよりも「よい」という認識を持つようになる。
  • そのような認識は、真のチームワークに欠かせない尊敬や信頼や約束を、あっという間に破壊してしまう。



アウトソーシング

アウトソーシングでは、仕事の一部を別の企業に肩代わりしてもらうことになる。 + その企業は、すぐそばにあることもあれば、地球の裏側にある場合もある。 + アウトソーシングによって、距離とはまた別の問題、つまり忠誠の問題がある。


作業者はトレードオフを行う際、自社の利益と相手企業の利益、そして、共同事業の利益に、どのように比重をかけるだろうか? そして、自らの仕事の存続とのバランスを、どのようにとるだろうか?

  • アウトソーシングに関して、最善の合意が取れた時に、これらの問への答えが明確になる。
  • 共同事業社の利益を重視すれば、それぞれの企業と、それぞれの社員に対して、最高の結果となる
  • その点を明確にしてなければ、作業者が水面下での利益の対立に苦しむことになる。


どうしたら、このような利益の対立を回避できるだろうか?

  • その答えは、アウトソースする作業の性質に応じて変わる。


インフラ、事務処理、開発の3つの場合について

インフラ

  • インフラは最もアウトソーシングしやすい
  • インフラに求められる機能は、市場でははっきり定義されており、ベンダーも多く、価格も手頃
  • 技術的には自前でインフラを構築することも可能だが、それに費やす時間を考えれば、アウトソースするメリットのほうが大きい。
  • 自分たちでするよりも、上手にコスト効率よくインフラを構築するサービスが提供されているなら、アウトソースを行う意味は十分にある。

事務処理

例をあげると

ある企業で、大量の書類を電子フォーマットに変換しなくてはならないのなら、
書類をスキャンして世界中どこにでも送って、変換すれば良い。


しかし、注意すべき点がひとつある、業界における真の競争優位が、データをいかに電子的に記録し、いかに書類なしですませるかという点にかかっているとしてらどうだろう?

  • 変換をアウトソースしてコストを抑えている企業は、なぜ文章の変換が必要なのかを自問するどう気を失う。
  • 事務処理をアウトソースする前に、まずバリューストリームをシンプルにし、事務処理の必要性をなくす努力をする。
  • 事務処理のアウトソースの利益の対立は、ほとんどの場合、単価制での報酬が原因になる。
  • アウトソース先の企業が、事務処理に応じて支払いを受けるのであれば、1事務処理にかかる時間を短縮するはず。


しかし、事務処理数を減らすことに本当の価値がある場合、単価制の報酬によって、雇用者側への忠誠と、事務処理を生み出す企業への忠誠との間に対立が生まれる。

例をあげると

イギリスの航空会社BMIが富士通にコールセンターをアウトソース
富士通はBMIに扱う通話数を減らすことを示す
同時に、BMIの運用コスト削減できることを示した

そのため、富士通BMIに、見込み通話数に応じた支払いへと変更させることが出来、BMIのコスト削減を手助けすることで利益を得た。

  • 両者にとってよい(Win-Win)パートナーシップ
  • 報酬に対するこの手法は、共同事業の利益を求めることが、全員にとって最大の利益になるということを明確に示した。


開発

  • インフラのアウトソースに十分に意味があるのと同様、一般的な(例えば、購買プロセス)のソフトウェア開発をアウトソースするのにも十分な意味がある。

しかし、この種のアウトソースでは、業界での平均しか手に入らない 通常、同業他社も、同じくアウトソースを利用しているから。

手作業でのテストをアウトソースする企業より顕著な競争優位を、ソフトウェア開発プロセス全体で得ることになる。


製品やソフトウェアの差別化要因になる開発コンポーネントをアウトソースするには、注意が必要

  • この種の開発を完全に社内でしか行わず、競争優位を生み出す根源としている企業もある
  • このような重要な開発部分を、効率的にアウトソース出来るようになった企業もある。
  • アメリカでは、トヨタの自動車部品の70パーセントは、サプライヤが開発・製造している。
  • 従来社内で行われてきた先進的な開発は、他企業とのパートナーシップによって実現されるようになった。


重要な開発部分をアウトソースして顕著な優位を得ている企業は いくつかの基本原則にしたがって動いている。

  • 1.重要な機能のアウトソースは、その企業が保有するよりも幅広い技術力に触れる必要があるため、あるいは、市場理解を広げる必要があるため、あるいはその両方の理由から行われている。
  • 2.重要な機能のアウトソースによって、かならず両者にとってよいパートナーシップを生み出している。  パートナーシップから相乗効果が生まれることを期待するだけではなく、相乗効果を生むようにパートナーシップを管理する。  報酬制度や共同作業の規則、経営目標を通して、作業者に、共同作業への忠誠は自社への忠誠と同等であり、  共同事業の成功が自分たちへの最高の利益になるというサインを送る。
  • 3.企業はパートナーに深い敬意を示し、その敬意がパートナーシップの詳細を定義するプロセスや手続きに組み込まれている。  うまくサプライヤを管理すれば、サプライチェーンが製造業界にもたらしたような、劇的な優位が開発業界にもたらせることになる。  まずは、アウトソーシンがコスト削減のため、リスク削減のため、あるいは能力向上のためだけではない、  ということを認識しなくてはならない。それは、相乗効果を生み出すためでもある。


契約

契約の目的は何だろう?これについては、2つの流派がある。

  • 1.契約の目的は、一方の利己的な振る舞いからもう一方を守ることである。
  • 2.契約の目的は、企業同士が相乗効果を海用に協業を進めるため、適切な報酬を規定することである。

このどちらかを取るかによって、規約に基づくリーンソフトウェア開発が非現実的となるか、 最高の成果の達成を目的として協業を進めるための枠組みを全員に提供するかが決まる。


事例:T5合意

イギリスの空港会社は、ヒースロー空港の第5ターミナルを2002年に着手し、2008年春にオープンした。 そのプロジェクトは巨大で、最初から、この規模のプロジェクトにつきものの、コスト超過や遅れは許容できないとわかっていた。

イギリス空港会社では、T5合意とよばれるものを考案した。 従来の契約に代わる法的拘束力を持つ文章で、建設業界のルールを変える。

  • すべてのリスクを負うことに合意する
  • その代わり、請負業者は統合チームで作業し、リスクを軽減し、再現の成果を達成できるよう出来る限り努力することを合意する。
  • プロジェクトごとに建設会社がつき、合意された目標コストがあり、リスクへの対応や報奨金のための資金プールがある。
  • 請負業者は、時間と資材に応じた支払いを受ける。
  • 再作業が発生した場合にも責任のなすりつけあいになることはなく、再作業分の費用も支払われる。
  • サブプロジェクトが目標コストを超過した場合には、そのサブプロジェクトの資金プールから支払われる。
  • サブプロジェクトの終わりに、それに携わったチームが資金プールに残っている資金の3分の2を分ける。

T5合意は、イギリスの空港会社が確信を持って実施した、まったく型破りなやり方で、リスクと報奨金の両方の課題を解決するための契約形態である。

T5合意は、リスクを抑えつつ、資金の大幅な節約にも貢献している。


事例:PS2000契約

PS2000契約は、ノルウェーコンピュータ協会が、ノルウェー科学技術大学(NTNU)やノルウェーの主要企業、主要公的機関との協力によって開発したもの。 大規模な公共ITプロジェクトに向けに開発されたPS2000契約は、調達や入札の段階でITシステムの詳細仕様を描くのは難しい場合が多い、という所見から生まれた。

  • 1.ベストプラクティスから、多くの大規模ITプロジェクトでの不確実性やリスクには、柔軟な反復型の開発モデルのほうが適しているということがわかる。
  • 2.そのためには、契約者と顧客の共通の理解を樹立するための仕組みが必要である。
  • 3.システムを開発する団体は、顧客の目的やニーズを満たす最善の方法を見つけ出す能力を備えて無くてはならない。

PS2000契約でユニークなのは、提供内容の仕様ではなく、顧客と契約者がどのように協業を進めるかを定めている点である。 契約の本体では、意思決定委員会を作り、意見に相違が生じた場合の調停役に指名し、契約主体の一般的な権利や義務について想定している。

プロジェクト目標や目標コストは、付属文章に書かれる。 契約では、システムを反復的に目標が合意内容に置き換えていく、 目標コストについての付属書類では、余剰資金や超過コストを契約主体がどのように分割するのかを想定しており、全体のコストの下限と上限が決められている。


事例:関係的契約

T5合意もPS2000契約も関係的契約

  • 関係的契約は各当事者の利益と共同事業の利益を一致させることに重点を置いている。
  • その根底には「人は通常、自社の利益を追求するものである」という想定がある。
  • そこで、共同事業で最大の利益を上げることに集中すれば、 各社の利益も最大になるという点を作業者に明確に示すために、関係的契約が作られている。

リーン開発_第8章_品質

フィードバック

古い習慣では生き残れない窮地になってはじめて、より優れた新製品開発手法が必然的に生まれてきた。 そのような、堅牢な開発プロセスにはかならず2つの共通点がある。

1.秀逸ですばやいフィードバック
2.優れた詳しい規律

リリース計画

計画は、市場ニーズ(あるいはビジネスニーズ)、製品コンセプト、目標コスト、
稼働タイミングを見極めるところからはじまる。

  • 1.初期投資期間中には、詳細な長期計画を作らず、短期間でインクリメンタルなリリース計画を作成する。
  • 2.直近の開発についての計画を立て、最も重要な機能を見つけ出し、その土台となるアーキテクチャを確立させる。
  • 3.収益獲得(や投資の回収)のために、最小限の有用な機能セットをもって早期稼働を計画する。
  • 4.定期的に機能を拡充するため、後続のリリースを計画する。
  • 5.初回のリリース目標は、実現可能性を確認し、暫定的なアーキテクチャーを確立する機能セットを開発することである。
  • 6.リリースは、アプリケーションのすべての階層を縦に貫き、全体がどのように組み合わさるのかを示していなくてはならない。


その機能セットは次の点を考慮して選ばなくてはなたない。

  • 1.価値が低い機能よりも、高い機能を先に
  • 2.リスクが低い機能よりも、リスクが高く価値の高い機能を先に
  • 3.すでによく知られている知識よりも、新しい知識を生み出す機能を先に
  • 4.開発やサポートに高いコストがかかる機能よりも、低いコストで済む機能を先に

リリース計画によって、詳細な計画に多大な資金を投入する前に、技術や市場に対する仮設を検証できるようになる。 実装に着手し、進捗をトラッキングすることで、計画の実現可能性を早い時点で見通すことが出来るのである。

リリース計画を実行に移してみて、最初のリリースでスケジュールから遅れたとしたら、その計画は強引すぎるということだ。 この時点では、ビジネスプロセスや開発中の製品を単純化したり、その機能を実装する技術的手法を単純化したり、その機能をそっくり削除してしまうのがいい。

一般的にイテレーションやリリースの決められた「時間枠(タイムボックス)」を守り、その時間枠内で実装を完了できる機能に制限するのが最善の取り組み方。


アーキテクチャ

  • 開発中の機能セットでの必要に応じて開発してくべきである、と主張している。

成功した寿命の長い商品では、新しい適用領域が発見され、当初のアーキテクチャーではまっく思い描いてなかった機能が必要になったら、3年に1回ぐらいは大幅なアーキテクチャー改善があるかもしれない。 もう、「アーキテクチャーは、あらゆる開発に着手する以前に、完全でなくてはならない」という神話は捨てなくてはならない。


イテレーション

  • 反復開発は、一定のリズムで、徐々に技術的進歩を同期させていく開発スタイル。

まず、バックログ(求められている機能の優先順のリストに簡単な説明をつけたもの)がある。 機能を実装する少し前に、顧客のドメインや技術を理解しているチームメンバーが機能を分析、ストーリーに分割する。


ストーリーとは

  • 2〜3日程度で確実に完成できると考えられる開発単位のこと。

計画ミーティングでは、チームが次のイテレーションでいくつかのストーリーが実現できるのかを、それまでの記録(速度)を基にして見極め、そのストーリーの完成を約束する。

イテレーションの間は、チーム全体が毎日短時間ずつ顔を合わせて、イテレーション計画の進みがどうなっているのかを話し合ったり、実装するという約どくを果たすための軌道確認をしたりして、お互いに助け合う。

イテレーションの最後のは、ストーリーが完成していなくてはならない。 結合し、テストし、ドキュメントを作成して、使用できる状態にする。

レビューミーティングでは、進捗の成果をデモし、フィードバックを得るために行う。 フィードバックは、ストーリーやバックログへの変更としてまとめる。

何度かイテレーションを繰り返せば、有用な機能セットは完成し、導入可能となっている。


準備

  • バックログ項目は、最初は大まかな内容の箇条書きである。大まかには理由がある。

リーン手法とは

詳細な分析を、対応に間に合う最後の瞬間まで遅らせる手法なので、項目は、優先順位の上位にいけばいくほど、より小さい、より管理しやすい断片へと分割していかなくてはならない。

バックログ項目は

  • その設計が1つ以上のストーリーとしてまとめられるまで、開発できる状態ではない。
  • 各ストーリーを実装する人たちは、ストーリーをはっきり理解し、その実装作業を確実に見積もることが出来なくてはならない。
  • 確実に提供するには、確実な見積もりが必要、各ストーリーは、ビジネスの視点から、なんらかの明確な価値を備えていなくてはならない。
  • ストーリーの規模を決める基準は、それにかかる実装作業量
  • 通常は、1.5〜4日分の作業のストーリーにする。
  • 製品を設計する人たちは、ストーリーの価値がその実装コストに見合うものかを見極めなくてはならない。
  • 通常、ビジネス目標に関連した用語で表現
  • ハイレベルな目標は、ストーリーというより、叙事詩(じょじし)のようになる。
  • 項目が優先順位の上のほうに来ると、顧客の仕事をよく理解しているチームメンバー(プロダクトオーナー、アナリストなど)が、叙事詩からストーリーへの分割作業を統率する。
  • 本質的なユースケースと懸念ドメインモデルの組み合わせや、ビジネスルールやポリシー、ユーザインターフェース(UI)プロトタイプ文書のような、標準的な分析テクニックは、製品設計のこの分割作業を考える上で効果的。
  • ユースケースが複雑で、関連するインターフェースやルール、永続化などを含めた場合には、1つのユースケースが数個のストーリーとなり、一度のイテレーションではそのユースケースの主要なシナリオを実現できない場合もある。

イテレーション準備の目的は

  • 次に開発されるはずの製品「全体」の一部を設計すること。
  • ビジネスルールやポリシー、ワークフロー、機能性、インターフェース設計について決定しなくてはならない。
  • この設計活動によって「ちょうど十分」で、注意深く考えられたストーリーを次のイテレーションに「ジャストインタイム」で作り出す。
  • 優れたストーリーは、きちんと定義された実装作業の単位になり、確実な見積もりを出したり、次のイテレーション内で完成させたり出来る程度に小さいもの。
  • 目的は、製品全体について、広範にわたる分析ドキュメントを作ることではなく、実装を行う人たちにビジネス上の意図を明確に伝えるために、サンプルとなるテストを十分に提供すること。

計画

  • イテレーションのはじめに計画ミーティングを開く
  • チャンピオンやプロダクトオーナーと協力し、チーム全体で、最優先のストーリーを開発、テスト、文書化、導入(あるいは導入準備)に必要な時間を見積もる
  • チームメンバーは最初のストーリーを選んで、その完成を約束
  • 2番目のストーリーを選んで、こちらも提供を約束できるのかどうか、判断する。
  • このプロセスは、チームメンバー次のストーリーを提供できるかどうか、確信を持てなくなるまで行う。
  • チームメンバーは、イテレーションの間位に実装すると合意した機能セットのテーマを表すイテレーション目標を約束
  • どの程度の作業が必要になるのかは、別段教わらなくても、2〜3回イテレーションを回せば、各チームが速度(ベロシティ)を確立するので、この値を見れば、チームが一度のイテレーションでどの程度の作業を済ませられるのか、全員が検討をつけられるようになる。
  • チームメンバーはその約束を、目標達成のために1つのチームとして協力し合うという成約であるとみなす。
  • ときには、チームが多くを約束することもあるし、技術的な問題が持ち上がるかもしれない。そのような場合、チームは適切に状況に対応し、多くの約束しすぎた根本原因を見つけて、再発防止のための対策を取らなくてはならない。

実装

  • イテレーションの間、チーム全体がイテレーション目標を達成するために協力し合う。
  • 全員が毎日、10〜15分のミーティングに参加し、一人ひとりのメンバーが前回のミーティングで以降に何をし終えたのか、次のミーティングまでに何をする予定なのか、どのような問題を抱えているのか、どの部分で手助けを必要としているのかを話し合う
  • このミーティングでチームが対話することによって、個々のメンバーは、チームの目標を達成するために次に何をしないといけないのかが、教えられなくてもわかるようになる。


お勧めの手法:ストーリーテスト駆動型開発

(受け入れテスト駆動型開発とも呼ぶ)

  • 一度に1つのストーリーに取り組むのだが、チームメンバーは機能的な詳細やワークフロー、ユーザーインターフェースの設計に重点的に取り組み、開発者と協力して、その製品に必要な振る舞い(ビヘイビア)を、テストケースの形式で的確に表現
  • このような議論により、関係のある変数や、適用できる方針、そのドメインのビジネスルールが確定していく。
  • この共通の言語を使って、入力や手順ときたいされる結果の形で振る舞いを定義する。
  • 何人かのチームメンバーが十分な件数のテストケースを出していく間、開発者はテストケースからアプリケーションへのインタフェースを作り、そのテストケースが通るコードを書く。
  • 開発者が、不明点を確認し詳細情報を知る必要が出てくれば、顧客ニーズを理解するチームメンバーがそれについて議論し、そこで合意した内容を記録するためのテストケースを定義する手助けをする。
  • テストケースをすべて集めれば、事実上、非常に詳細で、自己検証的な製品設計仕様書になる。
  • ストーリーテストによって仕様が示された振る舞いを実装するために、開発者は単体テスト駆動型開発を利用
  • コードを見て、ストーリーテストの目的に貢献するシンプルな振る舞いを選ぶ
  • その振る舞いを実装するため、開発者は適切な名前をつけたオブジェクトやメソッド、メソッドの引数を決める。ストーリーテストで使われている名前と一致する名前を選ぶようにする。
  • 開発者は単体テストを書くことによって、設計上の決定を文書化しておく
  • 単体テストは、新しいコードが意図されたとおりの振る舞いをするようになるまでは失敗する。
  • それ以前のテストを失敗させることなくこのテストが通りように、簡単なコードを書く
  • 最後に、新しいコードを加えたコードベースをチェックし、リファクタリングによってコードの重複を取り除いたり、理解しやすいように単純化したり、コードの意図を明確にしたりして、コードベースの設計を改善。開発者はこのサイクルを繰り返し、ストーリーテストを通るまで、振る舞いを追加していく。ストーリーテストが通ると、次のストーリーに取り掛かる。

毎回のイテレーションの終わりに、完全で「リリースできる」機能が出来ているのが目標

評価

  • イテレーションの終わりにレビューを開く
  • レビューによって、何かを変更しなくてはならないことになった場合、小さな問題であれば、新たなストーリーにし、大きな問題であれば、バックログに入れて、他の項目に照らして優先順位をつける。
  • それ以上は手間を掛けずに、次のイテレーションの計画ミーティングへ移る。
  • チームが学習していくのにあわせて、テスト一式も新たに生み出された知識を表現すように、適応していかなくてはならない。
  • 目を見張るべき点として、テストによって変更のコストが非常に低くなること
  • 誰かが以前の設計上の決定にうっかり反してしまったら、すぐにテストが失敗する。
  • それによって、チームがそのコードを直すのか、あるいはその設計を表現しているテストを更新するまで、ラインストップをするように警告を発する。


応用:ユーザインターフェース

  • ほとんどの組織では、実用に際して、自分たちの状況にあうように反復型プロセスを修正している
  • 修正が必要となる可能性の高い、特別な状況のひとつが、ユーザインターフェイス(UI)開発
  • イテレーション中、UI設計者にはいくつかの仕事がある。

  • 1.今後のイテレーションのための顧客データ収集

  • 2.前回のイテレーションで開発されたUIのテスト
  • 3.現在のイテレーションで、コーディング中に出来た質問への回答
  • 4.次回のイテレーションで実装されることになっているUIの詳細設計

UI設計を実装する前に、顧客データを収集し、プロトタイプでさまざまな選択肢をテストし、実装準備が整った詳細設計を確定する。 商用コードのユーザービリティテストは、実装よりも1つ後のイテレーションで行われる。


5S(ごえす)

  • 5Sは、必要になったときにあらゆるものがすぐに使える、余計な混乱のない職場を編成するための、古典的なリーンツールである。

「S」は日本語でSから始まる5つの言葉を指す。

  • 整理(Sort)
  • 整頓(Systematize)
  • 清掃(Shine)
  • 清潔(Standardize)
  • 躾(Sustain)

ソフトウェア開発の職場の5S


整理

  • チームのワークステーションやサーバにあるものを整理し、もう使われることのない古いソフトウェアバージョンやファイル、レポートを見つけ出す。
  • 必要ならバックアップをとってから、消す。


整頓

  • デスクトップのレイアウトやファイル構造は必要である。
  • 論理的な編成で、見つけやすいように作られていなくてはならない。
  • 2人以上で共有して使っている作業スペースは、チームで決めた共通のレイアウトに沿うようにし、どこにログインしても必要なものが見つけられるようにしておかなくてならない。


清掃

  • 空き缶やコーヒーカップを捨て、モニターの指紋を拭き取り、書類を片付けよう。
  • ホワイトボードは、重要な設計が描かれていたら写真に収めてから、キレイに消す。


清潔

  • 自動化や標準化を実施して、すべてのワークステーションに常にツールの最新バージョンがあるようにし、定期的にバックアップを行って、いろいろなゴミが溜まらないようにする。


  • これであとは、その規律を守り続けるだけ。



Javaの5S

整理

  • コードベースのサイズを小さくする。
  • 不要なものは捨てる。
  • 使われていないコードを除去する。
  • 使われていないimport文を除去する
  • 使われていない変数を除去する
  • 使われていないメソッドを除去する
  • 使われていないクラスを除去する
  • 冗長なコードをリファクタリングする


整頓

  • プロジェクトやパッケージを整頓する。
  • すべてのものの置き場所を決めて、そこにそれぞれきちんと置いておく。
  • パッケージ間の依存関係の解決
  • 依存関係の最小化


清掃

  • きれいにしよう。
  • 全てがきちんと、キレイになっていれば問題はもっと見つけやすくなる。
  • 単体テストの失敗やエラーを解消する(成功=100パーセント)
  • 単体テストカバレッジを向上させる(80パーセント以上)
  • 単体テストの効率を向上させる
  • 全テスト実施時の効率をチェック
  • Checkstyleの警告を解消する
  • PMDの警告を解消する
  • Javadocの警告を解消する。
  • TODO(やるべきこと)を解消する


清潔

  • 一度キレイにしたら、綺麗なまま保とう
  • 保守を楽にするために、時間の経過とともに増していく複雑さを減らそう。


  • 標準的な手順を用いて、それに従う。


標準

標準があれば、反射的に対応できるようになり、変換というムダなしに情報を移動させられるようになる。 共通のアーキテクチャーを持つ標準化されたインフラストラクチャによって、複雑さが減り、その結コストも低く抑えられる。

早く進みたい組織には、かならず有効な標準がある、ソフトウェア開発組織が考慮すべき標準を紹介

もちろん、標準は決めるだけで役に立たない。 一貫して適用されなければ、標準には価値がない。 リーンな環境では、標準はある仕事をするための、現在の最善方法として捉えている。

どんな場合でも、よりよい方法があるという前提なので どんな標準にも、誰でも積極的に異議を唱えていい。
よりよい方法が見つかって、そちらの方法のほうが効率的だとわかったら、それが新たな標準になる。 標準に従い、標準を絶えず変えていくという規律は、組織の骨格の一部である。


コードレビュー

コードレビューでは、別の問題に着目しなければなたない。

例えば
経験の浅い開発者のコードをレビュー

  • シンプルになっているのかどうか
  • 変更を受け入れやすいか
  • 重複がないか
  • その他の優れたオブジェクト指向の設計原則に従っている

などの点をチェックを行う。 コードレビューは。複雑さなどの問題意識を高めるためにも適切なツールになる。


ペアリング(ペアプログラミング

コードをチェックインする前に、レビューを行わなくてはならないという 決まりにすると、レビュー待ちの未完成の作業が累積してしまう場合もある。
リーンな環境では、そのような事態はなんとしても避けなくてはならない。 遅れをだすとこなく、コードレビューを行うひとつの方法として、ペアでコーディングを行う。

ペアプログラミングを行うことで

  • 一度にまとめて、コードレビューをするのではなく、流れの中で継続的にコードレビューを行っていく。
  • ペアリングは、上手に使うと非常に有益なものになる。
  • ペアになって開発を進めれば、学習効果やチームワークを、問題解決能力が高まる。
  • ペアになって2組の目で見ることによって、コードの品質と堅牢性が改善され、生産性が上がることが多い。
  • ペアになっていると、中断をうまくかわし、お互いをタスクに集中させておける。
  • ペアリングによって相乗効果が生まれる場合が多い、2人が協力し合えば、それぞれが別々に作業を進めた場合に比べ、より統合され、よりテストされ、より欠陥の無いコードが作り出せる。
  • ペアリングは、未完成の作業という在庫を積み上げることなく、レビューの効果が得られる最高の方法のひとつ


ポカヨケ

間違った人が悪いのではない、間違いが起こりそうな部分にポカヨケを施さなかったシステムが悪い。 ソフトウェアでは、失敗する可能性のあることは、実際に失敗する
個人の「責任」で起きた欠陥を数えていって、もっと注意深くなるようにプレッシャーをかけても、時間のムダ。 欠陥が見つかったら、その度にラインストップし、根本原因を見つけ出し、今後、同様の欠陥が防げる方法を考え出そう。
開発チームは、コードにポカヨケを施す効率的な方法について、広い視野で考えるべき。 テストや運用の担当者たちも参加させて、潜在的な障害発生地点を見極め、欠陥が起きる前にポカヨケを入れるようにする。


自動化

自動化をすることで、人為的なミスを防ぐだけではなく、人の知能に対する敬意を示すことにもなる。 繰り返しのタスクは、間違いのもとになるだけではなく、人をロボットのように扱ってもよい、という考えの現れ。 人であれば、よりよい仕事の進め方や問題の解決方法について、考えをめぐらせるべきである。


自動化の例
  • 1.ワンクリックビルド ビルドの自動化が第一歩である。 ビルドの後には、何かが壊れていないのかを確かめるために、自動テスト一式をキックする。 多くのチームでは、Antを使っている。

  • 2.定期ビルド ビルドがクリックひとつできるようになったら、簡単にスケジューリングできる。 時刻やコードのチェックインをトリガーとして、ビルドを実施 CruiseControlがよく使われる。

  • 3.ビルド結果の通知 誰にでも結果が知らされてないのであれば、ビルドをしても意味がない。 ビルドが失敗したら、メールで通知するようにするのが簡単でよい。 赤札をあげたり、赤いラバランプを点灯させたりして、全員にビルドの失敗の警告を出すのが良い。

  • 4.ワンステップリリース リリースには、リリースブランチを作成し、コードをダウンロードしたり、CDに焼いて配布できる形式の、ファイルやファイル一式にパッケージングするという作業が含まれる。 上記は、絶対に自動化すべきプロセスであり、そうすればエラーなど起こるはずがない。

  • 5.確実なインストール 配布ファイルが顧客の手元に届いたら その後のインストールプロセスは、手助けのために誰かを現場に出向かせるとしても、自動化されているべきである。 配布メディアには、インストールが失敗したとき(もし失敗したら、ということではない)に役立つ、簡単な診断ツールを含めておくことも出来る。


テスト駆動型開発

テストには2種類存在する。

  • 1.欠陥の発生後にそれを発見するテスト
  • 2.欠陥を予防するためのテスト

テストに求められているのが、欠陥の発見ではなく予防なのであれば、通常私たちが行っている様々な種類のテストにおいて、それがどういう意味になるのかを考える必要がある。


ブライアンマーリックは、テストを4つの視点から見るように提案

テストに2つの目的がある。

  • 1.プログラマの仕事を支援
  • 2.同時にそのソフトウェアが組み込まれる製品全体を評価

技術的な観点からと、ビジネス的な視点の2つの視点で行われる。 これで4つの一般的なテストカテゴリーが出来る。


それぞれのカテゴリーは以下の通り

単体テスト(プログラマテスト)

  • 単体テストは、開発者が自らの設計の意図をコードが実現している事をテストするために書く。
  • 開発者が単体テストを最初に書くと、テストからコードの設計が発展していくこと、そして、単体テスト一式が事実上のソフトウェア設計仕様になることに気づく。
  • 最初にテストを書くと、通常は設計がシンプルになる。
  • テスト可能なコードを書いていると、コードの結合度が弱くなるからこの好循環のおかげで、開発者がテストファースト開発をはじめると、それ以外の方法でソフトウェア開発したがらなくなる。
  • 単体テストを選び出して、ビルド時に走らせるテスト装置(testharness)にする。
  • ビルド時にのテスト一式はすばやく動かなくてはならない。
  • ビルドとテストは10分以内で完了すべき、これ以上長くなると開発者たちは使わなくなる。
  • ビルド時のテスト一式でテストするコードは、実行スピードを上げるために、モックオブジェクトを使って、データベースと切り離されることが多い。
  • 単体テストは、プログラマーテストと呼ばれる場合もあるが、それは、プログラマー単体テストのツールをコードの小さな部分以上のものをテストするために使っているため。
  • 単体テストのツールは、単体、機能、システムなど、どのレベルでのテストでも用いられている。


ストーリーテスト(受け入れテスト)

  • ストーリーテストは、システムのビジネス側の意図を示している
  • 顧客の仕事をこなす際に、ソフトウェアが適切に顧客をしえんしているかどうかを見極めるためのテスト。
  • コーディング前にストーリーテストが書かれていると、顧客の仕事にどんな作業が含まれているか、そしてそれをどのようにソフトウェアで支援していくことになるのかを、全員がじっくり考えるのに役に立つ。
  • チームは、システムが何をしなくてはならないかを示す例を通して、作業を進める
  • ストーリーテストは、実例より示される仕様書になる
  • 前もって仕様を書くなら、実行可能な形式にしても良い、後でテストを書くムダや、コードが仕様どおりになっているかを確認するムダが省ける。
  • 自動のストーリーテストは、ユーザインターフェースからは実行されない
  • 一般的には、ユーザインターフェースよりも下で実行される。
  • これを実現するには、ユーザーインターフェースは、非常に薄いプレゼンテーション層でなくてはならず、すべてのロジックやポリシーはそれよりも下の、独立してテスト可能な層になくてはならない
  • 通常の残りのユーザインターフェース層は、ビジネスロジックから独立して、完全にテストが出来る
  • ストーリーテストは、自動化し、現実的な範囲で出来るだけ頻繁に実行すべき
  • 通常、ストーリーテストはサーバやデータベースを必要とするため、ビルド時のテスト一式には含まれない。
  • ストーリーテストをいくつか選び出したものを毎日実行し、さらに完全に近いテスト一式を毎週実行すべき。
  • そして、イテレーションの最後にはすべてのテストが成功しなくてはならない。


ユーザビリティテストと探索的テスト

  • ユーザビリティテストや探索的テストは、その性質上、手作業で行うテスト
  • 自動テストを通ったら、システムが求められているとおりの挙動をしているというこになる
  • ユーザビリティテストは、実際のユーザがシステムの試験を行う
  • 探索的テストは、経験を積んだテスト技術者たちが、境界条件や予期せぬ入力に対するシステムの挙動をチェック
  • 探索的テストによって、コードのもろい部分が発見されたら、開発者たちに何をすべきかを示すテストを書いて、テスト装置に加えなくてはならない。


特性テスト

  • 特性テストには、応答時間や拡張性、堅牢性など、いわゆる非機能要件へのテストが含まれる。
  • 負荷をかけた状態でシステムをテストしたり、セキュリティ問題をチェックしたりするための専用ツールがある
  • 考えられるシステムの構成をすべてテストするための、連結テストを生成するツールもある
  • ツールが自分たちの環境に適しているようなら、時間や労力を割いて、ツールを使いこなさるようなると良い
  • 開発プロセスの初期段階でそのようなツールを使ってみる
  • 実際の操作条件に出来る限り近い環境でも使ってみる


構成管理

構成管理は、どのようなソフトウェア開発でおいても、中心に位置する規律

  • 1.コードのどの部分あっても、一度に数人が手を入れられる
  • 2.リリースが小規模で、頻繁である
  • 3.ある機能セットが商用リリースされる間に、新機能が開発されている
  • 4.コードベースの全体に絶えずリファクタリング(継続的な改善)が行われる

構成管理システムは、コードを変更しようとしている人たちにコードを貸し出して、コードが返ってきたら新シバージョンを正しくリファクタリングする、図書館員(ライブラリアン)のような役目を果たす。

コードのリポジトリはだけでなく、ドキュメントやテスト結果の管理にも利用できるため、規則の厳しい環境では特に有用。 どのような開発組織にも、組織内での用途に合った構成管理システムがなくてはならない。 そのシステムの使い方もきちんと定めておく。


構成管理システムの用途の典型的なシナリオをいくつか紹介

シナリオ1
  • 開発者が個人の作業スペースにファイルをチェックアウトする
  • そこで、変更を行い、コードをチェックインする直前に、各自のマシン上にある最新コードとマージして、個人環境でのブル度のテストを行う
  • すべてがうまくいったら、新しいコードを構成管理システムにチェックインする
  • それをトリガーとして、統合環境でのビルドのテストが行われる


シナリオ2
  • リリースのタイミングで、そのリリースに入るすべてのコードを含めたブランチが作られる。
  • 開発者はメインのコードベースに新機能を続ける
  • リリースのテストや保守の間に行われた変更はすべて、できるだけ早く、メインのコードベースにマージされる(コードがイテレーションの一部としてリリースされたり、修正なしにブランチが導入されたりする場合には、このシナリオは不要)


継続的な統合

  • コードが個別の作業スペースにチェックアウトされたり、別のブランチに分けられたりすると、からなず2つのコード系統で不一致が発生する。
  • 別々のコード系統として存在する期間が長ければ長いほど、その不一致大きくなる。
  • 頻繁に統合すればするほど、初期問題を捉えやすく、その原因を特定しやすい

ただ、開発者は開発スピードや都度起動するテストによって、開発時間をが削られることを嫌い、そのような理由から、コードベースに統合する前に、大量にコードを溜め込んでおこうという気になる。


  • 統合の間隔をあけても逆効果である

しかし、一度ソフトウェア開発チームがすばやいビルドや継続的な統合を実現する方法を見つけ、問題発見時にただたちにその対処のために、全員が誠実に作業を中断できるようになれば、神業に匹敵するほどの効果が得られる。
これが非常に実践しづらい規律であることは、いくどとなく言われてきたが、いったん上手く言ってしまえば、誰も古いやり方に戻そうとは考えないはず。


入れ子になった同期

  • 独立したチーム同士で、サブシステムを結合しようとした場合、何が起きる?

変更されることもないのだから、最終的にサブシステムが結合される段階になっても、なんら問題が起きないはず。 だが、現実はそのようにうまくいくことは殆どない。

事実、開発プログラムを締めくくりでのサブシステム結合の失敗が、スケジュールのずれ込みやコスト超過、プログラムそのものの失敗の、最大の原因の一つになってきた。


  • ソフトウェアを木と考え、サブシステムを枝と考えれば、どこに問題があるか、大体見当がつくと思う。

通常、枝をそれぞれ別に育てて、それから木の幹に接ぎ木しようとはしない。 サブシステムは生きた幹から育てていくべき、幹にあたるシステムがないのなら、それを最初に構築すべき。 それからサブシステムを有機的にシステムと結合させれば、最後にすべてを接合させようとして気を揉む必要もない。


  • 別々のコード系列についての法則は、より大きなサブシステムでも当てはまる。

インターフェースを定義して、それが上手く動くのを期待するのではなく、実際にまずインターフェースを定義してそれを動かし、それからサブシステムを構築して、現実的な範囲でできる限り頻繁に統合すべき。


実際に行うとした場合

  • 継続的に統合から手を付ける
  • 開発者が、一日に何度かコードをチェックインする
  • それが、トリガーとなって、自動のビルドとテストが行われ、細部にいたるまで、依然としてすべてが同期した状態にあるかどうかを検証する。
  • 受け入れテスト装置は、夜間に実行
  • さまざまな構成やプラットフォームのテストは、週末に行う
  • イテレーションごとにコードベース全体を同期し、「リリース可能な」状態にする
  • 他のサブシステムや、ハードウェアとの同期を行う場合もある。
  • リリースごとにコードを導入し、顧客と同期する


大規模システムや分散開発チームの場合

  • 入れ子になった同期がさらに欠かせないものになる
  • 継続的にコミュニケーションをとり、定期的にチーム全体の知識を1か所集積させるための基盤となる。


密接な関係を持つサブシステムに取り組むチーム間では

  • 共通のコードベースから離れて作業を進め、お互いの作業を同期すべき。


主要なサブシステムは


大規模プロジェクトでは

  • システム全体を現実的な範囲で出来るだけ頻繁に同期すべき

リーン開発_第7章_知識

ラリー社の事例

少しづつ反復的に考えられるようになることが、アジャイル的な考え方の重要な指針になる。

  • 開発は受け入れテスト駆動型であるべき。
  • アプリケーションの規模が大きくなっても、技術をアジャイルに保つには、それしかない。
  • 重要なのは、何が負債を生むのかを理解すること、追いつくために速度を落とすこと、そして、先が長いことを理解すること。
  • 知識を作り出す最善の方法を強調している。
  • つまり、会社おの成功の邪魔になっている最大の問題点を見つけて、社員全員をその問題解決方法発見に集中させる。
  • 一歩づつ前進し、どこまで進んだのかを確認し、何度も何度もそれを繰り返す。
  • それを全員の仕事の本質にするといい。


問題は具体的には何ですか?

トヨタ生産方式が開発された頃、トヨタには豊富な資金もツールもなかった。

ただ、単純な、目標が4つあった。

  • 1.可能なかぎり最高の品質とサービスを顧客に提供する。
  • 2.お互いを尊重し合い、協力し合って、社員一人一人の潜在能力を開発すること。
  • 3.どのようなプロセスかたもムダを排除し、コスト削減につなげること。
  • 4.市場の変化に対応できる、柔軟な製造現場を作り出すこと。


多くのリーン活動が失敗してきた根本的な原因の古候補は

  • 1.リーン手法の実践において、基本的な問題の解決よりもツールやプラクティスばかり重視していること。
  • 2.リーンのトレーニングが、自然な作業チームの問題解決スキルよりも、スタッフをスペシャリストとして育成することに重点をおいていること。

リーン活動は「どのように利益を出すか」を明確に思い描き、その邪魔になっている最大の問題を的確に理解するところから始めなくてはならない。


科学的思考法方法

科学的方法とは

  • 1.現象や現象群を観察し、記述する
  • 2.その現象を説明する仮説を立てる。
  • 3.その仮設を使って、ほかの現象や新たな観察結果を予測する。
  • 4.実験して、予測が正しいかどうかを確かめる
  • 5.実験が仮説どおりになれば、理論や法則として認められる場合がある。
  • 6.実験の結果が仮説と異なれば、取り下げるか修正をしなくてはならない。

作業チームには、すべての観察、仮説、実験そしてその結果の記録が求められている。
少なくとも、失敗した実験からも、問題の解決策発見によって生まれた知識と同じ量の知識が作り出されているのだ。


知識を記録する

反復開発の最大の問題点は何か?

  • 試したことをすべてを記録できないこと。また同じところに戻って、何度も同じ教訓を学習し直す。
  • 人は学習した内容を忘れてしまう。
  • 一人一人が学習したことを覚えていたとしても、使いやすい形で残しておかなければ、組織はその学習内容を役に立てられない。
  • 発明家のノートは、発明家自身や同僚が定期的にチェックするなかで、簡潔にまとめられ、図やグラフが散りばめられていく。
  • ソフトウェア開発では、ソフトウェアに埋め込まれた知識を文章化するために、厳密かつ簡潔でちょうどよい組み合わせがテストとコード。
  • 開発中の製品で、決定に至るまでに試した実験や調査した選択肢は、簡単に忘れられてしまう。
  • なぜなら、決してソフトウェアという形にならないからだ。
  • 書き留めて置くだけでそれが知識にあるとは限らない。
  • また、文章化しておなかった場合と同様、多すぎても、情報は膨大なドキュメントの底に簡単にうずもれてしまう。
  • 知識はそこにかいてある内容を必要な人のためのことを思って考えて、書かなくてはならない。


レポートの書き方

トヨタのエンジニアたちが入社時に書いている A3レポートについて

問題解決のためのレポート

  • 問題の要約
  • 根本原因分析
  • 対策の提案
  • 予定されている実験
  • 計測結果とフィードバック

知識共有のためのレポート

有用な機能のミニマムセット

  • ソフトウェアが行うべき顧客の作業についての説明
  • 顧客/開発組織への経済的価値
  • 機能セットが完成すると顧客は何ができるようになるのか
  • 含まれているものと含まれていないものを示す図
  • 他のシステムとの相互作用を示す図
  • 理想的なスケジュール

顧客の目標のため


ジャストインタイム

  • 決定を下さないと行けない場合 まず、いつその決定を下さなくてはならないのかを見極めなくてはならない。それから、決定を下すその時まで待つ。

その時、タイムリミットを越してはならない。 そんなことをしたらなにかに衝突してしまうかもしれない。

製品開発プロセスを指導する際には、製品開発とはすなわち学習することであり、決定を遅らせれば遅らせるほど、多くを学習出来ることを認識していなくてはならない。

実験もせず、フィードバックも得ないなら、学習していないのと同然。
つまり、どのようなソフトウェア開発プロセスであれ、その目的はソフトウェアに組み込む知識を生み出すことなのである。


集合ベース設計

  • 影響が大きく、撤回できない決定を下すのに適した手法

集合ベース設計とは

会社に大災害がおきたと想定 すぐに対応しないといけない2点が発生

  • 1..絶対にずらせない締切がある
  • 2.締め切りに間に合わないという選択肢はない。


絶対に成功させたいのであれば、対応のために3つの開発チームを配備するとよい
  • チームA その締め切りまでに絶対、間に合わせられるシンプルな対応策を開発させる。
  • チームB すべてが順調に運べば間に合わせられるかもしれない、もう少しまともな解決策を開発させる。
  • チームC 理想的な解決策を開発させるが、締め切りに間に合う見込みは薄い


締切期日になったら、解決策が出来ているはずであり、それはその時点で最高のものであるはず。 さらに、締め切りが前倒しになってもなお、きちんと動く解決策が用意できる。

逆に締め切りが後ろ倒しにずれた場合には、最適の解決策が完成しているかもしれない。
プロセスがするなら、企業はまず解決策Aを実施するところから始め、解決策Bに切り替えて、最終的に解決策cに移行すれば良い。


リファクタリング

リファクタリングの背後にある原理は次のようなものがある

  • 1.必要になるかどうかわからないうちに機能を追加すれば、複雑さが増し、ソフトウェア開発で最悪の形のムダになる。ゆえに、ほとんどの機能は徐々に追加していくべきである。

  • 2.機能追加や既存のコードベースへの変更を行う際には、複雑さを加えないことが非常に重要である。

  • 3.リファクタリングによってコードベースの複雑さが軽減され、設計がシンプルになる。それによって、複雑さを最低限に抑えて、新しい機能が導入できるようになる。


リファクタリングには、自動テストへの積極的な取り組みが必要になる。
コードベースの複雑さを軽減するための変更を開発者が行う場合、予期せぬ欠陥を招き入れないと確信できるようなツールが手元になくてはならない。
設計をシンプルにしているうちに、うっかりコードベースに入り込んでしまった欠陥をつかまえる、テスト装置が必要。 継続的なインテグレーションや、欠陥が見つかった瞬間でのライン・ストップも必要。

自動テストや継続的なコードベースの改善、それにまつわるテストに投資した時間と労力は、ムダの排除と複雑さの軽減に費やした時間。 リファクタリングは、広告の売り文句のように「損せずに得する」もの。


レガシーシステム

ビジネスや技術の変化に比較的適合しにくい、変化しにくいシステムが、ソフトウェア開発の世界では「レガシー」のレッテルが貼られる。

レガシーシステムへの対処には、3つの方法があると述べている。


  • 1.書き換えて捨ててしまう。 レガシーシステムを書き換える際には、そもそもレガシーシステムが変更を受け付けなくなった元凶である。
    複雑さを取り込もうとする場合が非常に多い。

  • 2.リファクタリングを手なずける。 リファクタリングという手法のほうが適している場合が多い。
    リファクタリングにはテストの装置が必要ようとなる。 コードに期待されているビジネス上の振る舞いの一例を表現する、受け入れテスト(ストーリーテスト)を作る。
    参考文献として、「WorkingEffectiveWithLegencyCode」 はレガシーコードをリファクタリングする上でのバイブルと呼ぶに相応しい書籍。

  • 3.覆い尽くす。 レガシーコードを覆い尽くすには、レガシーコードの一部を修正する度に、覆うコード(と自動テスト)を加えていく。
    変更が必要な振る舞いをすべてせきとめて、古いコードの代わりになる。古いコードの代わりになる新しいコードに送る。 その間、資産を新しいデータベースに移動させる必要も出てくる。
    実際に使われていた古いシステムがすべて入れ替わるまで、徐々に新しいコードとデータベースを構築していく。


問題解決

  • 秀逸な組織の証しは、問題がないことではなく、組織がシステムとして問題が無いことである。
  • ソフトウェアの特異性に悩む人達に、対処法を提案しなければ、ソフトウェア開発プロセスには何の意味もなく、どのようなチームにも、行く手の困難を体系的に発見し、対処するための時間が、定期的に確保されるべき。


規律ある手法

問題解決に規律ある手法を用いることで、
チームには希望的観測から抜け出し新たな知識や特定の対策、恒久的な成果を手にする。

  • 1.問題を定義する
  • 2.状況を分析する
  • 3.仮説を立てる
  • 4.実験を行う
  • 5.結果を検証する
  • 6.フォローアップ/標準化する。

1.問題を定義する

  • チームが「顧客の要求にもっと応えたいと」する。
  • このチームの最大の問題は、要望が無視されていると文句を言う顧客からの、長い苦情リストである。 そこでチームは、問題をもっとよく調査してみることにした。


2.状況を分析する

  • チームは過去4階分のリリースで導入した機能に着目し、機能のサイクルをパレート図に書いた。
  • 機能の4分の3以上は要望を受けてから6週間以内に導入していたので優秀な対応をしていた。
  • しかし、メンバーは要望の待ち行列に無視されている項目も数多くあることを知っていた、主に機能が常に追加され続けているからである。

現在待ち行列にある機能が待ち行列に追加されてからの時間をパレート図に表した。 そのデータから待ち行列にある要望の60%以上は、追加されてから8週間以上経っていることがわかった。

前のグラフからも、8週間以降に実際に提供された機能は9つしか無いことがわかる。
チームはごく最近の要望だけ取り組んで、古いものには取り組んでいないらしい。


3.仮設を立てる

  • 問題解決を急ぐチームが見落としてしまいがちなのが、テスト可能な仮設を立てること。

チームメンバーは、上位の3つの優先カテゴリ(緊急、至急、重要)に属する要求の平均発生率が10であり、それがほぼチームの出力と同じだ。という点に着目した。

つまり、待ち行列を要望40〜50件までに短くし、「普通」「低」の要望を受け入れないようにし、要求への対応スピードを少し上げれば、9割がた、新たな要望に4週間以内に応えられる。という仮設を立てることが出来る。


4.実験を行う

  • チームメンバーは、8週間以上待ち行列に入れられている要望を出した全員にメールを送って、バックログが減らせるのかどうかを試してみることにした。

1週間以内に確認が取れない場合には、要望はキャンセルしてもよいのもとして扱った。

チームメンバーは、出されてから16週間以上立つ要望の99パーセントは、もう求めておらず。 8週間以上たつ要求の77パーセントは、すでに有効ではな無いことに気づいた。 依然として必要だという確認が取れた29件の要望を調べれると既に「重要」の優先度が付けられていることがわかった。

今度は優先度が「普通」「低い」の要望を出した顧客に、同様のメールを送って確認をした。 これによって、待ち行列は要望100件にまで短くなった。

優先度の低い要望への対処法を実験し、いちばん成果のあった実験は、チームの顧客サポート担当に、低い優先度の要望を出している人たちに電話をかけさせ、
共同でその問題を解決する別の方法がないかどうかを見つけ出す。といことで解決できた。

低い優先度の4分の3は、このように個人宛に連絡してみることで、取り消された。


5.結果を検証する

  • 確実な対応速度を測定した、データから、待ち行列の長さが要望への応答時間の決定要因であることがわかった。


6.フォローアップする/標準化する

  • チームメンバーは、顧客ほとんどの要望に対し、4週間以内に対応することを通知したが、そうすればさらに顧客からの要望が出せることになることに気づき、チームメンバーの1人に、カスタマーサービスのコールセンターを支援させた。

そうすることで、要望の到着率を抑制し、優先度の低い要望に対しては、回避策が見つけられるようにした。 それに加え、対応までに掛かる時間が短縮されたこともあって、リリースごとの完成率は28件にまでにあげることが出来た。


カイゼンイベント

  • ときにはチームを日々の活動から少し離して、プロセスの重要な部分の改善だけに意識を集中させるのも良い。
  • 改善による変化が、企業の複数の部署に影響を与える場合には、特に有用である。
  • だからこそ、異なる役職の人たちや、別々のチームからのメンバーを参加させなくてはならない。
  • 大グループでの改善イベントはさまざまな理由から失敗することが多い。


1.中核となるビジネスプロセスの注力が足りず。。

  • 行き当たりばったりの改善になる。
  • 全体ではなく、局所的な最適化につながってしまう。

これは、小グループでの改善イベントを行っても起こりうる問題だ。
改善によって解決されるべきなのは、最も重大で目につく、ビジネス上の問題なのである。


2.多くのアイディアが承認されても、ほとんどは実践につながらない。なぜなら

  • 誰も、アイディアを実践に移す責任を負わないためである。
  • 職務の境界を超えた変更を行う権限が与えられていないためである。
  • 変更を行う人達に、そのための時間が確保されないためである。
  • 主催者によるフォローアップがないためである。

フォローアップがないと、特に大グループイベントの場合には問題であり、大勢を落胆させることになる。 失敗させるくらいなら、そのようなイベントは行わないほうがましである。フォローアップが出来ないようでは、イベント参加者に対する敬意を欠く。

改善は通常の作業チームによって行われるもの、作業チームを継続的に、規律をもって、ビジネス全体の成果の改善をじゃましている現在の最大の制約を認識し、取り除くべきである。