リーン生産方式の概略

はじめに

この記事では、「リーン生産方式の概略」について書いています。

DevOpsについて勉強をしていますが、「DevOpsはリーン生産方式の原則をITへ応用したもの」という文章を見て、リーン生産方式を今一度学びたいとなったのが記事を書いたきっかけでした。

自分に向けた備忘録でもありますが、「リーン生産方式について概略を知りたい」な人の一助になれば嬉しいです。

リーン生産方式とは何か

  • リーン生産方式（LPS: Lean Production System）
    • リーン: 「贅肉の取れた」という意味
    • 直訳すると「贅肉の取れた（＝ムダの無い）生産方式」
  • トヨタ自動車の生産方式（TPS）を体系化、一般化したもの

リーン生産方式のポイント

  • ２本の柱
    • ニンベンの付いた「自働化」
      • 異常が発生したら機械を即座に停止して不良品を造らないようにすること
      • 異常時にすぐ止めることで下流に不良品を送ることがなくなり、下流に迷惑をかけずに済む
      • 異常時にすぐ止め、そこで問題の究明と解消を行えば全体として不良品を減らせる
    • ジャスト・イン・タイム（JIT: Just in time）
      • 生産計画に合わせて「必要なものを、必要な時に、必要なだけ作る」という考え方
      • この考えの追求していくと「ムダ」「ムラ」「ムリ」がなくなりビジネス的な生産性が向上するといわれている。
  • 4つの取り組み
    • ムダ取り
      • 価値を生まない作業を徹底的に排除し、より多くの付加価値を生み出す作業だけに集中できるようにする
    • 改善（KAIZEN）を意識
      • 常に現状を改善しようという姿勢を組織に持たせる
    • 問題の見える化
      • 問題が発生したら隠すのではなく、職場全体に知らされるようにすること
      • 問題があれば機械を止めるということも見える化の一つ
        • 問題があっても動き続けたら問題があることに気づけない
    • 根本原因の分析
      • 問題が発生したときに、表層的な対処ではなく真因を突き止め根本的な解決を目指す
      • 真因を突き止めるための手法としては「なぜなぜ分析」が有名

おわりに

「リーン生産方式の概略」について解説しました。

DevOpsで紹介されるものを見返すとリーン生産方式に則ってる感じるものもあり、リーン生産方式を学ぶのはDevOpsを学ぶ上で重要であることが分かりました。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

denwadaikou.jp

www.clouderp.jp

制約理論とは何か、その概要

はじめに

この記事では、「制約理論の概要」について書いています。

DevOpsを学んでいる中で「制約理論」という言葉を見つけ、一体どんな内容なんだろうと思ったので調べその内容を記事にしました。

制約理論とは何か

  • TOC（Theory of Constraintsの略）とも呼ばれる
  • 業務全体の最適化を行い、生産性を向上するための考え方
  • 「ザ・ゴール」の著者であるエリヤフ・ゴールドラット博士が提唱した理論
  • 制約理論は、生産性向上だけでなく、経営マネジメントや経営哲学にも利用されている

制約理論のゴール

  • スループットの向上
  • そのために、スループットを制約しているボトルネックの（継続的）解消
    • 制約理論は「どんなシステムも、一部または単一の要素によって、そのパフォーマンスが制限されている」という思想がある

制約理論における改善ステップ

以下に書く一連の改善ステップを繰り返し行っていく

  1. ボトルネックを見つける
    • 「ムリ、ムラ、ムダ」が発生している箇所や機械装置の能力によって物理的な制約が生じている箇所を特定することから始まる。
  2. ボトルネックを最大限に活用する
  3. 全プロセス"を"ボトルネック"に"合わせる
    • 他の部分の処理能力を、ボトルネックの処理能力に合わせる
    • パフォーマンス低下に見えるが、全体最適になる
      • ボトルネックよりも処理能力が高い工程では、必要以上の在庫（＝ムダ）を作っていたり待ち時間が発生している可能性があるため
      • ボトルネックに合わせることで無駄なコストの発生を避けることができる
  4. ボトルネックを改善し、強化していく
    • この段階で、本質的な原因であるボトルネックの能力強化、改善を行っていく
    • ボトルネックの処理能力が向上したら、それに合わせ他の部分の処理能力もあわせて上げていき全体のスループットを高めていく

制約理論のポイント

「どのバリューストリームにも唯一無二の制約条件がある。その制約条件以外に対する改善は幻想にすぎない。」

ゴールドラット博士

「TOC(制約理論)を一言で言えというなら、それは「フォーカス」だ。 ここで、大事なのは、フォーカスするとは、何をすべきか決めると同時に、むしろ何をすべきでないか決めるということだ。 なぜなら、すべてにフォーカスするのは、どれにもフォーカスしないのと同じだからだ。」

ゴールドラット博士

おわりに

「制約理論の概要」について解説しました。

考え方は「一番のボトルネックを見つけ解消する、を繰り返す」というシンプルなものなので分かりやすく、そして業務改善など様々な所に活用できそうだなと感じました。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

logist.bz

japan-toc-association.org

www.nttdata-gsl.co.jp

DevOpsを構成する3つの原則

はじめに

この記事では、「DevOpsを構成する3つの原則」について書いています。

現在、DevOpsを勉強するために「The DevOpsハンドブック」（詳細情報は以下）を読んでおり、その中の内容の一部を読書記録的にまとめたものがこの記事になります。

書籍情報

ジーン・キム (著), ジェズ・ハンブル (著), パトリック・ボア (著), ジョン・ウィリス (著), 榊原 彰 (監修), 長尾 高弘 (翻訳) The DevOps ハンドブック 理論・原則・実践のすべて 株式会社日経BP, 2017, 487p

自分に向けた備忘録でもありますが、「DevOpsが何かを知りたい」な人の一助になれば嬉しいです。

本題

DevOpsの全ての行動やパターンは3つの原則（The Phoenix Project では「3つの道」と呼んでいる）を基礎としている（= 3つの原則を元にDevOpsの行動やパターンが導き出されている）

  1. ワークフローを高速化する
    • 実現により得られること
      • 納品に必要なリードタイムが短くなりスループットが向上する
      • （高速化のための施策により）作業品質も向上する
      • 素早く実験する能力が向上する
    • 実現のために行うべきこと
      • 仕事を可視化する
      • バッチサイズと作業の待ち時間を削減する
      • 品質を組込み、下流に不良品を流さないようにする
    • 具体的なプラクティス
      • CI/CD（継続的インテグレーション、継続的デリバリ）
      • オンデマンドによる環境の作成
      • 仕掛かりの削減
      • 変更に強いシステムや組織の構築
  2. 高速で継続的なフィードバックフローを確立する
    • 実現により得られること
      • 上流で品質を確保できる
      • 致命的な事故が起こる前に問題点を見つけて修正できる
    • 実現のために行うべきこと
      • フィードバックがいかに大切かを協調すること
      • 発生したら、対策が打てるまで一丸となって問題と向き合う
  3. 絶えず学習を行う組織文化を作ること

所感

  • DevOpsというのは範囲が広大で曖昧模糊としているイメージでしたが、３つの原則としてまとめられていたのでDevOpsの全体像がクリアになった気がしました。
  • 実践する上でのこの３つの関係は、同時並行で進めていくべきなのか、１から順番に達成していくべきなのかが少し分かりませんでした（読み進めていけば分かるのかもしれませんが）
  • ワークフローの高速化は項目が具体的なので取り組みやすく感じました。

おわりに

「DevOpsを構成する3つの原則」について解説しました。

DevOpsの知恵を自分のソフト開発にも取り入れ、更に良いソフトウェア開発が出来るようになりたいです

GitHub ActionでPythonの複数のバージョンを利用してみる

はじめに

この記事では、「GitHub ActionでPythonの複数のバージョンを利用してみる」について書いています。

GitHub Actionsは非常に便利な機能で色々使えるようになりたい思っており、その中でPythonを複数のバージョンにまたがって動作確認などできるのかなと調べたのが記事を書いたきっかけでした。

自分に向けた備忘録でもありますが、「GitHub ActionでPythonの複数のバージョンを利用してみたい」な人の一助になれば嬉しいです。

本文

早速ですが、Github ActionsでPythonの複数のバージョンを利用してみるためのymlファイルの中身は以下のようになります。

name: run multiple Python versions

on:
    workflow_dispatch:

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        python-version: ["3.7", "3.8", "3.9", "3.10"]

    steps:
      - name: Setup Code
        uses: actions/checkout@v3
      
      - name: Setup Python ${{ matrix.python-version }}
        uses: actions/setup-python@v4
        with:
          python-version: ${{ matrix.python-version }}

      - name: Display Python version
        run: python -c "import sys; print(sys.version)"

Note

上の例では実験をしやすくするためにトリガーをon: [workflow_dispatch]と手動実行だけにしています。 実際に自動で行わせるためにはpushなどのトリガーを設定する必要があります。

処理の内容は以下のようになっています。

  1. python-version: ["3.7", "3.8", "3.9", "3.10"]で使用するPythonのバージョンを設定する
  2. actions/checkout@v3では、リポジトリのコードをチェックアウトする
  3. actions/setup-python@v4Pythonでは、Pythonをセットアップする この記述の２行下にあるpython-version: ${{ matrix.python-version }}で、上のmatrixで指定したバージョンを使うように設定している
  4. python -c "import sys; print(sys.version)"でバージョンを出力する ここのコードでは単にバージョンを出力する処理ですが、もしテストなどの処理を行わせたい場合はこの部分（かそれ以降）に処理を追加すれば大丈夫です。

ではこれで実際にアクションを実行してみましょう。実行結果は下の画像のようになります。

左欄をみると、指定した通り、3.7, 3.8, 3.9, 3.10でJobが実行されているようです。

また、右欄のDisplay Python versionの内容を確認するとPythonのバージョンが出力されています。

おわりに

「GitHub ActionでPythonの複数のバージョンを利用してみる」について解説しました。

GitHub ActionsではPythonの複数のバージョンを簡単に利用することができました。

GitHub Actionsは非常に便利な機能で様々なことを自動化できるので、是非みなさんも活用してみてください。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

https://docs.github.com/ja/actions/automating-builds-and-tests/building-and-testing-python

Mermaidで基本的なガントチャートを書いてみる

はじめに

この記事では、「Mermaidで基本的なガントチャートの書き方」について書いています。

最近QiitaやGitHubなどでMermaidがサポートされるなど使える場面が増えているため、書き方を試しながら学んでみようとなったのが記事を書いたきっかけです。

自分に向けた備忘録でもありますが、「Mermaidでのガントチャートを書いてみたい」な人の一助になれば嬉しいです。

ガントチャートとは何か

Mermaidでのガントチャートの書き方

簡単なサンプル

```mermaid
gantt
    title ガントチャートのサンプル
    excludes weekends

    %% Section-Aに関する記述
    section Section-A
    alpha           : id_a, 2022-11-04, 9d
    beta            : after id_a, 4d

    %% Section-Bに関する記述
    section Section-B
    gamma      : 2022-11-11, 2022-11-16
    delta      : 2022-11-15, 5d
```
gantt excludes weekends %% Section-Aに関する記述 section Section-A alpha : id_a, 2022-11-04, 9d beta : after id_a, 4d %% Section-Bに関する記述 section Section-B gamma : 2022-11-11, 2022-11-16 delta : 2022-11-15, 5d

構文

Mermaidでのガントチャートは以下のように書いていきます。上のサンプルコードを見ながら読んでみてください

  • ガントチャートを書く時は先頭にganttキーワードを書きます。
  • titleを記述します。
  • 必要ならばセクションを記述します
    • 上のサンプルではSection-A, Section-Bがタスクです。
  • タスクを記述します。
    • 上のサンプルではalpha, beta, gamma, deltaがタスクです。

タスク

  • タスクは タスク名: ステータス, タスクID、開始日、終了日のように記載します。
  • 開始日はafter タスクIDと書くと、そのタスクIDのタスクの直後から開始させることができます。
  • 終了日は日付指定の他に、終了までの期間として記述することもできます。

その他

  • excludesで、任意の日を除外することができます。
    • 上の例ではexcludes weekendsとして週末を除外してます。
  • コメントは%%を先頭につけて記述します。
  • （環境によるかもしれませんが）今日の所には赤い線が引かれるようです。

おわりに

「Mermaidで基本的なガントチャートの書き方」について解説しました。

シンプルな記法でガントチャートが書け、使いやすそうだなと感じました。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

mermaid-js.github.io

dev.classmethod.jp

GitHub ActionsでPythonのpytestを自動実行してみた

はじめに

この記事では、「GitHub ActionsでPythonのpytestを自動実行する方法と実際に試してみた結果」について書いています。

GitHub Actionsは非常に便利な機能で色々使ってみようと思い、Pythonのpytestを自動で実行できるようにしてみようと考えたのが記事を書いたきっかけでした。

自分に向けた備忘録でもありますが、「GitHub ActionsでPythonのpytestを自動実行させてみたい」な人の一助になれば嬉しいです。

本文

早速ですが、Github Actionsでpytestを自動で行わせるためのymlファイルの中身は以下のようになります。

name: Run pytest

on: [workflow_dispatch]

jobs:
  pytest:
    runs-on: ubuntu-latest

    steps:
      - name: Setup code
        uses: actions/checkout@v2

      - name: Setup Python
        uses: actions/setup-python@v2
        with:
          python-version: 3.9
          
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install pytest
          
      - name: Execute pytest
        run: |
          python -m pytest
        continue-on-error: true

Note

上の例では実験をしやすくするためにトリガーをon: [workflow_dispatch]と手動実行だけにしています。 実際に自動で行わせるためにはpushなどのトリガーを設定する必要があります。

処理の内容はシンプルで以下のようになっています。

  1. リポジトリのコードをチェックアウトする
  2. Pythonを使うので、Pythonを（バージョン3.9で）セットアップする
  3. pytestをインストールする
  4. pytestを実行する

この段階ではまだサマリなど見やすい形での出力ではありませんが、第一段階としては十分かと思います。

ではこれで実際にアクションを実行してみたいと思います。

pytestのコードが書かれたリポジトリに対して上のアクションを実行した結果が以下の図になります。

Execute pytestの項を見るとちゃんとpytestが実行され、またその結果が出力されています。

GitHub ACtions上でpytestを実行することに成功したようです。

おわりに

「GitHub ActionsでPythonのpytestを自動実行する方法と実際に試してみた結果」について解説しました。

今回は単純にpytestを実行させてみただけですが、ここから更にサマリの形式で出力させることも出来るようです。

GitHub Actionsは非常に便利な機能で様々なことを自動化できるので、是非みなさんも活用してみてください。

MKDocsで数式を書く方法

はじめに

この記事では、「MKDocsで数式を書く方法」について書いています。

最近MKDocsを使って資料を書く機会が多いのですが、数式を扱うことがある人なら、MKDocsで数式を書けると便利かと思います。

自分に向けた備忘録でもありますが、「MKDocsで数式を書きたい」な人の一助になれば嬉しいです。

本文

今、以下の数式（何が表示されるかは後ほど分かります）をMKDocsで表示させたいとします。

$$
\int^{b}_{a} f(x) dx
$$

まずは何もしてない状態で、ymlファイルは以下のような記述です。

site_name: My Docs

theme:
  name: 'mkdocs'

このとき、MKDocs上では以下のような表示で、Formulaの節に数式が表示してほしいのですが上手く表示されてません

では数式が表示されるようにしていきましょう。

まず、次のコマンドを実行してpython-markdown-mathをインストールしてください

pip install python-markdown-math

続いてはymlファイルの中に記述を足します。以下のように記述してください

site_name: My Docs

theme:
  name: 'mkdocs'

markdown_extensions:
    - mdx_math

extra_javascript: 
  - http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML

ポイントは２つです。 + markdown_extensions:にmdx_mathを加える + extra_javascript:にmathjaxのURLを加える

さて、ここまで作業が実施できたら、改めてMKDocsの表示を確認してみましょう

Formulaの節の部分、無事に数式が表示されてます。（表示したい数式は積分式でした）

おわりに

「MKDocsで数式を書く方法」について解説しました。

数式も書けるようになると、更にMKDocsで書ける文書の幅が広がり、便利に使えるかと思います。

さいごに、記事を書く上で参考にしたサイトのリンクを以下に掲載します。合わせて読んでいただくと良いかと思います。

zenn.dev