いかにして問題をとくか

はじめに

いかにして問題をとくか（と, ライト、ついてますか（今、手元にない））の宣伝.

問題を理解すること

問題とはなにか

• プロダクトのパッケージングに失敗すること.

分かっていることは何か

• アプリケーションのビルドまで成功している.
• パッケージングに失敗している.
  • パッケージングに必要な設定ファイルとスクリプトの場所は分かっている.

（＊ここでのビルドは, ただアプリケーションがコンパイルの意味でビルドできること）
（＊ここでのパッケージングは, プロダクトを顧客がインストールして実行できる状態にすること）

計画を立てること

• 過去に似た事例はないか.
  • 内容が完全に同一のブランチのパッケージングに成功している.
  • 違いは何か.
    • 成功例では、パッチパッケージングではない、更新パッケージングである.
      • 完全に置き換え（更新）か、一部置き換え（パッチ）の違い.
    • ビルド・パッケージング環境を更新した.
• 未知のものはなにか.
  • 更新パッケージングであるかどうか.
  • パッケージング環境の更新.
• 未知のものが何に影響するか.
  • 更新パッケージングかパッチパッケージングか
  • パッケージングの設定ファイル
    • システム更新によって, ビルド・パッケージングマシンのアドレスも更新しなければならない.

計画を検証すること

計画を立てることと前後したり, 同時に実行していることです.
私は 自分を信じないし, 他人も信じない ので本当に考察したとおりなのか調査しています. ここに時間がかかり, 数十分消費します.

• 過去の似た事例は本当にそうであったか.
• 未知と思っているものは本当にそうか.
• 影響範囲は本当に考察したとおりか.

計画を実行すること

各段階を検討せよ, 影響範囲を考慮して, 閉じているか検討せよ（設定ファイルに原因があるという前提で）.

• 設定ファイルを変更したことによって, 意図したとおりにパッケージングが行われるか.
• 他のシステムに影響を及ぼさず, 閉じているか.

ふり返ってみること

• より良い方法があったか.
  • より良い方法はシステム化できるか.
• 過程と結果を次の問題に応用できるか.
• 過程と結果を知識にできるか.

まとめ

パッケージングに必要な 場所 の指定が複数に分散しているのは, システムを構築したものとして反省すべき点です. 振り返り に関して, 私の記憶力と応用力に依るものが大きいため, どうしたものかと悩みます.

ただのPDCAじゃねーか！, そのとおり.