アウトプットすることの大切さ

こんにちは。

今日は、アウトプットすることの大切さについて書いてみようと思います。

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

• 理解が深まる
• 人生に変化を付けられる
• 失敗しても次へ進める
• たまに大当たりがある
• 行動が早くなる

私は、インプットばかりでアウトプットをしない人間でした。

でも、こうしてブログなどでアウトプットする事で、自分の理解力の低さを実感できています。

理解が深まる

自分では理解しているけど、友達に教えると難しいという経験、誰でもありますよね。

でも、誰かに説明しないといけないと思って調べたり、本を読んだりすると、結構身に入ってくるんですよね。

私も何度も経験しています。

兄弟に勉強を教える時とか、何でこんなことがわからないんだと思うことがよくありました。

でも一つ一つ教科書を見ながら説明していくと、自分でも理解してなかったことが解ったりということがよくありました。

大人になってからも、後輩にプロジェクトの説明をしながら自分で納得していることがよくあります。

インプットすることは、頭に知識として入っているだけで、何も役に立っていないことが多いのです。

アウトプットすることで、曖昧に理解していたことを、再度理解し直すことができます。

人生に変化を付けられる

毎日、淡々と仕事をしていると、仕事をしている意味が分からなくなることが私はよくあります。

そういう時、私は、本読むようにしています。

小説とかの本を読む事もありますが、大体、成功する本やお金持ちになる本が多いです。

読んでいるだけで、自分も成功しそうな気持ちになるので気持ちもいいんですよね。

でも、インプットだけでは、読み終わったらそこまでなんですよね。

私は、ここ数年、そういう本を読んだ後は、身近なところで、できそうなことを本の中から１つ選んで実行するようにしています。

うまくいったらそれだけで人生に変化を付けれますよね。

失敗したとしても、やっぱこの程度じゃ無理かと次の本に移れます。

失敗しても次へ進める

本に書かれていることは、著者がいろいろやって成功した内容なので、真似したところでそう簡単に成功することはありません。

でも、それを理解した上で実践すると、失敗を前提として実行しているから、失敗してもすぐに次へ進むことができるようになります。

初めのうちは、うまくいかないことを悩んだり私もしていました。

でも、失敗を繰り返しているうちに、失敗に慣れるというか、失敗してもいいかと思うようになってきました。

たまに大当たりがある

何度も本を読む、実践する、失敗するを繰り返していると、たまに成功することがあります。

それも、何度も失敗した上での成功なので、小さな成功も気分的には大当たりに感じることがあります。

私は、この大当たりがストレスを発散させてくれていたりします。

初めのうちは、失敗するとストレスが溜まっていきます。

でも、失敗を繰り返すと失敗もストレスではなくなります。

実践できた自分をほめれるようになると、失敗もストレス発散になるのかもしれませんが、私はまだそこまでではないですね。

行動が早くなる

これは、私だけかもしれませんが、失敗を前提で行動していると、行動が早くなった気がします。

それまでは、行動する前に考え過ぎで、行動が遅くなることが多かったです。

今でもたまにあるのですが、そういう時って、失敗することを前提で行動できてないんですよね。

とりあえずやってみるかくらいの勢いで行動すると、その後で手戻りも発生することがあるけど、これじゃダメだって気づくのも早いので、戻る時間があったりします。

まとめ

つまり、本などでインプットしたら、そのままアウトプットとしてみると、失敗でも成功でも何か得られるのです。

大きなリスクを取らないとうまくいかない物もあります。

でも、本に書かれている内容には、小さなリスクでもうまくいく方法が一緒に書かれています。

そうしないと、読む人がいなくなるので。

そういうのを実践して失敗を繰り返してみてください。

たまに大きな当たりあるかもしれませんよ。

では、今日はこの辺で。

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

こんにちは。

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

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

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

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

世の中の役に立ちたい

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

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

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

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

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

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

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

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

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

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

プログラミングが好き

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

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

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

IT業界の今後について

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

では、今日はこの辺で。

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

こんにちは。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そして行動しましょう。

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

「今から本を読む」

「今からブログを書く」

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

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

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

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

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

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

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

まとめ

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

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

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

では、今日はこの辺で。

おまけ

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

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

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

課題の分離

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

こんにちは。

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

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

自殺の統計

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

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

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

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

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

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

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

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

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

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

チャイルドライン

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

よりそいチャット

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

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

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

要件定義のまとめ方

こんにちは。

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

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

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

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

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

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

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

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

業務の流れを理解する

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

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

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

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

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

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

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

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

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

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

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

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

言葉の定義を明確にする

これも重要です。

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

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

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

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

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

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

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

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

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

業界について理解する

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

では、今日はこの辺で。