ビジネスでは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分程度のウォーキングで十分です。

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

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

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

まとめ

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

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

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

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

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

では、今日はこの辺で。

PHP初心者が勉強する方法は？

こんにちは。

最近、「プログラミングを勉強しています」という声をよく耳にします。

特にWebエンジニアを目指している方が多いようです。

Webエンジニアになるには、以下の技術が必要になります。

• HTML
• javascript
• PHP

HTML、javascriptは、クライアント側で主にデザイナーが担います。

PHPは、サーバー側でエンジニアの仕事となります。

そこで今回は、PHP初心者へむけて勉強方法を書いていきます。

ちなみに、私は、組み込みエンジニアとして7年ほど、その後は、Webエンジニアとして10年ほど働いて来ました。

PHP初心者が勉強する方法は？

PHPを勉強する方法は、以下になります。

1. 基礎を勉強する
2. ソースコードを読む
3. 実際に作業を行う

PHPに限らず、プログラム言語を勉強する方法は、上の３つになります。

では、詳細を以下で説明します。

１．基礎を勉強する

何をやるにも基礎は大事です。

なので、PHPの勉強も基礎からやっていきます。

まずは、Hello World からですね。

いろんなプログラム言語を習得している方でも、はじめはここから始めます。

理由は、使用する環境が正常に動作するかの確認です。

その後は、プログラミングの基礎の勉強をします。

• 分岐
• ループ
• 関数
• クラス

この辺ですかね。

PHPの基礎については、Webで「PHP 入門」と検索すれば、たくさん出て来ますので、そこで勉強すればOKです。

なので、ここでは細かく取り上げません。

２．ソースコードを読む

PHPの基礎が理解できたら、一旦、他の方が書いたソースコードを読んでみましょう。

この、「ソースコードを読む」を飛ばして、実際に作業をする方が多いですが、そういう方が書いたソースコードは、読み辛く、無駄な処理が多いです。

ソースコードは、同じ処理や同じような処理を、関数やクラスでまとめて重複しないようにするのが１番です。

そう言った方法は、他の人が書いたソースコードを読むことで身に着きます。

まずは、ソースコードを読んでいて読みやすいと思うソースコードを真似することで、自分でも読みやすいソースコードが書けるようになるのです。

また、プログラミング言語には、それぞれにコーディング規約があります。

PHPだとSRP-2ですかね。

コーディング規約を読むことも必要なのですが、いろんなソースコードを読んでいると、次第に身に着いてきます。

今では、githubなどで多くのソースコードが公開されています。

ここで必要なことは、ロジックを理解する事ではなく、ソースコードの書き方や、クラスのまとめ方を見るようにしてください。

３．実際に作業を行う

ここまで来ると、勉強はおしまいです。

実際に作業をしましょう。

最初は、難しいと思います。

実際の作業は、勉強とはレベルが違います。

しかし、勉強ばかりしていても、実績が着きません。

なので、実際に作業をしながら勉強するようにしましょう。

PHPには、標準でいろんな関数が用意されています。

Webで検索すれば出て来ますので、困ったときは検索するようにしましょう。

それでもない時は、ロジックから考えて作ることになります。

技術は本では身につかない

PHPなどのプログラミングもそうですが、技術と言われるスキルは、本を読むだけでは身につきません。

本で知識を習得したら、手を動かし実際にやってみる必要があるのです。

プログラミングを習得するなら、本を読みながら手を動かし、実際にソースコードを書いてみて動かしてみるのです。

最初は、動かないことが多いかもしれません。

でも、それを乗り越える事でスキルは身についていくのです。

そして、基礎勉強が終わったら、実際に作業をする必要があります。

上にも書きましたが、実際に作業としてプログラミングを行うと、壁に何度もぶつかります。

それを、一つずつ乗り越える事で、実績が積み上げられるのです。

まとめ

今回は、PHP初心者が勉強する方法について書きました。

1. 基礎を勉強する
2. ソースコードを読む
3. 実作業を行う

この方法は、他のプログラミング言語を勉強する時も同じです。

コツコツと勉強することができれば、数ヶ月で実際に作業ができるまでに成長できます。

でも、モチベーションが保てなくて挫折する人も多いです。

そんな時は、お金を払ってプログラミング講座を受講するのも良いと思います。

お金を払って勉強しても、実際にプログラマーになれば、すぐに元が取れますし、勉強するモチベーションも保てると思いますよ。

では、今日はこの辺で。

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

こんにちは。

ここ数年、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への投資を検討してみてはどうでしょうか。

では、今日はこの辺で。

ITエンジニアのスキルアップ

こんにちは。

今回は、ITエンジニアのスキルアップについて書きます。

新卒でITエンジニア会社の内定をもらっても、これからどのようなスキルアップがあるのだろうと不安に思うでしょう。

私も、新卒で内定を貰った時は、嬉しさと同時に不安が込み上げて来たのを覚えています。

結論を言うと、ITエンジニアとして就職した人の一般的なスキルアップは以下になります。

1. テスター
2. プログラマー
3. 機能リーダー
4. システムエンジニア 
5. プロジェクトマネージャー

これは、理想的なスキルアップで、人生は理想的にはいきません。

１．テスター

新人でITエンジニアとして就職すると、まずはテスターとしての仕事をすることになるでしょう。

開発中のシステムを試験仕様書に基づいて試験していくのですが、結構、大変だったりします。

テスターの仕事って、同じ作業を何度も繰り返すことになります。

最初は楽しいのですが、数週間で飽きてくるんですよね。

それに、不具合を見つけると、プログラマーの先輩からウザがられるんですよね。

私もそうでした。

不具合を見つける数が多かったため、先輩プログラマーからよくウザがられていました。

なので、私は、不具合が発生すると、本当に不具合なのかを仕様書や設計書、プログラムを調査した上で、先輩プログラマーへ報告するようにしました。

そうすることで、プログラマーへのスキルアップを成し遂げたのです。

２．プログラマー

プログラマーは、多くのITエンジニアが目指すポジションだろうと思います。

しかし、プログラマーの作業範囲は、思った以上に広範囲です。

基本設計から詳細設計書を作り、製造、単体試験を行う事が仕事です。

プログラマーは、動くものを作るのが仕事です。

ですが、正常なデータで動くものだけを作るのではなく、異常データや想定外のデータでも動くものを作る必要があります。

なぜこのようなことを書くかと言うと、正常なデータ、異常なデータで動くものは作っても、想定外のデータで動くものを作るプログラマーは少ないのです。

想定外を想定でいるようになると、プログラマーとしては上級と言えるでしょう。

３．機能リーダー

上級のプログラマーとなると、部下を着けてさらに大きな機能を任されるようになります。

機能リーダーは、自分で作業する事がなくなります。

代わりに、期間内で最大の物作りの戦術を考え、実行する事が仕事となるのです。

つまり、マネージメントです。

どのようにすればチームの力を最大化できるのか、どうすればチームの負荷が下がるのかを考えるのが機能リーダーの仕事になるのです。

４．システムエンジニア

次のステージは、システムエンジニアになります。

システムエンジニアの仕事は、お客様との打ち合わせで、お客様が求めるシステムの要件をまとめることです。

システムの仕様書を作成するのはお客様です。

しかし、中小企業のシステム開発では、仕様書作成もシステムエンジニアが担うことになる事がよくあります。

そのためには、お客様のビジネスを理解し、必要とされている要件を検討する必要が出て来ます。

５．プロジェクトマネージャー

プロジェクトマネージャーは、ITエンジニアとして、最上級のポジションと考えている人が多いかもしれません。

プロジェクトの責任者であり、最終決定権を持つことになります。

なので、常にコストとリスクについて検討する必要があります。

中小企業のシステム会社の場合

中小企業のシステム会社は、機能リーダー、システムエンジニア、プロジェクトマネージャーがいない事が多いです。

その代わりの業務を、プログラマーが担っています。

そのため、プログラマーの仕事の負担は、もっと上がってしまいます。

なので、プロジェクトに遅延が発生する可能性が高いのです。

まとめ

一般的にITエンジニアとしてのスキルアップは、上に書いた５つです。

1. テスター
2. プログラマー
3. 機能リーダー
4. システムエンジニア 
5. プロジェクトマネージャー

１、２は物作り、３、４、５はマネージャーとなります。

中小企業のシステム会社では、３、４、５を専門でやる人材を持つのは難しいです。

なので、マネージメントを目指すのであれば、大手のシステム会社へ就職するのいいでしょう。

中小企業でプログラマーまでの経験を積み、大手へ転職すると言う方法もあるでしょう。

中小企業でプログラマーまでの経験を積むには１、2年で十分です。

なぜかと言うと、結構ハードな仕事を経験することになるからです。

その経験を持って大手に転職するのが、一番早いやり方ではないかと私は思っています。

では、今日はこの辺で。

会社を退職する前後で必要なこと

こんにちは。

今日は、会社を退職する前後で必要なことを書きます。

今の時代、新卒で入社した会社に、定年まで勤めると言うのは少ないと思います。

会社で働いた事が少ない学生が、自分に合った会社を見つけることは無理があります。

実際に仕事をしてみて、自分に合ってるかどうかが分かるものなのです。

ただ、会社を辞めるとなると、いろんな不安がありますよね。

なので、今回は、そう言う不安が、なるべく少なくなる方法を、私の経験をもとに書いていきます。

ちなみに、私は、これまでに3回退職を経験しています。

私は、プログラマーなのですが、この業界は、会社によってやれることや、給与が違って来ます。

なので、「給与をあげたい」「違う技術力をつけたい」と言った理由で、会社を辞めて別の会社へ移っています。

では、退職を決意してから、実際に退職した後までの流れの中で、やっておいた方がいいことを書いていきますね。

１．退職願を出す前にすること

まずは、退職願を出す前にすることについて書いていいます。

退職を決意してすぐに退職願いを出すのもいいのですが、できれば退職願を出す前にいくつか考えておいた方がいい事があります。

• 業務実績を整理する
• 退職理由を明確化する
• 次の会社の条件を整理する

大きく分けると、この３点です。

ここで考えることは、自分がこの会社で何をして来たのか、本当に退職しなといけないのかと言うことです。

業務実績を整理する

まずは、これまでの業務実績を整理しましょう。

自分は何ができ、どう言う仕事をして来たのかを整理していきます。

これは、次の会社を受ける際の職務経歴書を書くのと同じなので、直接、職務経歴書を書くのでも大丈夫です。

ここで考えてもらいたいのは、自分が今勤めている会社で、どれだけ成長したのかと言うことです。

新卒で入社したのであれば、職務経歴書を書くだけで、それ自体が自分の成長の記録となるでしょう。

退職理由を明確にする

退職理由は、人それぞれだと思います。

ただ、ここで考えてもらいたい事は、退職する本当の理由です。

上司のやり方に不満がある、業務内容に不満がある、作業に対して給与が安い、自分の技術力を存分に発揮できないなど、いろいろあると思います。

その本当の理由に対して、あなたはどう言う行動をして来たでしょうか。

上司に相談したでしょうか、自分の生産性を上げ会社に貢献したでしょうか。

何も行動していないのであれば、退職願を出す前に行動してみてはどうでしょうか。

退職の意思は固まっているのなら、ある程度の冒険をしてみるのもいいかもしれません。

実際、退職して次の会社へ移るとなると、大きなエネルギーが必要となります。

ストレスと言ってもいいでしょう。

なので、今勤めてる会社でやりたい事ができるのなら、退職はしない方がいいのです。

次の会社の条件を整理する

次に考えることは、次の会社の条件を考えることです。

よく、転職サイトを見ながら次の会社を考える人がいますが、これは間違いだと私は思います。

「隣の芝は青く見える」と言うことわざがあるように、転職サイトを見ていると、どの会社も今勤めている会社よりいい会社に見えてます。

そうではなく、自分のこれまでの実績や退職理由から、次の会社に求めることを整理した上で、転職サイトだったり求人情報を見る方がいいです。

例えば、給与に不満があり退職するのであれば、今の会社と同じような仕事をしていて、給与の良い会社を探すようにすると、転職で大きなエネルギーは必要なくなりますよね。

人によっては、全く畑違いの事に挑戦する人もいるでしょう。

その場合は、初心者でも実績が詰めるような会社を探す必要がありますよね。

ただし、全く畑違いの仕事に挑戦するには、入社までに基礎を勉強する必要が出て来ます。

例えば、営業からプログラマーへ転職するのであれば、次の会社を探す前に、プログラミングの勉強をする必要があります。

そう言う場合は、退職願を出す前に、プログラミングの勉強をするようにしましょう。

プログラミングの勉強は、少なくとも100時間以上は必要になります。

一人でプログラミングの勉強をするとなると、すごく大変なので退職願を出す前に少しずつ勉強をしておくことをお勧めします。

次の会社の条件を整理したら、その条件で従業員を募集している会社を探すことになります。

ただし、この段階で応募してはいけませんよ。

きちんと、退職願を提出し、退職日が確定してから応募するようにしましょう。

２．退職願が受理され退職する前にやること

ここでやることは、自分の仕事を人に引き継ぐ事と、退職後のことを考える事です。

• 自分がやって来た仕事を整理する
• 自分がやって来た仕事を引き継ぐ
• 退職後の事について考える

まずは、仕事の引き継ぎですね。

自分のやって来た仕事を整理する

仕事の引き継ぎは、今やってる仕事だけではありません。

これまで、あなたがやって来た仕事の全てを引き継ぐ必要があります。

あなたが退職した後、その会社から追加の仕事が入るかもしれません。

そんな時、引き継ぎをしていないと、誰も分からない状態になってしまいます。

なので、自分の会社でこれまでやって来た仕事を整理し、必要ならば新たに資料を作るようにします。

プログラマーの場合は、本番環境の情報や開発環境の構築方法、自分がコーディングしたロジックについてまとめておきましょう。

勤めていた期間が長い場合は、この作業が一番時間がかかる作業になると思います。

できれば、その都度、必要な資料をまとめておくのがいいです。

私の場合は、会社のファイルサーバーに、その都度、資料を作成していってます。

自分のやって来た仕事を引き継ぐ

これは、上で作成した資料を渡すだけでなく、きちんと口頭で資料を見ながら引き継ぐようにしましょう。

もし、同じ会社から新しい仕事の依頼が来た時、引き継いだ人が対応することになります。

その時に、資料を見るだけで思い出す事ができるように、引き継ぐ必要があります。

退職するから、その後は知りませんと言うスタンスでは、会社側もお客様側も困ります。

もしかすると、今後、今の会社は、自分のお客様になる可能性もあるのです。

なので、今の会社が困らないように、しっかりと引き継ぐ事が重要です。

その他に忘れてしまいがちなのが、自分がつかっているPCのライセンスに関する情報の引き継ぎです。

会社でライセンスを購入している場合は、会社でまとめられていると思いますが、個人でライセンスを購入している場合は、そのライセンスをどうするのかを話し合う必要があるでしょう。

間違っても、クレジットカードの情報や個人情報をPCに残さないように注意しましょう。

退職後のことについて考える

退職後、すぐに次の会社で勤めたいと言う人もいるでしょう。

でも、ちょっと考えてください。

ゆっくりとできる時間は、この転職の期間だけですよね。

体調面、精神面を考えると、私は退職後少し時間がとることをお勧めします。

上でも書きましたが、退職には大きなエネルギーが必要となります。

なので、できれば１ヶ月ほど休めるくらいの貯蓄をして、退職後は少し休む時間を作るのがベストだと思います。

だからと言って、次の会社を探すのを退職後にしないようにしましょう。

「１ヶ月あるのだから、退職してからゆっくりと探せばいいや」と思っていると、次の会社が決まらないなんて事が起きてしまいます。

この後書きますが、失業手当や再就職手当についても調べておきましょう。

３．退職した後にやること

退職した後は、失業手当の手続きを行い、再就職のための活動を行います。

• 離職票をハローワークへ提出する
• 失業手当の手続きをする
• 再就職のために活動する

離職票をハローワークへ提出する

離職票は、退職事に会社へ求めれば、会社が退職の手続きで取得してくれます。

手元に離職票が届くまでには時間がかかります。

退職する会社には、離職票が必要なことを早めに伝えて、できるだけ早く取得してもらいましょう。

離職票は、失業手当の手続きに必要な書類となります。

失業手当の手続きをする

失業手当には、離職票の提出後、７日間の待機期間が必要となります。

なので、早めの手続きが必要となります。

また、失業手当を受け取るには、退職理由や、それまでの勤務年数に応じて給付制限がつきますので注意が必要です。

ただし、給付制限を短くする方法もあります。

方法の１つとしては、職業訓練を受ける方法です。

ただし、これも良し悪しで、職業訓練を受けても就職につながるとも限らないし、内容は初心者レベルだったりします。

なので、１番いいのは早く再就職をすることだと思います。

再就職のために活動する

失業手当は、再就職をするための手当てとなります。

なので、再就職をする活動に注力するようにしましょう。

ハローワークには、早期再就職のためのサービスが設けられています。

例えば、再就職に対する相談、募集をしている会社の検索、面接の対応などありますので、ハローワークで調べてみるのもいいと思います。

再就職の面談を受けるのであれば、ハローワークを通した方がやはりいいようです。

上手く再就職できた場合は、再就職手当がもらえます。

しかし、失業手当の給付制限の１ヶ月目は、ハローワークからの紹介でないと再就職手当がもらえなかったりします。

詳細については、失業手当の手続きの際に話があると思いますので注意しましょう。

まとめ

今回は、退職を決意してから、実際に退職した後の話を書いてみました。

今回書いた内容は、私が過去3回転職して、その時に考えたことを書いています。

実際には、もっと考えないといけない事があったりしますので、そこは柔軟に対応しましょう。

ただし、「今の会社は、次の会社のお客様になる可能性がある。」ことだけは意識して、退職までの手続きには細心の注意をしましょう。

社会は、思った以上に狭いものです。

では、今日はこの辺で。