IBM TechXchange Japan Storage User Community

前回の記事：コンテナ利用時のメリット・デメリットって何？

今回はコンテナアプリってどうやって作成するの？についてです。

前回、アプリ開発のアプローチ手法として PDCA サイクルと OODA ループをあげてみましたが、

　PDCA サイクル ≒ 品質保証手法

　OODA ループ ≒ 意思決定手法

と、言い換えることもできまして、日本語に置き換えてみると結構手法に違いがありそうですよね。

コンテナアプリの作成方法だからといって基本的には今ままでと変わりませんが、アプリケーションによっては開発手法を変更した方が良い場合がありますので、その点を踏まえてみていくことにします。

まずは PDCA サイクルについてちょっと深掘りしてみましょう。

そもそも PDCA とは、Plan（計画）・Do（実行）・Check（評価）・Action（改善）の頭文字を取ったもので、業務や事業などの継続的な改善を目指す手法の一つといわれております。

業務効率の改善や事業の発展に繋げることができるため、この手法をアプリケーション開発に活用する事は多く、デファクトスタンダードになっているのではないでしょうか。一方で、「あまり成果を感じられない」と効果的に利用できていないケースも少なくありません。

それでは、なぜ「あまり成果を感じられない」事があるかを見てみましょう。

PDCA サイクルはゴール地点を決めてそれに向けて細分化し分業制で作業を開始するかと思います。この方法はゴール地点に近づいていくほどリスクと時間がかかり、最悪はゴール地点に辿り着くことができずに頓挫してしまう事も。。。リスクを恐れ品質保証の意識がブレーキをかけてしまい「あまり成果を感じられない」というジレンマに陥ってしまうのでしょうね。

次に OODA ループについてちょっと深掘りしてみましょう。

そもそも OODA とは、Observe（観察）、Orient（状況判断、方向づけ）、Decide（意思決定）、Act（行動）の頭文字を取ったもので、業務や事業などの継続的な改善を目指す手法の一つといわれております。

余談ですが、米国空軍のジョン・ボイド大佐が提唱した意思決定のプロセスで、
一瞬の判断の遅れやミスにより命を落としかねない戦闘機のパイロットが上官の指示を待たずとも自ら的確な判断が可能となることを目指し、作り出されたものと言われております。

OODA ならではのポイントとしては「観察」というプロセスがある事です。置かれている状況や周囲の環境を客観的に観察し、現状を正しく認識することが重要となります。

それでは、なぜ「観察」が重要であるかを見てみましょう。

OODA ループは意思決定が売りとしておりますので、トライアンドエラーを繰り返しながら「観察」を繰り返す事でリスクを減らし絶えず進めていく事が可能になるからです。ただ、良い事ばかりではありません。この手法はゴール地点を決めるのが困難のため、最初に考えていたゴール内容とは違うものが出来上がる可能性がありますので、中長期計画をたてるのが難しいと言われております。

お伝えしたかった事をまとめますと、

PDCA サイクルですと品質保証が第一となりますので、どうしても最新技術の利用が適応しにくい反面、安定したアプトプットが確立されますが、OODA ループの方法は常に最新の技術を利用して新しいものを作成しやすい反面、安定したアプトプットを確立するために日々の改修が必要になってきます。

ご自身の利用している携帯アプリをイメージしてみてください。やけにアップデートが多いものと、全然アップデートがないものと色々ありますよね。

結局どちらの手法が良いという訳ではなく、作成したいアプリケーション特性を理解して、その状況に合った手法を利用する事が大事です。

簡単ながらコンテナアプリの作成方法を理解していただけたかと思います。

さて、次の内容は何にしましょうかねぇ。

以下のような内容を考えております。

・コンテナセキュリティってどうすれば良いの？

コメント欄にご要望・ご意見をいただけましたら、ご要望の多いものから載せていこうと思っております！