さて、6月に入って、4月入社の新入社員が現場にやってくる時期になりました。研修で習ったことと現場との違いに戸惑うことも多いかと思います。今回は、現場に配属された新人が、プログラマとして仕事を始めるにあたって知っておきたい3つのことをご紹介したいと思います。わたしがJavaプログラマなのでJavaのことがメインになりますが、他の言語でも同じようなものです。
■IDEもエディタもあるんだよ
JavaでIDEといえばEclipseやNetBeansなどが代表的なものとしてあげられます。これらのツールは、ダウンロードしてインストールするだけでは、十分使いこなしているとはいえません。時には必要なプラグインを入れて機能を拡張したり、自分の手になじむキーバインドやテンプレートを設定したりと、ツールに自分を合わせる以上にツールを自分に使いやすいようにあわせることができます。LLであればvimやemacsを使うことが多いので、こちらも同様にプラグインで機能拡張したり、設定ファイルを自分好みに編集します。
自分の中で、「このツールはしっかり使える」というものを持っていると役に立ちます。とくにIDEで1つ、スクリーンエディタで1つ、合計2つ持っていれば、どのような環境でも作業に支障となることはないでしょう。
■最後に残った道しるべ（メッセージ）
過去にこんなやり取りをしたことがあります。
先輩「サーバとまってるみたいなんだけど！」
わたし「ログになんて出てます？」
先輩「みてない！」
わたし「え？」
新人じゃないエンジニアでもログやメッセージを確認しない人がいます。エンジニアの基本として、出力されているメッセージは見逃さないようにしましょう。さすがに異常終了したというだけでは、原因の特定なんてできません。もしかしたら、ここが原因かもという程度の推測は可能ですが特定にはいたらないでしょう。例外（Exception）が発生するには原因が絶対あります。スタックトレースであったり、HTTPのステータスコードであったり、任意で出力しているログであったりと問題の原因はかならずどこかに出力されているものなのです。
他の人にサポートしてもらうにも、これらの現象を正しく伝えることができるかどうかで対応するのにかかる時間が変わります。もし、メッセージの読み方がわからないのであればどういう経緯で問題が発生したかを伝えるようにしましょう。そうすれば、問題解決の糸口を見つけることができるかもしれません。
得にデータベース関係であれば、エラーコードが定義してあるのでそのコードでドキュメントを調べたり、インターネット検索して問題解決をすることがあります。（たまにさっぱり訳の分からないエラーを吐くミドルウェアもありますが……）
■「車輪の再発明」なんてないんだよ
世の中には優れたライブラリが数多くあります。それらを使わずに同じ実装をすることを、車輪のように当たり前にあるものを再び作ることに例えて「車輪の再発明」と呼びます。開発におけるバッドプラクティスの1つです。
いきなりさまざまなライブラリの内容を全て理解して自由自在に使いこなせというわけではありません。こういうものがあるんだなぁ程度でよいかと思います。存在を知っていれば、同じものを実装しなくても、そのライブラリを使えばよいわけです。Google先生に聞けばサンプルソースの1つや2つくらいはヒットするので、それを足がかりにすれば使い方も分かります。
JavaならばApache commonsやApache poiあたりを知っておくと、テスト時などにつかうような使い捨てツールには大変役に立ちます。たとえばExcelファイルにあるデータをDBに取り込みたいときなど、この2つの組み合わせで簡単に作ることができます。
そこからさらに一歩進めるには、そのライブラリがどのようにできているかを知るためにソースコードリーディングに挑戦するのもよいでしょう。オープンソースでなくても使う言語のAPIのコードを読んでみるのも勉強になります。さまざまな設計思想に触れるよい機会となります。
新人じゃない方はソースコードを読みましょう。OSSのソースコードを読んで、自分のソースコードに絶望することがあるかもしれません。でも、それは決して悪いことではありません。次に書くソースコードがよくなればいいのです。
これ以外に知っておきたいことはいろいろあります。
たとえば……
などなど。
これらは会社やプロジェクトによってさまざまなので、諸先輩方に習うのが一番でしょう。先輩方におかれましてはしっかり教えてあげてください。新入社員の方は教わったことで気に入らないことがあれば、ガンガン先輩方に突っ込むのを恐れてはいけません。楽しく宗教戦争しましょう。そうすることで、少しでも良い方向にプロジェクトが進めばと思います。
今回は、新人プログラマの方に知っておいてほしいことをお送りしました。入ってすぐはいろいろうまくいかないことばかりかと思いますが、1日も早くプログラマとして仕事ができるようお祈りしております。それでは、また次回。
■お知らせ
少し先ですがオープンソースカンファレンス2011 Kansai@Kyoto（7/15（金）と16（土））に参加します。
金曜日にエンジニアライフのブースに、土曜日はエンジニアライフのブースとセッション（LT）にそれぞれ参加予定です。わたし以外にもエンジニアライフのコラムニストの方が参加されますのでぜひお越しください。詳細はこちら
]]>3月の初めから新卒準備カレンダーという4月から新入社員としてIT業界に飛び込む方向けのAdventCalenderが進行中です。わたしも参加して1つ自分のブログにエントリをUPしました（ほんとうの4月からの新生活と向き合えますか）。今回はそこには書ききれなかったけど新入社員にお伝えしたかったことをお送りします。タイトルがわたしの勤めている会社の社員募集っぽく見えますが、まったく関係ありません。
■ブログはエントロピーを凌駕する？
わたしは新卒で入社した会社の新人研修でオブジェクト指向の概論とJavaを学びましたが当時クラスが何か、メソッドが何か、ガベージコレクションとは何か、むやみやたらにstaticをつけたらどうなるか、なんてことをJava言語仕様というドキュメントに基づいて習ったのですがさっぱりわかりませんでした。
今でこそ人並みにJavaを書いて仕事をしていますが当時は何のことかさっぱりわからなかったのです。そのため、休みの日にJavaの初学書を買って勉強しました。それでも、新入社員の中では下から数えた方が早いくらいの習熟度でした。
4月に入社すると多くの会社では新人研修ということで様々な研修が行われます。最初はビジネスマナー研修などから始まり技術研修やOJTなど長い場合は半年以上かけてさまざまなスキルを身につけるための研修が続きます。その中で内容を理解できないことがあるかも知れません。社内の研修でわからなければ本を読んだり、ネットの記事を調べたり、人に聞いておぎなうしかありません。そこで忘れてはならないのは調べた技術をアウトプットするということです。
世の中のモヒカン族（技術に長けた日々修練を怠らない人たち）の方々に共通していることは学んだことを必ずアウトプットしているという点です。ブログであったり、Twitterであったり、LightningTalksであったり人によってさまざまですが「こんなことがわかった！」と声を上げるということです。
「こんな初歩的なことを書いても笑われるかもしれない」と不安に思うかもしれません。でも、だれでも初めてその技術を学ぶ時は初心者です。どんだけキャリアを積んでも初めて触る言語でつまずくことはあります。あなたが1つブログのエントリを書くことで、そのような初心者の手助けになります。
逆に「○○が分からない」というのであれば、わからない点、調べたこと、やってみたことをブログの記事にしてしまえばいいのです。わかる人が教えてくれるかもしれません。
自分のわかることやわかったこと、わからないこと全部アウトプットすればいいのです。そうすれば自然とそのジャンルに興味をもつ人々が集まってきます。そのようにして人のつながりができれば、また新しいことにチャレンジするきっかけともなります。
きっとブログを書くことで苦労する内容以上の得るものが生まれるはずです。
■一生懸命働いて家に帰ると、ただ寝るだけ？
1日はどんな人にも24時間あります。人により仕事と睡眠の時間のバランスはさまざまですが8時間働いて、8時間寝ると残りの8時間は自由に使える時間になります。この8時間の中から通勤時間や食事の時間などを引いても4時間は残ります。4時間あったら何ができるでしょう。映画なら2本見ることができますし、本を読んだり、遊びに行くこともできます。これはあくまでも平日の話ですが、休みの日となればほぼ1日自由な時間とすることができます。（ただし家族サービスなどの時間は別です）
学生のころに比べると遊ぶ時間などが減ったように感じるかもしれませんが意外とそうではありません。遊ぶ時間はあります。ただ、遊ぶ時間のうち10％でも20％でもいいので、勉強する時間にあてたほうがよいでしょう。学生のころのように定期的に試験があるわけではありませんので、絶対この日までにこれだけやらなければならないというリミットはありません。
勉強することで仕事の時間を圧縮することができれば、さらに自由に使える時間が増えます。つまり、遊べる時間が増えるということです。または、「遊び」そのものを効率化するのもよいかと思います。ゲームを効率的に進めるためにツールを実装してみるというのが良い例です。楽しんで技術的な勉強をすることができますし、ゲームをする時間を圧縮できて他のことを楽しむ時間に割り当てることができます。
これらのことをつきつめて行くとリソース管理につながります。入ったばかりのころはあまり求められませんが、将来的には必要なスキルを自然と身につけることができます。
■胸を張れ！えへんと！
java-jaの創始者であるYoshioriさんは、以前こんなことをTwitterでPOSTされていました。
ブログラマになりたいって人に目を輝かせて「プログラマってイイヨ！！」って勧められない人間はプログラマなんかやめちまえと思う
Twitter / @Yoshiori: ブログラマになりたいって人に目を輝かせて「プログラマ ...
ITエンジニアだけでなく社会人として会社で働きはじめるとつらいこともいっぱいあります。入社したばかりのころはこの先何年もこの仕事を続けることができるかなんてわかりません。でも、自分の仕事を胸をはって「ITエンジニアってイイヨね！」という気持ちだけは持ち続けてください。
わたしも初めてStrutsをつかっての開発に参加した時、最初は何も分からず1日Eclipseと向き合ってコードを書いても何も表示されない日やオブジェクト指向があまりよくわかってなかったために変なコードを書いてしまって先輩に怒られたりとかしながら日々の業務をこなしていました。そして、自分が担当した処理が全て正常に動くようになりました。それまでは何も分からずひたすら作っていたものが全てつながり動作するようになった時の喜びは今も覚えています。「Hello,World」が初めて表示されたとき以上の感動でした。それが「ITエンジニアってイイな」と思えるきっかけでした。
ITエンジニアという職業を好きになるきっかけは人によりさまざまだとおもいますが、新入社員のみなさんがそのような体験をして胸を張って自分の仕事はイイよと言ってくれることがわたしたち先輩の楽しみでもあります。新入社員の方が1日でも早くそのような体験を出来るよう願っています。
今回は新入社員に向けてメッセージとして今回は書いてみました。新卒準備カレンダーも素晴らしいエントリが集まっていますので新社会人もそうでない方もぜひ一度お読みいただければとおもいます。
このコラムを読んで下さった方とどこかでお会いできることを楽しみにしています。
それではまた次回。
]]>このたびの東北太平洋沖地震によって被害にあわれた皆様に心よりお見舞い申し上げます。
地震発生時は仕事中で、客先のビルにいました。ちょうど仕事も一区切りしたところで、自席でコーヒーを飲んでいるときに地震が発生しました。あぁいつもの小さな地震だな程度に思っていましたが揺れも長く激しくなり、これは危ないと感じ揺れが収まるまで机の下で身を守る体勢となりました。その後、ビルは非常用電源に切り替わり、避難するように指示されました。そのあと、ビルから自宅まで徒歩で帰宅しました。
わたしは、大きな地震にあうのはこれで3回目です。1回目は1995年に発生した阪神・淡路大震災です。中学生であった当時、神戸で被災しました。このとき神戸の町は甚大な被害を受けました。自宅も半壊となりました。2回目は2000年に発生した鳥取県西部地震です。大学生だった当時、鳥取で被災しました。このときは鳥取県東部にいたので、自分の周りではさほど大きな被害ではありませんでした。そして、今回の地震です。
今回は、わたしの経験から、巨大地震が発生した直後どんなことが起こるかをお送りします。
■地震は一瞬。でも、起こったことを理解するには時間がかかる
どの地震も共通して言えるのは、地震が発生するのは「一瞬」だということ。最大の揺れが続くのは5分もありません。しかし、実際にどのような被害が発生し、何が起こったのか理解するには少なくともその後、１時間はかかります。さらに、被害の詳細状況が分かるのは、半日以上かかります。さらに冷静に事象を分析できるようになるには、もっともっと時間がかかります。
地震発生直後は、安全の確保が第一です。建物の中が危険であれば、外に避難することや津波が発生するような場合は高台に避難するなど、身を守ることが一番です。その後で情報収集しましょう。避難しながら、携帯電話やスマートフォンで情報収集をしている姿を多く見かけました。停電などで足下も悪く、さらなる被害を招く恐れがありますので、身の安全を確保してからにしましょう。
また、地震発生直後のインターネット上は「情報をください」というリクエストが圧倒的に多く、レスポンスはあまりありません。また、回線も混み合っていたり、ネットワークに接続できないことが多いので、そんなに焦って情報収集しても効率がいいわけではありません。
よくネット上で言われる「まだ焦る時間じゃない」ではなく「もう焦っても仕方ない」という心持ちで落ち着いて行動しましょう。
■ライフラインが寸断される
電気・ガス・水道は日頃あって当たり前なのですが、巨大地震の後はこれらのものは止まってしまいます。経験上、復旧は電気、水道、ガスの順だと思います。ただし、今回のように、電気は復旧したものの、電気需要の状況によって使用不能となることもありえます。水道も、飲み水として利用できない状態になることもありえます。
当たり前のようにあったものが急になくなると、とても不安になります。「なくして初めて分かる大切さ」なんていう話をよく聞きますが、まさにその通りです。とくに、電気がない状況では、携帯電話などのバッテリが切れてしまうと、通信手段を失うことになります。発信着信とも不可能となり安否も分からなくなってしまいます。
電話回線はしばらくトラフィックが増大して使いものにならないので、繰り返しかけ直したい気持ちをグッと押さえて、電池を温存しましょう。とくにスマートフォンは、バッテリ消費量が早いので注意が必要です。インターネットが利用可能である場合は、SkypeのSkypeOut機能を使うと一般回線に電話をかけることが可能です。今回の地震後、実家に無事を知らせる時に利用しました。
■電車も止まる
電車だけでなく、交通機関も止まってしまいます。今回の地震発生後と翌日は徒歩で職場に向かいました。幸い、自宅から職場があるいて1時間ほどなので可能だったのですが、離れたところからの徒歩帰宅となると、大変です。職場の近くで自転車を買って帰宅したという方もおられたようです。
交通機関の乱れは当分の間、続きます。今回のように計画停電があると、なおさらです。そういうときは不要不急に出社することを控えるべきでしょう。どうしても会社にいかなければならないという事情がなければ、交通機関が落ち着いてからの出社でもよいのではないでしょうか。
ITエンジニアの仕事であれば、「在宅勤務」というのも1つのやり方です。そのための環境構築や、社内の仕組み作りはあらかじめ必要ですが。
今回は、わたしの経験から大地震発生後に何が起こるかということをお送りしました。直接の被災地域ではないのですが、今回の大地震でシステムの運用に問題が発生した上に年度末も近いということで、急に忙しくなりました。しばらく、このような日々が続きますが読者の皆様も十分に気をつけてお過ごしください。
それでは、また次回。
]]>仕事も少し落ち着いてきたのでしばらくはイベントざんまいできそうなので、11月27日はWebSig1日学校というイベントへ、12月4日は関西で開催されるエンジニアライフのコラムニストイベントに参加します。関西ではLTもしてくるので、できれば関西弁LTがいいなぁと思っています（といっても出身は神戸なので、関西弁でしゃべれないってことはないのですが）。
さて、今回は仕事に使えるLT技術についてお送りします。日々の長い会議を少しでも改善して、忙しい12月を乗り切るきっかけになれば幸いです。
■日ごろの会議を振り返ってみると……
会議体には2つのスタイルがあります。1つは、議題について議論を行って決定するスタイル。もう1つは、決定事項や事実について報告するスタイル。前者はシステム障害についてどのように対策を取るかなどの会議、後者には作業の進行状況を確認する会議（報告会）が当てはまります。
特に、スケジュールの確認を行うような会議には、時間をかけたくありません。時間をかけたところで、それで生まれる効果が薄いからです。そのような会議を延々とやるくらいなら、手持ちの仕事を進めたい、というのが正直なところです。では、この場でどのような情報があればよいでしょうか。
1．作業のステータス
作業のステータスについての報告が最初に行われます。例えば、未着手・着手中・レビュー待ち・完了などは一言で済む話です。
2．作業のステータスの詳細・完了予定
具体的な数値や指標を示して現在の状況を説明します。例えば、「テスト項目数が○○あるうちの△△が完了していて、バグが□□件あります」など具体的な要素を盛り込んで説明が入ります。加えて、作業中であれば作業の完了予定などを報告します。
3．作業においての問題点
何か問題が発生しているのであれば、その内容について報告します。
これ以外については、特に時間を割く必要がありません。しかし、現実の会議では、これ以外の発言をだらだらと繰り返す人がいます。そのような人の発言を聞いていると、作業の内容について延々と話をしたり、作業の遅れについての言い訳が多くあって、あまり効率的とは言えません。場合によっては、愚痴や文句に当たるような発言を繰り返す方もおられます。聞いてる側からすると「どうぞ飲み屋でやってください」と言いたくなる感覚すら覚えます。そのような発言をするメンバーが多くいるのであれば、プロジェクトとして問題が別にあるので、別の対策が必要かと思います。
■教えて！ 魔法（LT技術）の上手な使い方！
ここで、前回LTで必要な技術としてお話しした『話すべきこと・話さないことの切り分け』を考えてみます。上の3つの点に注意しながら、報告する内容を考えてみます。そうすると、話す方としては話す内容を圧縮し、効率よく報告を行うことができますし、聞く方も整理されているため、理解が早くなります。複数の事項について報告を行うときも同じ順で報告すると、聞く方の理解もさらに早くなります。
この順で話すことには、実はもう1つ、LTで使うテクニックが隠されています。それは『大事なことは最初に伝える』ということです。
作業の状態を報告するうえで、一番大事なことは何でしょうか？ それは細かい作業の状態ではなく、『作業が終わっているかどうか』なのです。その話を起点に、話題を細かい情報に移していくことで、話を聞く方が理解しやすい形にしていきます。
この2つを押さえることで、話す内容はよりスマートな形になります。会議中に、1人でダラダラ話し続けてもあまりよいとは言えません。必要なこと（伝えなければならないこと）を最初に話し、そこから内容をブレイクダウンして、聞いている方に理解しやすい形で提供することが一番のポイントなのです。
今回は、「すぐに仕事で使えるLT技術」についてお送りしました。LTでは、限られた時間で自分の伝えたい情報を効率よく伝えられるかどうか、という点がポイントになります。印象に残るLTの多くは、5分間のストーリーが明確であるものが多く、話したいことが聞いている人々に分かりやすく伝えられているものが多いように思えます。
日々の仕事で、会議に掛けるコストは少なくありません。それだけのコストを掛けて、十分な成果が得られているでしょうか。成果が出てないようであれば、会議のコストを減らすための取り組みを行う必要があります。『長い会議＝仕事をしている』という勘違いをしないようにしたいものです。
■LTイベントのお知らせ
12月もGenesis Lightning Talksが開催されます。今回は「ざっくり2010」と題して、2010年を振り返るLT大会をおこないます。ベテラントーカーのLTを聞いて技術を盗むもよし、LT初心者枠で年内にLTデビューするもよし、といったイベントです。残念ながらわたしは他のイベントで関西に行っておりますので不参加ですが、ぜひお越しください（参加申し込みはこちら）。
次回もLTについてお送りする予定です。年末にかけて、さまざまなイベントが増えてきます。その中で少しでも役に立つLT技術をご紹介します。それではまた次回。
]]>さて、お休みしていた間に仕事の面で動きがあり、プロジェクトを引っ張る立場になりました。チームメンバーは少ないものの、メンバー管理やお客さまとの調整、ほかのプロジェクトとの調整などに走り回っています。落ち着いてコードを書きたいと思うこともありますが、残念ながらそういう時間は減ってしまいました。
わたし自身もそうですが多くの人は「打ち合わせ」や「ミーティング」という会議体に時間をかけたくありません（ごくまれに、会議時間は長い方がいいと考えられている方もおられますが）。そのため、短い時間で効率よく物事を伝え、議論を組み立てる必要があります。
「短い時間で効率的に物事を伝える」。これは、よくIT系イベントの締めで行われているLT（Lightning Talks）に似ていると思いませんか？ というわけで、今回はLTについてお送りします。
■「そんな短い時間で大丈夫か？」「大丈夫だ。問題ない」
まず、LTのルールについて確認しておきましょう。ルールはたった1つ。「制限時間は5分。5分経ったら途中でも終了」。これだけです。質疑応答もありません。イベントによって制限時間は変わりますが、基本は5分です。5分経てばドラが鳴って終了です（イベントによってはブブゼラであったり鐘であったり、さまざまです）。
何もない状態から5分間話をするのは、意外と難しいものです。しかし、1つのお題に対してスライドを作って練習してみると、5分を超えることはよくあります。つまり、LTは「5分しかない」と考えられます。「聞いている人に自分の考えを伝える」ことを考えると、早口でまくしたてるように話すのがいいとはいえません。細かいことを伝えるには、5分という時間は非常に短いのです。そのため、伝えることを必要最小限にとどめなくてはなりません。
LTで一番難しいのは「話すこと、話さないことの切り分け」なのです。
■「そんなスライドで大丈夫か？」「一番いいのを頼む」
次に、スライド作りです。一般的には、5分で話す分量であれば「スライド2～3枚＋表紙」という形がよいとされているかと思います。わたしが先日参加した研修では、そのような形であるべきという話がありました。1つのスライドに図や表をできるだけ詰め込んで、それをひたすら説明するのです。
ですが、聞く立場からすると、そのようなスライドを見て退屈に思うだけでなく、本当に伝えたいことは何なのか分からなくなってきます。LTでは5分しか持ち時間がないので、スライド１枚を見たときにすぐ把握できる情報量であることがベストなのです。
わたしがLTで使うスライドは、5分で40枚前後あります。1枚あたり10秒もかけられません。よく、テレビでスケッチブックを持って話をするタイプの芸人さんがいますが、彼らが1枚あたり1分も2分もしゃべっていたらどうでしょう？ 非常に退屈だと感じると思います。１枚あたりの情報量をあえて減らし、スライドをテンポよく進めることで、聞いている人たちを退屈させることなく、自分に世界に引っぱりこめるのです。
■LTが持つ唯一絶対の力、それは自らをアピールすることだ
LTをするとき、絶対に忘れてはいけないことが2つあります。1つは必ず自己紹介をいれること。もう1つは聞いてくださった方々への感謝の気持ちを忘れないこと。
自己紹介は、せっかく前に出て話すのですから、しっかり自分のことを覚えて帰ってもらいましょう。自分のTwitterIDやブログのアドレス。興味のある分野や趣味などについて、冒頭で触れておくとよいでしょう。イベント後の懇親会で声を掛けてもらえたり、ほかのイベントで声を掛けていただいたりと、出会いのきっかけになります。個人的には、自分から声を掛けていくのが苦手な方なので、声を掛けてもらえるととても嬉しく感じています。
LTの締めは「ご清聴ありがとうございました」など、聞いてくださった方への感謝を忘れないように。ドラが鳴ってもその一言くらいの時間はあるので、最後の締めのあいさつは忘れないようにしましょう。
■そうだな、次はこれを読んでいるあなたにも付き合ってもらうよ
いきなりLTをしてみようといっても、ハードルが高いかもしれません。そんなLTデビューを目指す方を応援するイベントが開催されます。「圧倒的なLT」をするためのノウハウや資料作成をハンズオンで学べるうえに、最後には自由に発表できる懇親会＆野良LT大会までセットになったイベントです。
わたしも、第2部のGenesis Lightning TalksプロデュースのLT大会に登壇する予定です。
さて、今回はLTの触りの部分についてお送りしました。次回は、仕事に生かせるLTテクニックについてお送りします。それではまた次回。
]]>さて今回は業務中に発生する作業について「なんで？」 とツッコミをいれることについてお送りしていきます。業務において発生する作業に「なんで？」 というツッコミをいれることで、作業について考え直すキッカケをつくりましょう。
■日常業務で「なんで？」 と思うことはありませんか？
わたしが大学を卒業して初めて勤めた会社の先輩に「どんなソースコードでも1行1行意味がある。意味を説明できないソースは書くな」と教わったことがあります。以前このコラムでご紹介した『なれる！ SE――2週間でわかる？ SE入門』（電撃文庫）という本の中でも、主人公に対して先輩が同じようなことを説いています。
日々の業務の中で「なんでこの作業が必要なんだろう」と考えたことはありませんか？ 仕事を始めたばかりのころ、指示通りに作業していればこのような疑問はもたないかもしれません。しかし、時間が経ち経験を積んできても、このような疑問を持たないとしたらどうでしょう。現状がパーフェクトであれば問題ありませんが、そうでないならばいささか問題です。少なからずどのような現場でも「なんでこんな作業をやっているのだろう」「なんでこんな手順でやっているのだろう」と疑問に思う部分があるかとおもいます。
ドキュメント1つをとっても、なぜこのようなものを作成しているのだろうか、と考えることがあります。その多くの原因はその作業が生み出す効果や付加価値が作業と釣り合いが取れていないからです。何日もかけて作ったドキュメントも、それが十分に活用できなければ、コストと効果が見合っていないといえます。よくいわれる「リーンな開発」とは、真逆の状態です。
「なんで？」 と思う作業には、必ず何かしらの無駄な部分があります。「人生回り道」なんてCMが以前ありましたが、仕事ではなかなかそうはいきません。無駄な作業はできるだけ避けるべきです。無駄な作業をいつまでもやっていてもモチベーションも下がる一方でしょう。無駄な作業は無駄なコストになり、結果、誰も得しない状態を招くだけです。
加えて、無駄な作業は、プロジェクトを管理する数字にも、なかなかあらわれません。誰しもが、それをやることを疑問に思わないからです。作業がアサインされたときに「なんで？」 と一度考えてみてください。分からなかったら、作業の依頼元に一度尋ねてみてましょう。明確な理由がなければ、その作業の方法や存在価値について一度考えてみてください。一度に業務に関するすべての作業を見直すことはとても時間がかかります。それでも、日々の業務の中で少しずつ行えば、よりよい方向にプロジェクトが進行していくと思います。
さて次回はお客さまに対してのツッコミ力についてお送りします。それでは、また。
]]>イベントや勉強会（社内外問わず）で、仕様書についてや現場の生の話などを議論したい、話を聞きたいなどがございましたら、フットワーク軽くうかがいますので、regtan1210_at_gmail.comまでご連絡いただけたらとおもいます。
さて、今週はわたしたちの仕事とは切っては切れない関係にある「お客さま」についてお送りします。
といっても「単価が……」や「Win-Winの関係が……」というお話ではなく、もっと日常的なお客さまとの関係について考えていきます。わたしたちが仕事をする場合、お客さまの現場で常駐して作業をするというスタイルもありますし、お客さまの要求を聞き取って自社に持ち帰って開発するスタイルもあります。お客さまといっても、他社の人とは限りません。自社システムの開発であれば、そのシステムを使う部署がお客さまになります。新しいサービスの開発ともなると、ステークホルダーと呼ばれる方だけでなく、一般のサービスを使うユーザーもみんなお客さまです。
■世界で一番お客さま そういう扱い心得てよね！
日常生活に置き換えてみると、わたしたちもレストランに入ったとき一番の扱いをしてもらえると嬉しいですね。それと同じ、自然なことなのです。お客さまから見れば、わたしたちの会社が他のどんな仕事をしているかなんて、あまり興味がないことなのです。
つまり、わたしたちのいかなる都合もなかなか理解してもらえず、難しいわけです。いま直接関係しているお客さまは、一番の扱いをしてほしいと常に考えています。
だからといって、昔のえらい人が言ったように「お客さまは神さまです」の精神で、何でもかんでも受け入れればよいというわけではありません。前回お送りしたとおり、わたしたちの仕事は常に、何かしらの制限があるのです。その制限の中で、最良の結果を出さなければなりません。となると、わたしたちの仕事はとてつもなく難しく感じてきます。
では、どこから取り組めばよいのでしょうか。まず、お互いのポジションを正しく理解することから始めるべきでしょう。ここで大事なのは「お互いの」というところです。どちらか一方的に理解してもらうことは難しいのです。
見積もりを提示する際に「○○という作業には○○くらいかかります」という提示を行います。ここでちょっとだけ工夫して、「○○という作業には○○くらいかかります。でも、お客さまの方で△△していただくと、お客さまの希望どおりにすることが可能です」という風に提案してみます。見積もりには「松・竹・梅」の3つのコースを用意しろ、とよくいわれます。それだけではなく、どちらかが一方的に要求を叶える立場にならないようにするためのアクションなのです。
わたしたちはお客さまのすべての希望を叶えられれば最高ですが、現実には難しいことが多くあります。お客さまもエンジニアがすべての要求を叶えてくれるものであると考えてしまうと、最悪共倒れをしてしまうことさえあり得ます。お互いがお互いの立場を理解し、協力できるところは協力して、最適解を導きだすことこそが、お互いにとって利益になります。
■お客さま「わたしだってやればできるもん 後で後悔するわよ」
ITエンジニアはITのプロです。さまざまな要求事項をシステム開発をとおして実現していくのがITエンジニアの仕事です。では、お客さまは何のプロなんでしょうか。答えは、そのシステムが実現しようとしている「実務」や「サービス」のプロなのです。
お客さまにいきなり「ソース書いてください！」とお願いしても、それは無理な話です。それはITエンジニアのフィールドであってお客さまのフィールドではありません（たまにかなり詳しいお客さまもおられますが……）。実務に関しては、もちろんお客さまの方がよく知っています。経理のシステムであれば「ココの計算ではレート○○で計算が必要」など、仕様書などでは見落としやすい内容も隅々まで把握しています。それまでは自分たちが別の方法で行っていたわけですから、知らないことなんてないのです。
そうであれば、ここでお客さまに協力をお願いしないのは大きな損失です。分からないことは素直にお客さまに説明を求めればいいのです。出来上がってから要求とズレているといわれてしまっては、システムの品質の問題に関わります。せっかく、正解を知っている人が近くにいるわけですから、これを利用しない手はありません。
システムは、ITエンジニアの力だけで作ることは不可能です。お客さまとITエンジニアのお互いが得意な部分を担当することで、より良いシステムを構築できるのです。また、システム構築のコストをカットすることも可能です。お客さまもどのように手伝えばいいか分からない、と悩んでいることがあります。そういうときには、ITエンジニアから積極的にシステム開発に巻き込むよう、アクションを起こしていきたいものです。
今回はお客さまとエンジニアの関わり方についてお送りしました。お客さまの要求をすべて叶えないといけないと盲目的に信じ込んでいるITエンジニアと、ITエンジニアはすべての要求を叶えてくれると思い込んでいるお客さまは、お互いにあまりいい関係にならないことが多くあります。彼女の願いをすべて叶えないといけないと思っている彼氏と、彼氏はすべての願いごとを叶えてくれると思っている彼女のカップルが長続きしない（経験上）のと似たようなものです。
お互いのポジションを正しく理解して、ITエンジニアとお客さまの間でより良い関係を続けることこそ、ITエンジニアが継続的にお客さまにバリューを提供するための第1歩です。お客さまを巻き込んでのシステム開発は簡単には実現しないかもしれませんが、積極的にアプローチしていきたいものです。
さて次回はエンジニアに求められる「ツッコミ力」についてお送りします。
それでは。また次回。
]]>■勉強会夏祭り2010に登壇します
いよいよ今週末7月17日に開催される「勉強会夏祭り2010」に、「それは一枚の不思議な仕様書でした……」というテーマで登壇することになりました。LightningTalksでは何度か「マジカル仕様書」についてお話ししたことがありますが、今回はたっぷり50分間ということで、「マジカル仕様書」を通して「ITエンジニアがユーザーに提供しているバリューとは何か」ということを考えてみようかと思います。わたし以外にも、学生からOSSエンジニアまで、さまざまなジャンルの方が登壇します。詳細・参加申し込みは、こちらのサイト（http://atnd.org/events/6067）をご覧ください。
さて、前回に引き続き、今回も不思議なマネジメント「エキセントリックマネジメント」についてお送りします。前回は、主にプロジェクトにまつわる「数字」の話をお送りしました。今回は、よくある危ないマネジメントについてお送りします。
■なんでもかんでも「やりましょう！」
Twitterで大人気の某携帯電話ベンダの社長の「やりましょう！」はすばらしい、と評価する声をよく聞きます。中にはこの社長を目標とされている方も多いと聞きます。この「やりましょう！」をプロジェクトに持ち込むとどうなるでしょうか。
ユーザーの声から新たな要件を抽出し実装するという「やりましょう！」は、ユーザーのサービスに対する満足度を上げるという側面では評価できます。しかし、前回もご紹介したとおり、プロジェクトに費やせるリソースには制限があります。その制限の中で、すべての作業を終えリリースを行わなくてはなりません。サービスを完成させリリースすることが対外的なミッションなのです。つまり、「やりましょう！」といってできることには限界があります。
「スケジュールを○○日までお願いします」「やりましょう！」「この機能を追加してください！」「やりましょう！」「この画面を変えてください！」「やりましょう！」となんでも「やりましょう！」ということを繰り返していると、チームの生産可能な成果物の限界を超えてしまいます。
「やりましょう！」と返事をすることは、お断りするよりとても簡単です。しかし、無策に「やりましょう！」を繰り返すとチームは破綻します。マネジメントに必要なのは、最近話題の「仕分け」なのです。必要な機能にリソースを集中させることや、不必要な要件は優先度を下げたり実装を見送ったりすることが、マネジメントの基本になります。
何でもかんでも「やりましょう！」を続けた先には、メンバーが疲弊したチームしか残りません。そのような状態では、顧客とコミットメントした最初の要件を満たすのも難しい状態すら、招く結果となります。本当に必要な要件を選択すること、それに対しリソースを集中すること、これを適切に行うことが重要なのです。
■その工数はだれもの？
ソフトウェア開発にかかる工数は誰が負担しているものでしょうか。いいかえると、ソフトウェア開発に必要なコストは誰が負担するものでしょうか。それは顧客が負担しています。自社の社内システムであれば自社が顧客となりますし、新しいWebサービスのローンチであればステークホルダーが負担します。
プロジェクトにかかるコストが、果たして顧客のためになっているでしょうか。ここで、システム運用や維持作業を行うプロジェクトで運用しているシステム上のバグにより、システムに不具合が生じてしまったというケースを考えてみましょう。このような場合、システムを復旧させることが第1のミッションとなります。原因追及やバグの修正が第2のミッションになります。
年に一度や二度しか起こらないうえに、復旧にかかる工数もほとんどかからないし、冗長化によるシステムへの影響度はないと判断するのであれば、施策をとらないこともあるでしょう。しかし、これが月に数回や週に数回になると、いくら復旧に時間がかからずシステムも見た目上は影響を受けないとはいえ、何かしら施策をとらなければなりません。
ここで考えたいのは、「復旧に関するコストは、本来顧客が負担すべきものであったのかどうか」ということです。本来であれば、バグがなく安定して稼働することが、システムのあるべき姿なのです。つまり、本来発生すべきでないコストなのです。短期的に見たら大したことがないコストでも、長期的な観点で見ると大きなコストとなるわけです。
顧客がコストを負担するということは、プロジェクトとしてはバリューとなります。しかし、このような場合は、本来発生しないコストからバリューを生む仕組みとなってしまっています。このバリューと、顧客に対してサービスを提供して得られた本来のバリューを混同してはなりません。本来発生すべきでないバリューだけを積み重ねることを続けていると、真に求めるべきバリューを失うことになります。
さて、2回にわたって「エキセントリックマネジメント」についてお送りしてきました。このようなマネジメントは、短期的にはプロジェクトをなんとか運営できても、長期的に見るとメンバーは疲弊して、最悪の結果を招くことになるでしょう。プロジェクトメンバーは、いま所属しているプロジェクトがカットオーバーを迎えると、次のプロジェクトへアサインされます。次のプロジェクトでも同じようなマネジメントを繰り返せば、メンバーは会社そのものに疲弊していきます。その先は……いうまでもありませんね。
さて次回は、ソフトウェア開発に関する四方山話をお送りいたします。それではまた次回。
]]>毎回テーマが設定されますが、トーカーの皆さんそれぞれ独特の解釈があり、さまざまな切り口でお話を聞けるイベントです。今回もさまざまなトーカーの方のお話を聞けて、非常に楽しいイベントでした。
keccon2010は、結婚カンファレンスということでさまざまなコミュニティから参加者が集まり、なかなかお会いできない方ともお話をする機会に恵まれたイベントでした。このたび結婚したお二方のお祝いをするためのLightningTalkイベントだったので、通常では聞けないテーマのお話が多く大変貴重な体験ができました。
■「勉強会夏祭り2010」に登壇します
7月17日に開催される「勉強会夏祭り2010」に、「マジカル仕様書」についてのセッションで登壇することになりました。LightningTalksでは何度かお話ししたことがありますが、今回はたっぷり50分間あるということで、「マジカル仕様書」を通して「ITエンジニアがユーザーに提供しているバリューとは何か」ということを考えてみようかと思います。わたし以外にも学生からエンジニアまでさまざまなコミュニティから登壇されます。詳細・参加申し込みはこちらのサイトをご覧ください。
お知らせ事項が続いてしまいましたが、今回と次回は不思議なマネジメント「エキセントリックマネジメント」についてお送りします。マネジメントといえば主にスーツな方々が数字をごちゃごちゃと操作しているようなイメージを持つ方が多いかとおもいます。わたし自身が経験した現場でも、マネージャという方々は日々報告されるさまざまな指標値を見て、進捗管理やリスクマネジメントを行うことをメインの仕事としている方がほとんどでした。
■スーツな方々が好きな数字の世界
「進捗率」や「生産性」や「ステップ数」など、スーツな方々が好きな数字は、ギークと呼ばれる方々にはとても不評です。例えば、ステップ数が多いほどスーツな方々にとっては良いソース、つまり、高価なソースだと考えられていた時代が過去にはありました。古き良き日本のシステム業界といわれていたころです。
残念ながらそのような風潮は、現在も一部では残っていると聞きます。一方、ギークな世界では無駄に冗長なソースコードは嫌われる対象です。冗長に書くより適切に書いたソースコードは品質も良く、メンテナンス性も高いため扱いやすいとされるからです。
しかし、仕事上システムを構築する場合、時間が無限にあるわけでもないし、何人でもメンバーを投入できるわけではありません。何かしらの制約がある状態で、プロジェクトは運営されています。そのような状態で、マネージャがプロジェクトの状態を簡単に知るためには、数字に頼るしかないのです。
数字でプロジェクトの状態を知るのは、悪いことではありません。客観的にプロジェクトの状態を知るには一定の指標をもって状態を把握することが必要です。規定値から外れたところでプロジェクトの状態を是正する処置を行えば、プロジェクトをあるべき姿に近づけることが可能なのです。
■それでもやっぱり怖い数字の世界
果たして「進捗率」や「生産性」などの数字がプロジェクトのすべてを示しているのでしょうか。プロジェクトの中で数字が1人歩きしだすと、あまり良い状態とはいえません。行き着く先は「○○の機能を作るには○○枚以上の仕様書が必要です」や「この機能にはあと○○ステップのソースコードが必要」という不思議な指標が出てきます。
プロジェクトにいるもの以上の成果物を求めることが必要でしょうか。必要以上の成果物は無駄になります。プロジェクトを最適に運用するのであれば、できる限りプロジェクトから無駄な物を排除するのがベストでしょう。どのような開発スタイルをとる場合であっても、リーンな開発（無駄の少ない開発）はプロジェクトの運用コストを下げることに繋がります。つまりは、最小のコストで最大の収益を上げることになります。
プロジェクトメンバーも人間である以上、常に一定の生産性で作業ができるわけではありません。作業時間が長くなれば、徐々に生産性は落ちてきます。無駄な成果物を作成しないことで、全体の成果物を減らす。そうすることで、全体の作業時間を短くすることが可能です。
直接的に見える数字だけに捕われたマネジメントでは、プロジェクトに潜む本当の問題点を見落とす恐れもあります。数字が表す事象は、すでに問題が発生した後なのです。数字ばかりを追いかけていると、後追いで対処を行わなければなりません。先に手を打つことで回避できる問題も数多くあります。傷口が広がる前に手を打つ取り組みを忘れてはなりません。
今回は数字を追い求める不思議なマネジメントについてお送りしました。数字を見ることはマネジメントを行う中で必要な場面もあります。ただし、それに異常に固執することはプロジェクトをあらぬ方向へ導いてしまう可能性があります。マネージャはプロジェクトにおけるナビゲータなのです。そのナビゲータが道を失ってしまえばプロジェクトは方向性を見失ってしまいます。そうならないためにもマネジメントする際には、本当に求められるゴールを見失わないように進めなくてはなりません。
さて、次回はケーススタディをとおして「エキセントリックマネジメント」についてご紹介し、真に必要なマネジメントについてご紹介します。
それではまた次回。
]]>今回は、前回に引き続いて「ミステリアスソース」についてお送りします。前回は、ミステリアスソースの問題点、なぜ発生するかという話題をお送りしました。今回は、ケーススタディをとおしてミステリアスソースを見てみましょう。
■あれ？ これどこかで見たソースなんだけど……
どの言語でも、同じような処理を複数の場所で行う場合にはファンクションを作成し、それを呼び出すことで処理の共通化を行います。Javaの場合、修飾子をつけてそのメソッドのスコープ（公開範囲）を決めて、不必要なメソッド呼び出しを行わないようにします。同じソースの中で同じ処理を複数回書くのを避けることで、バグの原因を狭い範囲にとどめられます。
これを無視して、同じ処理をコピーして複数回ソースコード内に記述してしまうと、どうなるでしょう。ソースの複雑度が一気に上がります。問題が発生した場合、コピーした部分すべてを確認しなければなりません。また、テストも同様にすべての修正箇所に対して行わなければなりません。
作成時は、Ctrl＋CとCtrl＋Vを繰り返すだけで、ソースコードは完成します。しかし、修正にかかるコストは正しくファンクションを利用したうえで構築したものに比べると、数倍以上に膨れあがります。同時に、同じだけの品質を担保するためのテストの工数も一気に上がります。
このようなソースが発生する原因は、多くの場合は設計段階で共通処理の洗い出しが正しく行われていないからです。コピー＆ペーストが行われるということは、同じ処理があるということです。その内容について、設計書から読み取れればいいのですが、そのすべてを記述することは難しいでしょう。ソースコードを作成する側でコピー＆ペーストを行う前に、処理の共通化を行えるかどうかを考えてから実装する必要があります。
「ステップ数が多い＝いいコード」というわけではありません。また、ステップ数でプログラマの価値が決まるという古きよき日本のプログラマ文化は、もう存在しないといっても過言ではないでしょう。
■え？ これがベストの実装？
例えば、日付の妥当性確認の実装について考えてみましょう。1月32日など存在し得ない日付を指定した場合はチェックNGとするようなロジックです。どのようなアプリケーションにもあるような基本的なロジックです。このロジックの実装には様々な手法があります。使用している言語が持つ標準APIを利用する方法や正規表現でチェックする方法などがあります。
Javaの場合、日付を扱うクラスを利用して妥当性を確認できます。しかし、これを利用せずに1月は31日までしかなくて、2月はうるう年があるから月末日が変わって……13月はなくて……ということをすべて実装すると、ロジックは一気に膨れ上がります。それをテストするとなると……あぁもう考えたくない……となりませんか？ わたしはもう、2月の時点で心が折れてしまいそうです。
さすがに、実装法を細部にわたって記述している仕様書はありません。もし、あったとすればプログラムの数倍の物量になり、プロジェクト全体となれば電話帳くらいの量になってしまうでしょう。管理するのはもちろん、持ち運ぶのも大変です。実装法の選択はプログラマに任されています。
プログラマは常に、最適な実装を目指す必要があります。わたし自身、それが常にできているか？ というと、そうではありません。ペアプログラミングやソースコードレビューなど、別の視点からソースコードを見直すことで補っています。ときには、ソースコードレビューで厳しいことを言われることもあるでしょう。しかし、自分の考えとレビュアーの考えとのコミットメントを取ることは重要です。他人に説明できないソースコードには、何かしら問題が潜んでいます。またレビュアーも、その意思を聞き出すことに重きを置くべきです。「コメントが～～」とか「インデントが～～」とか「ステップ数が～～」とかつまんないことを言っても仕方ないのですから。
2回にわたって、ミステリアスソースについて紹介してきました。自分の書いたソースがいろいろな人の目に触れるということは、かなりのプレッシャーです。例えば、ブログに書いたソースコードが見られて「え～あの実装イケてないよ～」と言われることもあります。
でも、大抵の場合、そういうことって忘れてしまうものです。次の機会にそれを直しておけばいいだけの話なんです。社内社外問わず、いろいろな人の目に触れることを恐れず、ソースコードをさらす勇気を持ちましょう。きっと、自分で作成するソースに自信を持つキッカケを作れると思います。
自信をもって書かれたソースは、ミステリアスソースにはなりにくいものです。哲学的ではありますが、「ソースコードは自分を映す鏡」なのです。自分が不安に思ったところには必ず、バグやミステリアスソースになる要素が含まれています。1人ひとりが作るソースコードの健康が、アプリケーションの健康やプロジェクトの健康に繋がります。
次回は「エキセントリックマネジメント」ということで、不思議なチームマネジメントについてお送りいたします。関東は梅雨入りしましたが、夏のような暑い日が続きます。ビールがおいしい季節ですが、くれぐれも飲み過ぎないように過ごしましょう。それでは、また次回。
]]>さて今回と次回の2回にわたって、「ミステリアスソース」についてお送りします。最近ではレガシーコード（テストコードを持たないコード）にいかに対処するかということや、TDD（テスト駆動開発）などプログラムを読みやすく質の良い状態にするためのさまざまな取り組みが検討されています。しかし、残念ながら、読みにくいソースコードは数多く存在します。これから、そのようなコードに対する対処法などを考えていきます。
■ミステリアスソースって？
日々の業務の中で、さまざまな機能の実装を行います。実装を行う際は、利用している言語の特性を考慮し、無駄なロジックを組み込まないように注意しながら、作業を進めます。作成しているものが仕様と差異がないか、処理速度に問題は出ないか……こういったことを考えながら実装を行います。開発の中で一番楽しくもあり、一番苦しくもある時間です。
しかし、しばらく時間が経ったあとにソースコードを読んで、「なぜこのような実装になっているのか」と疑問に思ったことはないでしょうか。経験上、自分で作成したものならまだ読めますが、他人の作成したものとなると一苦労、ということが良くあります。新しい技術を習得して「こんな実装しちゃって恥ずかしいなぁ。書き直したいなぁ」という振り返りのキッカケになることはよいのですが、トラブル発生時にソースを読み返して「何じゃこりゃ……さっぱり分からんぞ……」となるようなソースでは問題です。
「ミステリアスソース」は、単にスパゲッティコード（構造が極度に複雑化してスパゲッティのように絡まっている状態のソースコード）を指すわけではありません。「ミステリアスソース」は、「実装者の意図が分からないソースコード」なのです。
■ミステリアスソースはどこにある？
それでは、ミステリアスソースはどこに隠れているのでしょうか。少し分析してみましょう。
1.そもそも動作していないソース
これがプロダクトソースに含まれていると問題です。「そのようなソースはない」という前提に立っても問題ないでしょう。万が一、プロダクト全体に無駄なソースコードが大量に含まれていると、検出することも難しくなります。まず、使われているかそうでないかの切り分けから始まりますので、検出するのにも時間がかかります。
2.動いているが、仕様と異なる挙動をするソース
一般的にバグと言われるものです。これは、バグと思われる動作を再現させて、挙動を確かめて該当するソースを絞り込むという作業になります。問題部分を修正して問題となったオペレーションと同じことを行って動作を検証します。同時にデグレッションテスト（退行テスト）も行います。このとき、JUnitやRSpecなどのテストコードがあると、作業も楽になります。
3.動いているけれども非機能要件を満たさないソース
「処理時間は○○秒以内であること」のように、機能ではありませんが満たさなければならない要件を「非機能要件」と呼びます。これらを満たしていないソースは、リリース後に問題となりプロファイラでチェックしたり、オプティマイザとにらめっこして、問題を分析しパフォーマンスチューニングを行います。ソースコードを直接修正するだけでなく、データベースのチューニングなどミドルウェアの設定を修正することもあります。
それでは、ミステリアスソースはどれに含まれるのでしょうか。多くの場合１～３のどれにも含まれません。ミステリアスソースの多くは、正常に動いているソースに含まれるのです。だったら、修正しなくてもいいんじゃない？ と考えられることもできます。
破れ窓理論（一部のソースの荒廃を許すと全体に派生する）に従うのであれば、一部のミステリアスソースは、全体に影響を与えます。全体がミステリアスソースになってしまったプロジェクトでは、一度問題が発生すると、通常のプロジェクトにくらべ修正にともなう時間も手間もかかります。また、作業者のモチベーションを極端に下げます。見つけ次第、すぐに修正したいものです。
現実として、正常に動いているソースコードに手を加えることを避ける場合が多く、事態が改善されることなく放置されているといったことが多くあります。ミステリアスソースを改善するよりも、発生しないように取り組みを行う必要があります。
次回は、ケーススタディを通して、ミステリアスソースの発生や問題点について、もう少し深く考えてみましょう。それではまた次回。
]]>残念ながら「わたしの人生の1冊」としてご紹介するほど、何度も何度も繰り返し読んだりする本はあまりありません。というわけで、今回は最近読んだライトノベルについてご紹介します。
技術書やハードカバーの本、コミックを読まれる読者の皆様は多いかと思います。最近ではヒットを飛ばす作品も多く、「ライトノベル」という単語を耳にしたことはある方もいるでしょう。
わたしの場合は職業柄、技術書を読むことが多いのですが、寝る前や気分転換したいときにライトノベルを読んで、頭を休めます。ライトノベルには、頭をフル回転させて読まなければならない作品は、あまりありません。気楽に読める作品ばかりなので、気分転換やリラックスに最適です。
■生徒会の一存シリーズ（著：葵せきな・イラスト：狗神煌）
ライトノベルの仲でも、これほどのんびりまったり読める作品は少ないかと思います。舞台は北海道（？）にある、とある高校の生徒会。基本的に、生徒会で交わされる会議という名の雑談をメインに話が進んでゆきます。よくも悪くも雑談なのです。そのため、あまり深い展開はありません。
もちろん、ライトノベルなので、登場するキャラクターは普通ではありません。生徒会役員は全校生徒から人気投票で選ばれた4人（全員容姿端麗な女の子）に加え、その輪に入りたいがために全校で成績トップをとった男の子（主人公）。この時点で普通の小説ではあり得ない展開です。ライトノベルだからこそできるフォーマットではないでしょうか。
そんな生徒会役員が繰り広げるラブコメストーリー。時にはちょっと甘酸っぱい展開もありますが、ほとんどがコメディです。読む時は深く考えず、気楽に読むことをオススメします。
■なれる！SE ―2週間でなれる？ SE入門（著：夏海光司・イラスト：Ixy)
ブラック企業に就職して限界かもしれないお話は、映画にもなりました。「なれる！SE ―2週間でなれる？ SE入門」は先日発売されたばかりで、Twitterでも話題になっていた1冊です。
この作品は、ブラック企業に就職してしまった主人公と、直属の上司の可愛らしい女性エンジニアのお話。
入社2日目から終電帰宅や徹夜など、とんでもない労働環境の話やトレーニングとは言えないようなOJTの話はさておき、「Ciscoのルータのコンフィグレーションが～」や実際に操作している描写などは、この業界の人間から見ても非常に良く書かれていて「あるある」と思える話でした。
システムを組みあげたときの達成感や、現場での緊張感などエンジニアとしての仕事の楽しさ、女性の上司の発言の中にある「エンジニアとして忘れてはならない心構え」などを読んでみると、自分が新人だったころのことを思い出しました。
この業界に勤めている人だからこそ分かる、苦しみや楽しみがつまった1冊です。一度手に取って、新人時代を思い出すのもいいかもしれません。
この作品はあくまでもフィクションなのでこれがIT業界だと思われてしまうと困りものですが、今年新社会人として働き出した方にもオススメの1冊です。
さて、今回はライトノベルを2冊ご紹介しました。ライトノベルは分量も少ないため、1冊１時間～2時間で読み終えられるかと思います。たまには、こういうジャンルの本で息抜きするのはいかがでしょうか。
次回は、本編に戻って「なにこれ……」と思えるミステリアスソースについてお送りいたします。それではまた次回。
]]>今回は、前回に引き続き「マジカル仕様書」についてお送りいたします。前回は「仕様書とは～」という話題でした。今回はケーススタディを通して、「マジカル仕様書」がどのようなものか、なぜそのようなものができてしまうのかをご紹介していきます。
■データベースは使いません！？
どんな言語を使って実装するか、どのようなフレームワークやパッケージを利用して実装を行うか。これらの内容は開発の初期段階で決定されることの1つです。通常のWebアプリケーションであれば、データを保存する技術として必ずと言っていいほど、リレーショナルデータベースが利用されます。最近ではKVS（Key Value Store）という仕組みもありますが、まだまだリレーショナルデータベースを利用する場面の方が多いかと思います。
Aさんはとある業務システムの開発担当にアサインされました。システムの構成を示す仕様書を見ると、サーバ構成はとても高価で素晴らしいものです。しかし、よくよく見ると、利用されるミドルウェアのうちで何かが足りません。そうです。データベースについての記述が一切なかったのです。実はこっそり裏にかいてあるとか、白文字で設定されているとか、そういう何かでもありません。
まさか、すべてのデータをXMLに保存するようなシステムなのか？ それとも、CSVに全データをもつという何とも恐ろしいシステムなのか？ 悪い方向に想像は広がるいっぽうです。Aさんは設計者に「この仕様書ではデータベースについて何も触れられていませんが大丈夫ですか？」と尋ねました。
設計者：「データベースは使いません！ Oracleを使います！」
もはや仕様書が云々というレベルではない会話になってしまいました。このように仕様書を作成する際、そこに書かれるべきことに対する前提知識がまったくなければ、仕様書を作成することはできません。この場合の設計者はOracleはデータベースの一種であるという知識がなかったのです。
ここで、マジカル仕様書を作ってしまった原因を考えてみましょう。設計者は要件に応じた実現方法が分からなかったのです。今回挙げたケースは極端な例ですが、実際の開発においては大なり小なりこのようなことが起こりえます。TDD（Test Driven Development）では、最初にゴールとなるテストパターンを作成し、それを目指してプログラムを作成します。それと同じように、設計も常にゴールを見失わないように行うことが必要なのです。
■同じ項目のはずなのに？
データベース周りのでマジカル仕様は、場合によっては「デスマーチへ一直線」という事態を招きます。どのようなシステムを作成する際も、データベース周りの設計は設計者の大きな悩みの種の1つです。経験上、一定の理念のもとにモデリングされたデータベースは多少複雑であっても、想定したデータをすぐに抽出することができます。逆に、行き当たりばったりのモデリングをすると、システムが稼働開始後に何かしらの問題が発生します。運用する人たちの安寧のためにもモデリングは気をつけて行いたい部分です。
Bさんはとある業務用Webシステムの開発担当にアサインされました。開発工程は順調に進み、間もなくプログラミングを始めるという段階です。この時点で、データベース周りの設計は終了していると聞いていました。先ほどの「データベースは使いません」という設計担当とは違い、滞りなく設計は完了したとのことです。
さっそく、Bさんは実装にとりかかりました。しかし、実装を進める中で、テーブルレイアウトを確認すると、とあるテーブルではユーザーIDが英数字8桁で設定されていたのですが、別のテーブルでは英数字12桁で設定されていました。また、金額を扱う項目にカンマで3桁ずつ切ったものが入っていたり、普通の数字列が入っていたり……。
このように同じ項目でも違う型でデータベースに登録されていた場合、プログラム上は別の扱いをしなくてはなりません。多くのデータモデリングツールでは辞書機能（ユーザー型定義管理機能）があり、同一のデータは同じ扱いがされるようにモデリングを行います。ツールやモデリングの基本理念が正しく理解されていたのであれば、先ほどのような設計にはなり得ないのです。残念ながら、このような状態に陥った場合は毎日のようにテーブルレイアウトが変更され、それに対応するためのプログラムの修正やテストなどに大幅な工数を割くことになります。
画面上では、右詰めにするからデータベース上も右詰めのカラムにする、といったモデリングを行っているものもあります。プログラムのロジック的に有利な場合もありますが、データのメンテナンスを考えると有効な手法ということは難しいでしょう。設計者は、常に複数の視点を持って設計を行わなければなりません。データベース設計はそのなかでも最もそのような視点が求められる部分です。入力・出力をはじめ、他の機能との整合性など常にさまざまな視点をもって設計を行わなければなりません。
さて、今回は2つのケースを見てきました。両方ともデータベース絡みの問題です。このようなマジカル仕様書を見落とすと根が深く修正するにもコストがかかり、顧客・開発企業にとってどちらも幸せにならない結末となります。マジカル仕様書は、許容量を超えてしまうとデスマーチへの片道切符になる代物です。ゼロにするための対策や発生した時の対策はリスクマネジメントの一環として考えておかなければなりません。
「設計者や実装者のスキル不足」と言ってしまえば話は終わってしまいますが、それらを発生させないような取り組みはプロジェクト全体で行っていくべきことなのです。
2回にわたってマジカル仕様書について見てきました。次回は「なにこれ……」と思いたくなる「ミステリアスソース」についてのお話です。
それではまた次回。
]]>さて、今回と次回は「マジカル仕様書」についてお送りします。マジカル仕様書、つまりは「不思議な仕様書」。実務ではめぐり合いたくありませんが、どうしてもめぐり合ってしまうものです。そんな、憎まれながらも愛すべき存在であるマジカル仕様書についてのお話です。
■そもそも仕様書って何？
読者の皆様が、開発業務の中で「仕様書」というものを作成する、あるいは読むことは日常茶飯事だと思います。これらのドキュメントには、開発しているシステムの概要や各モジュールの挙動など、さまざまなことが記述されています。
これらを作成することがゴールではありませんが、開発業務の中では多くの時間を仕様書作成に費やします。仕様書を元にプログラムを作成したり、各機能の検証を行ったりと、各開発工程の橋渡しをしてくれるものだからです。つまり、仕様書は各開発工程のアウトプットであり、次の開発工程のインプットとなります。
これらが、役割を果たさなければ、その時点で開発の流れは途絶えてしまいます。ウォーターフォール開発で例えれば、そこで「水の流れ」が途絶えてしまいます。途絶えてしまうだけでなく、水がこぼれだし、まったく違う流れを作ってしまうことだってあります。仕様書が役割を果たさなければ、目的から遠ざかってしまうことすらありえるのです。
■マジカル仕様書って何？
前回のコラムでは、「『ピッと押したらドーンとなる』というレベルのものから、日本語としてパースできないものまで」と表現しました。前回ご紹介したものを例に見ていきましょう。
1．ピッと押したらドーンとなる！？ 仕様書
前回のコラムでご紹介した「このボタンクリックしたらファイルがDLできる」というものを例に紹介していきます。
この仕様には、さまざまな疑問点があります。
プログラミングを行う工程のインプットとなる仕様書には、これらのことが一切書かれていませんでした。エンドユーザーの要望からプログラミングを行う工程まで、ずっとこのままの状態であったわけです。決して、エンドユーザーさんの要望が悪かったわけではありません。要望としては妥当だったのです。
エンドユーザーさんが事細かに「このファイルはutf-8のCSVでカンマ切りで～～」なんて定義してくれたら、プログラムを書く以外、わたしたちの仕事はなくなってしまいます。システムに関して素人であるエンドユーザーさんが、ゆるくてふんわりした仕様（ゆるふわ仕様）を提示するのは当然です。逆に、システムを作ることに精通しているわたしたちが同じようなことを言っていると、プロとして恥ずかしい限りです。
2．情報の伝達に齟齬が発生するかもしれない……仕様書
とある小説の中で、「宇宙人的存在の少女が主人公に自分の正体を説明するシーン」があります。少女は淡々と、ロボットのように自分の存在を説明します。その説明はとても長く現実離れしているため、主人公は言われていることが理解できず、そのシーンは終わってしまいます。仕様書も同様に書き手（設計者）と読み手（実装者）の間の情報伝達に、データ欠損を起こすことがあります。
それでは、「文字列SがAまたはBでない」という表現を思い浮かべてください。日ごろの仕様書の中でも「文字列HOGEがAまたはBでない時は処理MOGEをする」という表現をするかと思います。この「AまたはBでない」という表現をよく考えてみると以下のパターンが考えられます。
文字列SがAだった場合、上の例だと条件を満たしませんが、下の例だと条件を満たします。条件が複雑になれば、さらに複雑な文章になり、どの場合が適合するのかわからなくなってしまいます。
「AまたはBまたはCではない条件を満たさない場合」と表記されると、書いてる本人が分かってるのかどうかもあやしくなってきます。冗長な文章ほど、真の意味を外してしまいがちです。よくインターネットでいわれる「（長すぎるから）3行でよろしく」というのは、ある意味ベストプラクティスなのかもしれません。
上記2つの例を見てきましたが、これ以外にもマジカル仕様書と呼びたくなるものは世の中に数多く存在します。
マジカル仕様書かどうかを判断する大きなポイントとして、「書き手（設計者）の意思が読み手（実装者）に伝わっているか」ということがあります。ミスリードされやすい文章になっていないか。情報を書き漏らしていないか。仕様書を作成する側も読む側も、十分にこれらの点を確認し合うことが必要です。
次回は、ケーススタディを通して、ちょっと面白いマジカル仕様書の世界をご紹介しようと思います。
それではまた次回お会いしましょう。
]]>今回が初エントリということで、少しわたし自身のことをお伝えしておこうと思います。
今流行の草食系の妙齢（30歳）のプログラマです。ＩＴ業界の仕事は現在の会社で2社目です。新卒で一度大手SIerに就職しましたが、その後1年で退職。大学院を経て、現在の会社に勤めています。現在の仕事は業務系Webアプリ開発やERPのカスタマイズなどをメインに仕事をしています。プログラマといいながら、時には小さいながらもプロジェクトメンバーを引っ張ってお仕事することもあります。
仕事以外の部分ではLT（LightningTalk：5分間で一定のテーマについて発表する）したり、さまざまな勉強会（主にjava-jaやGLT）に参加しています。また、OSSプロジェクトJiemamyにも参加しています。もしかしたら、読者の皆様の中にもお会いした方がおられるかもしれません。
このコラムでは、主に勉強会の懇親会のネタとなる「不思議なプロジェクト」の話やこれまでであった「不思議なエンジニア」の方の話などを中心に進めていきます。特に「プロジェクトマネジメントが～」とか「ウォーターフォールが～」とか「品質問題が～」という難しい話をする気はないので、仕事の合間の一息入れるついでに、肩の力を抜いて読んでいただければと思います。
ただ、「残業きつくてねぇ……定時で帰れる奴はいいですなぁ」と奴隷の鎖自慢をしても仕方ないので、どうしてそのプロジェクトは燃え上がったのか、回避するにはどうすべきだったかと考えることや、そこから導き出されるプラクティスについて考えるキッカケになれば幸いです。
日々開発業務を行う中で、「このプロジェクト（設計orソースorマネジメント）おかしくない？」と思ったことはありませんか？ 大きく分けて、以下の3つの「不思議なモノ」に分類されます。
1．マジカル仕様書
「このボタンクリックしたらファイルがDLできる」という、一言だけの内部仕様書を過去に見たことがあります。設計者は何を伝えたかったのでしょうか？ このように、仕様書といいながらも、本質的に何の意味もなしていない仕様書を「マジカル仕様書」と呼びます。「ピッと押したらドーンとなる」というレベルのものから日本語としてパースできないものまで、さまざまな種類があります。
2．ミステリアスソース
ifブロックをよく見ると、ifブロックもelseブロックもまったく同じ処理をしているソースコードをみたことあります。プログラマは何を想定して作成したのでしょうか？ 2、3日寝てなかったのであれば、書いた方の体調を心配してしまいます。このような、コンパイルエラーにはならないものの、実装した方の意図を誰も読み取れないようなソースコードを「ミステリアスソース」と呼びます。「バグではないけれど、なんでこんな実装になってるんだろう」と疑うものから完全にバグであるものまで、影響度はさまざまです。
3．エキセントリックマネジメント
実装する前からできあがるソースコードのステップ数が決まっていたり、仕様書の枚数が決まっていたりと、奇怪なマネジメントを経験したことはありませんか？ マネジメントする人は何を考えてプロジェクトを運営したのでしょうか？ このような、誰もが不思議に思い、プロジェクトが明後日の方向へ進みかねないマネジメントを「エキセントリックマネジメント」と呼びます。場合によってはデスマーチ直結のようなマネジメントもあり、メンバー誰もが幸せにならないという最悪の結末を生んでしまう可能性があります。
これらの言葉はわたしが個人的に呼んでいるだけで、厳密な定義などはありません。皆さんが日々の業務で「これはないわ～」と思ったことは、この3つのうちのどれかに当てはまると思います。
次回から、この3つの軸を中心に実際に経験したことをご紹介していきます。また、このような貴重な経験をされた方がおられましたら、コメント欄で情報提供していただければ、取り上げてみたいと思います。
それでは、また次回お会いしましょう。
]]>