「システムインテグレーション崩壊」を読んだ

システムインテグレーション崩壊 を読みました。

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?


まず最初「はじめに」にて以下のように『システムインテグレーション』を定義していたところが良かったです。

 ここでいうシステムインテグレーション(SI)とは、「工数積算を前提としたビジネス全般」のことです。準委任や請負などの受託開発、SES(システムエンジニアリングサービス)や派遣などがこれに含まれます。
 これを「SI」という言葉にまとめてしまうには少々抵抗もありますが、世間でシステムインテグレーターSIer)と呼ばれる企業の多くは、これらをあわせ持って生業としているところが少なくありません。中にはSIerと自称しつつも、実態はSESと派遣が大半を占めているところにも決してめずらしくありません。そんな実態から、本書ではSIという言葉を広義に解釈して使っています。

よくSIerオワコンみたいなブログがあったりするのですが、定義が曖昧なまま筆者が経験した内容をもとに記載されていて、それはそれで良いのですが「SIerは〜」と主語を大きくして書かれていることに違和感を覚えることが多々ありました。SIer といっても業務内容やビジネスモデルは様々です。そんななか、書籍では『システムインテグレーション』について定義をした後、内容に入っていたところがとても印象的でした。



書いてあることは、過去に記事やブログなどで話題になっていたりすることだったりするのですが、それが整理されて1冊の本としてまとまって刊行されている、ということが良いですね。会社とかで読書会などをやるということもできますし。

印象に残ったところ

  • 021ページ:「ゴールの不一致」と「相互不信」という構造的不幸 の図
  • 037ページ:SI事業者に内在する3つの壁
  • 041ページ:ユーザ企業に内在する3つの壁
  • 055ページ:サービスビジネスへのシフトが期待される理由
  • 071ページ:新しい3つの収益モデル
  • 099ページ:日米のビジネス環境の違いから読みとく「クラウド導入の壁」
  • 130ページ:文化の違いを理解しなければ失敗する
  • 142ページ:ウォーターフォール型の開発プロセスでは新しい価値を発揮できない
  • 150ページ:なぜ、アジャイル開発が受け入れられないのか

受託開発を行っているエンジニアがこの先生きのこるには

138ページに「お客様のCIOの役割を果たす」という内容が載っています。私も、受託開発を行っているエンジニアにとって必要なのは、これだと考えています。
お客様のCIOの役割を果たすための人材は、具体的には以下のことができないいけない、ということが140ページに書かれています。

・テクノロジーと経営について正しく理解できる
・ITを組み入れたビジネスプロセスの改革やイノベーションを実現するための施策を組み立てることができる
・IT活用の可能性や価値を経営者に理解させ、施策を提案し、実行についての交渉や説得ができる
・施策を実施するためのチームを組織し、その運営をマネジメントできる

これはまさにそうだと思います。
しかし、その前に『お客様のビジネスに興味を持つ』ということが重要なのではないでしょうか。(当たり前すぎて書いていないことなのかもしれませんが)
お客様がどういうビジネスをしていて、どのように収益を上げているのか、ということに興味をもって仕事をすること、これが最初の一歩だと私は思っています。上記、CIOの役割を果たすための人材に求められていることは、とてもハードルが高いことですが、まずはお客様のビジネスに興味を持って、自分がどうやったら貢献できるか、ということを考えることを続けていくことで、価値を提供できるようになっていきたい、と私は思っています。

この本の良くなかったところ

図が多く載っているのですが、いくつかについて説明不足で何が言いたいのか分からないものがありました。


まとめ

受託開発に関わるエンジニアの皆さんに読んでほしいし、とりあえず会社とかで進めてみようと思いました。

僕がネットワークエンジニアに片足突っ込んだときに読んだ資料の話

僕は15歳で高専情報工学科に入って、それから専攻科への進学、大学院への進学、就職と環境が変わりつつも基本的にはプログラムを書くことで学業を進めたりお賃金をもらったりしてきていましたが、今年の転勤でネットワークエンジニアに片足を突っ込むことになりました。


ネットワークといえば、新人研修で2週間くらいちょろっとやったのと、仕事でハードウェア構成とかネットワーク構成をちょろっと見てたくらいで本格的にやった経験はありませんでした。そんな自分が何を参考にしてきたのか、ということを、せっかくなので記録に残しておこうと思います。


ところで、私は結局片足を突っ込んだけど、わりとすぐに引っ込めた感じで、本格的にネットワークエンジニアになったわけではありません。従って、本エントリを読んだけどネットワークエンジニアになれなかった、という苦情にはいっさいお答えできないので、ご了承ください。

入門書

TCP/IPの絵本 ネットワークっておもしろい!

TCP/IPの絵本 ネットワークっておもしろい!

会社の新人研修で読まされた本。ほんと入門書だけど、NWが初めて、という人には悪くないかも。
ただ、自分が2000円近く出して買うかと言われれば・・・(以下自粛



小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる

小悪魔女子大生のサーバエンジニア日記 ――インターネットやサーバのしくみが楽しくわかる

はてなブックマークでn年前に話題だったので買った本。監修が村井純先生なので安心できます。
入門書としてレベルは適当だと思うけど、いかんせん手書き文字が読みにくい・・・と思ってしまうおっさんでした。


ちょびっと詳しくかいた本

〔改訂新版〕 3分間ルーティング基礎講座 (3分間NetWorkingシリーズ)

〔改訂新版〕 3分間ルーティング基礎講座 (3分間NetWorkingシリーズ)

前述の入門書でNWの概要をおおまかに知った後に、ルータの設定とかに関して話を聞く機会があって、ルーティングについて知らないとなーと思ったときに買った本。徹頭徹尾、ルーティングについて記載されていて勉強になりました。
STP(Spanning-Tree Protocol)なんかは、全然知らなかったので勉強になりましたし、VLANに関することも記載されていて参考になりました。


参考書

最短突破 Cisco CCNA Routing and Switching/CCENT ICND1 合格教本 [200-120J,100-101J対応]

最短突破 Cisco CCNA Routing and Switching/CCENT ICND1 合格教本 [200-120J,100-101J対応]

本格的にNWに取り組むなら、CCNAとかも視野にいれないといけないかな、と思って買った本。
結局、ほとんど読んでなくて CCNA とか CCENT については現時点で受験する予定はないです・・・。
(そもそも資格についてちゃんと調べてなくて、入門者が何を受けると妥当なのかすら分かってません)


まとめ

アフィリエイトやってないので、本エントリを参考に本を買った人がもしもいたとしても自分の懐はうるおわないので、アフィリエイトを初めてみたいと思いました。

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

2014/06/21 に開催された、kanazawa.rb meetup #22 に参加してきました。
meetup #22 - kanazawa.rb | Doorkeeper
Meetup #22 - Kanazawarb
kanazawa.rb meetup 22 - Togetterまとめ
主に自分の復習用のエントリで、個人の日記レベルです。



kanazawa.rb への参加は3回目。
1回目:#kzrb meetup 13 に参加してきた話 - shiget84's blog
2回目:#kzrb meetup 15 に参加してきた話 - shiget84's blog
これまでは横浜に住んでいたので金沢までくるのが少し大変でしたが、転勤して大阪府民になったため乗り換え1回、2時間30分程度で来れるようになりました。とても来やすいですね!


今回は、「2014初夏のクラウド祭り。今度はHerokuだ!」ということで、 @keiko713 さんをお招きしての Heroku のハンズオン+参加者のLTでした!
Heroku は、「 Rails 寺子屋に参加した - shiget84's blog 」のときに少しだけさわったくらいでほぼ未経験、とても期待して参加いたしました。

資料はこちらにあがっています: Heroku101 Kanazawa // Speaker Deck
最初のHerokuについてでは、「Third-Party Buildpacks | Heroku Dev Center」や「Heroku Add-ons」、「Heroku | Pricing」なども見ながら説明。やはり、料金については皆さん気になるようで、色々な質問が飛び交っていました。



その後はデモとして、sinatra で "Hello, world!" サンプルを作り、ローカル上での動作確認をしてから Heroku にデプロイ。で、"Hello, kanazawa.rb!" とかに編集してから、rollback したりしました。以下、自分の手元でのコマンド履歴。

vim web.rb
vim Gemfile
bundle install
vim Procfile
foreman start

git init
git add .
git commit -m 'init'
heroku create
heroku open
git remote -v
git push heroku master
heroku open

vim web.rb 
git commit -am 'kanazawa.rb'
git push heroku master

heroku releases
heroku releases:rollback v4

heroku open でブラウザが立ち上がって表示されるの、凄い便利!!!!!
rollback で簡単に戻せるところも良いですね。勉強になりました。



次に、GitHub からアプリを落としてきてローカルで動作確認し Heroku にデプロイ、というのをみんなで体験。git clone のときに Permission denied (publickey). で上手く行かない、というトラブルがありつつも、@rch850 さんに助けてもらいながらなんとか動くところまでを確認。感動!!!
やった内容は、こちらにまとまっているので復習するのも便利ですね! :
https://gist.github.com/izawa/058019c5d88e8d65203c


その後、add-on による拡張の話などを聞いて Heroku 101 はおしまい。



続いて、LTが5本あり、kanazawa.rb #22 の本会終了。


懇親会はショットガン.rbだったり、2次会でまさかの @yotii23 さん参加だったり、ものすごい盛り上がりでした。いい感じにまとまっている togetter もあるので、興味があるかたはどうぞ!
kanazawa.rb meetup 22 - Togetterまとめ

まとめ

  • ハンズオン楽しかった
  • 懇親会楽しかった
  • kanazawa.rb 楽しいのでまた参加したい
  • 金沢で宿泊すると、なぜかツインだったりダブルだったりする



転勤してました

2009年に新卒で SIer に入ってから神奈川県民として活動してきましたが、2月に転勤して現在は大阪府民として活動を行っています。
実家が北陸なので横浜からに比べると圧倒的に帰りやすくなりましたし、 kanazawa.rb にも行きやすくなったので積極的に参加していきたいと思っております。



これまでやってきたこととか、転勤に関するところとかを下書きで書いていたのですが、個人の日記レベルですし見てもそんなに面白くないと思うので消しました。興味のある人は個人的に聞いてください。

まとめ

転勤すると会社から引っ越し代とか住居の初期費用とか(ある程度)負担してもらえるので美味しい。

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日(木)の松江の宿を予約しています。