「フルスタックエンジニア」に見るWeb系とSI系の差

久々にブログ更新。そういや、前回の記事で書いたVX279ですが、結局返品することになりました。気が向いたら事の顛末を書くかも。


日本でこの言葉が流行るきっかけになったのは、publickey1さんのこの記事だったと思います。こちらによると

• クラウド化によりインフラ周りの負荷が軽くなった
• サーバーサイドも各種フレームワークの登場で負荷が軽くなった
• クライアントサイドも同傾向

これにより

1. 以前より全体的に作業負荷が減ったんだから、空いた時間で他のタスクも出来るよね？
2. じゃ、他のタスクもやってね！
3. おまえ、全部出来んじゃん！
4. こういう人がいると便利だよね。これからはこういう人を募集しよう！

という展開になったのではなかろうか、と。

この「フルスタックエンジニア」、度々話題に登るので、みなさんどう考えているのかWeb上を漁っていたところ、2つの異なる面白い記事を発見しました。

Web系の方のご意見

35歳定年説より怖いフルスタックエンジニアしか生残れない未来とは

SI系の方のご意見

フルスタックエンジニアもオフショアに脅かされる未来


リンク先の内容を要約すると、Web系の方(転職支援サイト運営)は

• 受託開発のSIer中心から、事業者・サービス提供者の内製中心へと転換
• 「市場の求めるニーズに素早く到達するための開発」
• こういった環境に適しているのは少人数で素早くプロダクトを作れるフルスタックエンジニア
• オフショア先から見て給与水準の高い日本は、長期的に見るとそれらの国のエンジニアよりも高い価値を生み出していかないと職を奪われる

対して、SI系の方(元請けSIerのプロジェクトマネージャー)

• クラウド化により地理的制約が小さくなったので、オフショア先のベンダーとの競合性が増加
• 技術のコモデティ化、学習コストの低下は日本人だけの特権ではない
• よって、フルスタックエンジニアといえど、優位性はあと5年程度

どちらも「このままではオフショア先に職を奪われる」と言っているのですが、Web系とSI系でかなり内容が異なります。どちらにも所属したことがある身として、この差は何処から来るのかを考えてみました。


まず、Web系企業の場合、文字通りWebでサービスを提供することで利益を得ているため、Webサービスの開発能力が利益に結びつきやすい傾向があります。特に、提供するサービスの質がライバルより劣れば、即座に死活問題に発展します。その為、開発力向上に繋がる、技術的な事柄に対する関心も強くなります。

それに対し、SI側は別記事 コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない にある通り、「結局、生き残るのはビジネスを作れる人」であり「フルスタックエンジニアではない」とおっしゃっているようです。これは、裏を返せば「現状、多くのSIerにはビジネスを作る能力がない」ことを意味します。

また、このことは「ビジネス創出能力の欠如」だけでなく、同時に「顧客の利益に直結するシステムを提供できていない」ことも意味します。「システム増える = 利益増える」関係が成立していれば、顧客からの引き合いが無くならないので、ビジネスを作れなくても困らないからです。


つまり、SI側は

1. 自社に仕事(ビジネス)がない
2. その為、仕事を取ってくるか創り出す必要がある
3. ほとんどのSIerにはビジネスを創る能力はない。だから、外部の仕事を取ってくる
4. 多くの場合、お客さんを支援(お金稼ぐ or コスト削減)するシステムを提供する
5. 技術面では遅かれ早かれオフショア先に追いつかれる
6. そうなると、人件費で不利な日本のエンジニアは、技術に興味のないお客さんから見放される可能性大
7. 見放されたくないので、お客さんの利益に結びつく能力をアピールする必要がある
8. 振り回されたくなければ、「ビジネスを作り出せる力」が必要

という論旨を展開しています。実際には、決して安い買い物ではないので、中身に全く興味がない顧客は珍しいです。ですが、こういう傾向は多くに見られます。

対して、Web側は

1. 自社に仕事(ビジネス)はある
2. でも、事業環境の変化が激しいので、変化に対応し続けるには開発にスピードが必要
3. 要件定義・設計・実装・運用で縦割ると、引き継ぎやコミュニケーションコストやらが増える
4. だったら、一人で横断的にやった方が早い(ドキュメントとか要らないし) *2
5. 掛け持ちが不可能な、超専門的な作業はスペシャリストに投げればOK
6. なので、フルスタックエンジニアかスペシャリスト以外要らないよね

という理屈です。もちろん、Web系の企業だからといって必ず自社サービスがある訳ではなく、受託的な案件も行っている場合が多いとは思いますが、上記の転職支援で紹介される先は自社開発色の強い企業が多いようです。


このWeb系とSI系、他の話題でもよく意見の対立を見るですが、掘り下げていくと

- Web系とSI系 -

	Web系	SIer *2
自社ビジネス	あ る	な い
成果物利用者	自組織	外 部
利用部門の立場	本業 営利部門	本業外 *3 コスト部門
属人化リスク	負う (技術は人に属する)	負いたくない (対策として作業標準化)
付加価値	横断型専門性(フルスタックエンジニア) 部分特化型専門性(スペシャリスト)	非技術的専門性 (業務知識やマネージメント)
キャリア志向	生涯エンジニア できれば技術で食いたい	マネージャー 技術では食えない

こういう前提があるのではないかと。で、お互い、お互いの前提を考慮しないので意見が噛み合わなかったり、衝突したりする。

中でも、自社ビジネスの有無と、「技術で食べたい」キャリア志向の差が、大きな衝突要因に見えます。実際、上記転職支援サイトの方は「技術で食べる」為の選択肢として「フルスタックエンジニア」のキャリアを提示しています。その前提を変えるとなると、「なら飲食でも介護でも何でもよくね？」ということになってしまうからです。


で、何が言いたいかというと、特段「コレ」というものはないです。ただ、この手の衝突を見る度モヤモヤすることがあったので、ちょっと自分の中で整理した感じです。そもそも、オイラには他人を心配するほどの余裕はない訳ですし (^^;;;


*1 ドキュメントの重要性(詳細さ、作り込み)が下がる、と解釈願います
*2 ユーザー系SIerと独立系SIerでは結構異なる気もしますが、面倒なのでまとめます (^^;;;
*3 本業が情報通信関連の企業は除きます

ASUS VX279Hを買ったでござる

現在使用しているディスプレイ FlexScan S2410W-R を置き換えるべく、ディスプレイを買い換えることにしました。ギラツブで有名な当機種ですが、純正の液晶保護パネルで後付ハーフグレア化可能で、ギラツブ感を大幅に軽減できたので画質にはそれほど不満はありませんでした。ただ、HDCPに対応していないので、使い回しが難しくなってきたのが主な理由です。

条件は以下の通り

• 予算は上限4～5万
• 27インチ、Full HD以上の解像度
• 非TN液晶

上記から、以下の製品を候補としました。

1. iiyama ProLite XB2783HSU
2. IO-DATA LCD-MF275XPBR
3. ASUS MX279HR
4. ASUS VX279H

XB2783HSUとLCD-MF275XPBRは先月発売されたばかりの機種で、Web上に情報が無いも同然の状態。人柱になろうか、とも思ったのですが、XB2783HSUは行きつけのヤマダやヨドバシで実機が確認できなかった為に断念。LCD-MF275XPBRはヨドバシで実機が確認できたのですが、国内メーカー初のFull HD PLSパネル搭載機ということで、今回は見送りました。
WQHD用PLSパネル搭載機は全体的に高評価なので興味はあったのですが。

残りはASUSの2機種になった訳ですが、機能を見る限り、MX279HRは動画向け、VX279Hは静止画向けの模様。動画は結構見ますが、それ以上に文字の読みやすさを重視している為、VX279Hを選定するに相成りました。


で、購入したのですが、早速問題が

1. 表示領域が狭い
2. HDMI接続なのに文字が滲む

どうも、こちらの方と同じ現象のようです。

ASUS VX279H購入

まず、表示領域がせまい。ベゼルが0.8cmとありますが、外周部の非表示領域が明らかに2.0cm以上あります。その為か、文字が潰れて表示され、結果滲んでしまっている模様。リンク先の方はD-sub接続にて対応されたようですが、それでは買い替えた意味がなくなるので、別の解決策を探すことに。

よくよく見ると、BIOSでは全表示領域を使いきれている模様。このディスプレイ、OSはWindows7 SP1、VGAはRadeon HD 6750 (ドライバは13.152.1.8-131008a-163824C-ATI)を搭載したPCで使用しているのですが、表示領域異常が確認できるのはOS起動後からです。ということは、ディスプレイ側の異常ではなく、OS(Windows)側の異常の可能性が高い。

上記のようにアタリをつけて片っ端から設定を確認。Catalyst Control Centerの[スケーリング オプション]でスケーリング値が[10%]になっている箇所を[0%]に変更した所、表示領域異常が治りました。文字潰れ問題も同時解決。こんな設定を変更したことは無いのですが、なんでだろう。別ディスプレイのS2410-WやRDT261WHでは問題なかったと思うのですが。


余談ですが、このVX279Hはヨドバシ(ネットショップ)で購入しました。店舗にも足を運んだのですが、店員は製品知識もなく、3人位たらい回しにされ、価格もネットショップ価格＋配送料、というあまりのやる気の無さにゲンナリ。店舗購入を取りやめて帰宅し、ネットショップで購入しました。店員がLCD-MF275XPBRをプッシュしてくれば、恐らくそっちを選んだと思うのですが、製品情報すら提示できていない状態でした。値札も手書きだし(他はスペック付きで印刷)。もう実体店舗の存在意義が問われるレベルだよね...

PyCharmでIronPython

PyCharm Community Editionが公開されました。Professional Editionと比べ、サーバーサイド関連の機能が制限されているようですが、個人的には問題ないです。


試しにWindowsに入れてみたのですが、インタプリタにIronPythonを設定した際にパッケージマネージャのインストールで軽くトラブったのでメモ。

環 境	バージョン
OS	Windows7 SP1
IronPython	2.7.4
PyCharm	3.0.0

まず、PyCharmを起動し

1. File → Settings → Project Interpreter → Python Interpretersを選択
2. ダイアログ右上部の「＋」ボタンを押下、インストール済みのIronPythonを選択
3. ダイアログ下部の[Install setuptools]を選択

上記の様にIronPythonにパッケージマネージャをインストールを試みると、エラーが発生する。どうやら、PyCharm標準の方法でsetuptoolsやpipをインストールしようとすると、Framesオプション絡みの問題でエラーが発生する様子。

正しい解決方法かどうかイマイチ分からないのですが、対策としてインストール作業をコマンドプロンプトから行うことに。一応、これでもPyCharmに設定が反映される模様。まず、IronPythonをインストールしたディレクトリにパスを通し、

1. ez_setup.pyをダウンロード、バージョンは0.6.11
2. コマンドプロンプトから
   >ipy64.exe ez_setup.py
3. Scriptsにeasy_install.pyが生成されたことを確認後、コマンドプロンプトから
   >cd Scripts
4. コマンドプロンプトから
   >ipy64.exe easy_install -install pip

上記の通りにパッケージマネージャをインストールする。
pipのインストールが正常に終了すれば、以降はPyCharm上からパッケージマネージャを使用可能。

しかし、Jetbrainはいい仕事してますねー Σd(ﾟ∀ﾟd)!
次のライセンス更新時までありがたく使わせて頂きます。

関連リンク

• still can't install setuptools/distribute/pip under IronPython 2.7.3
• Installing Python Packages - IronPython

久しぶりにSignalStreangthを覗いたら

昔作ったアプリをLTEに対応させる過程で面白い(?)ものを見つけたのでメモ。

1. AndroidのLTE対応に伴い、SignalStreangth内部にもLTE関連のプロパティやメソッドが追加された
2. ところが、追加されたメソッドは軒並み非公開 ( ﾟдﾟ)
3. しかし、隠蔽したLTE絡みのプロパティをtoStringでゲロってる！

で、これを利用した手っ取り早く内部プロパティにアクセスする方法が

How to get LTE signal strength in Android? (stackoverflow)

Reflection使うよりマシと言え、お世辞にもスマートとは言えないよね。
(getLevelやgetAsuLevelは使い勝手良さそう。既存のgetterをリプレースできるし)


この辺りってみんな似たような処理を書くと思うのだが、なんで隠蔽しているんですかね？
もしかして、良からぬことしているんですか、とか突っ込んじゃいそう...

w2ui ver1.2のローカライズ その2

次はカレンダー。公式サンプルを元に日本語化してみました。

サンプルから該当箇所抜粋

<div id="form">
    <div class="w2ui-page page-0">
        <div class="w2ui-label">Date:</div>
        <div class="w2ui-field">
            <input name="field_date" size="16" type="text" />
        </div>
    </div>
</div>

1. まず、カレンダーの月・曜日を日本語化する為のjson (ja-JP.json)を用意

{
    "shortdays"  : ["月", "火", "水", "木", "金", "土", "日"],
    "fullmonths" : ["1月", "2月", "3月", "4月", "5月", "6月", "7月", "8月", "9月", "10月", "11月", "12月"]
}

2. ja-JP.jsonを"/json_path/locale"に配置する

3. カレンダーフィールド用のオプションを下記の様に設定する

$('#form').w2form({ 
    name   : 'form',
    fields : [{
        name: 'field_date', type: 'date', options: {
            format  : 'yyyy/mm/dd', // 日付書式
            start   : '2013/05/10', // 選択可能範囲(開始日)
            end     : ''            // 選択可能範囲(終了日)
        }
    }]
});

4. w2utils.localeでjsonをロードする

var file = {
    lang: 'ja-JP',
    path: '/json_path'
};

w2utils.locale(file);

ローカライズ前後の違いはコチラ



　本来であれば、日曜を左端に持ってきたいところですが、何らかの形でw2fieldのcalendar_monthを差し替えなければならないのが面倒です。っていうか、できればやりたくない。外部からの設定だけでできないですかねー...

w2ui ver1.2のローカライズ

最近、w2uiという軽量なJavaScript用widgetライブラリがバージョンアップされました


ver 1.2でメッセージのローカライズがサポートされたっぽいのですが、公式ドキュメントに具体例が記載されていないので、軽く調べてみました。


1. まず、メッセージ用jsonを用意(ファイル名はja-JP.json)

{
    "phrases"   : {
        "Required field": "必須項目です",
    }
}

2. ja-JP.jsonを"/json_path/locale"に配置する

3. w2utils.localeでjsonをロードする

var file = {
    lang: 'ja-JP',
    path: '/json_path'
};

w2utils.locale(file);

こんな感じになります



pathに"/locale"が付加される点に注意。ver 1.1の時は、ソース内リテラルを直接編集するしかなかったので、大分楽になった印象です。内部的にはリテラルが分離され、w2utils.lang()を噛ませるようになった模様。

Windows XPのサポート終了まであと1年! (その3)

気になるニュースが飛び込んできたので、はじめに。

• 中国セキュリティーベンダーが独自にWindows XPをサポート！

Windows XP自体は既にかなり解析されており、実力のある組織なら単発のセキュリティパッチを出せないことはないと思いますが、永続的なサポートについては眉唾と考えたほうがよいでしょう。


国内でも以下の様な企業が現れました。こちらはXPサポート終了後、3年程のサポートを行うようです。

• FFRIのセキュリティソフト、Windows XPを2017年末まで保護対象に

この件に触れたのは、今後この手の話が増えてくる可能性がある為です。非現実的な謳い文句をぶら下げて、コソコソと動きまわる輩(自称コンサルタントの類)が出てくる気がしています。変な売り込みには気をつけましょう。



で、前記事からの続きになりますが、根本的な対策は

「5年に1度は環境を見直す」習慣をつけること

です。この界隈は変化の速度が早く、5年先の最も有効な手段を想定するのが極めて困難な為です。


Windows以外のOSでも、比較的サポート期間の長いLinux(Ubuntu LTS, Cent OS)で5年、打ち切り時期こそ明言されていませんが、Mac OSは事実上2年程度のサポート期間となっております。どのOSを使用しても、ハードウェアが壊れるまで永遠に使い続けられる訳ではありません。


また、5年も経てば、OSベンダーの事業環境も大きく変化しており、サポート方針に変更がないとは限りません。今から5年前の2008年といえば、Softbankが国内でiPhoneを販売開始した時期であり、Android端末に至ってはまだ国内販売は開始されていませんでした。この事ひとつからも、2013年現在とは状況がまったく異なることがわかると思います。


5年に1度くらいは自組織の環境を見直し、PC等の備品購入時に「今後、どうしようか？」と考えてみましょう。なお、今から5年後の2018年は、Windows Vistaのサポートが終了済、Windows 7のサポート終了期限が迫ってきている時期です。

2013年時点での主なWindows

OS	サポート終了時期
Windows Vista	2017年4月11日
Windows 7	2020年1月14日
Windows 8	2023年1月10日

今頃、日本の少なくない場所で、こういった感じの提案書や稟議書が少なからず生産されているんだろうなぁ。

追記

仮想環境関連の話には意図的に触れていません。仮想環境自体のサポートや仮想環境評価の話に発展する為です。ある程度以上のリテラシーを持った方が、自分の責任の取れる範囲で使用する分には問題ないと思いますが...