１）使用している技術についての解説、リファレンスマニュアルへのURL等が記載してあった。
　 またそれを使用している理由等についてもコメントで述べられていた。
　
　 本来であれば、このようなことはドキュメントに記すべきだと思いますが、
　 ドキュメントが一切ない場合には、まずソースコードを見ることになります。
　
　 開発当初は、開発初期メンバーが絡んでいることが多く、
　 採用した技術を選定したメンバーがいるため、なぜそれが使われているのか？
　 なぜ他のものを採用しなかったか？
　 などその人に聞かなければわからないことが多々あります。
　
　 後で保守する身になって考え付く理由は、
　 「きっとそれが最適だと思ったんだろう」ぐらいしかわかりません。

　 実は、バージョンの組み合わせ、他のミドルウェアとの組み合わせにより
　 問題があったため、いろいろ検証した結果、現在使用しているものだけが
　 最終候補として残ったのかもしれません。
　 そのようなことが、後から保守する担当者が想像しうるでしょうか？

２）ロジックの理由、特別な書き方をしている理由が述べられていた。

　 ソースコードの書き方が、わざと無駄なことをしているように見受けられる場合でも、
　 実は重要な処理、何か問題を回避するための施策を行っていることがあります。
　 それなのに、保守・改善等を求められた際、「ここが無駄な処理しているな～」
　 という安易な考えで、無駄な処理を取ってしまったばかりに、
　 後々大問題になるといったことがあります。
　
　 これらを回避するためには、なぜそのような書き方をしているのかの、
　 理由（言い訳）を書いておくと後で、他の人がソースコードを見た際に、
　 「○○の問題があるから、仕方なくそうなっているんだな」と納得することができ、
　 安易に手を加えて大問題ということが避けられます。
　

逆に保守にやさしくないコメントをひとつだけ紹介します。
開発者の方であれば、間違いなく納得してくれると思いますが、
ウソが書いてあるコメントが本当に困ります。
コメントがウソなのか、コメントのとおりに実装しようとしたが
記述ミス、プログラムミスによりバグが混じっているのか、まったく見分けがつきません。

コメントには何をしているかと書くことも重要ですが、
なぜそうなっているのかを書いてくれたほうが開発者にとっては助かります。
何をしているかは、ソースコードを読める開発者であれば（普通読めますよね）
見ればわかることですから、書いてくれれば助かりますが、
ないことが致命的なことを招くわけではありません。

ちなみに弊社では、コメントを書くルールがコーディング規約で決まっており、
ソースチェックなども行っているので、コメントなしのプログラム等はありませんので
ご安心ください。
　

今回は、私がハードウェア面の知識を蓄えるために、日々行っていることを紹介します。

（１）一日一度ニュースサイトでリリース情報を確認
常に最新のリリース情報を知らなければ、何も始まりません。
自分が普段使わないような機器であったとしても、大手IT系ニュースサイトで
発表されているリリース情報は、全て目を通しておきます。
この時には流し読みで覚える必要はありません。

（２）特に注目されている商品は発売後3日以内に試す
最新のパソコンや、iPad、Android携帯など、日々ハードウェアは進化しています。
特に話題になっている製品はお客様が使用される事も多く、
その機器向けのソフトウェア開発を依頼される可能性があります。
相談をうけてから触っていては遅いので、必ず3日以内には軽く触り、
今後必ずユーザが増えると考えられる物は、購入して使うようにしています。

（３）ベンチマーク情報を集める
システム開発を行う上で、それを動かすサーバを導入する事があります。
その際にコストとパフォーマンスを最適化するためには、
今市販されている機器の性能と価格を的確に把握する必要があります。
例えばCPUを選ぶ際、IntelかAMDかという選択肢がある場合に、
情報を集めていればコストパフォーマンスの良いものを選べますが、
情報が無いと有名だからIntelで、といった選択しか出来ません。

これらの事を行う上で作業を楽にしてくれる方法に、Twitterがあります。

現在、大手ITサイトやメーカーはこぞってTwitterのアカウントを持っています。
また、メーカーの広報の方のアカウントなどで、Webに載ってない最新情報を呟くこともあります。
その他にも、ハードウェアやソフトウェアの業界で有名な人のアカウントをフォローしておくと、
最新機器の使用感などもいち早く知ることが出来るのでオススメです。

是非、これらの事を1つでも試してソフトウェアだけでなく、
ハードウェアにも強い開発者を目指してはいかがでしょうか。

（１）条件が多い分岐は、ネストになってしまっても、分ける。

A = B かつ、C <> D かつ、E = F または ...というように、
分岐条件が多くある場合があります。

大概、実際のソースでは、「A = B」の3文字で済むことなど無いので、
条件が多くなればなるほど、エディタの横幅から溢れていきますし、
改行を入れても読みづらくなりがちです。

また、仕様変更があった場合にも、
どこに条件を追加するのが妥当なのか判断するのに時間もかかります。

そのため、私は、ネストすることになっても、if文を分けて書くようにしています。

最初は権限区分の条件のif文、その後に日付等データの条件判定のif文など、
なるべく意味によってグループ分けします。

プログラマーとして、なるべくひとつの文に収まることを追求することも大事ですが、
誰でも修正しやすく、誰にでもわかるコードを書くことが、
システム開発においては重要だと思います。

（２）コメントは要所要所にしっかり残す。

よく、コメントを残さなくてもいいようなソースコードを書け、
というようなことが本などに載っていると思いますが、
私は、仕様の重要な点や、なぜこのような作り方をする必要があるのか、
コメントをなるべく詳しく書くようにしています。

プログラム作成にあたり、なぜこのような作りになった（作りをした）のか等、
仕様書に記載しきれないことは、作ったときに書いておくと、
メンテナンスすることになった場合に、非常に役に立ちます。
（書いておかないと、後で思い出せない場合も多々有ると思います。）

また、仕様についてコメントしておくことで、
上司や先輩がソースチェックをした際に、どういう意図でそのソースを書いたのかがわかり、
仕様が間違っていればすぐにわかりますし、
コメントとソースの内容が違っていれば、バグだということもすぐにわかります。

ちなみに、私がコメントをつける際に注意しているのは次の2点です。

1．1つのコメントは、長くなっても2行までにする。

2．他の処理からコピーしてきたソース中のコメントが残ってしまい、
　 内容が食い違ったままにならないようにする。

（３）インデントはしっかりつける。

当たり前のことですが、インデントをしっかりつけておけば見やすいです。
特に、他の人が作ったプログラムを読む時には、インデントが揃っていないと、読むのが大変です。
インデントくらい、と思わずにしっかり揃えましょう。

私たちの作っているプログラムは、一旦作成、納品したらそれで終わりではありません。
お客様のご要望にお応えしやすいよう、
修正しやすいプログラム、可読性の良いソースコードの実装を心がけたいですね。

システム開発において、切っても切り離せない存在がプログラムです。
この業界に入った方は、どんな形であれ一度は、プログラムについて、
学ぶのではないでしょうか？

今回は、「プログラミング言語を学ぶ」とは何かということについて、
私なりに考えていることを書いてみます。

「プログラミング言語を学ぶ」とはどういうことでしょうか？
単に文法や記法を学ぶことでしょうか？
または、その言語特有のテクニックを学ぶことでしょうか？

確かに、文法や記法、プログラミングのテクニックを学ぶことも、
プログラミング言語を学ぶことには違いないかと思います。
初めてプログラミングを勉強する場合は、
文法や記法、プログラミング作法を学ぶことは大切なことです。
これらをおろそかにしては何も始りません。
特に、プログラム初心者は、決しておろそかにしてはいけないことです。

では、その段階を終えてしまった人はどうでしょうか？
少し乱暴な言い方かもしれませんが、
文法や記法、プログラミングのテクニックは、
仕事などを通して他のプログラミング言語を使用した経験さえあれば、
新しいプログラミング言語であっても、それを仕事で利用しているうちに、
ある程度のレベルまでは、簡単に身につけることができるようになってきます。

しかし、はたしてそれでそのプログラミング言語を学んだと言えるのでしょうか？

昔読んだ本には以下のように書かれていました。

「新しいプログラミング言語を学ぶということは、
単に新しい文法や記法を学ぶことではなく、
プログラミング言語を通じてその背景に触れ、
自分の考えを広げることにもつながる。」

確かにそのとおりだと思います。

そのプログラミング言語がなぜ生まれたのか、
何を目的としているのか、何ができるのか、
そして、これからどうなっていくのかなど、
単なる文法や記法、プログラミングのテクニックだけでなく、
そのプログラミング言語の思想にまで踏み込んで学んでこそ、
本当の意味で「プログラミング言語を学ぶ」ということなのだと思います。

私は、「プログラミング言語を学ぶ」場合には、
そのプログラミング言語の思想について学ぶことを強くお勧めします。
なぜならば、そこからは単なる文法や記法を学んだだけでは、
得られない多くのことを学べるからです。
そして、今まで学んできた他のプログラミング言語からは得られなかった
新たなインスピレーションを得ることもできるからです。
そのインスピレーションは、今まで学んできた他のプログラミング言語にも
生かすことが必ず出来ます。
逆に、今まで学んできた他のプログラミング言語で培ってきたものは、
必ず新しいプログラミング言語を学ぶ際にも役立つかと思います。

実際に教育関係者、大学、専門学校や塾の講師、生徒など
教育に携わる様々な人の"生の声"を聞けたことは大きな収穫でありました。

授業や請求関連の業務を紙で管理しているというお客様が想像以上に多く、
システム化し、授業、請求、講師、生徒情報を一元管理したいとのことでした。

そんなお客様に実際に"Your-SCHOOL"のデモンストレーションを見ていただくことで
Web広告では伝わりきらない操作性、効率性、ユーザビリティ等をお伝えすることが出来ました。
また実際に触って頂いた上で使う立場としての意見や感想を頂き、
開発側の目の届かぬところが鮮明になりました。

お客様に製品を提供する立場として、お客様の目線に立ち開発することは、
必要不可欠であることを今回の展示で改めて実感できました。

この経験を経て、これからの開発に活かせれば言うことなしですね。

塾やスクール関連の業務管理でお困りの方は是非とも
"Your-SCHOOL"をお試しください。

絶賛発売中！！

そこで、いくつか障害や仕様変更の対応があったのですが、
その作業を全て一人で行っていて、保守を考えてコーディングする大切さに気づきました。

既に稼動しているシステムを修正するので、
影響範囲などの調査、コーディング、テストという流れで作業を行っていました。
障害であれば、上記に、リカバリー作業が発生する場合もあります。

今までは、コーディングのみ自分で行い、それ以外は上司や先輩が行うことが多かったので、
あまり気付くことはありませんでした。

では、保守を考えてのコーディングとはどういうものなのかというと、
すごく簡単で「可読性を最重視する」ということです。

私もそうなのですが、プログラムが出来るようになると、
意外と凝ったことをしてしまいます。

あまり凝ったことをすると、次にそのプログラムを修正する人は、
そのプログラムの「調査」にどうしても時間が掛かってしまいます。
そう考えると、凝ったプログラムよりも可読性のいいプログラムの方が保守がしやすいのです。

個人的に一番大切なのは、1メソッド1処理という考え方だと思っています。
ごくごく当たり前のことなので、ほとんどのプログラマが思っていることだと思います。

ただ、最近は、1処理も徹底したほうがいいと考えています。
例えば、「更新処理」の中に「データ更新処理」と「論理削除処理」があった場合、
今までは、ともに「更新処理」なので、引数で制御していました。

この場合でも、「更新処理」、「削除処理」とはっきり分けるのがベストだと
今更ながら、そのように考えるようになりました。

上記は、あくまで1例ですが、
保守を経験したことで、コーディングする際に、
いかに次のプログラマが楽に改修できるかを考えるようになりました。

このことは、システムを開発する上で、プログラマにとって一番大切な点だと考えています。

先日「踊る大捜査線 THE MOVIE3」を観てきました。

今回の映画では本庁と所轄の調整を行う調整役という
役職が新しく登場しました。実際は「サーバントリーダー」
ということなので調整役という言い方をするのは
少々申し訳ない感じではあります。
ただ「踊る大捜査線」ではこのような新しい役職が次々登場し、
物語を面白くしてくれます。
それもこの作品の魅力の1つと言えるでしょう。

話は変わりますが、システム開発における調整役といえば
やはりプロジェクトマネージャになるのでしょうか。

プロジェクトマネージャはとにかく調整しなければ
いけないことが多いです。

例えばスケジュールに遅れがでていれば、
納期に間に合うようにしなければいけません。
今チームを抜けてしまっては困る重要なメンバが、
次のプロジェクトが決まっている場合には、
次のプロジェクトのマネージャとうまく話をつける必要があります。
チーム内のメンバの対立をまとめる必要もあれば、
ステークホルダー間の意見の相違もまとめる必要があります。

これらはすべて「調整」という言葉で置き換えることができる作業ですし、
これ以外にも多くの仕事を抱えています。

ドラマと比較するのも違うとは思いますが、
「踊る大捜査線」に登場した調整役の仕事なんかよりも、
やらなければいけないことは明らかに多いです。
そうすると今後は、プロジェクトマネージャの仕事も細分化する方向ですすむのでは。

そんなことを「踊る大捜査線」を観終わった後に考えていました。

近い将来スケジュールとリソースのみの管理を行う「スケジューラー」や、
対立を解消させる「リゾルバー」なんていう役職ができるかもしれませんよ。

システム開発というのはゴールの見えない仕事ではないかと思います。
というのは、どんなに素晴らしいシステムを開発しても、
「もっと良くするにはどうしたらいいのだろうか？」という考えが捨てきれないからです。

私は今までプログラマーとしてプロジェクトに関わってきたことが多く、
特に技術的な面でそう感じてきました。

プロジェクトでは、常にゴールを目指し最善の方法を選択してきましたが、
職業上というか、私の性格上どうしても「もっと良い方法はないか？」
という考えが頭から離れないのです。

プロジェクトでは「今までと同じやり方」を選択しがちです。
なぜなら、技術においても、システム開発全般においても「今までと同じやり方」には
財産や経験があるからです。
ですが、いつまでも「今までと同じ」ではいけないのではないかと思っています。

今までのやり方、考え方はゴールではなく、もっと良くするにはどうしたらよいのかを
模索し続けることによって、弊社のビジョンにもあるように
「新しい価値」を創造できる可能性が広がると信じています。

例えば、新しい技術を学ぶことによって、
今まで出来なかったことや難しかったことが出来るようになれば、
生産性、技術レベルが上がり、より多くのお客様により質が高く、
費用も抑えてシステムを提供できるということになります。
これも1つの「新しい価値」に当てはまるのではないでしょうか。

ゴールが見えないことはツライことでなく、「新しい価値」を創造する過程であると信じて、
システム開発を行っていきたいと考えています。

システム開発について自由に書いてほしいとの依頼がありましたので、
プログラマとして私がいつも意識していることについて書いてみます。

私がいつも意識していること、それは、
「小さな簡単な機能を組み合わせることにより、一つの大きな機能を作る」
ということです。

経験年数が長くなるにつれて、
より複雑でかつボリュームのある機能のプログラムを任されることになります。
つまりは、一つの大きな機能を作るわけです。

何も考えずに大きな機能をプログラミングしようとすると、
大体は機能の複雑さに比例して複雑なコードになり、
バグが発生しやすいものになります。
しかし、小さな機能に分けることを意識して作ることにより
複雑さは解消され、バグも発生しにくいものになります。

機能を小さくすることにより得られる効果はこれだけではありません。
改修がしやすくなるということ、私はこれが一番大きな効果だと思っています。

これは、私たち開発者だけではなくお客様にも有益であることは間違いありません。
なぜなら、改修がしやすくなるということは、
費用を抑えて改修が出来るということになるからです。

このことを常に意識しながらプログラミングをするのは、とても疲れることですが
お客様に満足して頂くシステムを開発するには
プログラマとしてやるべきことの１つだという強い思いがあります。

色々ありますが、最終的な目的はただ１つ。
お客様の会社を増益に導くことだと思っています。
それに尽きる。それしかない。

ただ、個人的な想いとしては、利益を出した後のことの方が、
本来は大事であろうと思っています。
利益を出して、その会社が何をしたいのか、何を目的としているのか？
経営理念ですね。

詳しくは「会社概要」をご覧いただきたいのですが、私は、
弊社の経営理念、ビジョンにある「取り巻くすべての人々に幸せを与える...」
というくだりが、とても気に入っています。
アイロベックス（I LOVE X）という社名の由来にも通じているし、
個人的なビジョンともマッチしているからです。

その会社（もしくはその人）が、何をやりたいのか？
何を目的としているのかが、本来もっとも大事なことであり、
利益を出すのは、そのための手段（大前提）であると思っています。

個人に置き換えても、まったく同じ。
自分に何が出来るのか？ ではなく、自分は何がしたいのか？
ということだと思います。
個人理念ですかね。

IT（システム開発）を通して、お客様を増益に導くことを大前提とし、
その先にある想い（理念）までも共有できるようであれば、
本当に幸せなことだと思います。

私個人としては、いままで大手SIerさんから案件をご紹介いただくことが多く、
実際、大規模なシステム開発プロジェクトにいくつも絡んできました。

この２つのタイプのプロジェクト...
------
(1)直案件のプロジェクト（規模はさまざま）
(2)SIerさん絡みプロジェクト（大規模が多い）
------
(1)はお客様と直接やりとりをさせていただく為、
お客様の立場、気持ち、困っている点など
非常に身近に感じられ、且つ 中小企業ならではの
小回りや融通の効く、時代に沿ったサービスを
提供しやすいというところが良い点です。

(2)は残念ながらお客様との距離感は離れやすくなりますが、
大手SIerさんが長年培ってきた仕組み（プロジェクト管理など）を
肌で感じられるところが良い点です。

(1)(2)を両方経験することにより、
お互いの良い点を明確に体感することが出来るため、
システム開発に携わる人間として、
一回りも二回りも成長できると思います。

(1)(2)の両者から得た良い経験を、互いのプロジェクトに
活かすことが出来るのは大きなことです。

人間、頭ではわかっていても、実際の比較対象がないと
なかなか実感として得ることが出来ません。

私は日頃、iPhoneアプリの「マイコミジャーナル」、
「産経新聞」を利用して情報収集をしています。

ご存知の方も多いかと思いますが、
「マイコミジャーナル」は、毎日コミュニケーションが提供している情報サイトです。

「マイコミジャーナル」 URL：http://journal.mycom.co.jp/index.html

その「マイコミジャーナル」のアプリ版もWEBサイト同様、
様々な最新情報を提供してくれます。

ハードウェア、ソフトウェア、プログラムに関するIT系の情報だけでなく、
芸能・映画・ゲームといったバラエティに富んだ最新の情報を提供してくれます。

異なる分野の最新情報を一気に得ることができるので、非常に効率的で便利です。

更新頻度も高く、毎日情報が入れ替わるので、飽きることなく利用できます。

次に、「産経新聞」についてご紹介します。

このアプリは、その名の通り、産経新聞をiPhoneアプリにしたもので、
iPhone上で産経新聞を読むことができます。

毎朝の通勤時に、これらのアプリがチカラを発揮してくれます。
非常に混んでいる電車内では、雑誌等を読みたくても、
ある程度の空間を確保しなければ読むことはできません。
しかし、iPhoneならば片手で操作ができる、僅かな空間さえあれば閲覧が可能です。

通勤時は非常に頭が冴え、集中するのに最適な時間帯です。
有効に活用するならば、これらのアプリを利用して情報を頭に叩き込むために利用するべきです。

しかも、これだけのサービスを提供するにも関わらず、
無料で取得できるというのも非常に好感が持てます。

その日一日の話のネタがなくて困っている人、
朝忙しくてニュースを見る暇もない人にお奨めのツールです。

一つの仕事を長く続けていれば（例えば１年以上）、
その仕事が向いているといえる確率は非常に高いと思います。
（仕事の質にもよりますが）

ただ、本当に向いているという意味で、ひとつポイントを挙げるとしたら...

「提供する側として長く続けられるか」

ということが言えるかもしれません。

例えば、自分の好きなことを仕事にしたいと思うのは当然であり、
ゲームが昔から好きだったから、
ゲームプログラマになった、というのは自然な流れです。

ただ、必要なのは「提供する側」としての意識であり、
「ゲームをするのが好き」という提供される側の理由だけでは
不十分だということです。

ゲームを作り続けることが出来るかどうか？
提供し続けることが出来るかどうか？
成果を出し続けることが出来るかどうか？

結構当たり前のことを言っています。

何を隠そう私も経験者です（４月だったかも）

５月病とは新入社員が新しい環境に適応できず、
不安、無気力など、精神的な症状に現れることですが、
私の場合も「自分はこの仕事に向いてないんじゃないか？」とか、
なんだかんだ理由をつけて早く辞めたいと思っていた時期がありました。

この事は５月に限らず若い人に良くありがちな悩みです。
しかし、何も感じることなく、ただボーっと生きているよりは、
色々なことに悩み、迷いながら生きている方が
社会人として遥かに素養があると思います。

この話題については、無責任なことは言えないですし、
人それぞれ違う悩みがあるでしょうから一概にも言えません。

ただ一般的には...
「そんなに早く向き不向きなんて判断できない」
「長く続けるということはそれだけで価値がある」（特に日本では）

暗に「もうちょっとやってみろよ」といっているのではありません。
やり直しなんていくらでも出来るという考えもありますし、
全ての人に適用する理屈でもありません。

ただ１つ言えるのは、
「迷っている時間は無駄である」ということと、
この先も色々なことに「悩み、考え」続けてほしいということ。

私は今年で入社１５年目！（長過ぎ）