aws memo

AWS関連の備忘録 (※本ブログの内容は個人的見解であり、所属組織及び企業の意見を代弁するものではありません。1年以上古いエントリは疑ってかかってください)

DevOps : 日本語で語る DevOps

Japanese Words for DevOps Practitioners | IT Revolution

もともと DevOpsは、リーン開発やアジャイル開発とも近いので、TPS (トヨタ方式)の哲学が入っていても不思議ではないですが、やっぱり大野耐一さんはすごい。そして、製造業におけるシステム運用ともいえる生産ラインの方法論こそ、Opsに一番必要な気がする。Devは、生産ラインそのものを建造することに近いし、継続的なDevは、生産ラインをどんどん変更・拡大・追加をしていくことに近いと思う。

====

Gemba

「実際の場所」を意味する。ビジネスでは「価値が生まれている場所」を意味し、リーン製造業では「工場」もしくは「店舗」を意味する。リーンシックスシグマ(LSS)では「現場へ行け(Going to Gemba)」というフレーズは一般的である。また、よくプロセスマッピングにも使われる。

この単語がDevOpsにおいて重要な理由は、DevOpsがLSSと制約理論(Theory of Constraints, TOC)から多くの考えを継承しちえるからであり、LSSとTOSの両方が、広域最適化( big picture)に強くフォーカスしているからである。全体を改善すること、個別にフォーカスしないこと、はLSSとTOC両方の中核をなす考えである。ボトルネックとフローを理解することは、バリューストリームを理解する上で重要な要素である。

DevOpsでは「Aha to the Ka-Ching」もしくは「left to right flow」について話をしている。「Going to Gemba」はフローを実際に見るためにとても重要であり、決して口上ではない。a)ムダを削除すること、b)例外・ばらつき(Mura)を最小化すること、の2つによってどのように改善されうるかを決定するためにGembaを歩くことが必要である。

Kanban

「サインボード」や「居酒屋のラストオーダーを知らせる板」を意味する。後のリーン製造業となるトヨタ生産方式( Toyota Production System, TPS)の父である大野耐一は、「last call」の種類としてKanbanを「Just in TIme, JIT」を実現する意味で使っていた。Kanbanカードは、新しく部品を補充・発注する際に在庫とフローを制御する手段の信号として使われた。2007年にDavid J AndersonはKanbanメソッドを、TPS製造モデルではなく、ソフトウェアデリバリパターンとして定義した。今日では、Kanbanはアジャイルチームにおいて有効なツールとして使われている。Kanbanに含まれている重要な考えの一つとして、a)Kanbanはプル型の仕組みで b)ワークフローの見える化によってスループットを改善し、 c) 特殊な作業の 「仕掛品 Work-in-process, WIP」を増やさないようにする。

KanbanがDevOpsで人気な理由は、割り込みが多い運用やサービス指向のグループで有用だからである。ScrumとXPが開発組織で有用であるように、DevOpsが哲学でDevとOpsが密に作業している組織の多くで、Kanbanの利用事例を見つけるだろう。

Kaizen 

WikipediaではKaizenは「improvement 」もしくは「change for the better」と表現されている。製造業、エンジニアリング, ゲーム開発、ビジネスマネジメントにおける継続的なプロセス改善の哲学・プラクティスとして言及されている。

カイゼンは日々のプロセスであり、常に前日より良くなっている。また、カイゼンはシンプルな生産性向上の考えに起因している。職場を人間的にしハードワーク(muri)を減らすし、科学的手法の適用と、ムダを検出し撤廃する方法を教えてくれる。

カイゼンはリーンと同じようにDevOpsでは大きな役割である。DevOpsでは常にフローの改善の考え方がある。フローのばらつき(バグ、性能問題)を見つけ、早期にフローのエンジニアリングを行う。また、改善は、ボトルネックを緩和(alleviating)し継続的に全体最適を行う。

Kata

文字通りの意味としては「フォーム、手順」である。この単語はマテリアルアートで一般的だが、それ以外では、文化的な条件を意味する。日本のビジネスにおいてカタは正しく実行する方法の概念である。弓の弾き方、名刺交換、謝罪の重要性、品質への執着等は全て、日本の文化に深く起因している。

ある組織の文化は、一貫した役割設計、ティーチング、コーチングを通して、カタとして特徴づけられる。 Mike Rotherは「Toyota Kata」という本でカタとリーンの観念を普及させた。Toyota Kataは改善のカタと、コーチングのカタという2つの領域に分けられる。改善のカタは継続的な改善・適用・革新の熟達を教えている。コーチングのカタは、継続的な観測とガイドの側面を強調している。この理論は、難しい何かや慣れてない何かをしようとした時に、コーチ無しでも怠けないようになる。ある組織が改善に最適化されている場合、それは彼らのカタであると言える。

Muda

Mudaは不要物である。トヨタ生産方式(TPS, Leanとも呼ばれている)の父であるトヨタの大野耐一によると、価値を産まない活動はすべて無駄である。大野耐一は有名な7つのムダを指摘した(作りすぎ、手待ち、運搬、加工、在庫、動作、不良を作ること)。この概念は、すべての活動を2つに分類する。つまり、価値を生む活動と、価値を産まない活動である。

DevOpsでムダを減らすことは、重要な原則である。Ka-chingについて語るときは、顧客へデリバリするサイクルタイムを邪魔するムダな壁をいつも探している。

Mura

Muraは一貫性がない、もしくは過剰な変動を意味する。作業が標準化されていない場合、無駄な動きによって無駄が生じる(例えば、明確な工程や手続きが無い場合)。Muraは品質の問題を引き起こしかねない。

Kanbanのコア原則の一つが、工程の方針を明示的に作ることである。Kanban はMuraを削減する素晴らしいツールである。Chef, Puppet, CFEngineといった構成管理ツールは、インストール・設定の標準化プロセスを作ることでMuraを制御する、という議論がある。Leanは 無駄(muda)を除去し 、 Six Sigmaは変動(Mura)を削減する。DevOpsでは、3M (Muda,Mura,Muri)を削減するよう努める。

Muri

Muriは TPSにおけるMura, Muraに続く3つ目の廃棄すべきものである。日本語では、過負荷、理不尽、不条理を意味する。Muriは、工程・人間・機械が許容範囲内で活動することを表している。

Pola-yoke

フェールセイフ、もしくは人的ミスの対策。 Poka-yokeは、製造現場にて、欠陥を防止することとヒューマンエラーへの注意を促進する。この単語はTPSの一部として新郷重夫が追加した。

現実世界でのPola-yokeの素晴らしい例として、氷入れが満タンの時には冷蔵庫内の製氷機は製氷しないので、冷蔵庫が氷であふれることはない、といったもの。 Poka-yokeは明らかに DevOpsと関係が深い。DevOpsの作業の多くが人間の活動をベースとしていることは、殆どの人が同意するだろう。ソフトウェア開発と運用は人間の努力とであり、インフラをPola-yoke化すること(Poka-yoke'ing) は、DevOpsのゴールのひとつである。テスト駆動開発(Test Driven Development, TDD)は、ソフトウェア版Poka-yokeの一例である。セルフサービスの運用やPaaSも別の Poka-yokeの形態ともいえる。監視は、素晴らしいPoka-yokeの例である、というのも、エラーが発生する前にエラーを見ているのだから。