ビジネスでは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を、うまく使い分けることで、ビジネスを伸ばしていけるのではないでしょうか。

では、今日はこの辺で。

プログラミングのロジックはアナログから考えろ

こんにちは。

経験が浅いプログラマーは、
「このプログラムのロジックが思いつかない。」
「プログラミングのロジックってどうやって考えれば良いの？」
と悩むことがあると思います。

ロジックというのは、処理の手順のことです。

私は、以下の方法でロジックを考えています。

1. プログラミングのロジックはアナログから考える
2. アナログな方法を抽象化する
3. ループ処理を入れ子にしない

私は10年以上プログラマーとして働いて来た。
経験が浅い頃は、ロジックが分からなくで悩んだりしていました。
でも、今ではロジックが分からなくて悩むことはなくなりました。

いろんなロジック考え実装してみて、たどり着いた結論が上の３つの方法になります。

以下で細かく説明していきます。

１．プログラミングのロジックはアナログから考える

プログラミングのロジックは、
アナログな処理を自動化することです。

なので、まずは、
「自分がこの処理をするなら、どうやってやるか？」
を考えてみましょう。

例えば、
与えられた２つの数字から、その間の合計を計算するロジックを考えてみます。
与えられる数が１と１０なら、５５を返えします。

その場合、
１＋２＋３＋４＋５＋６＋７＋８＋９＋１０＝５５
と計算しますよね。

なのでロジックとしては、以下になります。

1. 与えられた小さい数に１を加える
2. 与えられた小さい数を合計に加える
3. 合計に１で作成した値を加える
4. １で作成した数に１を加える
5. ３、４を繰り返す
6. ４で作成した数が与えられた大きな数になったら終わり
7. 合計を返す

でも、実際にプログラマーとしてロジックを作っていると、
アナログな方法が分からないこともあります。

そんな時は、プログラミングの依頼内容が理解できていないのです。

なので、プログラミングを依頼して来た人に聞いてみましょう。

つまり、プログラミングのロジックを考えるにはアナログな方法を考えるのが1番です。

２．アナログな方法を抽象化する

上で書いた方法は、アナログなロジックです。

プログラミングする上では、アナログなロジックでも良いのですが、
処理速度が遅くなることがよくあります。

上の例だと、与えられる小さい数と大きい数の差が大きい場合、時間がかかってしまいます。

そこで用いるのが抽象化の考えです。

上の例だと、数学に強い人はすぐに分かると思いますが、
以下の式で求めることができます。

合計 = n * (a + b) / 2
aとbは与えられた数
nは、aとbの間の個数 (b - a + 1)

このように、ロジックを抽象化することで、
常に同じ処理時間で処理できるロジックを作ることができます。

３．ループ処理を入れ子にしない

これは、プログラミングのロジックを考える方法ではないのですが、
ロジックを考える上で、常に頭に入れておいた方がいいことです。

ループ処理というのは、繰り返し行う処理のことです。

つまり、繰り返し処理の中で、繰り返し処理を行わないということです。

ループ処理が入れ子になると、処理時間がかかるからです。

例えば、
10回ループする処理の中で、100回ループする処理が入っていたとします。
すると、その処理の中では、1000回の処理が実行される事になるのです。

ループの回数が固定なら、同じ処理時間で終わるのでいいのですが、
ループの回数が与えられた数で変動する場合は、処理を見直した方がいいです。

特にwebシステムの場合は、データが多くなるにつれて処理が重くなり、
挙句の果てに、画面表示がタイムアウトする事になります。

このような不具合はよくある事で、
最初はサクサク動いていたのに、使っていくうちに重くなっていくのです。

どうやって勉強すればいいの？

最後に、プログラミングのロジックの勉強方法について書きますね。

プログラミングのロジックは、
「どんなシステムを作るのか」
「どんな処理を作るのか」
とさまざまです。

なので、勉強して覚えられることではありません。

でも、いろんなロジックを見ていると、
「あそこで使ってたロジックが使える」
「あのロジックを少し変えれば使える」
と思い出せるようになります。

経験が浅いうちは、ソースコードを読む事も少ないと思います。

しかし、Web上には多くのシステムのソースコードが公開されています。

公開されているソースコードをまずは読んでみましょう。

何故このようなロジックになっているのか
を考える事でプログラミングのロジックを鍛える効果があります。

また、プログラミングについても知識を増やせると思います。

まずは試してみてください。

では、今日はこの辺で。

プロジェクトのリスクはマネージメントする事で軽減できる

「プロジェクトのリスクをマネージメントするにはどうしたら良いか？」

私は、プロジェクトを任されると、いつもこの疑問にぶち当たってしまいます。
特に、初めてプロジェクトを任された時は、この疑問が重くのしかかって来ました。
なので、今回は、そんな自分へ向けて、解決策を明示したいと思います。

結論を言うと以下になります。

1. 管理
2. 監視
3. 見直し

私は、これまで大きなプロジェクトのマネージメントの経験はありません。
しかし、複数の小さなプロジェクトをマネージメントして来た。
また、その中で、大きな問題は発生してしまい、何度も失敗を繰り返して来ました。
そんな私が、以下で説明していきます。

プロジェクトのリスクはマネージメントする事で軽減できる。

プロジェクトでは、複数のリスクが発生します。 そのリスクを回避する事で、プロジェクトは利益を得るのです。

では、どのようにマネージメントするのかについて、以下で書いていきます。

１．管理

管理する内容は以下になります。

• リスク内容
• 判断基準の作成
• 対応策の作成

リスク内容

プロジェクトのリスクは、経験上、似た内容のリスクが考えられます。
そのため、経験を詰めは、リスク内容は現実的になって来ます。
システム会社ならば、それまでの実績からリスクの一覧は既にあるでしょう。
なので、リスク内容の精査をするだけで、リスク内容の一覧はできるでしょう。

判断基準の作成

こちらも、既にある判断基準を利用できます。
しかし、プロジェクトの規模によって判断基準は変わって来ます。
なので、判断基準は、プロジェクトごとに見直す必要があります。

対応策の作成

対応策については、プロジェクトごとに考える必要があると、私は考えています。
マネージャーによっては、既存の対応策を使用する方もいます。
しかし、プロジェクによって状況が違うため、対応策については、その都度考える必要があると思っています。

２．監視

監視は、上記で書いたリスクの一覧をもとに、プロジェクトを監視します。
プロジェクトの状況が、判断基準を超えないようにすることが重要です。

プロジェクトは、状況が刻々と変わっていきます。
そのため、リスクの判断基準の監視を忘れていると、いつの間にか超えていたと言う状況になるのです。

ただ、マネージャーを経験したことのある方は分かると思いますが、マネージャーの仕事は多いのです。
しかし、リスクが発生してしまうと、大きな損失を被る可能性が高いので、リスクの監視は常に行うようにしましょう。

良い方法としては、定期的に行うことです。
例えば、朝と定時前に判断基準をもとに確認することです。

リスクによっては、数時間間隔で確認する必要があるかもしれません。
その時は、数時間間隔で確認をするのです。

特に、判断基準に近づいているリスクなどは、数時間間隔で監視した方が良いです。

３．見直し

リスク一覧は、定期的に見直すことも必要です。

プロジェクトは、時々刻々と変化しています。
そのため、プロジェクト初期に作成されたリスク一覧は、工程やフェーズによって見直す必要があるのです。

もちろん、対応策についても見直しが必要となります。

私の経験から言うと、工程ごとにリスクは違って来ます。
また、後工程になるほど、対応策が具体的になって来ます。

何故、後工程ほど対応策が具体的になるかと言うと、プロジェクトの初期は、自分のチームで解決する必要があることでも、後工程になるとお客様の状況も分かるようため、お客様を含め解決策を返答することができるのです。

例えば、プロジェクト初期では、試験工程に遅延が発生したとしても、マンパワーでやり切るしかなかったリスクも、後工程になると、お客様に手伝ってもらう対策も打てるようになるのです。

ただし、プロジェクト初期でリスク対策を検討する時に、お客様を当てにするのは間違いです。
十分にコミュニケーションを取った後で、もしもの時は手伝ってもらえる状況が作れた時にお手伝いをお願いする事になります。

なので、それまでに、お客様の状況や立場を十分に理解し、プロジェクトの状況も共有して理解してもらう必要があるのです。

このように、リスクは、工程やフェーズで見直す必要があるのです。

まとめ

今回は、プロジェクトのリスクをマネージメントする方法についてまとめてみました。

結論は、リスク一覧を作成し、プロジェクト中はリスクの監視をします。 そして、工程ごとにリスクを見直しするのです。

こうしてプロジェクトのリスクマネージメントについて書いていると、そんなに難しくないように思えるかもしれません。 しかし、実際にやってみると、これが凄く難しいのです。

私も、これからも試行錯誤していくと思います。

では、今日はこの辺で。

仕事をしたくない・辞めたい時は自分の時間で勉強しよう

私も「仕事したくない」「仕事辞めたい」と思うことがよくあります。

そのような時は、私の場合、以下のような気持ちになっていることが多いです。

• 仕事が面白くない。
• 今の仕事に将来性を感じない。
• 仕事をしたくない時どうしたら良いだろう。

そのような時、私は以下の順番で次の行動を考えています。

1. 仕事をしたくない・辞めたい時は自分の時間で勉強しよう。
2. 作業がマンネリ化しているなら、こっそり広げてみよう。
3. 仕事以外の時間を大切にしよう。
4. ハラスメントがある会社からは、すぐ辞めよう。
5. ブラック企業からはすぐに辞めよう。

私の経歴としては、最初ブラック企業で働いていました。
その時は、会社がブラック企業だと分かってすぐに辞めました。

その後、働いた会社では、ブラック企業にSESで常駐で作業ををしていました。
その時は、精神的に病んでしましました。

今は、結構ホワイトな会社で働いていますが、それでも、「仕事したくない」「仕事辞めたい」と思うことがあります。

こんな私が、以下で説明していきます。

１．仕事をしたくない・辞めたい時は自分の時間で勉強しよう。

仕事がしたくない、辞めたいと思った時は、自分の時間でまず勉強しましょう。

仕事は、ビジネスを行う場であって、実績が１番です。
なので、やりたい仕事と、実際にやれる仕事は一致しないのです。

しかし、仕事以外の時間は、あなたの時間です。
その時間を使って、まずはやりたいことの勉強をしましょう。

このような思いを抱く時は、仕事以外の時間をダラダラと過ごしていないでしょうか。
やりたい仕事ができなくて、ストレスが溜まっている状態ではないかと思います。

そう言う場合は、仕事は淡々とこなし、自分の時間を充実させることで、やっている感が感じられるはずです。

こんな主張をすると、「仕事で疲れいるからできない」と言う人がいます。
私も仕事後は疲れていて、何もやる気がしない状態になっていました。

でも、だからと言って何もやらないと、やりたい仕事につくことは難しいです。

なので、仕事がしたくない、辞めたいと思った時は、自分の時間でまず勉強しましょう。

２． 作業がマンネリ化しているなら、こっそり広げてみよう。

例えば、プログラマーで新卒で就職すると最初は、試験からただと思います。

長い時は、1年以上試験ばかりをする事になる場合もあります。

でも、プログラマーとして就職したのだから、プログラミングをやりたいですよね。
そのギャップがストレスになると思います。

なので、上でも書いたのですが、まずは自分の時間でプログラミングの勉強をしましょう。

そして、ある程度、基礎勉強が終わったら、実際に仕事で実勢してみましょう。

システムの試験を行っているのであれば、不具合が発生した時に、原因をソースコードから探してみましょう。
時間がかかるかもしれませんが、そうする事で、ソーコードを読む力がつきます。

また、修正された場合、修正箇所を確認すると言うのも良いと思います。

結果的に、自分の活動範囲が広がっていきます。

不具合の原因をソースコードから見つけれるようになると、そればあなたと実績となります。
実績を積むと、必ず次のステージへ上がることができます。

３．仕事以外の時間を大切にしよう。

これまでは、自分の時間で勉強しましょうと主張して来ましたが、仕事以外の時間を大切に過ごすだけでも、十分に変化が感じられると思います。

どうしても、仕事を終えて家に帰ってくると、ゆっくりと休みたい気持ちになりますよね。
でも、その時間、本当に休めていますか。

テレビを見たり、スマホを見たりして、結局、ダラダラと過ごしてしまっているのではないでしょうか。

私も、最近までそのような生活を送っていました。

でも、それって本当の意味で休めていないんですよね。
「ダラダラ過ごす＝時間の浪費」なのです。

仕事をしている時もそうですが、ダラダラ時間を浪費するくらいだったら、「就業時間８時間で、これだけの成果を出す」とか、「この時間で勉強する」と言ったように、時間に区切りをつけて生活をした方が、精神的にも楽になります。

また、寝る前にテレビやスマホを見ると、寝つきがよくないと言った研究成果も報告されているようです。

みなさんも、仕事以外の時間を見直してみてはどうでしょうか。

４．ハラスメントがある会社からは、すぐ辞めよう。

仕事以外の原因として考えられるのが、ハラスメントがある会社ですね。

パワハラ、セクハラなど、こう言ったハラスメントがある会社は、すぐに辞めるのが一番です。

一昔前までは、こう言ってハラスメントは日常茶飯事でした。

私が社会に出て最初に就職した会社も、パワハラが凄かったです。
私は、社会に出てすぐだったので、これが社会なんだと最初は我慢していたのですが、1年で辞めました。
辞めてハローワークで相談して、初めてこれがパワハラだと知ったのです。

ちなみに、その会社は、私が辞めて1年後に従業員が全員で辞表を提出して解散となりました。

今でも、パワハラ、セクハラを行う人はいます。
そう言う会社は、ハラスメントをする人を、ある意味野放しにしている会社なのです。
なので、そう言う人がいる会社は、辞めてしまいましょう。

５．ブラック企業からはすぐに辞めよう。

世の中には、ブラック企業が今でもたくさんあります。
法律的にもグレーなビジネスをしている会社です。

例えば、長時間労働を強いる企業です。
今は、長時間労働は違法ですが、1日のタスクが8時間で終わらないようなものを渡す会社は、今でも存在します。
口では、「長時間労働をしないように」と言っていますが、長時間労働をしないと終わらないタスクばかりなのです。

また、営業で女性がいる方が良いからと、女子社員を連れ出すと言ったことも、実は行われていたりします。

そのような会社は、ブラック企業なので、すぐに辞めましょう。

まとめ

今回は、「仕事をしたくない」「仕事を辞めたい」と思ったときに取る方法について考えてみました。

結論としては、仕事以外の時間を大切にして、勉強をし、仕事に役立てるようにすると、緩和されるのではないかと思います。

しかし、ハラスメントがあったり、ブラック企業などは、すぐに辞めてしまいましょう。

仕事以外の時間を大切にしても、どうしても「仕事をしたくない」「仕事を辞めたい」と思う時は、会社を辞めてしまうのも良いと思います。
今は、１つの会社で一生頑張るような時代ではありません。
今の会社で実績ができたら、あっさりと辞めてOKだと私は思います。

では、今日はこの辺で。

プログラマーでうつ病になる人が多いけど、何故そんなに多いのかな？

以前、知り合いから「プログラマーでうつ病になる人は多いですね？」と言われたことがあります。
私も7年ほど前にうつ病と診断されて治療中なので、
「プログラマーはうつ病になりやすいのか？」
「プログラマーは何故うつ病になるのか？」
について考えてみました。

結論を言ってしまうと以下になります。

1. プログラマーでうつ病になる人は多いです。
2. プログラミングは、動かないことがよくあるため悩みも多くなってしまいます。
3. システム開発は、プログラマーに依存しているの原因かも。

私は、プログラマーとしての経験が10年以上あり、これまで多くのプロジェクトに携わって来ました。 そして、私自身うつ病で苦しんだ経験があり、現在でも治療中ですが心身ともに安定した生活が遅れています。

こんな私が、以下で詳しく説明していきます。

１．プログラマーでうつ病になる人は多いです。

ぶっちゃけ、IT系でうつ病になる人は多いです。

私が携わったプロジェクトにも多くのうつ病患者がいました。
大体、うつ病になるプログラマーは、責任感の強い方や、作業の早いプログラマーです。
仕事は、そのような方に集まるのです。

これは、プログラマーだけではないと思います。

２．プログラミングは、動かないことがよくあるため悩みも多くなってしまいます。

プログラマーがプログラミングすると、すぐに動くプログラムができると思うかもしれません。

しかし、結構動かないことが多いのです。

プログラマーは、何故動かないかを、ひとつひとつロジックを追いながら、正常に動くプログラムへ修正していくのです。
なので、何故プログラムが正常に動かないかが分からないと、ストレスも溜まっていくのです。

システム開発は、チームで行っているように見えますが、それぞれが異なる処理をプログラミングしています。

そのため、個人で作業しているのと同じなのです。

その様なところも、プログラマーにうつ病が多い原因なのではないでしょうか。

３．システム開発は、プログラマーに依存しているの原因かも。

システム開発は、プログラマーに依存しているため、うつ病になる方も多いのではないでしょうか。

上にも書きましたが、システム開発は、チームで行っている様で、実は個人で行っているのです。
特に作業が早いプログラマーには、予定以上の作業が流れて来ます。
その分、プログラマーへかかるストレスは大きなものになるのです。

チームで開発を行うと、チームメンバーには、プログラマーとして経験が長い方から浅い方までがいます。
なので、均等に作業を分配してしまうと、経験が浅い方が担当したプログラミングが遅れてしまいます。
それをカバーするために、経験のあるプログラマーへ多くの作業が流れてしまうんです。

私は、経験が浅いメンバーのチームで開発を行っているときに、うつ病になってしまいました。

この様な主張をすると、「チームリーダーが無能なんだ」と言った意見が聞こえて来ますが、チームリーダーのみに責任を押し付けるのはどうかと思います。

私も、チームリーダーをしたことがありますが、集められたメンバーの経歴などは、ほとんど知らされません。
特に大きなチームになると、パートナー会社からの出向だったりで、その人がどこまでできるのか分からないまま、開発を開始するのです。

つまり、システム開発がプログラマーに依存しているため、プログラマーはうつ病になり易くなるのでしょう。

では、どの様にすればプログラマーのうつ病は減るのでしょうか？

結論としては、以下の対応が必要だと思います。

• 無理をして仕事をしない。
• 1日５〜６時間で終わるタスクにする。
• 適度に運動する。
• 心療内科を受診する。
• 休みをとる。

あなたが仕事をしなかったとしても、仕事は周ります。
逆に言うと、あなたが仕事をしないことで、仕事が回らない様なら、会社が社員に依存する風土があると言うことです。
その様な会社は、将来性がありません。
転職をお勧めします。

ストレスが溜まったら適度な運動が効果的です。
30分程度のウォーキングで十分です。

ストレスで心身に影響が出たら、心療内科を受診しましょう。
心療内科で医師と相談し、適切な薬などを処方してもらいましょう。

少し休暇を取るのも良いと思います。
収入が気になるかもしれませんが、会社員の場合は傷病手当が受けられます。

詳しく書くと、長くなるので別のブログに書こうと思いますが、基本、無理をしないことです。

まとめ

今回は、「プログラマーでうつ病になる人は多いのか？」「プログラマーは何故うつ病になるのか？」について考えてみました。

結論として、プログラマーでうつ病になる人は多いです。

原因としては、プログラミングは、動かないことがよくあるため悩みも多くなり、ストレスも溜まりやすいのです。
また、システム開発は、プログラマーに依存しているため、プログラマーへのストレスも大きくなると思われます。

では、その改善方法としては、無理をしないで、適度に運動し、それでもダメなら、心療内科を受診しましょう。

プログラマーのみなさん、無理をしないようにしましょうね。

では、今日はこの辺で。