ＩＴエンジニアを目指す学生達へ

こんにちは。中城です。久しぶりの更新になります。

さてさて、GWも過ぎ弊社では新入社員の技術研修が始まりました。
これからは、その技術研修を通じて新入社員に伝えたことをメインに更新していこうと思います。


研修を始めて毎年新入社員に必ず伝えることがあります。
それは

・プログラムの１行１行をしっかりと理解すること！
・質問するときには、主語・述語を省略しないこと！
・ほうれんそう　は必ず行うこと！

の３点です。
毎年個性ある新入社員ばかりなのですが、上記３つについては漏れなく教えています。
それは、たとえどんなに優秀であっても、やはり社会人としてまだまだ十分なレベルに達しているとはいえないからです。

では、社会人として十分なレベルになるためにはどのような点に注意したら良いのでしょうか？次回より各項目について細かく説明していきます。

こんにちは。中城です。

システムを作るうえでいつも問題になるのは
「トレードオフをどこに定めるか？」
ということです。
性能を突き詰めるためには速度が犠牲になったり、
また、速度を突き詰めるためには正確性が犠牲になります。

システムとして、実際の現場で使えるものを作るためには
この「トレードオフの落しどころ」をどこに定めるのか？が重要になってきます。
これがあいまいだとシステムにブレが生じ何度も作り直す羽目になります。

では、どうすれば「正確な落しどころ」を定めることができるのか？
正直僕もまだよくわかりません。（というかこの問題に答えることができる人はそうそういないでしょう）
何のためにそのシステムをつくるのか？という目的をはっきりとさせることが
1つの正解といえるかもしれません。

システム（やその元となるプログラム）を作る中で、妥協せざる終えない場合には
この「そのシステムの目的」を明確にし、はっきりとした理由をもって妥協点を
定めるようにしましょう。

こんにちは。中城です。

今日は「メモの大事さ」について書きたいと思います。

日々作業をしたり、新しい技術について学習するときにはいろいろと調べながら
作業を行っていると思います。
このとき「調べたこと」や「聞いたこと」などは必ずメモに残すようにしましょう。

特に重要なのが、仕事に慣れてきたとき　です。
最初の右も左もわからない頃は比較的メモをとることを意識的にやるのですが、ある程度仕事に慣れてくると、メモをとることがおろそかになります。

その理由としては、作業に慣れてきているため、わからないことがあってもちょっと調べればすぐにその答えを見つけてしまうため、その事をそれほど重要ではないと感じるためです。

ですが、僕の経験上、仕事に慣れたときに疑問に感じたことや躓いたことほど後々重要に成ってきます。その躓いた箇所はかなりの人が同じように躓くことがあるからです。

また、今の作業を続けている間はいいのですが、ほかの作業を1年とかして、しばらく今の作業から離れたあと、また今の作業に戻ったとき（仕事のなかではこういうことはよくあります）に、以前躓いた箇所で同じように躓きます。
そのときに、その解決策をとっているメモが大きな意味をなしてくるのです。

仕事をスムーズに進めるためには「メモを取る癖」をつけるのが大事です。
メモを取る習慣をつけ「できるプログラマー」への一歩を踏み出しましょう

こんにちは。中城です。

前回に引き続き自動化の利点について書いていきます。

プログラムに限らず何かしらの作業をする場合に一番気をつけるべきことはヒューマンエラーです。
ヒューマンエラーとはその意味のとおり「人間のミスにより起こるエラー」のことです。
作業効率を向上させるためにはこのヒューマンエラーを排除するのが効率的です。
人間は完璧ではありませんから、必ずミスが発生します。（ミスのまったくない人はまずいないでしょう）

ヒューマンエラーは人間が介在することで起こるのですから、自動化によって人間が介在する機会を減らすことでヒューマンエラーは取り除けるということです。

ヒューマンエラーが介在しやすいのは以外にもとても単純な作業のところが多い気がします。
たとえば、ファイル名をリネームしたりほかの場所にコピーするなど　　です。
しかもこれらの単純な処理でミスを起すとかなり気が滅入ります（ｗ

逆に単純な作業はプログラム化しやすく自動化しやすくもあります。


たとえ1ステップの自動化であっても、その作業を繰り返していけばその自動化の効果は絶大なものとなっていきます。なにしろその自動化した箇所でのヒューマンエラーは完全に取り除けるのですから。

お久しぶりです。現役プログラマの中城です。
ちょっと私事でしばらく更新していませんでしたが、本日からまた更新していきます。

これからの記事は新入社員プログラマ向けに書いていきます。
今回は「自動化のすすめ」です。

仕事をはじめると結構こまごまとした作業に追われて、本来やりたかった
作業ができないことがあります。
ちなみに、よく仕事ができる人とあまり仕事ができない人は、このこまごまとしたことを
どうやって片付けているのか？で決まるのではないかなぁと個人的に思っています。

ちなみに、僕はこまごまとしたこと（特に頼まれごと）はさっさと片付けるようにしています。

結構こういったこまごまとしたことは多いです。頼まれごと以外でもデータ整理やコンバート作業などなど・・・・・

で、こういった細々としたことをさくっと片付けるために「自動化」を取り入れるのが効果的です。
自動化といっても全自動にこだわる必要なありません。たとえば、それを行うために４ステップ必要であるのならば、それを３ステップや２ステップで終わるように一部を自動化するだけでもかなりの効果があります。
また、同じ作業を２度行ったら（データコンバートとかとか）すぐに自動化に取り掛かるとよいでしょう。ここで注意するのは「全自動」にこだわらないことです。１ステップでも縮められるのならそれでよしとしましょう。

僕の経験上、２度同じ作業を行った場合はかなりの確立でその作業を繰り返すことになります。１度で終わる場合は多いですが、２度続いたときは２度で終わることは少ないはずです。(経験上・・・・)


まだまだ書きたいことはあるのですが、今日はここで終わります。

最後に僕の好きな名言を・・・・

「楽をするための苦労をするのがプログラマだ！」

こんにちは。中城です。

JavaやRubyなどを勉強している人は一度はオブジェクト指向の考え方が分からずに躓いた経験があるのではないでしょうか？
僕も以前はオブジェクト指向が理解できずJava言語に抵抗を感じていました。

今回は、そういったオブジェクト指向を学ぼうとしている人にお勧めの本を紹介します。

増補改訂版Java言語で学ぶデザインパターン入門

これを読んで僕もオブジェクト指向とはどういうものか？というのがなんとなく分かってきました。
最初はとっつきにくいかもしれませんが、デザインパターンを学ぶことでオブジェクト指向の利点がみえてくるのではないかと思います。

オブジェクト指向は考え方（設計手法）の一つなので、これが正解というのは無いと思っています。なので正解を見つけようと気負わず、まずは自分なりのスタイルを身につけるつもりで学ぶといいかもしれません。

これを見ている学生にはきっと一番興味のある事柄だと思うので、一社員としての考えを書いておこうと思います。


贅沢をいえば、最初からプログラムがバリバリできて、とりあえず頼まれたことは問題なく解決できる能力がある事になるのですが、この業界を考えるとそういう人は稀だといえるでしょう。
それはプログラマが扱う畑はとても広く、かつ、プログラマが使う道具（PCとかOSとかプログラム言語）はすごいスピードで変化しているからだと自分は考えています。

その中で、唯一変わらない（今のところ変わっていない）ことは電子計算機基礎論でしょう。つまりパソコンの元となっている基礎理論のことです。
自分が扱う道具のことなので当然ある程度は理解しておいてほしいです。

あとは、プログラミングの経験です。できれば参考本の写しではなく、どんなに小さくてもいいので自分で考えて作ったものがより良いですね。


少なくともパソコン（やプログラム）を扱っていて

なんか知らないけど動かなくなった

は絶対にないということを理解できるだけの知識と経験は持っておいてほしいなぁと思います。

今回の記事はカテゴリーの趣旨とは少し外れていると思うので興味のある人だけ読んでもらえたらいいと思います。


現在、プログラマ＝IT技術者　といった通念が横行しているが、僕はそうは思わない。
ゲームプログラマやミドルウェア開発者はIT技術者ではないと考えている。

そもそもIT（Infomation　Technology)とはなんであるかを考えた事はあるだろうか？
IT=情報技術と訳される。
僕は文字通りITとは情報技術、すなわち

情報の収集・分類・定義・抽出

などを行う分野として捉えている。

もちろんそれを基本とし、今現在のインターネットを活用した技術＝IT技術とすることに表立って異を唱えるつもりはない。

ただしかし、これからIT技術者を目指している（もしくは今現在IT技術者として頑張っている）人にはいまいちどITとはなんであるのか？を考えてほしいと思う。

つまりITとは情報の「収集・分類・定義・抽出」などを行うための技術であるのだから、IT技術者と呼ばれる人は、その人自身も情報の「収集・分類・定義・抽出」を行える必要があるべきだ。

それは別に難しい事ではない。要は自分の知りたい事・興味のある事について、調べて、集めた情報から関係のある事を抜き出し、理解することである。
つまり、その行為自体は日常的に行っている事に他ならない。

しかし、現在ではインターネットが発達し、個人が自由に発言のできる場が数多く提供されたことで、より「関係のある情報」を抜き出すことは難しくなっている。
そういった、情報氾濫社会（筆者の造語ですｗ）のなかで、より自分に関係のある・有利な情報をいち早く導き出すためには、やはりそれ相応の技術や経験が必要になる。


常日頃行っている「情報収集」という行為について、無意識的に行うのではなく、意識して行うことがIT技術者としての本当の一歩なのかもしれない。

こんばんは。中城です。

他人のプログラムを参考にしたり、はたまた他人が書いたプログラムを修正するためだったり、自分の書いたプログラムを修正するためだったりとプログラムを読む機会は多くある。

プログラムを読むときにはいったい何に注意すべきだろう？
やはり、コードの１つ１つを正確に把握することだろうか？

しかし、それでは莫大な量のプログラムの場合は全体を把握するのにとても時間がかかってしまうのではないだろうか？


そもそも、プログラムというのは必ずある目的を達成するために書かれているものである。
つまりそこにあるコードの１つ１つには何かしらの意味（目的）が存在するはずだ。

プログラムを読むときにはこの意味（目的）を捉えていくことが重要となる。
１つ１つのコードはもちろんだが、各ブロック（関数）ごとに意味を把握していくことで大量のコードのあるプログラムも少ない時間でその目的を把握できる。


この意味（目的）を把握する事はプログラムを書く場合にも重要となってくる。ただ漠然と必要なことを書き連ねるのではなく、何のための処理をさせたいのか？この条件(if)文は何を判定しているのか？といった事をしっかりと意識することで、よりきれいなプログラムを書けるようになるはずだ。

こんにちは。中城です。

プログラムを書いているとエラーによく遭遇します。
さてエラーが発生した場合あなたはどうしますか？

プログラムを始めたての人によく見られるのは、エラーが出た時点であきらめる（手が止まる）か、表示されたエラーメッセージをよく見ずに自分の書き換えたソースコードとにらめっこすることです。

確かにエラーとなっている原因が単純だったりソースが短ければ、原因となっている箇所を
見つけることができるかもしれません。が、これはあまり良い方法とはいえないでしょう。

まずはエラーメッセージを良く読むようにしましょう。

ほとんどのエラーについてはエラーメッセージが非常に親切にその原因をおしえてくれているはずです。


エラーメッセージは何が書いてあるのか良く分からない。という声が聞こえてきそうですがそんなことはありません。多くの場合は簡単な英語であり、最近では日本語で書いてある場合もあります。
最初はよく分からない単語も多いでしょう。意味の分からない単語があれば検索エンジンで調べてみましょう。親切な解説ページが見つかるはずです。

エラーメッセージを理解することがプログラマとしての大きな成長につながるはずです。