私がプログラマーを目指した理由

こんにちは。

今日は、私がプログラマーを目指した理由について書いていきます。

私がプログラマーを目指したのは、17年前になります。

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

• 世の中の役に立ちたい
• プログラミングが好き
• プロのプログラマーになりたい

世の中の役に立ちたい

学生時代、私は天文学を研究していました。

2年浪人して理系の大学へ行き、化学、数学、生物学、地学、物理学と研究室を転々としていました。

そして、最終的にたどり着いたのが天文学でした。

４年間、大学で勉強し、また、思いっきり遊び、バイトもたくさんしていました。

3年の後期から天文学を研究し始め、もっと研究したいと、大学院修士へ進みました。

天文学を研究していて、この研究が、世の中にどのように役に立つのかという疑問にぶつかっていました。

その答えを大学院で見つけることができず、就職することを決意しました。

就職するといっても、当時、自分にやれることがなく、あえてできるのがプログラミングでした。

研究結果のデータ分析で解析システムをカスタマイズしてたし、また、望遠鏡の制御プログラムのカスタマイズも行っていました。

この技術を使って就職し世の中の役に立ちたいと思っていました。

プログラミングが好き

先ほども書きましたが、大学院での研究にプログラミングを行っていて、自分が思うように動作するシステムを作るのが、私は好きでした。

「好き」という気持ちは、とても重要だと思います。

「好き」でないと、プログラマーの仕事は続かないと思っています。

システムは、プログラミングされたようにしか動作しません。

そのため、少しでも不具合があると、コンパイルも通らないし、コンパイルできたとしても正常に動作しないということはよくあることです。

思ったように動作しないと、それだけてかなりのストレスとなります。

また、動作しない原因を調査するために、デバッガを使って変数の値を見ながらステップを追っていくと、時には長時間ストレス状態にさらされます。

この作業は、「好き」でないとできない作業です。

プロのプログラマーになりたい

学生時代に行っていたプログラミングは我流でした。

本やWebで調べてプログラミングしていたので、多くの制約があり、もっと柔軟なシステムを作りたいと思っていました。

当時もすでにオープンソースが出ていたので、そのようなソースコードを読んでいました。

そういうソースコードを見ると、綺麗で柔軟なソースコードが書かれていました。

自分ももっと経験を積んで、綺麗で柔軟なソースコードを書きたいという思いが沸いていました。

まとめ

つまり、私は、研究でプログラムを使っていて、プログラミングが好きで、世の中の役に立ちたいという思いがあったので、就職しプログラマーを目指しました。

これから就職活動を始めようとしている学生の方へ言いたいのは、まずは好きなことを仕事にするのが長続きするコツです。

給与や福利厚生で仕事を決めるのは最悪です。

逆に、今はできないけど好きなことで就職をするのはありだと思います。

好きなら自分で勉強し行動することがストレスにならないでしょう。

今はできなくても経験を積めば、すぐに上へ行くことが可能で。

新型コロナウィルスの影響で就職活動も大変でしょうが頑張ってください。

以下に以前書いたブログのリンクを貼ってお行きます。
こちらも就職活動の参考になればと思います。

IT業界の今後について

私がプログラマーでいる理由

では、今日はこの辺で。

自分の人生を楽しむための目的論

こんにちは。

今日は、自分の人生を楽しむための目的論について書いていこうと思います。

結論から言うと以下の３点になります。

• 人の行動には必ず目的があります
• 原因を探し続けるのはやめましょう
• まず目的を決めましょう

 目的論は、アドラー心理学で出てきます。

目的論を使って楽しい自分の人生を作っていきましょう。

人の行動には必ず目的があります

試験勉強をしようとして、ついSNSを見たり、YouTubeを見てしまったり、部屋の掃除をしたりしたこと、誰しもありますよね。

私も学生時代は、試験前日なのに、部屋の模様替えをした事があります。

これって、結局、点数が悪かった時の言い訳を作っているんですよね。

「言い訳を作る」という目的があって行動しているのです。

こうやって書いている、私も、このブログを書く直前にTwitterを見ようとしたり、YouTubeを見ようとしてしまいました。

人の行動には必ず目的があるのです。

意識していなくとも無意識でやっている事もあるでしょう。

それでも、その行動には目的があるのです。

原因を探し続けるのはやめましょう

問題が発生した時、原因を探して分析することは、同じ問題を防ぐために効果的な事です。

でも、原因を探し続けるのはやめましょう。

特に自分の事になると、「なぜ」「どうして」を繰り返して原因を探し続ける人が多いように思います。

原因を探し続けるとどうなるか。

自分の嫌な面がたくさん出てきます。

そのせいで、どんどん落ち込んでしまいます。

その先にあるのは、鬱という精神疾患です。

ちょっと飛躍しすぎかもしれませんが、そうなる可能性がある事を理解しましょう。

私の場合は、仕事が上手くいかなくて、原因を探して、自分の嫌な面が見えて、挙げ句の果てに、適応障害になり休職しました。

まず目的を決めて行動しましょう

まず、今から行う行動の目的を決めましょう。

そして行動しましょう。

「今から明日の試験対策をする」

「今から本を読む」

「今からブログを書く」

「今から思いっきりSNSを読む」

目的を先に決めて行動すると、その行動に集中する事ができます。

勉強も、読書も、遊びにも集中する事ができるのです。

もっと飛躍すると、人生も目的を決めてしまうと、楽しい幸せな人生にする事ができるのです。

私の場合は、プログラマーである目的から考えました。

「相手が喜ぶ顔が見たい」「相手が驚く顔が見たい」「面白いものを作りたい」が私のプログラマーである目的でした。

今は、その目的のためにプログラマーとして仕事をしています。

まとめ

何か問題が起きた時は、原因を考えるのも必要ですが、一通り考えたら目的を決めましょう。

そして、次の行動に移りましょう。

そして、自分の人生を楽しみましょう。

では、今日はこの辺で。

おまけ

以前、課題の分離について書きました。

この課題の分離も目的論から出てくる方法なんですよ。

以下も合わせて読んでください。

課題の分離

未成年者の自殺者数に思うこと

こんにちは。

今日は、未成年者の自殺者数に思うことを書いていきます。

2020年3月17日に、『令和元年中における自殺の状況』という統計情報が、厚生労働省自殺対策室と警察庁生活安全局生活安全企画課から発表されました。

自殺の統計

私は、ここ数年、未成年の自殺者数を減らすにはどうしたら良いか考えています。

結論を言うと、どうしたら未成年の自殺者が少なくなるのか、私にはわかりません。

自殺者数を見ると年々減少傾向にあるのですが、未成年の自殺者数は、ここ10年ほど６００人前後で減少していません。

『令和元年中における自殺の状況』から、昨年の未成年の自殺者は、659名だそうです。

その原因は、さまざまで、家庭の問題、健康の問題、経済・生活の問題と多岐に渡るようです。

そして、１番多いのが、学校の問題でした。

自殺をした方には、それぞれ居た堪れない理由があったのでしょう。

周りの大人は、親は、先生は、気付いてあげれなかったのでしょうか。

ただ、自分の周りに思い悩んでいる子がいたとして、気付いてあげれるかは、正直わかりません。

自殺を考えている方、思い悩んで、辛くて辛くてどうしていいか分からない方が、もし、このブログを目にしたなら、以下の方法で相談してください。

チャイルドライン

２４時間子供SOSダイヤル
フリーダイヤル：0120-0-78310 （※通話料は無料）

よりそいチャット

絶対に、自殺なんかしないでください。

あなたの命は、あなただけのものではありません。

生きているからこそ、変えていけるのです。

要件定義のまとめ方

こんにちは。

今日は、要件定義のまとめ方について書いてみます。

要件定義とは、システム開発のウォータフォールモデルで最初に行う工程です。
実際にお客様とどの様なシステムを開発するのかを話し合い、文章に起こす作業になります。

ウォータフォールモデルとは

今回は、要件定義を書く前のまとめ方について、私の経験を元に書いていきます。
なので、これが正解という内容ではないのでご了承ください。

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

• 業務の流れを理解する
• 言葉の定義を明確にする
• 業界について理解する

大きく分けると上の３点になります。

要件定義は、どんなシステムを作るのか、相手がシステム企業かエンドユーザかによって変わってきますので、その辺も分けて書いていきます。

業務の流れを理解する

まず必要となるのは、現在の業務の流れを理解する事です。

私は、ここが一番大事だと思っています。

相手がシステム企業の場合は、その先にエンドユーザがいるのですが、システム企業が相手の場合、この辺は分析されているので、ざっくりとした説明を聞くのみとなります。

相手がシステム企業で、エンドユーザの業務の流れを理解していな場合もたまにありますが、その場合は、大体プロジェクトが炎上してしまいます。

相手が悪いと言ってしまう事もできるのですが、作る方としても良いものをエンドユーザへ提供したいので、どうしても時間をかけて本当に必要なシステムを開発します。

そして、時間がかかりすぎて赤字になる事がよくあります。

では次に、相手がエンドユーザの場合です。

相手がエンドユーザの場合は、実際に作業している方からヒアリングをします。

まずは、大きな業務の流れを理解します。

その後で、各作業の詳細を理解していきます。

相手が実作業をしている方の場合は、業務の流れを絵に書いて話し合うのが経験上効果的です。

たまに、大きな業務の流れだけを要件定義にして、詳細は設計で行うプロジェクトがあるのですが、業務の中には、例外的な作業も含まれているので、手作業でする方が良い作業と、システム化する方が良い作業を要件定義の段階で分ける方が良いと私は思います。

言葉の定義を明確にする

これも重要です。

言葉の定義が違っていて、炎上するプロジェクトって思った以上に多いのです。

私が経験したプロジェクトでも、言葉の定義を間違えて設計書をOKとしたために、試験工程でNGとなって炎上した事が何度かあります。

相手がシステム企業の場合は、言葉の定義に違いがないだろうと思うかもしれませんが、同じ業界だからこそ起きる言葉の違いがあります。

なので、曖昧な言葉は、お互いに意味を共有し、要件定義書にまとめておくことをお勧めします。

相手がエンドユーザの場合は、業界用語の意味を把握する必要があります。

一般的な用語でも、エンドユーザ特有の意味が含まれる事があります。

そのため、Webで意味を調べて推測して要件定義書を作成しても、あと工程で機能の不足が出てきたりします。

また、これは相手がシステム企業でもエンドユーザでも同じなのですが、「あたりまえ」と言う言葉には注意した方が良いです。

私の当たり前は、相手の当たり前ではない事がよくあります。

業界について理解する

これが、一番難しいところです。

業界を絞ったシステム企業の場合は、業界についての知識も充分にあると思いますが、請負でシステム開発を行うと、いろいろな業界から依頼を受けるので、新しく知識を着けないと、深い内容まで聞けなかったりします。

相手がシステム企業の場合は、業界に詳しい事が良くあるので、調べて分からない時にその都度聞く事ができます。

なので、要件定義書を書きながらでも聞けますし、その後の工程でも、分からない時は聞く事ができます。

相手がエンドユーザの場合は難しいです。

実作業されている方は、業界については知識が少ない事も良くあります。

実際、業界については、相手企業の社長様に聞くことになる事もあります。

そのため、時間が限られてしまうので、なるべく必要な業界知識は、要件定義の話し合いまでに調べておき、分からない部分を聞く様にしましょう。

また、同じ業界でもエンドユーザによって認識が違う事がありますので、曖昧なところは明確にする様にしましょう。

まとめ

要件定義をまとめる時は、相手が同じシステム企業でもエンドユーザでも、言葉の意味を明確にし、作業の流れを明確にしないと、システム開発は上手くいかない様に思います。

上手くいったとしても、エンドユーザは新たな作業が増る事も良くあり、システム化したけど作業は楽になってなかったりします。

正直、その場合は、プロジェクトは成功でも開発は失敗だと私は考えます。

では、今日はこの辺で。

リーマン・ショックの時に私の身の回りで起きたこと

こんにちは。

今日は、リーマン・ショックの時、私の身の回りで起きた事を書いてみようと思います。

ここ数日、日経平均株価も急下落しており、コロナ・ショックと言われています。

経済は、繰り返されるので、前回の経済危機であるリーマン・ショックの時に、私の身の回りで起きたことまとめておく事で、同じような状況に備える事ができればと思っています。

結論から言うと、私の身の回りで起きたのは以下になります。

• 給与未払い
• 当時の職場を退職
• 当時の職場が倒産

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

リーマン・ショック

少しリーマン・ショックについてまとめてみます。

詳細が知りたい方は、Webで検索してみてください。

2007年にアメリカで、サブプライム住宅ローンが不良債権化したのを切っ掛けに、関連する株や債権が暴落しました。

そして、2008年9月15日に、リーマン・ブラザース・ホールディングが経営破綻し、世界規模の金融危機が発生しました。

私は、当時、社員100名ほどのシステム開発企業に勤めていました。

当時勤めていた企業は、お客様先へ常駐して開発するSES業務を主軸としており、プログラマーの90%がSESで働いていました。

リーマン・ショックが発生した直後は、何の影響もありませんでした。

しかし、世界規模の金融危機が発生したことは、ニュースなどでも知っており、景気に影響を受けやすいIT業界はすぐに影響を受けるのではないかと怯えていたのを覚えています。

しかし、実際に影響が出だしたのは、2011年頃からでした。

関東や関西のシステム企業は、もっと早い段階で影響を受けていたようですが、私が勤めていた企業は福岡だったのと、当時私は、企業の経営に携わっていなかったのもあり、直接影響が出たのが2011年頃からでした。

給与未払い

まず最初に起きたのは、給与の支払い遅れでした。

交通費は支払われるのですが、給与は10日遅れたり、半月遅れる事もありました。

そのうち、給与が分割して支払われるようになり、2012年2月には完全に未払いとなりました。

随分と時間が経ってから、当時の上司に話を聞いたところによると、資金繰りが厳しくなり、いろいろなとことからお金を借りて給与を支払っていたようです。

また、経営に携わっている方は、2011年末から給与未払いとなっていたそうです。

退職

給与の未払いとなった時点で、私は当時勤めていた企業に見切りを付けました。

ただ、当時携わっていたプロジェクトが2011年4月まであり、当時そのプロジェクトの機能リーダーを勤めていた事もあり、4月まではお客様先での仕事を続けました。

しかし、退職したのは良いのですが、IT業界は仕事がなく、求人も少なくなっていました。

なので、再就職（現在の会社）するまでに半年もかかってしまいました。

倒産

私が退職したのち、数ヶ月後に当時勤めていた会社は倒産しました。

倒産までその会社で勤めていた方に聞いたところによると、給与の未払いが続いて、訴訟になったそうです。

倒産した後は、未払いの給与は債権者に移ったようで、全額は支払われなかったと聞いています。

私は、退職の際に未払い分を払ってもらいました。

まとめ

IT業界は、景気の影響を受けやすい業界です。

SES事業は、景気が悪くなるとIT投資を抑える企業が多いため、もっとも影響を受けてしまいます。

コロナ・ショックは、リーマン・ショック以上の経済危機となるという意見もあるようです。

では最後に、もしリーマン・ショック以上の経済危機となるのなら、どういう対策ができるのか、私の考えを少し書いてみます。

現状、経営が悪い企業の場合は、まず立て直しを早急に考える事です。

最終的に影響を受けるのは、末端で働いているエンジニアです。

現状、上手くいっている企業は、未来への投資をする事です。

新しいシステム開発に着手するチャンスだと思います。

景気が好転した時、その投資は回収できるのではないでしょうか。

経済は、良い時があれば、悪い時もあります。

きちんと備える事も必要になると思います。

では、今日はこの辺で。