ドラッカーのマネジメント論を開発プロジェクトに置き換えて考察してみた

ドラッカー マネジメント 開発エンジニアコラム

はじめに

 本記事では、オーストラリア出身で「経営学の父」とも言われるピーター・ドラッカーのマネジメント論をシステム開発に置き換えてみると、どんな効果が得られそうかを考えてみた記事です。ドラッカーは経営を主軸においていますが、経営とシステムは現代では切ってもきれない関係になっており、開発プロジェクトが頓挫すれば経営も傾いてしまう状態の会社もたくさんある。

 ベンダーやユーザーと言えどもあらゆる会社でソフトウェアやハードウェア、クラウドが開発・利用されていることを背景に、ドラッカーのマネジメント論を応用することでシステム開発を上手くリードすることが出来るのではないかと考察してみたい。

本記事の読み方

 ドラッカーはマネジメントを「組織に成果をあげさせるためのもの」と定義している。システム開発で言えば、プロジェクトそのものが組織に値し、開発プロジェクトの目的はQCDのバランスを考慮し、高品質なシステム・サービスを作り上げることが使命である。

 本記事ではドラッカーが組織を如何にマネジメントするかを、プロジェクトに置き換えて考えてみることにする。※本記事は下記の本を参考にしています。

開発プロジェクトのマネジメント

 ドラッカーのマネジメント論を開発に置き換えて見ると、プロジェクトをマネジメントをする上で最も大切な要素は次の3要素である。

Point

① プロジェクトの使命
② プロジェクトの生産性
③ プロジェクトの社会的責任

プロジェクトの使命

 ドラッカーはどんな組織(政府や組織、教育機関、企業)であっても使命が大切で、誰かのニーズを満たすために存在していると論じている。

 開発プロジェクトも同様で、使命なきプロジェクトを完遂することなど不可能であり、システムやサービスは誰かに利用してもらうために開発プロジェクトが存在すると考える。本来プロジェクトでは特定の個人が、一時的な期間を伴った共通の目的のために存在しているものであり、ゴールに到達すれば解散するというのがプロジェクトの本質である。

 皆さんも、「このプロジェクトは何のためにやっているのだろうか」と思ったことはないだろうか。これはプロジェクトが存在する意味(使命)が伝達されていないか、そもそも明確に決められていないことが多く、このようなプロジェクトは大抵炎上している。少なくともプロジェクトをマネジメントする場合には、ドラッカーが掲げる5つの質問に答えられないのであれば、プロジェクトとして成り立っていないので、見直す必要があるだろう。

Check

① われわれのミッションは何か?
② われわれの顧客(ユーザー)は誰か?
③ 顧客(ユーザー)にとっての価値は何か?
④ われわれにとっての成果は何か?
⑤ われわれの計画は何か?

 ここで注意しておきたいと思うのが、「④ われわれにとっての成果は何か?」である。短期的に見ればシステムを納品することが成果になってしまうが、そうなってはいけないと考えている。他の問にもあるように、開発プロジェクトの目的は常に顧客(ユーザー)目線で、価値を提供することにあり、開発することが目的になってしまうことは避けたいところである。

プロジェクトの生産性

知的労働社会

 現代では1900年代の大量生産社会と違って、大量に同じものを作っても売れない。既に世の中にモノは溢れかえっている。そして2000年代には知的労働社会になり、単純に作って売るというビジネスモデルから、労働者の知識を活用して各企業独自の製品やサービスを作っていくことが必要である。

 最近ではアウトソーシングや副業なども流行ってきており、ますます個々人が持つ専門性に焦点が当てられている。また、大量生産社会では企業が生産設備を持ち、労働者はそれを利用することでモノを作っていたが、現代では専門性を持つ労働者達そのものが生産設備を所有していることと同等になっている。そのため、専門性を持つ方たちは生産設備を「移動」することが簡単になっている

 このような時代に大事になってくるのは、専門性を持つ人達を如何にマネジメントして生産性をあげていくかということになる。ドラッカーは生産性向上のための条件を6つ定義している。

Point

① 仕事の目的を考える
② 自らがマネジメントを行う
③ 継続してイノベーションを行う
④ 自ら継続して学び、人に教える
⑤ 量より質だと知る
⑥ 組織にとっての資本財

 

変化をマネジメントする

 知的労働社会では知識が生産設備となるため、常に知識をアップデート(変化)させていくことが必要になる。これは個人の労働者だけでなく企業も同様。ドラッカーが推奨している方法として、「体系的破棄」というものが存在する。

 これは、全ての仕事や作業を実行していないと考え、その上で今からでも実行するかと問い、「ノー」ならば破棄するという考え方である。プロジェクトを始めると報告のための資料作りや、大した意味もない進捗会議などあるのではないだろうか。プロジェクト開始直後であれば必要であったものでも、必要がないものはどんどん破棄していくことが必要だ。

 この考え方と似ている開発手法としてアジャイル開発/スクラム開発というものがある。アジャイル開発は簡単に言えば必要な要件を優先度を上げて開発し、常にリリース可能なシステムを開発していくことである。スクラム開発はアジャイル開発手法の一つであり、決定しない要件に対して柔軟に変更を加えていくことで、よりユーザーのニーズに合った開発をしていくことが可能になる。詳しい説明は下記を参照してください。

強みにフォーカスする

 プロジェクトを複数メンバーで行っていれば、各個人によって「強み」「弱み」が出てくるだろう。ただ、この時に「弱み」に着目して克服しようとしないことが知的労働者会では重要になってくる。日本の教育制度だと受験などもあってか、弱い教科を重点的に克服することを求められるため、弱みを克服させようとする会社は多い。

 一方ビジネスでは、より専門性を持ったビジネスモデルや企業が勝つことは明確になっている。アップルでは従来コンピュータのハードウェアを製造していたが、中国などが台頭してきてからは撤退をしている。アップルでは製造は弱みだったからだ。

 開発プロジェクトでも同じで、各エンジニアに弱みを克服させようと無理に強いることは辞めておきたい。例えば、開発・実装が得意で管理が苦手なメンバーに、管理業務を割り当てることは必要ない。それならば管理が得意なメンバーに任せれば良い。ただ、1点注意しておきたいのは、その「弱み」によって「強み」が阻害されている場合は、早急に克服させるべきだろう

プロジェクトの社会的責任

 ドラッカーは企業が果たすべき最も重要な社会的責任とは、特定の社会目的の達成、つまりは使命の遂行と論じている。これをプロジェクトに置き換えて考えてみると、少し大袈裟な感じもするが、プロジェクトにも必ず使命が存在し、その使命が社会的責任に繋がっていることは間違いない。

 現在日本では老年人口(65歳以上)が増え、生産年齢人口(15〜64歳)が減り続けている。2065年には生産年齢人口は現在の60%程度から50%程度まで減少し、人口全体では9000万人近くまで減少すると見られている。

 こうした中で1プロジェクトが社会的責任を負うというのは中々考えづらいところではあるが、製品やサービスを開発することで顧客(ユーザー)を想像し、ひいては経済的発展につながるということを考えれば、製品を生み出すことへの責任と、将来に対する責任を持つと言えるだろう。

 前者については言わずもがなで、新製品を作り経済を回していくことで社会に対して何らかの貢献ができることはイメージできる。後者については、例えば選挙における投票システムを開発したとしよう。日本が抱える人口減少による生産労働人口の減少を考えれば、現在のような投票所を運営していくことは到底困難になるとともに、投票システムが存在することで将来の労働者は、より専門的な仕事を行うことが出来る。こういった側面を考慮すると、将来の社会問題に対しての社会的責任を負っていると考えられる。

顧客(ユーザー)とは誰か?

 何度か顧客(ユーザー)という言葉が出てきているが、これをもう少し深堀りしてみよう。顧客にはシステム・サービスと直接している想像しやすい顧客と、潜在的な顧客がいると考えられる。ベンダー企業であれば目の前にいるクライアントが顧客になるだろう。ユーザー企業であればシステム・サービスを利用してもらうインターネットを介したユーザーかもしれない。

 しかし、実際には想像しやすい顧客(ユーザー)だけでなく、潜在的にいる顧客(ユーザー)を見落としてはいけない。例えば分かりやすい例で言うと、認証システムを伴った経理システムがあるとする。経理システムそのものは依頼元のクライアントが利用するためのシステムなので顧客(ユーザー)はクライアントになるだろう。

 一方認証システムのみが欲しい潜在的な顧客も存在するかもしれないという前提に立てば、認証基盤はベンダー企業で所有し、その上に経理システムをサービスとして乗せることで、潜在的に認証システムのみを利用したい顧客に別サービスをコストを下げて再開発することができる。いわゆるシステムの再利用性と言われるものだ。エンジニアだとライブラリなどがそれに値するだろう。こうした顧客を見落とさず、我々の顧客は誰になるのかということを本質的に考える必要がある。

まとめ

 今回は、ドラッカーのマネジメント入門を軸に、経営・企業マネジメントを流用して開発プロジェクトに応用できないかと考察してみました。少々強引な部分はあると思いますが、現代では開発プロジェクトそのものがビジネスになり得るケースが大半を占めており、活かせる部分は大いにあると思います。

 特に、プロジェクトの使命を考えることは最も大事なことがだと考え、企業が存在する意義からブレークダウンし、「なぜこの開発プロジェクトが必要なのか」ということを明確にした上で、プロジェクトを始めることが成功に繋がる大きな要因であることは間違いないと思う。

 一方実際に開発を行っていく上では、使命があるだけでは不十分で、アジャイル開発/スクラム開発のような具体的な手法を活かしていくことも必要だと考えます。下記にスクラム開発においてのアンチパターンを書いていますので、開発を行っている方はぜひ見ていただきたいと思います。

 最後に、オススメのドラッカー書を紹介して終わりたいと思います。

最後まで読んで頂きありがとうございます!

面白かった、参考になった、と少しでも感じて頂けましたら
ブログランキング上位になるための応援をして頂けないでしょうか!
今後も面白い記事を更新していきますので、ぜひ宜しくおねがいします!
エンジニアコラム
【TechGrowth】

コメント