要件定義のまとめ方

こんにちは。

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

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

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

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

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

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

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

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

業務の流れを理解する

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

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

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

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

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

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

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

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

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

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

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

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

言葉の定義を明確にする

これも重要です。

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

私が経験したプロジェクトでも、言葉の定義を間違えて設計書を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投資を抑える企業が多いため、もっとも影響を受けてしまいます。

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

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

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

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

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

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

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

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

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

では、今日はこの辺で。

アジャイル開発

こんにちは。

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

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

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

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

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

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

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

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

アジャイル開発

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

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

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

アジャイル宣言

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

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

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

メリット

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

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

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

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

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

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

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

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

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

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

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

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

デメリット

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

では、今日はこの辺で。

何をやっても上手くいきない時の私なりの対処法

こんにちは。

今日は、何をやっても上手くいきない時の私なりの対処法を書いてみます。

長く生きていると、何をやっても上手くいかない事が続いて、気が滅入ってしまう時がありますよね。

そんな時、私は以下のように行動し解消しています。

• 原因を探さない
• 小さな成功を積み重ねる
• それでもダメなら、何もしない

以下で私の経験を交えて書いていきます。

原因を探さない

上手くいかない時って、なぜ上手くいかないのだろうと、過去の行動に原因を探してしまいますよね。

でも、それって、原因が見つからなくて、逆にストレスを溜めてしまう事が多いのです。

もしくは、原因がありすぎて、結局、自分を責めてしまいストレスが溜まってしまいます。

そういう時は、原因を探すのをやめましょう。

原因が分かったところで、現状は打開できないのです。

過去は、変えられませんから、ストレスばかりが溜まってしまいます。

原因は、自分にあったのだろうと思うくらいで、後は今何をするかを考えるのです。

実際、私も、過去を振り返ってばかりで、上手くいかない原因を探しまくっていました。

その結果どうなっかというと、適応障害になりました。

今何をしたいのかだけを考えて、実際に動くようにすることで、少しずつ精神的に落ち着いて毎日を過ごせるようになりました。

小さな成功を積み重ねる

上手くいかない時って、大きな成功をいつも追いかけている事が多いです。

一発逆転するような、大きな成功を追い求めても、上手くいく可能性は薄いです。

なので、小さな成功を追い求めましょう。

小さな成功は、一発逆転の効果はありません。

でも、上手くいく可能性は高いですし、継続することも難しくありません。

では小さな成功とは何でしょう。

• 靴を揃える
• 毎日、鏡を見て笑顔を作る
• 毎日、ありがとうと言う

こんな、些細なことで良いのです。

今日はできた。今日もできた。今日も何とかできた。

そう言って、小さな成功を継続するのです。

できれば、できた自分を充分に褒めてください。

私が行ったのは、自分の靴を揃えるです。

家族の靴までは揃えません。自分の靴だけです。

それでもダメなら、何もしない

小さな成功は、継続しても、上手くいかない事もあります。

そんな時は、何もしない日を作ります。

できれば、休みの日ではなく、普通の日に何もしない日を作ります。

私の場合は、２ヶ月ほど仕事から離れました。

休んでいる日も、PCには触らない。

携帯も見ない。

外をブラブラ歩いたり、人の少ない公園を散歩したり、

家の中でボーッとしていたり。

そんな毎日を過ごしていると、キーボードを触りたくなってくるんですよね。

やっぱり好きなんだなと思ってきました。

そこから、また、毎日の小さな成功を積み重ねています。

まとめ

上手くいかない時は、辛いものです。

そこから抜け出すには、実際、方法なんてないのかもしれません。

でも、私は上の３点を気にかける事で、精神的にも安定するようになりました。

いろいろやってみるのなら、上の３点もやってみてください。

では、今日はこの辺で。

内定から入社の間にやること

こんにちは。

今日は、企業の内定をもらってから入社までにやっておいた方が良い事について書いてみます。

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

• PCを毎日触る
• 思いっきり毎日を楽しむ
• 仲間を大切にする

私はこれまで、内定者に対して情報処理の資格取得を目指して勉強するように言ってきました。

ですが、時間がある時にやっておいてもらいたい事は、上の３点なのです。

PCを毎日触る

まずは、PCに慣れる事です。

プログラミングを行うのではなく、趣味のWeb検索をするだけでも良いので毎日触ってもらいたいです。

そうする事で、PCに対する抵抗も入社する頃には少なくなっているのではないでしょうか。

触る時間が無かったり、気持ちがのらない時は、PCの掃除だけでも大丈夫です。

思いっきり毎日を楽しむ

社会に出てエンジニアとして働きだすと、しばらくの間は自由な時間が持てません。

業務も覚えないとならない、プログラムの勉強もしないといけない、新しい技術も吸収しないとならない。

これは、IT業界だけではないと思います。

内定をもらって就職活動から解放されたら、学生生活を思いっきり楽しんでもらいたいです。

時間があるこの時に、たくさんの経験をすることは、後々役に立ったりするので、やりたいことはできるだけやってください。

仲間を大切にする

学生時代の仲間は、社会人となってからの同僚とは違います。

楽しい時間を共有してきた仲間は、本当のあなたを覚えてくれています。

社会に出ると、本当の自分が出せずに悩み苦しむこと必ずがあります。

そんな時に助けてくれるのは、本当の自分を知っている学生時代の仲間なのです。

ですので、今いる仲間を大切にしてください。

まとめ

学生と社会人の違いは、どれだけリスクを取りながら生きるかの違いです。

つまり、学生時代は避けてきたことでも、社会に出てからは避けて通ることはできないのです。

そのため、ストレスが溜まり精神的な病気になる人もたくさんいます。

実は私もその一人です。

そんな時支えてくれたのは、家族や学生時代の仲間、そして仕事以外のコミュニティの仲間です。

内定をもらって就職活動から解放されたら、仲間を大切に毎日楽しんでください。

4月から社会に出る方も、まだ時間はあります。

では、今日はこの辺で。