プログラムが動かない時の対処法

こんにちは。

今日は、プログラムが動かない時の対処法について書いてみます。

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

• ロジックを追って確認する
• ログを埋め込んで確認する
• デバッガで確認する

上記の順で確認すると、大抵の不具合は解決します。

プログラムを作成していると、動かないというのはよくある事です。

調べていくとロジックのミスの場合が多いです。

ロジックを追って確認する

専門用語で言うと、机上デバッグと言います。

実際にソースコードがどのように動くかを、１ステップごとに追って確認する方法です。

大体、大きなロジックによる不具合は、机上デバッグで見つけることができます。

この段階で見つかる不具合は、詳細設計の段階で不具合が入り込んでいるケースが多いです。

ウォータフォールモデルでの開発では、ソースレビューを行うので、不具合がなくともレビューで見つかると思います。

ログを埋め込んで確認する

机上デバッグである程度動くソースコードができると、ログを出力して確認します。

机上デバッグでは、データの変動による不具合が見えにくいことがあります。

その場合は、ログに変数の値を出力し、なぜ動作しないのかを確認します。

私は、ログを埋め込む時に、どこのログか分かるように埋め込むようにしています。

特にループ処理の場合は、何回ループが回ったかを確認するようにしています。

たまに不要なループが回って、処理に負荷がかかっている場合があります。

そういうのは、ログを埋め込んで確認するのが１番です。

デバッガで確認する

デバッガで確認するといろんな情報を取得することができます。

デバッガは、プログラムとは別のツールになります。

実際に仕事でプログラムを開発していると、ログを埋め込んで確認するのを飛ばして、デバッガでデバッグする事もあります。

上にも書いたように、デバッガは別のツールなのでいろいろと設定が必要になります。

ツールを使用できない事もあるので、ログを埋め込んで確認する方法も身に付けておきましょう。

デバッガを使用すると、様々な変数の値を見ることができます。

そこで、不具合に気づく事もよくあります。

まとめ

プログラムには不具合が付き物です。

不具合のないプログラムを組むことが理想ですが、最初から不具合のないプログラムはありません。

なので、プログラミングの後に試験を繰り返し不具合を叩き出すのです。

その時必要となるのが、上にあげた３点になります。

では、今日はこの辺で。

ブラウザとザーバーの関係

こんにちは。

今日は、ブラウザとザーバーの関係について書いてみようと思います。

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

• ブラウザとサーバーは常に接続している訳ではない
• サーバーはテキストのみを出力する
• ブラウザはテキストを解析する

Webサービスを開発していると、経験の浅いメンバーから処理をどこに書いたらいいのかと言う質問をされることがあります。

その場合、ブラウザとサーバーの関係を理解していないことが多いです。

なので、ここでまとめてみようと思います。

ブラウザとサーバーは常に接続している訳ではない

開発をしていると、画面と処理をサーバーに置くため、ブラウザでWebサイトを開くと常に接続状態になっていると勘違いするようです。

しかし、実際は、ブラウザに表示するリソースが取得できれば、ブラウザとサーバーの接続は切断されます。

ブラウザは、必要な時のみサーバーに接続します。

実際、常にブラウザとサーバーを繋いでおく事もできるのですが、今回は、もっとも基本的な処理を扱います。

サーバーはテキストを出力する

サーバーからは、html、css、javascriptのテキストが出力されます。

実際には、それぞれのテキスト内容がデジタル化された状態（0、1のデータ）でサーバーからブラウザへ送られます。

テキストをデジタル化する処理は、Webサーバーソフトが行います。

実際に開発するのは、htmlを作るための処理です。

ブラウザはテキストを解析する

ブラウザは、サーバーから受け取ったテキストを解析してサイトを表示します。

まず、ブラウザは、htmlで画面構成を解析します。

次に、cssから画面に装飾を行います。

javascriptは、画面の動作を定義します。

まとめ

つまり、サーバーとブラウザは、テキストを受け渡すことでサイトを表示しているのです。

そのテキストを作成することが、Webサイトの開発となるのです。

では、今日はこの辺で。

プログラマに必要なマインド

こんにちは。

今日は、プログラマに必要なマインドについて書いてみようと思います。

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

• 自分ならどうやって動かすかを考える
• 動かない理由を考える
• 考えることにストレスを感じない

この３点は、私が大切にしているマインドです。

自分ならどうやって動かすかを考える

私は、動いている物を見ると、どうやって動いているのだろう、というのが気になります。

まず、興味を持つことが、プログラマに必要なマインドだと私は考えています。

そこから、私ならどうやって動かすかを考えます。

まずは、自分でロジックを考えてみます。

そうすることで、実際にフレームワークを使う時に新しい知識がスンナリと入ってきます。

動かない理由を考える

プログラムは、書いたようにしか動きません。

そこに、論理的な間違いがあった場合は動きません。

そこを考えることができないと、先に進むことができません。

つまり、動かない理由を考えることは、プログラマにとって必要なマインドなのです。

簡単に解決できる場合もありますが、デバッカツールを使っても分からない時もあります。

そこを、論理的に考え修正し先に進める必要があるのです。

考えることにストレスを感じない

上にも書いたように、長時間、論理的に考えることがよくあります。

その時間を楽しめるかどうかなのです。

考えることにストレスを感じていると、すぐに潰れてしまいます。

私も、長時間考えることを楽しめれているかは分かりません。

多分、少しずつストレスを感じているのかもしれません。

そのため、適応障害になったのかもしれません。

でも、考えている時間は、自分なりに楽しめれていますよ。

まとめ

私も、上に掲げた３つのマインドを全て持っている訳ではありません。

でも、だからこそ、この３つのマインドの必要性が分かるのかもしれません。

逆に言うと、上の３つのマインドを全て持っていなくても、プログラマにはなれるのです。

後天的に、上の３つのマインドを身に付けることができるのです。

では、今日はこの辺で。

プログラミングを勉強する時に大切なこと

こんにちは。

今日は、プログラミングを勉強する時に大切なことについて書いてみます。

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

• まずは１つのプログラム言語をマスターする
• フレームワークは学ぶ必要ない
• Linuxコマンドをマスターする

この３点に注力すれば、３ヶ月でそこそこ動くプログラムを作ることができるようになります。

これは、社会に出たばかりの自分に伝えたいことです。

まずは１つのプログラム言語をマスターする

まずは、１つのプログラム言語を充分にマスターしましょう。

プログラム言語は、どの言語も似ている点が多いです。

また、基本となる処理は以下のみです。

• 分岐
• ループ
• 関数

基本となる処理については、過去に書いた記事がありますのでそちらを参照してください。

プログラムの基本処理

１つのプログラム言語をマスターしてしまえば、違うプログラム言語を勉強するのも、すんなり入ってきます。

フレームワークは学ぶ必要はない

フレームワークは、初めのうちは学ぶ必要はありません。

実際に仕事をするようになると、フレームワークを使います。

しかし、企業によって使うフレームワークは違ってきます。

プロジェクトによって違う場合もあります。

なのでフレームワークを学ぶのではなく、まずは、１つのプログラム言語を十分に身に付けることを意識してください。

フレームワークは、実際に仕事をするようになってからで十分に学ぶことができます。

また、使用するフレームワークに詳しい先輩や仲間がいるので、分からないことは使いながら学ぶことが可能です。

しかし、プログラム言語を１つも知らなと仕事になりません。

Linuxコマンドをマスターする

実際にプログラマーとして仕事をすると、Linuxサーバでの作業が多いです。

開発するPCはWindowsでも、実際に動作するOSはLinuxが大半です。

Linuxコマンドが使えなと動作試験で苦労します。

Linuxは、デスクトップもありますが、コマンドで使えるようにしておきましょう。

GUIのツールがある場合もありますが、実際遅いです。

Linuxコマンドに慣れているだけで、プログラマーとしての生産性が結構違います。

まとめ

つまり、Linuxで１つのプログラム言語をとことん勉強するのが一番です。

私が社会に出たばかりの頃は、いろんなプログラム言語を勉強していました。

それに使えそうなフレームワークがあれば、いろいろと使ってみてました。

でも、フレームワークは、プロジェクトで決まっていることが多く、いろんなフレームワークを知っていてもあまり役に立ちませんでした。

結局、私はいろいろとやって遠回りをしてしまいました。

この３点に注力すれば、プログラミングの仕事は何とかなるのではないでしょうか。

では、今日はこの辺で。

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

こんにちは。

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

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

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

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

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

理解が深まる

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

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

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

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

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

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

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

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

人生に変化を付けられる

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

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

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

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

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

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

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

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

失敗しても次へ進める

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

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

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

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

たまに大当たりがある

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

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

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

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

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

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

行動が早くなる

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

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

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

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

まとめ

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

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

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

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

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

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

では、今日はこの辺で。

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

こんにちは。

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

私がプログラマーを目指したのは、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投資を抑える企業が多いため、もっとも影響を受けてしまいます。

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

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

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

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

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

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

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

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

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

では、今日はこの辺で。

アジャイル開発

こんにちは。

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

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

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

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

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

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

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

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

アジャイル開発

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

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

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

アジャイル宣言

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

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

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

メリット

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

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

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

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

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

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

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

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

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

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

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

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

デメリット

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

では、今日はこの辺で。

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

こんにちは。

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

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

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

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

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

原因を探さない

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

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

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

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

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

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

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

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

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

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

小さな成功を積み重ねる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

携帯も見ない。

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

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

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

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

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

まとめ

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

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

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

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

では、今日はこの辺で。

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

こんにちは。

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

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

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

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

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

PCを毎日触る

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

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

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

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

思いっきり毎日を楽しむ

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

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

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

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

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

仲間を大切にする

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

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

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

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

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

まとめ

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

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

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

実は私もその一人です。

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

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

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

では、今日はこの辺で。

IT業界の今後について

こんにちは。

今日は、IT業界について書いてみようと思います。

新型コロナウィルスの影響で、2021年卒業の学生が就職活動に困っているようなので、実際にIT業界で働いているエンジニアの一人として実状を書いていきます。

結論から言うと、これからもIT業界には需要があります。

しかし、これからのIT業界は、これまでとは違い、プログラムが組める程度では通用しなくなるのも事実です。

IT業界の今後について

新型コロナウィルスの影響で、在宅で働くテレワークが多くの企業で行われています。

本来、東京五輪の開催時に行うはずだったテレワークが、このような形で実施され多くの企業では実証実験ができたのではないでしょうか。

そのため、今後は、テレワークを主軸にシステム開発を行うIT企業も多くなると考えられます。

テレワークで働けるようになると、日本全国、世界から優秀なエンジニア に働いてもらうことが可能となります。

また、AIやブロックチェーン といった高度の開発も普通に行われるようになるでしょう。

AIやブロックチェーン は、フロントエンド側の開発とバックエンド側の開発で大きな違いがあります。

フロントエンドでは、AIやブロックチェーンサービスのWebAPIを使用することで、開発期間がさらに短くなるのではないでしょうか。

また、バックエンドは、より高度な数学が必要となり、これまでのシステムとは桁外れのソースコードとなることが考えられます。

中小のシステム企業では、フロントエンドの仕事が多くなり、さらに納期が短くなることが考えられます。

そうなると、フットワークの軽いフリーランスの需要が高まることは分かりますよね。

では、企業に就職せずにフリーランス として働いた方がいいのでしょうか。

私は、企業に就職することをお勧めします。

プログラミングができる方

まずは、プログラミングができる方に焦点を当てて書いていきます。

すでにプログラミングがきますと言って入社して来る方がいますが、正直、実戦では全く使えません。

実際に行う作業は、お客様のビジネスモデルに沿ったシステムの開発です。

PCに向かってする仕事は半分くらいで、残り半分は、お客様との話し合いなど人との関わりです。

お客様の前に出せるだけのビジネスの知識が、新卒では持ち合わせていません。

そのため、教育制度のある企業に就職し、エンジニア の勉強をしつつ、ビジネスの勉強をお勧めします。

また、プログラミングができる方は、いろいろなプロジェクトに参加できるような企業がお勧めです。

企業によっては、SES（システム・エンジニアリング・サービス）を主軸としている企業もあります。

SESは、お客様先に常駐してシステム開発を行うのですが、実際は、古い基幹システムの不具合改修や機能追加などが多いです。

古いシステムを相手にするため、技術力も思った以上に上がりません。

また、古いシステムを長年扱ってきた方を相手とするため、自分でアンテナを張っていないと、最新技術から遅れをとることになります。

なので、主軸を自社開発や受託開発に置いている会社がお勧めです。

プログラミングができない方

では次に、プログラミングができない方や文系の方などに焦点を当てて書いていきます。

プログラミングができない方は、まず教育制度の整っている企業をお勧めします。

まずは、システムに抵抗を感じなくなることを優先した方がいいでしょう。

PCは、幼い頃からそばにあった世代でしょうが、システムとなると抵抗を感じる方が多いようです。

通常自分が仕事で使うPCでさえも、自由に使えるようになるのに時間がかかる場合があります。

しかし、文系の方は、ビジネスに対する知識を持っている方も多いため、お客様との話し合いには最適だったりします。

ですので、教育制度の整った企業に就職し、エンジニア知識を着ければ、すぐにでも実戦へ投入できると私は考えています。

まとめ

実際、入社時にプログラミングができるかどうかは、ほとんど関係ありません。

文系、理系もほとんど関係ありません。

大切なのは、社会に出てからどれだけ努力するかです。

あともう一つ言っておきたいことがあります。

試験を受ける企業のことは、できるだけ情報を収集しましょう。

特に経営状態は重要です。

IT業界は、景気に左右されやすい業界でもあります。

ですので、入社時の経営状態はしっかりと収集しておかないと、新入社員研修が終わると営業に回されることもよくある話です。

ピンチはチャンスです。

新型コロナウィルスのために就職活動の開始が遅れたとしても、それをバネに頑張ってください。

では、今日はこの辺で。

（追記）IT業界の今後については、以下の記事も参考にしてください。

今後IT業界は成長するのか

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

こんにちは。

今日は、システムの開発手法の一つであるウォーターフォールモデルについて書いてみます。

最近では、アジャイル開発の方が効率的と言われていますが、
大手のシステム企業では、ウォーターフォールモデルを使っています。

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

先ほども書きましたが、ウォーターフォールモデルとはシステム開発手法の一つです。

以下のように工程を分けてシステム開発を進めていきます。

• 仕様書作成
• 基本設計
• 詳細設計
• 製造（コーディング）
• 単体試験
• 結合試験
• 運用試験
• 納品

各工程で納品物が決まっており、納品物のレビューしたのち、作成者、作成企業、発注企業で押印し納品されます。

そもそもウォータフォールとは滝の意味で、水が上から下へ流れ落ちるように開発する手法です。

工程も、上流工程と下流工程とに分けられ、上流工程は、仕様書作成、基本設計が含まれ、下流工程には、詳細設計、製造、単体試験、結合試験、運用試験が含まれます。

メリット

各工程において、全員が納得した納品物を作成するため、明文化された書類、設計書があり次の工程へすぐに入ることが可能です。

また、後戻り作業が発生しないというのもウォーターフォールモデルの特徴です。

技術者は前工程で納品されたものに集中し作業することができ、スケジュールの遅れも少ないとされています。（実際には、技術者の経験等によりスケジュールが遅れることがよくあります。）

見積りも工程ごとに行うことが可能で、上流工程（仕様書作成、基本設計）と下流工程（製造、単体試験、結合試験、運用試験）で金額が変わることがよくあります。

そのため、上流工程をベテラン技術者が行い、下流工程を若手が行うことで、若手の育成を行うことも可能です。

デメリット

デメリットとしてまず上げられるのは、仕様書作成から納品までが長いということです。

時には数年を費やすこともあります。

そのため、納品され実働に投入される頃には、開発言語が古くなっていたり、時にはセキュリティ上の不具合が含まれることもあります。

また、納品までに時間がかかるため、金額も高くなります。

そして、1番のデメリットは、機能の追加・修正ができないということです。

実際には、機能の追加も同時に行うのですが、前工程の納品物から作り直しになり、再度、レビューや押印が必要となるので、さらに時間がかかります。

まとめ

ウォーターフォールモデルでは、若手の育成ができる良い面もありますが、システム開発の期間が長く、金額も高くなるなります。

しかし、工程ごとにきちんとした物が出来上がるため、大手システム企業では今だに使用されている手法でもあります。

そのため、これからプログラマーを目指す方は、ウォーターフォールモデルでの開発を調べておくと、実戦で役に立つかもしれません。

では、今日はこの辺で。

クラス設計とは

こんにちは。

今日は、クラス設計について書いてみようと思います。

クラス設計で大切なのは以下の３点です。

• 基底クラスを作る
• 継承を使う
• リファクタリングを行う

最近は、フレームワークを使うため、いちからクラス設計することはありませんが、クラス設計は、知っていると結構役に立ちます。

クラス設計とは

クラス設計とは、システム開発の詳細設計の工程で作成する設計書の１つです。

クラス図とも呼ばれ、クラスの関連性を図示したものです。

クラス設計がなぜ大切かと言うと、同じ処理を何度も書かないためです。

同じ処理を異なるクラスで書くと、修正する際に大変になりますし、不具合の原因となります。

どのクラスで、どの処理を行うかで、ソースコードが綺麗な読みやすいものになるかを左右します。

綺麗なソースコードは、不具合が少なくなります。

では、以降でクラス設計で大切なことを説明していきます。

基底クラスを作る

基底クラスとは、継承元となるクラスです。

スーパークラスとも呼ばれ、全てのクラスで使用できる変数や関数をコーディングします。

フレームワークを使用していると、基底クラスを作らず、フレームワークのクラスを直接継承し作成することもあるのですが、なるべくフレームワークのクラスを継承する基底クラスを作ることをお勧めします。

経験上、設計・コーディング・リファクタリングしていくと、同じ値を保持することがよくあります。

例えば、状態を保持する変数は、基底クラスで設定し、状態繊維の処理も基底クラスにコーディングすることで、状態の不一致で不具合となることが減ります。

また、例外処理を基底クラスでコーディングするとで、継承先のクラスでは処理に専念することができます。

継承を使う

新しいクラスを作る時は、継承して作成しましょう。

単体のクラスをすぐに作るプログラマーも多いのですが、フレームワークを使用すると、ある程度の必要な処理はフレームワークに含まれています。

せっかく信用あるフレームワークを使用するのですから、フレームワークで用意されている処理は使うようにしましょう。

無理に独自処理を組み込むことは、セキュリティ上の脆弱性を組み込んでしまう可能性もあります。

昔々は、ステップ数が多い方がいいという時代もありましたが、現在は、安全性が重視されます。

リファクタリングを行う

ソースコードは、リファクタリングしましょう。

動くソースコードが出来上がったら、試験の工程へ移行しますが、ソースコードは、何度もリファクタリングを行うことで、より綺麗なソースコードとなります。

リファクタリングでまず必要となるのが、クラス設計の見直しになります。

特に継承先のクラスで何度も使用する変数や処理は、継承元のクラスに移すことで、より洗練されたソースコードになります。

システムは、動作するものができたら終わりではありません。

定期的にソースコードをリファクタリングを行うことで、セキュリティ上の脆弱性を防ぐこともできます。

大きなシステムほど、過去のソースコードには手を加えないという暗黙の了解のあるプロジェクトがありますが、そのようなシステムは、スパゲティコードになっていることがよくあります。

まとめ

クラス設計書は、詳細設計の工程で作成される設計書ですが、何度もリファクタリングを行い、それに伴って改訂をしていきましょう。

クラス設計書があることで、新たな機能の追加や変更にも早い対応ができます。

また、クラス設計を行うツールも多く出ていて、クラス設計からソースコードを生成してくれくツールもありますので、用途に応じて探してみるのもいいかと思います。

では、今日はこの辺で。

良く使われるデザインパターンMVC

こんにちは。

今回は、よく使われるデザインパターンについて書いていきます。

結論から言うと、よく使われるデザインパターンは、「MVC」というデザインパターンです。

おそらく、ほとんどのシステム開発で採用されているのではないでしょうか。

私が携わったシステム開発は、ほとんどがMVCで開発を行っていました。

デザインパターン

デザインパターンとは、GoF の著書『オブジェクト指向における再利用のためのデザインパターン』で記した２３種類のパターンをいいます。

オブジェクト指向の良いところは、再利用可能であるということです。

再利用できるため、システム開発の生産性は上がるはずなのです。

別の機会に書こうと思いますが、実際は、生産性が上がらないことも良くある話です。

MVCは以下の頭文字です。

• Model（モデル）
• View（ビュー）
• Controller（コントローラ）

MVCは、良く使われるフレームワークで使用されており、MVCに分けて設計・製造することで、綺麗なソースコードとなります。

Model（モデル）

Modelは、データを扱うクラスです。

データベースを使っている場合は、テーブルごとにModelクラスを作成することが多いです。

フレームワークによって違うのですが、テーブルごとにModelクラスを作成することで、テーブルの外部キーを使用して、テーブルの連結を行うことができ便利です。

SQLを記載しデータを取得するのも、このModelクラスとなります。

View

Viewは、画面表示のクラスです。

Webシステムでは、ViewにHTMLなどが書かれます。

また、Webシステムでは、ViewはControllerから受け取ったデータをHTMLに取り込み、ブラウザへ渡します。

CSSやJavascriptは、Viewではなく別に管理されることが多いようです。

私の経験では、Viewは、動的な画面のHTMLに値を設定する処理を書いて、静的な画面のHTMLやCSS、Javascriptは、別のディレクトリで管理していました。

Controller

Controllerは、制御をするクラスです。

Webシステムの場合は、まずControllerクラスが呼び出されます。

ControllerからModelを呼び出し、画面表示に必要なデータをViewに渡す処理を行います。

フレームワークにもよりますが、Controllerから返すのは画面表示に必要なデータのみで、実際にViewでデータを埋め込むのは、フレームワークが処理することが多いです。

MVCパターンでビジネスロジックをどこに書くか

MVCのフレームワークを使用する時に良く起きる問題が、ビジネスロジックをどこに書くかです。

結論を言うと、私にも分かりません。

ビジネスロジックとは、実際の処理のことです。

例えば、ボタンを押して、データベースから値を取ってきて、加工して表示するとします。

1. ボタンを押して、Controllerへ処理がきます。
2. ControllerでModelを呼び出し、データベースからデータを取得します。
3. データを加工します。
4. Controllerがデータを返します。

上の処理だと、３の工程をControllerで行うかModelで行うかという問題です。

私の経験から言うと、半々くらいです。

ただし、ビジネスロジックが入るとソースコードが複雑になり、場合によってはソースコードが汚くなることがあります。

ビジネスロジックを書くクラスを作るプロジェクトもあるくらいです。

この問題は、プロジェクトに合わせて設計・製造するしかないと思います。

まとめ

フレームワークでは、良くMVCのデザインパターンが使われています。

そのため、これからプログラマーを目指すのでしたら、MVCを意識して勉強することで、実践で困ることも少ないのではないでしょうか。

では、今日はこの辺で。

プログラムの基本処理

こんにちは。

今日は、プログラムを学習するときに押さえておきたい点について書いていきます。

結論から言うと以下の処理を押さえておけば、プログラムを読むことはできるようになります。

• 分岐（if文）
• ループ（for文、while文）
• 関数

プログラムの基本処理

プログラムは、全てが四則演算でできています。

入力された値を変数に入れて、足したり、引いたりと加工し、出力した値を作り上げます。

私は、いろいろなプログラム言語で開発した経験があるのですが、コーディングを開始する前に、まず確認するのが、分岐、ループ、関数の書き方、呼び出し方です。

分岐（if文）

まず必ずと言って良いほど必要なのが「分岐（if文）」です。

条件によって処理を分岐することは必ず発生します。

Javascriptだと以下のような書き方になります。

if (<条件>) {
// 処理
}

分岐を理解するだけでも、プログラムは読めるようになります。

ループ（for文、while文）

同じ処理を繰り返し行う場合は、ループで処理します。

同じ処理を何度も書かないということは、不具合を減らすためにとても大切なことです。

Javascriptでは以下のように書きます。

for (<初期値> ;<条件> ; <加算> ) {
// 条件が不一致となるまで実行する処理
}

ちょっとわかり辛いですかね。

具体的なソースコードを書いておきます。

var a = 0;
for ( var i = 1 ; i < 5 ; i++) {
a = a + i;
}
// a = 10

a の初期値は０です。

i の初期値は１で、５より小さい値の間、i を１づつ加えて処理します。

つまり、a の値は以下のように変化します。

a = 0;

a = 1;     // i = 1

a = 3;     // i = 2

a = 6;     // i = 3

a = 10;   // i = 4

i は 5 まで変わりますが、条件に不一致となるので、ループを抜けます。

ループには、while文という処理もあります。

while文は、条件判定は処理した後に行う時によく使用します。

つまり、一度はループ内の処理を行った後条件を判定する場合です。

Javascriptでは以下のようになります。

do {

// 処理が不一致の場合に実行する処理

} while (<条件>);

while文で気を付けないといけないのは、条件の部分です。

while文は、条件が一致した場合にループを抜けます。

また、無限ループを作成し、処理内で分岐してループを抜ける場合もあります。

while(1) {

// 処理

if (<条件>) {

break;

}

}

ただ、このような書き方は、できるだけしない方がいいです。

できるだけ条件を入れて無限ループは作らないようにしましょう。

関数

最後に必要となるのは、関数です。

ループ処理でも書きましたが、同じ処理は何度も書くと不具合の原因となります。

同じ処理と何度も必要となる時は、関数にして呼び出すようにしましょう。

また、最近の書き方だと、１関数１処理で書くようにすると綺麗なソースコードになります。

Javascriptだと以下のような書き方になります。

function <関数名> (<引数>) {

// 処理

}

プログラミングの経験を積んだ方でも、処理を関数化せずにダラダラと書く方がいます。

そういうソースコードをスパゲティコードといいます。

処理が長くなって、少し修正するだけで不具合の原因となったりします。

まとめ

プログラムを読む際の基本となるのは、この３点です。

• 分岐
• ループ
• 関数

そして、後は多くのソースコードを読んで、処理の書き方や、綺麗なソースコードの書き方を学んでください。ソースコードは人によって書き方が違います。読むだけでも結構勉強になったりしますよ。

では、今日はこの辺で。

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

こんにちは。

今日は、私がプログラマーをしている理由についてまとめてみます。

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

• 考えることが好きだから
• 楽しいから
• 喜んでもらえるから

私は、もう２０年ほどプログラムに携わっています。

はじめでプログラムを勉強したのは大学の時で、

授業でプログラムの講義を受講したのが初めてでした。

その時は、Basic言語を授業で勉強しましたが、

あまり興味は持ちませんでした。

その後、C言語の授業を受講し、

すでに研究室に入って研究の手伝いをしていた私は、

これは結果の整理に使えると思って自分で勉強するようになりました。

ちなみに、大学１年の後期の頃です。

考えることが好き

私は、いろいろな事を考えることが好きな方です。

どうやって動いているのだろう、どうやって利益を得ているのだろう。

プログラムを書いていても、

単にプログラムを書くだけてなく、

修正しやすくなるように、読みやすくなるように、美しくなるように、

と考えて書いています。

これを考えずに書かれたソースコードは、

動くのですが読みにくく、修正し辛いソースコードになってしまいます。

また、実は不具合が出やすいソースコードは、

何も考えずに動くことのみを目的として書かれています。

プログラミングを行うことは、基礎勉強が終わった方でもできます。

しかし、どうすれば読みやすく、修正しやすく、不具合の少ないソースコードになるかを考えてプログラミングするには、やはり経験が必要となります。

楽しい

私がプログラマーでいる理由は、これが一番です。

やはり、楽しくないと続けていられません。

また、IT業界は日進月歩で発展しています。

それに着いていくには、新しい技術の勉強が欠かせないのです。

勉強といっても、本を読んで勉強するのではなく、

これどうなってるのだろうと興味を持ってWebで調べ、

新しい技術を吸収しています。

この作業は、楽しく、好きでないと続きません。

たまに、どうやって勉強したらいいですか、と聞かれることがあるのですが、

正直勉強しているつもりはないので、勉強なんかしてないよとしか答えられません。

そんな方は、プログラマーと言う仕事を楽しんでないんだろうなと私は思っています。

喜んでもらえる

プログラマーの仕事は、お客様の期待に答える仕事でもあります。

なので、出来上がってお客様の作業が軽減されると喜んでもらえます。

もっとこうしたい、こういい機能も加えたいと言われると言うことは、

そのシステムが喜んでもらえている証拠だと思ってます。

ただ、無料でやってくれと言うお客様もよくいるのですが、

それはちょっと傲慢だなと思います。

喜んでもらえるのは嬉しいのですが、

やはりビジネスとしてプログラマーをやっている以上は、

作業にかかる代金は払ってもらえないとモチベーションも落ちてしまいます。

たまに、ソフトウェアは無料で使えると考えているお客様がいます。

同業者にも、有料ソフトウェアをライセンス料を払わずに使っている方もいます。

ビジネスとしてプログラマーをやっている側から言えば、

投資をして開発されたソフトウェアをライセンス料を払わずに使うのは、

窃盗に近いと考えています。

ソフトウェアを使うのであれば、

きちんとライセンス料を払いましょう。

まとめ

やはり、好きで楽しいことを仕事とすることが一番いいように思います。

楽しくないと、新しい情報を吸収しようと積極的に動けないし、

そもそも、情報が入ってきません。

楽しく働いていればストレスも、あまり溜まらずにすむのではないでしょうか。

では、今日はこの辺で。

NULLは0ではありません

こんにちは。

ほとんどのプログラム言語に存在するNULLですが、
値が0なので0として使っているソースコードをたまに見かけます。

しかし、NULLは0ではありません。

C言語を知ってる方は分かると思いますが、NULLはメモリーのアドレス0番目を指します。

なので、値は0なのです。

しかし、メモリーのアドレス0番目は、不正処理にあたります。

つまり、本来、例外を意味しているのです。

経験の浅いプログラマーが、勘違いして使うのはいいとして、
何年もプログラマーとして働いてきた技術者が使っているとイラッとします。

随分前に関わった開発のリーダーにNULLを0として使っている人がいました。
そのチームのコードレビューに参加したことがあるのですが、
コードレビューの場で0をNULLに置き換えるように指示しているのを見て驚いた事がありました。

後でこっそり教えましたけど、受け入れてもらえませんでした。

ちなみに、NULLは「ヌル」と発音する人と、「ナル」と発音する人がいますが、
「ヌル」はドイツ語で、「ナル」は英語だそうです。

言語によっては、同じ意味でnilを使う事があります。
例えば、Rubyはmilを使っています。

NULLについて少しは理解してもらえたでしょうか。

では、今日はこの辺で。

プログラマーのお仕事

こんにちは。

今日は、ちょっと技術的な内容を書きます。

ここ数年、転職してプログラマーを目指す方が多くなっています。

でも実はプログラムを書くのは、そんなに難しくはないのです。

今回は以下の点について書いていきます。

• ホームページを作る
• Webシステムを作る
• 本当に難しいのは何をするか

ホームページを作る

ホームページを作るには以下の技術が必要になります。

• HTML
• CSS
• JavaScript

HTMLでホームページの枠組みを作り、CSSでデザインをすれば静的なホームページは完成です。

動きをつけたい場合は、JavaScriptを使います。

ホームページを作る時に難しいのは、デザインです。

デザインさえ出来れば、コーディングはそこまで難しくはありません。

それに、今ではWeb上にたくさんの情報があります。

Webシステムを作る

ブログやECサイトを作るのも、そんなに難しくはありません。

ブログならサーバにWordpressを入れればすぐに作成できます。

ECサイトは、EC-Cubeを使えば手軽に作成できます。

新しくWebシステムを作るとなると、ちょっと難しくなります。

それでも、上に書いた、HTML、CSS、JavaScript それとPHPが使えたら、ある程度のWebシステムは作れます。

WordpressもEC-Cubeも使ってる技術は同じです。

本当に難しいのは何をするか

プログラマーになって、本当に難しく感じるのは、システムで何をするかを考える事です。

Webシステムを作りたいお客様と話をして、どこをシステム化すればいいのかを判断するのは、実は担当の技術者という事がよくあります。

また、SFに近いアイデアを持ち込むお客様もいます。

お客様との会話の中から、お客様が本当に欲しいシステムを提案することは、本当に難しいです。

つまり、技術は勉強する事で習得できますが、その技術で何をするかを考えるのが難しのです。


プログラマーを目指すみなさん、技術の勉強をしながら、アイデアを出す訓練もしましょう。

新型肺炎（新型コロナウィルス）への対策

こんにちは。

今日は、新型肺炎（新型コロナウィルス）への対策についてまとめてみます。

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

• 手洗いを徹底する。
• 人が密集する空間ではマスクをする。
• 正しい情報を取得する。

手洗いを徹底する

新型肺炎（新型コロナウィルス）は、接触感染する可能性がり、アルコールに弱いということなので、手洗いを徹底することで拡大を防ぐことができると思います。

流水で十分に手洗いを行うと、ある程度のウィルスは洗い流すことができます。

水は冷たく十分に洗うことも辛いですが、ウィルスの感染拡大を防ぐことができるのですから十分に洗うようにしましょう。

できれば、アルコールで消毒をするようにしましょう。

人が密集する空間ではマスクをする

人が密集する空間での感染が報道などで流れています。

特に通勤電車や事務所内では、自分がウィルスに感染しているかもしれないと考え、マスクをして拡大を防ぎましょう。

「お客様先では、マスク姿は失礼になる」なんてことはありません。

大切なお客様だからこそ、マスクをするようにしましょう。

正しい情報を取得する

非常事態の時はデマが流れます。

正しい情報を取得し、冷静に判断・行動しましょう。

私も、毎日多くの情報を取得します。しかし、得た情報をそのまま受け止めず、まずその情報が正しいかを確認するようにしています。

上記の３点に私も明日から気を付け生活するようにしたいと思います。

みなさんも、ウィルスに感染しないように、ウィルスを拡大させないように気を付けましょう。

課題の分離

こんにちは。

今日は、ちょっと思考を変えて、「課題の分離」について考えてみたいと思います。

私が「課題の分離」という言葉と出会ったのは、『嫌われる勇気』でした。

それまで自分の中でモヤモヤとしていたものが、「その課題は誰の課題か？」というのを意識することで、すっきりとしたのを覚えています。

私は、他人の課題に踏み込んでしまう癖があるようで、会社の将来や後輩の成長、プロジェクトの今後など、自分に関わる課題を全て自分の課題として考えてしまっていました。

「自分には、いろんな課題があるから、自分の課題に取り組む時間がない」と自分に言い訳をしていました。

でも、よく考えると、会社の将来については、社長や役職者が考えないといけないことで、私が考えなければいけない課題ではない。

後輩の成長についても、後輩が自分から学ぼうとしない限り、他人が学ばせようとしても、それは無理というもです。

プロジェックとの今後については、直接自分が関係しているけれど、開発するパッケージを、お客様がどのように使うかはお客様しだいで、私が個人で考えることではなかったのです。

このように、自分が抱えている課題を一つずつ考えていくと、実際に自分が考えないといけない事は、目の前の仕事のことのみになったのです。

ということは、目の前の仕事を解決すれば、自分の時間ができるのです。

自分の時間ができるということは、自分が本来考えないといけない課題に取り組めるのです。

もちろん、社長、後輩、お客様に相談された時は全力で考えます。

「課題の分離」は、私が自由になる最高で最初に行うべきことだったのです。

今後も「課題の分離」によって、自分の課題に積極的に取り組んでいきたいと思います。