ビジネスではPDCAとOODAをうまく使えば伸びる

こんにちは。

突然ですが、OODAってご存知でしょうか？

OODAとは、以下のように思考して行動することです。

• 観察(Observe)
• 状況判断(Orient)
• 意思決定(Decide)
• 行動(Act)

PDCAと言うと、知っている人もいるかもしれません。

• 計画(Plan)
• 実行(Do)
• 評価(Check)
• 改善(Act)

よく経営者とかが、「PDCAを回していいサービスを作る」とか言ってますよね。

でも、最近、いろんなWebサイトを見ていると、
「PDCAはもう古い」
「これからはOODAだ」
「OODAの方が効率的だ」
と言う意見が多いです。

そこで、以下の質問に対して、私個人の意見を書いてみようと思います。

• PDCAとOODAの違いは？
• PDCAとOODAはどっちがいいの？
• PDCAって古いの？

結論としては、以下になります。

1. ビジネスではPDCAとOODAをうまく使えば伸びる
2. マネージメントはPDCA
3. リーダーはOODA

私は、15年以上、IT業界でプログラマーとして働いて来ました。
その中で、いろんなプロジェクトに参加し、リーダーやマネージメントの経験をして来ました。
そして最近では、私が勤めている会社の経営の手伝いもしています。

こんな私が、これまでの経験から、以下でPDCAとOODAについて説明していきます。

１．ビジネスではPDCAとOODAをうまく使えば伸びる

私は、ビジネスでは、PDCAとOODAをうまく使えば伸びると考えています。

よく経営者と現場で働く人では、考え方が違うと言われますよね。
それは、経営者やマネージメントをしている人は、長期的なスパンで物事を考える必要があるからです。
その場合、必要となるのが、PDCAです。

一方、現場で働く人は、毎日、自分の課題に取り組んでいます。
つまり、現状を見て、判断して、行動しているのです。
なので、OODAが適しています。

例えば、プロジェクトマネージャーとプログラマーで考えてみます。

プロジェクトマネージャーは、常にプロジェクト全体を見ながら、人員の配置や作業の振り分けをします。
これは、プロジェクト計画があり、それに沿ってチェックと行動を繰り返す作業です。

プログラマーは、振られた自分の機能について、課題を出し、設計をし、製造します。

こういう事を言うと、プロジェクトマネージャーも、OODAで良いのではないかと言う疑問も出てくると思います。
確かに、１つのプロジェクトだけを見ると、OODAで良いように思えます。
しかし、プロジェクトマネージャーは、他のプロジェクトや会社全体の事も考慮しながら、自分のプロジェクトを進める必要があるのです。
他のプロジェクトや会社全体の事を考慮しないと、必要な人材を持ってくる事もできないですよね。

つまり、経営者とマネージャーがPDCAを回しながら思考・行動し、現場で働く人が、OODAで思考・行動する事で、ビジネスは伸ばすことが可能なのです。

では、PDCAだけてビジネスを展開するとどうなるでしょうか。
PDCAだけだと、C(チェック)までに時間がかかるため、現場では、問題が発生していても対応が遅くなってしまいます。

逆に、OODAだけでビジネスを展開するとどうなるでしょうか。
OODAだけだと、状況によって判断するため、ビジネス全体がフラついてしまいます。

なので、ビジネスには、PDCAとOODA両方が必要になるのです。

２．マネージメントはPDCA

上にも書きましたが、マネージメントには、PDCAが必要です。

なぜなら、マネージメントをするには、明確な方向性が必要だからです。
マネージメントは、方向性に沿った計画をする必要があり、計画に沿って進んでいるかをチェックし、次の行動を決める必要があるのです。

例えは、プロジェクトマネージャーを例にしてみましょう。

プロジェクトには、プロジェクト計画とプロジェクトで使用できる予算があります。
プロジェクトマネージャーは、プロジェクトが計画通りに進んでいるのかをチェックし、次の工程でどのくらいの人材が必要となるのかを判断しないとならないのです。

ただし、人を投入しすぎると、予算オーバーとなってしまいかねません。
そのためには、プロジェクト全体を長い視点でチェックする必要もあるのです。

では、マネージメントをOODAで行動したらどうなるでしょうか。

状況を見て判断するので、対応は早くなるでしょう。

しかし、状況を見誤ると、方向性がずれてしまうことが考えられます。
マネージメントの判断が間違っていると、会社として死活問題になる事さえあります。

なので、マネージメントには、PDCAで行動する必要があるのです。

３．リーダーはOODA

上にも書いたように、現場で作業する人には、OODAが必要です。
特に、現場を取りまとめるリーダーには、OODAが必要となってきます。

なぜなら、現場では、毎日、問題が発生するからです。

特に、リーダーは、毎日多くの問題が報告されて来ます。
リーダーは、その問題が、すぐに対応しないといけないのか、今後、対応されていくのかを判断しないといけません。
そのために、早い判断が必要となるのでOODAが必要と私は考えています。

例えば、プログラマーを例にするとこうなります。

プログラマーは、仕様の一つ一つを設計に落としていきます。
つまり、問題点をロジックで解決していくのです。

そのため、プログラム全体を見て、新しくロジックを作る必要があるのか判断しないといけません。

これをPDCAでロジックを考えてしまうと、ひとまず仕様にあったロジックを作ってから、チェックをし、不要なロジックを削除することになります。
無駄な作業が発生する可能性が高くなるのです。

リーダーがPDCAを使用したらどうなるでしょうか。

PDCAだと、計画に沿った行動に対し、チェックをする事になります。

チェックをするには、それなりの実績が必要となるので、実績がある程度溜まるまではチェックができません。
実績が溜まってから判断すると、手遅れになってしまい、最悪の場合、手戻りが発生してしまうことになるのです。

つまり、リーダーや現場では、OODAで行動する必要があるのです。

導入に書いた質問の回答

上記の内容から、導入部分で書いた質問

• PDCAとOODAの違いは？
• PDCAとOODAはどっちがいいの？
• PDCAって古いの？

この回答としては、以下になります。

Q. PDCAとOODAの違いは？
A. 行動のスピード感が違うと思います。

Q. PDCAとOODAはどっちがいいの？
A. どちらが良い悪いではなく、どちらを適用すると最適かを考える方が良いと思います。

Q. PDCAって古いの？
A. PDCAは、昔からビジネスの世界で使われている方法なので、情報が豊富です。しかし、十分に使える方法だと私は思っています。

まとめ

結局、ビジネスを伸ばしていくには、PCDAとOODAをうまく使うことだと思います。

とは言え、小さい会社の場合、マネージメントと現場の作業は、明確に分けることができないと思います。

小さい会社だと、一人で案件をこなすことが多いですよね。

実は、私が勤めている会社も、社員数が数十人の小さな会社で、私も数件の案件を同時並行しています。

では、小さい会社だと、PDCAとOODAをどう使ったら良いかと言うと、時間を分けることが良いと思っています。
私の場合は、マネージメントする案件と、現場でプログラミングする案件なので、午前中にプログラミングして、午後はマネージメントをしています。

マネージメントと現場での作業は、全く違う作業なので、同時並行で行うと、どちらも上手くいかなくなると思います。
実際、私の場合は、同時並行で作業して、両方とも失敗したという経験があります。

つまり、PDCAとOODAを、うまく使い分けることで、ビジネスを伸ばしていけるのではないでしょうか。

では、今日はこの辺で。

システム会社への依頼からサービスの現場投入までの流れ

こんにちは。

ここ数年、DX（デジタルトランスフォーメーション）と言う言葉をよく耳にします。
DXについては、以下のWikipediaを参照してください。

Wikipedia：デジタルトランスフォーメーション

そのような中、「システム化したいけど、どうしたらいいのだろう？」と言う声も聞こえて来ます。

そこで、今回は、システム会社への依頼からサービスの現場投入までの流れについて、依頼する側の目線で書いていきます。

私は、プログラマーとして10年以上の経験があります。
私の場合は、システム会社で実際にシステムを作のが仕事なのですが、依頼する側の動きによって、システム開発の成否が決まる事があります。
なので、今回は、依頼する側の目線で書いていきます。

システム会社への依頼からサービスの現場投入までの流れ

では、早速ですが結論です。

1. 仕様を作る
2. 見積もりを取る
3. 契約する
4. 検証する
5. 現場に投入する

これが、システム会社へ依頼して現場投入するまでの流れになります。

以下で、詳細について書いていきます。

１．仕様を作る

まずは、自分の会社の業務を棚卸から始めましょう。

以下を整理するのです。

• 仕事がどのように流れているのか。
• どういう作業をしているのか。
• そこにコストはどれだけかかっているのか。

その上で、どこをシステム化すれば、本来の業務に集中できるのかを検討するようにしましょう。

ちなみに、システム化しやすい作業としては以下になります。

• 計算
• 単純なチェック
• データの整理

仕様の作成が難しい場合は、仕様の作成のみをシステム会社に依頼するのもありだと思います。

２．見積もりを取る

仕様をもとに、システム会社へ見積もりを依頼しましょう。

見積もりを依頼する会社は、複数あった方がいいと思います。

仕様については、詳細に説明をし見積もりに漏れがないようにしましょう。

また、契約する会社を検討する場合は、金額だけではなく、詳細を見るのが必要です。

よく必要な機能が含まれていなかったり、納品物が思っている物と違っていたりする事があります。

システム会社もビジネスなので、見積もりに含まれていない機能は、追加で請求されます。

終わってみたら、思っていた以上に請求されたという事がないように、この時点できちんと確認するようにしましょう。

見積もりで詳細が分からない場合は、詳細について直接聞くのがいいと思います。

３．契約する

見積もりについて十分に納得できたシステム会社と契約することになります。

契約する際の注意点は以下になります。

• 納期の確認をする
• 問い合わせ窓口を明確にする
• 進捗報告の方法について明確にする

納品の時期というのは、使用を作る際に決めていると思うのですが、改めて具体的に日付について確認します。

また、システム開発中に、いろいろな質問が双方に発生するので、その窓口を明確にしておく事が必要です。

窓口は、基本１本化した方が、システム全体が統一されていいと思います。

それと、質問についてはリスト化しておくことをお勧めします。

あとで言った言わないの問答になる事がなように、質問はリスト化して双方で管理しましょう。

進捗報告については、定期的な報告を受けるようにした方がいいです。

システム開発は、依頼する側からすると見えないので、今どういう作業をしているのかを確認できるようにしておきましょう。

４．検証する

システムが納品されると、すぐに現場へ投入したくなるでしょう。

その気持ちはよく分かります。

しかし、納品されたシステムが期待通りの動きをするのか検証する必要があります。

もし、現場へ投入した後で、不具合が発生した場合、多いな損失が発生する事があるからです。

検証の流れは以下になります。

1. 仕様と照らし合わせ検証する
2. 実データを使って検証する
3. エラーデータを使って検証する

まずは、仕様と照らし合わせて検証しましょう。

ここで不具合が発生するようであれば、再度、結合試験のやり直しを依頼しても良いと思います。

次に、実データを使って、実際の運用に耐えうるかの検証をします。

もし、実運用で複数のPCを同時で使用するのであれば、同じように複数のPCを使用することをお勧めします。

次に、エラーデータを使って検証します。

実運用するようになると、エラーデータも扱うことになりますので、そのための検証となります。

よくあるのは、エラーを検出できなかったり、システムが落ちてします事があります。

５．現場へ投入する

検証まで終わったら、実際に現場へシステムを投入することになります。

その時は、検証で使用したデータは削除するようにしましょう。

現場へ投入する手順は以下になります。

1. 並行でシステムを稼働させる
2. 問題ないかの確認をする
3. システムへ切り替える

検証が完了したからと、システムをすぐに本番稼働させるのは危険です。

実際の業務では、想定外の負荷がシステムにかかったり、想定外のデータが入力される事があります。

その時、システムが不具合を起こすと大きな損失が出る可能性があります。

なので、初めの数ヶ月は、これまでの作業と並行でシステムを稼働させるようにしましょう。

並行でシステムを稼働させて、問題がないかの確認をします。

その時、実際に使用している方にヒアリングするのも良いと思います。

ただし、この段階での使い勝手などは不具合にはなりませんので、追加案件としてシステム会社へ依頼することになります。

並行でシステムを稼働させて問題ないようなら、システムを切り替えて業務することになります。

システムを開発した会社へフィードバックする

これは、テーマとは少し外れてしまうのですが、一度システムを開発した会社とは、その先も繋がっておいた方が良いと思います。

なので、本番稼働したら業務がどのように変わったのか、現場はどう変わったかと言ったフィードバックを返すようにしましょう。

これって、実際に開発した側からすると、本当に嬉しいんですよね。

依頼した側から見ても、システム会社と繋がりがあるというのは、次のDXへの強い味方になると思います。

まとめ

今日は、システム会社への依頼からサービスの現場投入までの流れを説明しました。

1. 仕様を作る
2. 見積もりを取る
3. 契約する
4. 検証する
5. 現場に投入する

これは、基本的な流れになります。

実際には、問い合わせの対応など細かいことで検討が必要になります。

ここまで読んでみて、どう感じたでしょうか。

• システム化には時間がかかる。
• 面倒。
• 全てシステム会社がやってくれるわけじゃないんだ。

そんな声が聞こえて来そうです。

しかし、あなたの事業は、システム会社は知りません。

システム会社かシステムを依頼通りに作り上げる会社なのです。

なので、仕様の作成も、正常に動作するかの確認も、依頼した側が責任持って確認するしか方法がないのです。

そこまで見込んでシステムへ投資すると、金額は大きくなるかもしれません。

しかし、システムが実際に稼働すると、回収できるから依頼したと思いまし、回収が思った以上に早く終わったという会社も知ってます。

なので、DXへの投資を検討してみてはどうでしょうか。

では、今日はこの辺で。

コミュニケーション・コストが高いと感じた時の対処法

こんにちは。

プロジェクトでマネージメントしていると、コミュニケーションに時間（コスト）が結構かかります。

時間は、みんな等しく24時間ですが、その時間の価値はそれぞれ違うのです。

仕事で言うと、自分の時間をどのように使うかで、作業の進捗も変わって来ます。

理想を言えば、短いコミュニケーションで、高品質の作業ができるのが一番です。

とは言え、育って来た環境が違うので、コミュニケーション力は、みんな違います。

なので、コミュニケーション・コストの高い人に対して、どのような対応をするかが問題となってきます。

結論を言うと、以下の３点に注意する必要があります。

1. 少し細かいところまで説明する
2. 専門用語の使用を少なくする
3. どこまで理解できているか確認する

この３点を見ていると分かるかもしれませんが、コミュニケーション・コストが高いのは、自分のコミュニケーション力が低いのが原因となっているのです。

以下でその説明をしていきます。

１．少し細かいところまで説明する

コミュニケーション・コストを下げるには、普段は、少しのコミュニケーションで済ませるところを、少し細かいところまで説明する必要があります。

その時に気をつけることは、詳細までは説明しないことです。

詳細まで説明しないと理解できないと言うことは、基礎知識が不足しているのです。

なので、基礎知識から勉強してもらう必要が出て来ます。

それと、相手のせいにしないことです。

相手のせいにしても先には進みません。

なので、まずは、自分の説明が不足していると思って、細かいところまで説明をしましょう。

２．専門用語の使用を少なくする

専門用語が多いと、経験が浅い人にとっては、理解が難しくなります。

私も経験がありますが、専門用語が多いと、話の流れから想像することになって、結局、勘違いしてしまっていると言うことはよくあります。

特に相手が業界の違うお客様の場合、専門用語を使うと全く通じません。

たまに専門用語をバンバン使ってお客様へ説明し、あとで「あの客は、何も分かっていない」と言う人がいます。

専門用語は、同じ業界で仕事をしていないと分からないものです。

特にIT業界は、専門用語が難しいです。

なので、コミュニケーション・コストを下げるには、専門用語をなるべく使わないようにすることなのです。

３．どこまで理解しているか確認する

よく一方的に話して、聞き手がきちんと理解しているか確認しない人がいます。

独演会ならいいのですが、仕事でこれをすると、認識の違いが生まれてしまいます。

コミュニケーション・コストが上がってしまうのです。

なので、コミュニケーション・コストを下げるには、相手がどこまで理解しているのか確認する必要があります。

つまり、区切りがいいところで、「ここまで大丈夫ですか」と相手が理解しているか確認する必要があるのです。

たまに、普通に話していても、マシンガントークしてくる人いますよね。

そう言う時って、大体周りは聞いていないんですよね。

まとめ

結局、コミュニケーション・コストが高いのは、自分の責任なのです。

自分のコミュニケーション力が低いために、相手に正しく理解してもらえないのが原因なのです。

つまり、変わらないといけないのは「自分自身」なのです。

その対処としては、専門用語を少なくして、少し細かいところまで説明し、相手の理解を確認しながら説明することです。

それが、コミュニケーション・コストを下げる方法なのです。

仕事をしていて、コミュニケーション・コストが高いなと感じた時は、自分のコミュニケーションを改善してみましょう。

では、今日はこの辺で。

エンジニアとビジネス

私は、サラリーマンのエンジニアです。
ある企業に所属し、その企業から給与を得ています。
なのでサラリーマンなのです。

しかし、エンジニアである以上、何かを創りだし、収入を得たいを思うのは当然です。

エンジニア仲間の中には、サラリーマンであることを忘れて、自分で作り上げたものと勘違いする人もいます。

でも、やはり、企業に属し、何も創りださなくても、収入を得ることができる以上、サラリーマンなのです。

そう考えると、自分で何かを作り出すには、企業から飛び出す必要があるのかもしれません。実際、企業を飛び出し、フリーランスとして活躍している人も多くいます。

一度、そういう環境へ身を置くのも、いい経験になるのかもしれないな。

ビジネスと技術

経営者と技術者では考えることが異なっています。

経営者は、やはり売上を上げるようなアイデアを出してきます。
それに対して、私達、技術者は実装面で考えて答えてしまいます。

経営者が出してくるアイデアを、技術者は、新しい物を作るのではなく、既存である物やフリーで使える物で対応できないか考えてしまいます。

＜経営者＞
「このソフトみたいなもの作れる？」

＜技術者＞
「こういうソフトがありますよ」
「このソフトとこのソフトを使うとできそうです」

こんな感じの会話が出てくるのです。

しかし、経営者側は、既存のソフトを使うのではなく、自分たちで作り育て、自社開発ソフトとして出したいのだと思います。そうすることで、会社の宣伝効果、売上向上を狙っているのでしょう。

私達、技術者側から見ると、アイデアの出し方を工夫してもらいたいと思います。自分たちで作るしかないと思えるような問いかけをお願いしたいです。

「このソフトじゃこんな点で物足りないから作れないかな？」
「今のソフトにこんな機能を入れたいけど作れる？」

こんな問いかけから、問題の本質を解いて、ソフトを改良することは、私達、技術者の得意とするとこなのです。

しかし、既存であるソフトと同じものを、イチから作ろうといったアイデアには、どうしても興味がわかないし、そのソフトを超えるソフトを作れる気がしないんですよね。
正直。

この経営者と技術者の認識の溝を埋めるには、どうしたらいいのだろうと、最近よく考えています。