突出した人材を活かせないとか言うてますが

第3回　「突出した人材」を活かせないIT業界、低い女性の管理職比率

 何ともまぁ、ネタにして下さいオーラ満々なタイトルですが、
中身もつっこんで下さいな感じなのでエントリーにしてみました。
（会員登録してないんで、１ページ目しか読めませんでしたが＾＾；）

１ページ目を要約すると、
多くのIT企業では、突出したIT人材を確保できていないし、いても使えていない
という事を書いています。

このページで対象となってる突出したIT人材とは、
「IT分野において斬新な発想を形にできる才能をもち、製品やサービスのイノベーションで活躍するような人材」
だそうです。
いやいや、欲張りすぎやろ！


そもそも、斬新な発想を形して、製品やサービスのイノベーションで
活躍できるような人が、日本のような行動に制約が多くなり、
年功序列で歳を重ねないと決定権をもてる役職に
就けない会社にはわざわざ入らないでしょうね。

自分で会社を起こすか、海外のベンチャー基質の強い企業で働いたほうが
能力を活かせると思いますし、そういうフィールドで活躍してほしい。

会社は、トータルで優れていないが、ある点で能力を持った人達が
チームを組んでいい物を生み出して行く場所だと考えているので、
パーフェクトな人を欲しがるよりも、今いる人達の能力を見直して、
良いサイクルが生み出せるように注力すべきなのじゃないかな～っと。

なんてことを、記事を読んだ時に感じたので、
つらつらとブログのエントリーにしてみました。

・・・・・・・こういうネタなら、twitterでつぶやくだけでもよかったな。

インフラ構築におけるアジャイル開発とクラウドコンピューティング

前回のエントリーでは、ウォーターフォールモデルを経験して感じた問題点と
それらを改善しようと、最近注目を浴びているアジャイル開発について書きました。

今回も前回に便乗してアジャイル開発を取り上げたいと思います。
ただし、今回は、サーバ構築やネットワーク構築を行う、インフラ担当のエンジニアにとっての
アジャイル開発について書いていきます。

では、本題。
アジャイル開発は、主にソフトウェア開発を想定しているせいか、
インフラエンジニアにとっては非常に導入が難しい手法だと言えます。

というのもアジャイル開発の利点を考えた時、

• 成果物は、実際のシステム
• 小さな機能を一つずつ開発して、大きなシステムを構築するためクライアントの追加要求や変更要求にも柔軟に対応できる開発

などが挙げられますが、これを、インフラ構築で適用しようとした場合、大きな障害が発生するからです。

それは、サーバやストレージといった機器の調達作業です。

インフラ構築する際には、ウォーターフォールモデルでいう、基本設計や詳細設計の期間に機器の発注作業をし、
機器が導入されて初めて構築作業に移ります。

そのフローに、アジャイルのような柔軟な開発手法を取り入れた場合、機能追加の度に、発注が必要となったり、サーバ導入した際には、
ベンダーの保守も併せて導入しようとすると、サーバ毎に保守期間に差異が出たりで運用側に余計な作業も増やすことになります。

こう言った理由から、インフラエンジニアによって、アジャイル開発のような
システム開発中に柔軟に対応していく手法は、相性が悪いといえます。

じゃあ、インフラエンジニアは、今後未来永劫、ウォーターフォールモデルを
採用し続ける必要があるのかと言うと、そこで今流行りのクラウドコンピューティング（以下、クラウド）の登場です。

従来のコンピュータ利用は、ユーザー（企業、個人など）がコンピュータのハードウェア、ソフトウェア、データなどを、自分自身で保有・管理していたのに対し、クラウドコンピューティングでは「ユーザーはインターネットの向こう側からサービスを受け、サービス利用料金を払う」形になる。

（クラウドコンピューティングより引用）

クラウドは、今や多種多様なサービスで用いられ、
猫も杓子もクラウドって言うくらい、IT業界では普及し始めています。

クラウドの特徴にみられる、「必要な機会に必要なリソースを提供する」を用いれば、
機能を追加する度に、機器発注する必要が無くなり、リソースを提供してもらうことで、
インフラ構築でもアジャイル開発ができちゃうってわけです。

インフラに引きづられて、アプリ開発でもアジャイルを
より導入しやすくなるので、なおいいですね。

そもそもクラウドコンピューティングが普及すれば、
インフラエンジニアの数は減るという意見をよく聞きますけど、
それは安易すぎると思います。

クラウドを利用するに当たって、
・どのくらいのリソースがシステムで適切なのか？
・クラウド上でインフラ環境を最適化するにはどうすればいいのか？
・クラウドコンピューティングサービスで順応しないミドルウェアはどうするのか？
といったように、まだまだインフラエンジニアの必要な場面はクラウドでもあります。

一見、アジャイル、クラウドコンピューティング
という単語だけを見ると、つながりは見えにくいですが、
使用の仕方だけでソリューションを提供できる幅が広がります。

というわけで、前回に引き続き、今回もアジャイル開発について書きました。
いつまでも同じような方法でシステム作って、デスマしてヒイヒイ言うのではなく、
多角的視点で柔軟なシステム開発を行っていきたいですね。

ウォーターフォールモデルとアジャイルソフトウェア開発について

システムエンジニアになって早くも半年が過ぎて、
初めて参画したプロジェクトもやっと終わりが見えてきました。

ウォーターフォールモデルによるシステム開発に一通り関わる事ができましたので、
ウォーターフォールモデルを通じて自分なりに感じた事と
最近注目を浴びているアジャイル開発についてまとめます。

ご存知の通り、日本のシステム開発のほとんどはウォーターフォールモデルで行われます。

ウォーターフォールモデルを簡単に説明すると、
開発プロジェクトを作業工程に分割して、時系列に行っていくモデルです。

例： 「要件定義」→「基本設計」→「詳細設計」→「開発」→「テスト」

このような感じで、一つの作業工程が完了してから、
次の作業工程に移っていき、開発していく手法です。

ウォーターフォールモデルは古くからある開発手法ですが、
現在でも、ほとんどのシステム開発で用いられています。

日本のシステム開発では外注を多様するため、
工程作業がはっきり分割できるウォーターフォールモデルは相性が良いみたいです。
（要件定義～基本設計まではA社で、詳細設計～開発をB社に外注みたいな感じ）

この開発手法は、作業工程が明確に分かれているため、各作業工程で成果物が求められ、
その成果物にOKが出て、やっと次の工程に移れます。

成果物と言っても、システムを納品するのは最終的にテスト作業が完了した後なので、
ほとんどの工程ではドキュメントが成果物となります。
今回参画したプロジェクトでも、ドキュメント作業が多く、wordやexcelがいつも以上に嫌いになりました。

要件定義工程では、要件定義書。
基本設計工程では、基本設計書。
詳細設計工程では、詳細設計書。
といった風に、各工程できっちりと成果物を作成し、
それを基に次の工程に移っていきます。
モデルの性質上では、後戻りはせず、計画性の高い開発ができます。

しかし、システム開発に携わった人なら経験あると思いますが、
いくら綿密な計画を立てても、作業の後戻りが発生しないなんてことはありません。
また、クライアントがシステムを触れるのは、全行程が完了した後なので、
実際にシステム触ってみて、想像してたのとは違うなんてことも起こります。

クライアントの要求が途中で追加又は変更になって、
後戻りバンザーイ状態なんてのも誰しもが経験したことがあるのではないでしょうか。
システムの要件は変更するけど、納期は変更しないなんてドＳなクライアントに
当たった時には、連日の徹夜作業が待っています。

ウォーターフォールモデルでは、各工程できっちり成果物を出すので、
後戻りが発生すると、 多くの時間が要求されます。

福の神がついてたはずが、いつの間にかキングボンビーになってたように、
計画性の高いプロジェクトからデスマーチプロジェクトに変貌します。

今回、ウォーターフォールモデルでの開発を経験して、
このモデルが抱える問題点についても経験できました。
多くのドキュメントに時間を取られて、肝心の現場作業を圧迫したことも少なくありませんでした。
（まぁ、それは僕がドキュメント作成に慣れていないってのも理由なんですけどね・・・）
それだけでなく、途中でクライアントの要求が増えて、急遽対応したことも・・・・・。
その度にリスケする作業は終電帰りの機会を見事に増やしてくれました・・・・・。

このようにウォーターフォールモデルだけでは、プロジェクトが破綻してしまう恐れがあるため、
後戻りも考慮した柔軟な開発手法も注目されています。

そのひとつが、アジャイルソフトウェア開発（以下、アジャイル開発）です。
wikipediaには以下のように記載されています。

アジャイルソフトウェア開発とは、ソフトウェア工学において、

迅速且つ適応的にソフトウェアを開発を行う軽量な開発手法郡の総称である。

（アジャイルソフトウェア開発より引用）

アジャイル開発とは、一つの確立された開発手法でなく、
いくつかの定義があり、それを基に確立されたソフトウェア開発手法の総体です。
その為、アジャイル開発と言っても、いろいろと種類があり、それぞれに長所短所があります。

さすがに現在公開されているアジャイル開発の手法を全部紹介すると長くなるので、
アジャイル開発によく見られる特徴といえば、以下のような感じですね。

1. 少人数精鋭のチームをつくる。
2. システム全体をいくつかの機能に小分けする。
3. 小分けた機能を一つずつ作成していき、全体を作成。
4. 一つの機能にかける時間は数週間レベル。
5. 成果物は、実際に動くシステム。
6. ドキュメント類は極力少なくする
7. クライアントの要求や変更に対応しやすい。
8. クライアントが、早い段階で、実際に動くシステムを目にするので、システムの齟齬が発見しやすい。
9. システム開発の途中でのクライアントの要求にも対応しやすい。

紹介されている情報では、ウォーターフォールモデルの問題点を
解決できる開発手法で、より良いシステムが作成できそうです。

ただ、日本での導入実績は非常に少なく、正当に評価することは難しいです。
また、最初の方にも記載しましたが、日本のシステム開発は実際の開発を
外注なんてザラにあるので、アジャイル開発は現実的に難しいようです。

しかし、クライアント目線からしたら、ドキュメントばかり見せられて、
肝心のシステムは最後のお楽しみでは不安要素が大きいと思います。
（そのせいか、やたらとミーティングが多いんですよね～）
プロジェクトの早い段階で動くシステムを見て、
自分が想像してたベクトルとあっているかなどをチェックしたいはずです。

過酷な現場が多い、システム開発ですが、
いつまでも同じようなシステム開発をするのではなく、
うまくいかなかったときは、違う手法も試すくらい柔軟になっていってほしいものです。
今後、日本でもアジャイル開発のような柔軟なシステム開発が増えていくことを期待します。

「エンジニアとしての生き方」という本が面白かったので紹介

「エンジニアとしての生き方」を読みました。

内容がとても興味深く、ノンストップで読めるくらい面白かったので紹介します。

Twitterでこの本を紹介した時には、
「若手エンジニアやIT系の学生には特におすすめです。」
 ってつぶやきましたが、お勧めどころか読むべきですね。
ぜひ読んで今の日本のIT業界について考えてほしいと思いました。



簡単に本ついて紹介すると、
この本は著者、中島さんのブログ：「Life is beautiful」の記事や
雑誌：「Web+DB PRESS」に掲載された記事などから構成されています。

ただ、ブログ記事や雑誌掲載記事が記載されているのではなく、
関連する個々の記事が章単位にまとまってあります。
そのため、著者の考えがストレートに伝わり、
今までブログや雑誌を読んだことのある人にも楽しめる内容です。

日本のITに業界に対して、疑問や不満を多少でも抱えている人にとって、
「そうそう、その通り！」って読んでて声に出るくらいストレートに記載されています。

著者のエンジニアに対する考えや自分に適した職を選ぶ基準
なども記載されているので、悩める若手エンジニアの人や、
近い将来、エンジニアとして活躍しようと考えているIT系の学生の方にとっては、
自分のキャリアを再度考察しようと思える一冊です。

「エンジニアとしての生き方」おすすめです！

iPad2 3Gをおすすめする２つの理由

早速ですが、iPad2 3Gをゲットしました！

３日程使用してみて、iPhone使い始めた時くらいの利便性を感じてます。

はっきり言って、３G過小評価してました。
これは便利です。

てことで、iPadの購入を考えてる人や
wifiモデルを視野に入れてる人向けに3Gモデルの良さを
今時のhow to本ぽく
「iPad 3Gをおすすめする２つの理由」
と題して紹介します。


ではでは本題に入ります。

1.持ち運びがしやすくなった
初代の時に比べて軽さと薄さが向上してるおかげで、
外出用途として使いやすくなりました。
外でネットするのに、いちいちwifiスポット探すのってめんどいですよね。
外でネットする時は大抵時間に制約がありますし、
そんな時、３Gモデルなら場所を気にしなくてもネットができます。
（地下鉄以外）
逆に外出が多い人には３Gモデルでないとなかなか使用しないかもしれませんよ。

２.カメラ搭載
これが最大の理由かもしれませんね。

初代はカメラがついていなかったので、
ネット閲覧用もしくは電子書籍用くらいでしか
紹介されていませんでした。

今回、カメラが搭載されたことによってネットを見るだけでなく、
カメラを用いた情報発信ができるようになりました。
例えば、写真撮って、その写真を用いたブログをアップするなんてことがiPadで可能になりました。
また、現状3G回線ではFacetime使えないですが、
それは後々アプリとかでカバーできるかもしれないですね。
そうなれば、外にいながら好きな人とfacetimeで会話ができるようになりますね。

これはwifiモデルでは無線環境が必要という制約があるので、
大きなメリットだと思います。
iPadにカメラ搭載されたことによって、
世界カメラみたいなARアプリももっとおもしろくなりそうですね。


以上がwifiモデルでなく３Gモデルをおすすめする理由です。

無線ルータ持っている人はwifiモデルで十分だと思いますが、
そうでない人は3Gをおすすめします。
「iPad購入したけど家でしか使ってなくて、やっぱノーパでいいや」
なんて宝の持ち腐れになるかもしれません。

３Gモデルは月々回線料が必要ですが、飲み会を一回我慢すれば支払える金額です。

飲み会一回我慢するだけで、日々の生活が格段に便利になるので、

iPad2 3Gモデル思い切って購入してみてはいかがでしょうか。