2013年をふりかえって

あと1時間程度で2013年も終わってしまいますね。
恒例の*1、1年をふりかえってなんか書きます。

仕事のこと

仕事は相変わらず SIer で特定のお客さまを対象に受託開発を行っています。
1月〜3月は昨年（2012年）の夏から行っていたプロジェクトの実装・テスト・リリースフェーズで、進捗が遅れに遅れるなか残業したり休日出勤したりでなんとかスケジュール通りにリリースすることができました。が、テストコードが十分じゃなかったり、ちゃんと CI まわせてなかったりで多くの課題が残ったプロジェクトでした。
4月、5月はその残った課題への対応を行っていたり、要望のあった追加機能を実装したりしつつも、比較的落ち着いた時期だったかなと。
ひとつ、 とある製品のバグを踏んでしまい、緊急で深夜対応を行ったのもこの時期ですね。早急な対応が必要だけれどもサービスとしてお客さまに提供しているシステムは（今は正常に動いているため）止められないので、利用者がほとんどいなくなる深夜に対応する、というとても貴重な経験ができました。このときは、まさか朝普通に出勤したときにはこうなるとは思っていませんでしたね。
6月からはチーム内でもう一つ動いていたプロジェクトのテストフェーズから合流。どういうプロダクトを作っていたかは近くで見ていたのでずっと知っていたのですが、プロジェクトのメンバーとして参加するとなると細かな部分がわからず最初は苦労しました。
その後、テストをやっていて「動いてはいるんだけど、なんか動作気になるな」というところがあったときに、出力されるログをじっくり確認しバグに気づけたときには達成感がありました。
9月中旬にそのプロジェクトも終わりプロダクトをリリースした後、すぐに別のプロジェクトが動き始めるも、自分はそこまで深くは関わらないことに。比較的落ち着いている時期だったので、長めのお休みをもらい実家に帰ったり、石川・富山に出歩いていたりしました。#kzrb に初参加したのがこのタイミングですね。
9月にリリースしたプロダクトのバグが見つかってその対応などを行いつつも、平行してプロジェクトを進めていたのが11月中旬ごろまで。
その後は今年前半にやっていたプロジェクトの派生開発として追加機能を実装するため動き始めました。受託開発なのでお客さまからお金をもらわなければ開発できません。お客さまから予算をもらうため、資料を準備したり、見積もりを行ったり、スケジュールをたてたりしていたのが11月〜12月ごろ。お客さまのところに資料を持っていって打ち合わせして、ダメ出しされたところを修正して次の週に資料を持っていって、などを行っていました。


1月〜5月ごろまではそこそこコードを書いていて、その後はほとんどコードは書いていないですね。テストデータを作成するためのスクリプトを書いたり、作業を効率化するための簡単なツールを作ったりはしていたのですが。夏〜秋はExcelさんと、最近はExcelさん＆PowerPointさんと仲良くしています。


SI(SIer)のこと





今年も SIer からの退職エントリがはてなブックマークをにぎわせましたが、私はまだ辞めてません。幸いにも、仕事していて「わりと SIer って楽しいなー」と思えるときが多いです。
なんで楽しいのかなーと思えるのかと考えてみました。

  • 特定のお客さまのみを対象に受託開発を行っている
  • 受託開発の一次請けで直接お客さまと話をすることができる
    • お客さまの言いなりになっておらず、いい点・悪い点の話ができる
  • 請けた仕事は、基本的に設計・実装・テスト・リリースを自分たちで行い、リリースした製品の保守も自分たちが行っている
    • そのため、中途半端なクオリティでリリースしてしまうと後々自分たちが苦しむので、「良い製品にしよう」という意識で開発ができる
  • 職場・チームの雰囲気が悪くなく、業務が落ち着いていれば定時退社したり有給休暇を取得したりできる

簡単に思いつくのはこれくらいですかね。
「SIer で受託開発を行っている」のですが、特定のお客さまを対象としているため、感覚的には「お客さまの情報システム部門として働いている」という感じです。
お客さまの経営が苦しくなるとIT予算に投資がまわらず、ウチも仕事を受注できなくなりご飯を食べていけなくなるので、お客さまのドメインについても個人的に勉強したりして「お客さまをもっと儲けさせるにはどうしたらよいか」みたいなことを（少しずつ）考えられるようになり、成長できているのかなーと感じています。


自分は今のところと、その前にいたチームしか知らないのですが、いわゆる「SIerの退職エントリ」を見てると恵まれている現場のように見えます。

これから

という恵まれた現場で仕事をしているのですが、新しいことにチャレンジしたいというワガママを会社に言って、来年2月から別の業務をやることになりました。転勤です。関東の皆さん、1月中に美味しいものを食べにいきましょう。

まとめ

  • 2013年は皆さんお疲れさまでした
  • SIer も（現場によっては）楽しいです
  • 2014年も頑張りましょう
  • 関東の皆さん、1月中に美味しいもの食べに連れて行ってください

以上です。
と書いてる間にもう年が変わる。良いお年をー。

*1:書くのは恒例だけど、まとまらず下書きのまま放置されていたりしました

#kzrb meetup 15 に参加してきた話

RubyWorld Conferece 2013 をはやめに離脱し、京都に一泊した後はサンダーバードに乗って金沢へ。
kanazawa.rb の meetup #15 に参加してきました。
http://kanazawarb.github.io/meetup/15/
http://kzrb.doorkeeper.jp/events/6745
http://togetter.com/li/594153


どのような内容だったかは、cottonさんのエントリをご覧ください。
http://cotton-desu.hatenablog.com/entry/2013/11/26/210818


私は、せっかく RubyWorld Conference 2013 〜 kzrb meetup #15 と続けて参加できたし、いい機会だったので「RubyWorld Conference 2013 さんか報告」と題して飛び入り LT を行ってきました。以下にスライドをおいておきます。
https://speakerdeck.com/shiget84/kanazawa-dot-rb-number-15


発表内容としては、参加して私が感じたことを中心に話したもので、もしかしたら事実や登壇者の主張と異なっていたりするかもしれませんのでご注意ください。また、発表資料を準備する時間および飛び入りLTでもあまり時間がなかったので、1日目の内容しか話をしていないです。
が、1日目の最後の五十嵐さんの発表の内容をもとに、kzrb という場所があるのはいいことだという話でうまく落ちをつけられたかな、と。
話した通り、kzrb というのはとてもよい場所なので、また機会をみつけて参加していきたいところです。

RubyWorld Conferece 2013 に参加してきた話

11月21日〜22日に島根県松江市の「くにびきメッセ」で開催された RubyWorld Conference 2013 にプライベートで*1参加してきました。
20日（水）は普通に仕事して、20時くらいに退社し、急いで家に帰って荷物を準備し、21時30分ごろ新横浜発の新幹線にのってまずは新大阪へ。新大阪に向かっている途中で予約した新大阪駅付近のホテルで一泊した後、21日（木）午前6時発の新幹線で岡山に行った後*2、午前7時すぎに岡山を出る特急やくもにのって松江までいく、という強行軍でした。ちなみに松江に行くのは2度目。前回は、『高専カンファレンス in 松江（ http://kosenconf.jp/?037matsue ）』で2年前でした。


matzのお話を聞いていて「試行錯誤」できるといいな、とは思うものの今のチームなり職場なりでやるにはどうしたらいいんだろう、と悩んだり、高井さんの「何も特別なことはやっておらず、Deployment Pipeline を構築して可能な限り自動化している」という話にグッときたり、みよひでさんの話は職場での参考になりそうだなーと思ったり、「Social Translating すげー」と思ったり、五十嵐さんの「ゴールは未来に設定」という話にグッときたり、Tom Preston-Werner さんかっこいいなーと思ったりしている間に、あっという間に時間は過ぎ去っていきました。


その後、途中で RWC2013 は離脱し京都まで行き、京都で一泊した後に kanazawa.rb の meetup #15 に参加するために金沢まで移動したのでした。



なかなか交通費や宿泊費がかかりプライベートで行くのはしんどいなーと思いつつも、とても楽しく充実した時間を過ごすことができたので、参加してよかったなー、また来年も参加したいなーと思うのでした。松江の街を散策したりはできなかったので、またそのうち松江に遊びにも行きたいなー。

*1:「仕事として行けませんか？」と上司に相談しましたが、業務でRuby使ってないのでダメでした。

*2:ちなみに、この新幹線の中でに21日（木）の松江の宿を予約しています。

#kzrb meetup 13 に参加してきた話

9月28日（土）に ITビジネスプラザ武蔵 研修室2 で開催された、kanazawa.rb meetup #13 に参加してきました。*1

http://kanazawarb.github.io/meetup/13/
http://kzrb.doorkeeper.jp/events/5667
http://30d.jp/kzrb/3


twitter などで kanazawa.rb の人たちが楽しそうにしているのを見ていて、いつか参加したいなーとずっと思っていたところちょうど仕事も落ち着き実家に帰省することになったので、帰省のタイミングをこのmeetupにあわせて北陸に行くことにしました。

27日（金）に新横浜から米原経由で実家のある福井に帰り、28日（土）の朝に福井から金沢に出かけました。会場の ITビジネスプラザ武蔵 が最初どこにあるかわからなかったのですが、めいてつ・エムザの中のエレベータから行けるのですね。Twitter で教えてもらって無事にたどり着くことができました。
　

今回の kzrb #13 は、「意識高いもくもく会＋α」ということで、参加者の自己紹介のあとに LT があって、その後もくもく会となっていました。
LT については、cotton_desu さんの参加エントリにまとまっているので、そちらを見るのがわかりやすいかと思います。
http://cotton-desu.hatenablog.com/entry/2013/09/30/232425


もくもく会については、先月（8月3日）に参加した Rails寺子屋の復習をやる、というのを目的にすすめました。参加エントリをここに書いていなかったので、まずはそれを完成させ（ http://shiget84.hateblo.jp/entry/terakoya02 ）、その後あまり時間はとれなかったのですが、実際にやったことを復習していました。
プログラミング言語に限らずなんでもそうだと思うのですが、やっぱり一度やっただけでは全然身につかず、定期的に自分の手を動かしていかないと覚えられないですね。仕事も落ち着いてきたので、定期的に自宅で手を動かす時間をとりたいです。



もくもく会の成果発表後は今後の kzrb についての意見交換。11月の開催では、Railsをテーマとするということが決まりました。今後やりたいことをこのように話あったりできて、「みんなでつくりあげていくコミュニティ」というところを意識してるんだなーと感じました。



時間は17時になり、本編はおしまい。その後、懇親会に参加し、とても楽しかったので福井に帰ることをあきらめ二次会・三次会に参加し解散したのは26時すぎ。12時間以上にわたって、とても充実した時間を過ごすことができました。


普段、横浜に住んでいてなかなか参加することができないけど、今後ともタイミングをあわせて北陸に帰ってきて参加したいなーと思うのでした。


みなさん、お疲れさまでしたー！

*1:12/31にエントリをアップしています

Rails 寺子屋に参加した

8月3日に開催された Rails寺子屋 に参加してきました。
以下、エントリの半分くらいは8月3日のうちに書いてしまっていたのですが、そこから約2ヶ月ほど寝かせておいて、そろそろ成熟してきただろうということで、9月28日に残りの半分を書いてアップします。（こんなに遅くなるとは思わなかった。そして、やったことをそこそこ忘れてしまっている・・・）


環境構築

まず事前作業として、8月2日に環境構築を行いました。
会社を有給休暇で休んで、Apple Store 銀座へ行き、Macbook Air 13インチ を買ってきました。
そして家に帰ってきてから、以下のページを参考にして「10.7, 10.8 用 RailsInstaller」を用いて Rails 環境を構築し、その後に gem update rails で 4.0.0 にしました。
http://railsgirls.jp/install/

当日午前の部

Rails Girls のチュートリアルを参考にアプリケーションを作成しました。
http://railsgirls.jp/app/

Rails Girls のチュートリアルは初めてだったけど、scaffold してブラウザで確認するところまでは問題なく完了。他の Rails 入門みたいなのはこの段階でブラウザから確認して終了、だったりするけど今回はその後に「デザインする」という項目で Twitter Bootstrap を利用してスタイルを変更する、という段階があってとてもよかった。その後、「写真のアップロード機能を追加する」という行程もあり、どのように機能を拡張していくか、ということが少しイメージしやすかったです。
過去に Web や本を見ながら Rails に手を出してみたときには、scaffold で作ってブラウザから確認した後に自分の実現したいものに近づけるにはどうしたらよいか、というところがわからなくてモヤッとしていたので、今回このチュートリアルで体験できて勉強になりました。

当日午後の部1の1

引き続き Rails Girls を参照しながら進めることに。今回は Heroku に Rails アプリをアップするところまでです。
http://railsgirls.jp/heroku/
まずは Heroku のアカウントを持っていなかったので取得。その後、データベースのアップデート。本番環境（Heroku）では PostgreSQL を利用するように設定しました。PostgreSQL は仕事で使用することもあるので親しみがわきますね！（わかない）

その後、現在までの状況を git に登録します（登録する、という表現でいいのかな？）
git もちょっと手元で触ったことあるけど、ソースのバージョン管理としてまともに使ったことがなくて初体験。わくわくしながら進めました。

そして待望の Heroku にデプロイ。わーい！ わーい！
おめでとー！！！！！

午後の部1の1で確認できなかったところ

今後、このアプリケーションを拡張したいときの動作確認はどのようにするとよいのだろう？

group :development do
gem 'sqlite3'
end
group :production do
gem 'pg'
end

をやってるから、開発環境（ローカル）では sqlite3 を使って、本番環境（Heroku）を使うときには PostgreSQL にできるんだろうけど、それをどのように指定するんだろう？
具体的には、ローカルで改修して動作確認するときにどう指定するのか、Heroku にデプロイするときにどう指定するとよいのか？　特に意識する必要ないのかな？
# うまく伝わらなかったら申し訳ないです


午後の部1の2

午後の部1の1を終わらせたところで時間があまったので、残りの時間は GitHub 入門！！！
オープンソースとソーシャルコーディング、どのようにカルチャーが変わってきたかということについて。興味深い話題でした。
その後は、日本の歴史のお勉強。
https://github.com/june29/japanese-history
誤った日本の歴史があがっているので、修正して pull request を送る、という体験をしました。
june29 さんのリポジトリを Fork して、自分のリポジトリを git clone して エディタで編集して、commit して push して、june29 さんに pull request を送る、という流れ（であってますよね？）
github をちゃんと使うのも今日がほぼ初めてで、さらに pull request まで送っちゃうなんて、とてもドキドキでした。！！！


午後の部2

sora_h 師範による、Ruby 大喜利。にちょいちょい参加しつつ、主には午後の部1の2までにやったことを復習していました。


まとめ

8月3日に開催された 第2回Rails寺子屋 に参加してきました。
もともと Ruby はテストデータ作成用のスクリプトを書いたり、Excel を処理するのに簡単なスクリプトを書いたりで、Rails や Sinatra などのいわゆる「Web」にはこれまで関わってこなかったので、今回の参加はとても勉強になりました。

なかなか昼間のお仕事が忙しくて Ruby や Rails にふれることができなかったりしますが、せっかくこうやって貴重な体験をすることができたし、この経験を活かしていきたいです！

SIer での働きかたについて考えたりするなど

SIer が利益をあげるには、高い金額で受注して安く完成させる以外にない。
SIer と言ってもやっていることは様々で、僕は特定のお客さまを対象に基盤となる業務システムの保守および派生開発をメインに行っているチームで仕事をしている。

こういうチームの場合は保守料として定常的に一定額のお金をお客さまからいただいているので、障害などが発生しなければ基本的にはこの保守料が利益になる。また、開発案件があるときには、上記のように高い金額で受注して安く作ればそれが利益になる。
お客さまにも年間の予算や事業計画があり、そのなかで SIer に開発を依頼する訳であり、SIer が開発案件を受注したいからといって受注できるものではない。
このような状況のなかで働く人々にとって必要なのは、どれだけお客さまのビジネスに貢献できるかという意識を持つことだろう。

  • お客さまが利益をあげる
    • 投資にまわる予算が増える
    • 開発案件が増え受注も増える（といいな）
  • お客さまが利益をあげられない
    • 投資予算が縮小
    • 開発案件が受注できない、保守料も値下げを要求される、など次々と襲いかかる厳しい状況

簡単な話である。


いわゆる SI としては開発を行い納品したところで終わりなのかもしれないが*1、お客さまとしては納品されたところがスタートでこれを使ってどれだけ利益をあげられるかというところがポイントとなる。
では、開発中にエンジニアはどこを向いて仕事をすべきか。ウォーターフォールであれば実装は設計書に従って行うことになるが、実装中に「ここは設計書では○○だが、△△にしたほうがよいシステムになるだろう」とか、「☆☆機能については明記されていないが実装したほうがよいのではないだろうか」とか思うことは多々あると思う。こういうときに柔軟に対応できるお客さまだったとして*2、どこまで対応すべきだろうか。対象の変更の規模にもよるだろうし、お客さまと相談して品質・コスト・納期などを考慮して決定されるものでいわゆるプロジェクトマネージャやプロジェクトリーダの仕事になると思うが、いざ自分に判断が任されたときに何を基準にするとよいだろうか。
個人的には出来ることは可能な限りやるほうがよいと思うが品質を犠牲にはできず、納期を遅らすというのも許されない場合が多いだろう。求められていることを期間内に完了させることに加え、追加でお客さまのために＋αをやろうと思うと残業などによりコストをかけてやるしかない。お客さまから予算を追加でいただければ問題ないかもしれないが、実際にいただけるケースというのはまれだろう。となると、自社の利益を削って行うことになるが、SIer で働く立場としては「何故利益を自分から削りにいくのか」という問題と衝突してしまう。



上手い例が思い浮かばず一部極端なところがあったりするけれども、「自社の利益を最大限確保するために最低限の求められていることだけをやる」か「多少自社の利益を削ってでもお客さまのビジネスに貢献できるよう全力をつくす」か、どういう意思で仕事をしていくと自分が幸せになれるか、自分だけでなくみんなが楽しく仕事をするにはどうしたらよいか、というところが最近のモヤッとしているところであったり、今後の解決していかないといけない課題だったりするわけあり、id:hotchemi さんのエントリ『人月 - ギークに憧れて』を見て書きたくなったことでした。




世界が平和でありますように

*1:保守等が続いて行くということはある

*2:このようなお客さまは実際に存在しないかもしれないが

「SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-」に参加した #DevLOVE

SI SIer

ちょうど１週間前の10月09日に、マイクロソフト品川オフィスで開催された「SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- - DevLOVE」に参加してきました。
詳細については、NAVER まとめ「DevLOVE SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道- - NAVER まとめ」を読むとよくわかりそうです。
スライドはこちら：業務系SEの今後について


以下、私の記憶に残ったところとか、私が思ったこととか。
（私の思考整理用メモみたいなものです）


「実質所得は体感的に減少する」 （スライド3ページ目、4ページ目）

今まで△△歳で○○万円あった収入が8割くらいに下がる、とのこと。若者としては、もともとあまり給料を貰ってないところに今後も上がる見込みはなく、そんな状況で消費税も上がるのでお先真っ暗という現実。

プログラマの生産性は10倍以上の開きがある（スライド8ページ目前後）

  • 他の業界では開きがあっても3倍
  • 普通はそんなに一人当たりの出力がずれたら商売にならない
  • 優秀な人の生産性が高い、というよりも低い人が多すぎる
  • モチベーションは給料では上がらない、むしろ落ちる
    • できる人の給料をあげられない

SI の現実と今後（スライド12ページ目前後）

人月で売り上げが決まるとか、個人レベルでは残業すればするだけ残業代で懐が潤う、みたいな現場だと、収入が減ってしまうので効率化や生産性の向上をするモチベーションが保てない、ということもあるか。
プログラマの三大美徳を備えていないプログラマはプログラマではなくコーダーだ。そういう人たちばかりな SIer には未来がない、ということか。

大きな SIer になると動きも遅くなるし、組織が大きくなるにつれ制度に縛られて身動きがとりづらくなる。少人数、小さな組織で小回りをきかせながら SI をやって、そのなかで出来る人の給料をあげていく、という道。
# 「会社を少人数でやっている理由は給料をあげやすいから」というのが記憶に残っています


SIer に属する SE として今後どうしていくか？（スライド13ページ以降）

  • 考えるべきこと
    • マーケットがどう変化するか？
    • 変化するマーケットにどう自分自身をビッドするか？
    • 賭けるチップ（自分の能力）は手元にあるか？
  • 手持ちの武器は何が必要か？
    • 最強のカードは、複数の「最強-1」のカードには勝てない
    • 最強のカードになるにはかなりコストはかかるが、最強-1であれば実は真面目にやればいけてしまう

「最強-1」になるのにもかなりのコストがかかるのではないか、と何も武器を持っていない今の私は思います。
複数の興味の持てる分野について「最強-1」になろう、と思ったときにどう学習していくとよいのでしょうか。ある分野について、徹底的に学習してからその次の分野に着手するとよいのか、色々な分野に手を出しつつ少しずつ深度を深めていくとよいのか。人それぞれなのでしょうかね。自分にあったやりかたで勉強を進めていきましょう。
# このことを考えながら、学生時代にやってた探索手法を思い出しました。深さ優先探索とか、幅優先探索とか、反復深化とか。

  • 何をカードにしておくか

に関するそれぞれの解説がとても参考になりました。


まとめ（私の理解）

  • 今後の SIer および SIer に属するエンジニアには夢も希望もない。自分でこの先の未来を切り開いていかなくてはいけない。
  • ふつうのエンジニアは食べていくことが辛くなる
  • が、規模は縮小するとはいえ SI はなくならないし、ある程度マルチでできる能力があれば困ることはなさそう？
  • エンジニアとして自分は何を武器にしていくか？
  • 車輪の作り方をしっておく必要はあります（実際に作るべきかどうかは別）
  • 複数の領域で力を発揮できるように勉強しておきましょう


-「リファクタリングなんてしている時間はない」