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

こんにちは。

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

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

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

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

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

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

試験勉強をしようとして、つい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投資を抑える企業が多いため、もっとも影響を受けてしまいます。

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

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

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

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

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

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

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

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

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

では、今日はこの辺で。

アジャイル開発

こんにちは。

先日、ウォータフォールモデルというシステム開発の手法を書きました。

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

今日は、アジャイル開発について書いて書きます。

まず、正直に言いますが、私はアジャイル開発の経験が浅いです。
ずっと、ウォーターフォールモデルで開発を行ってきました。

ただ、現在は進行形でアジャイル開発を行っています。

経験が浅いなりに考えてみると、
正直、ウォータフォールモデルとアジャイル開発のどちらが良いとは言えないと私は思います。

プロジェクトの状況や、お客様から求められているものによって、ウォータフォールモデルとアジャイル開発を使い分けて良いと思っています。

では、アジャイル開発について以下で説明します。

アジャイル開発

アジャイル開発は、システム開発の手法のひとつです。

アジャイル宣言というものがあります。

詳細は以下のサイトをご覧ください。

アジャイル宣言

アジャイル宣言の背後にある原則

一言で言うと、お客様と必要なソフトウェアを作っていきましょうと言うものです。

ウォータフォールモデルとアジャイル開発の違いは、「変化への対応」だと私は思います。

メリット

アジャイル開発メリットは以下の３点だと思います。

• 必要なシステムを開発
• アイデアが出やすい
• 手戻りが小さい

アジャイル開発の最大のメリットは、お客様が必要とするソフトウェアを開発できると言う事だと思います。

お客様は、実際に動くソフトウェアを早い段階で目にする事ができます。

そのため、こんな機能が必要だ、この機能はあまり使わない、などの意見や案が出てきます。

ウォータフォールモデルでは、変更が発生すると大きな手戻りとなってしまいます。

実際にお客様が動くソフトウェアを目にする事ができるのは、開発の後半になってからなので、変更となるとカットオーバーの遅れと追加費用が発生します。

中小企業のシステム会社の場合、大きな赤字となってしまいます。

それが、アジャイル開発の場合は、動くソフトウェアをすぐに見て、改善点を上げる事ができるため、手戻りも小さく抑える事ができるのです。

実際、アジャイル開発でシステム開発を行うと、多くのアイデアがお客様から生まれてきます。

また、お客様は動くソフトウェアを見ながら、今の業務フローがどのように変更されるのかをイメージでき、カットオーバーまでに準備を進める事が可能になるようです。

お客様によっては、動くソフトウェアを見ながら、新しいビジネスモデルを考えられる方もいらっしゃいます。

デメリット

では次に、アジャイル開発のデメリットを書いていきます。

• 見積りが難しい
• スケジュールが作れない
• 引継ぎに時間がかかる

まず難しいのは、見積りだと思います。

変更があるということは、受注する時点で見積りを行う事が難しいという事です。

常に見積りを意識していないと、気づいた時には赤字という事もよくあります。

また、変更が発生するために、先々のスケジュールを組む事が難しいです。

この週でこの機能を作って、この週にこの機能を作るとスケジュールを組んだとしても、その間で変更があると、スケジュールの組み直しが必要となります。

もしかすると、スケジュールを作成する機能ごとに作る事で解決するのかもしれませんが、そうすると、終わりが見えなくなってします。これって、プログラマーにとっては、結構なストレスとなったりします。

また、開発者が途中で変わる場合は、その引き継ぎが大変になります。

ドキュメントは作成するのですが、引継ぎを行っている間も変更が発生していく時があります。

そのため、引継ぎ漏れが発生する事も発生します。

実際、現在私が行っている開発は、前任者から引き継いだ開発なのですが、変更がありすぎて引継ぎ漏れがあり、お客様へご迷惑がかかった事がありました。

私が引き継いだ理由も、赤字プロジェクトとなったためだったのです。

まとめ

ウォータフォールモデルとアジャイル開発は、それぞれメリットがあります。

お客様の要望や納品物によってどちらの開発手法を使うか選択いて良いと思います。

ただし、私は経験ないのですが、途中で開発手法を変えるのはあまり良くないと思います。ウォータフォールとアジャイル開発で求められる物が違うので、現場が混乱してしまうのではないでしょうか。

では、今日はこの辺で。