業務系エンジニアはどうしていくべきか？
まず超個人的な見解です。あとWeb系の人は関係ないので、そういう人は読んでも無駄です。ここでいう業務系エンジニアというのは、主にSI屋で特定企業向けのシステムを構築しているエンジニアの人たちをさします。
まず、非常に難しい時代になったと思います。
端的に、ちゃんとしたSIをやることが難しくなりました。まず、技術的には面倒なことが増えた、というかできるオプションが制御できないくらいに増えているので、うまく制限をしないとコードや仕組みが劣化する一方になりました。エンジニアリングに自由を！というのは聞こえはいいのですが、チームプレーをするのに、いちいち約束事決めないと回らないようになっているような気がします。それも毎回。始めるたびに。
別段、いきなりチームメンバーの能力があがったり、さがったりするわけではないのですが、なぜか外すと酷いことになる振れ幅が増大したような気がします。ルール決めをいちいちやっていかないと、「ここまでは最低限で決めたから、あとアドリブで適当に判断してね！」ってやると、気づいたら立て直し不能な状態になることが多くなっています。さらにルール決めのなかに、昨今のセキュリティだ、社内ルールだ、決めごとが増え、報告・連絡・相談だ、挙げ句に「標準化」「ISO」コンプライアンス・・・なぜこうなったというぐらいオーバーヘッドが増えました。そもそも客先で自社のメールがとれないとか、どこの月面ですかここは？という話も普通です。
個々人をみると、まぁ確かにアレな感じな人もいるですが、全体的には酷くないのに、なんか一方的にやられてる感もあります。これが現状でしょう。さらにさらに最近ではリストラの嵐まで吹きまくって、どうしたもんかと。
さて、どーしたらいんですかね？という話ではあります。会社やめてフリーになるのも手だし、ベンチャーに飛び込むの手でしょう。流行のネット系にいくのも悪くはないですし。上は某検索エンジンや携帯ゲーム屋、下はうほほなWeb屋まで結構いくらでもある（といえばあります）
とはいえですね。まぁ、そうもいかないわけで・・・現業務屋的にどうしましょう的な案です。プロジェクトをこうしろ、ああしろってのは、いくらでも本があるので、そっち読んでください。
以下は「業務屋が生き残るために」で自分が考えていることです。
割と最近の論調で言われるのでは、「全部できろ！」ってやつですね。サービスの企画・実装・インフラあたりまで”全部”てきろって話です。Web系ならともかく最近ではSI屋さんの人事部まで同じようなことを言い出す始末です。ま、無理ですね。複雑化が進む一方の、この時代のITでは「全部できろ」は不可能だと思います。
わたしの個人的な意見は、「仕様は残るが、実装は腐る。なので、自分の時間は”残るものをつくることができる能力の向上”に時間を割いた方がよい」です。（残るというのが、どの程度の期間か？ということは別の時に・・）
・・えっと、「残るモノをつくることそのもの」に時間を当てるのではなく、「「残るモノをつくること」のできる能力の向上」に時間を割くべきです。要は、ピラミッドをつくるんじゃなくて、ピラミッドをつくる能力をつくれって言ってます。これ似てるけどかなり違います。（アーキテクトになれ、とか抽象的な話ではなくて、もっと実務的・具体的な話です。）
腐るモノを素早くつくる能力と残るモノをかっちりつくる能力は違います。Web系は前者で、業務屋は後者です。前者も後者も極めればそれなりに潰しが効きます。（前者は専門外なので、そのへんのブログとか漁ってください。よくわからんけど、凄い人は凄いのはわかります。）安易に専門外に転職するのではなく、まずは必要な能力をちゃんと普通に通用する水準までもってくるべきです。いま、なんでか知りませんが、普通の事ができない人が多いので、「普通にできるようになる」といいと思います。
本来的には手を動かしてコードを書く、ということが大変重要なのですが、どうしてもPM業務やPMサポートが主軸になると実際に手を動かす暇はほとんどなくなります。なので管理をやりながら自力でスキルをあげるには、という点で意図的にいろいろ工夫していく必要があります。まず、端的に言うと、「いろんな箇所の設計」ができるようになるべき、でしょう。現在、開発方法論は隆盛を極めて居るにも関わらず、逆説的ですが、設計ができる人間が強烈に不足しつつあります。本当にいません。
（尚、以下はあくまで業務系SEにおいては、という視点です。ミドルレイヤーに特化したり、Web系のベンチャーのように自分で手を動かさないと破綻するというカテゴリーに属する人は違うと思います。）
1.仕様の「ロジック」を押さえる能力を取得する。モデリングとかいうと語弊しか発生しないので、その言葉は使いたくありません。「その仕様は、なぜ、どうしてそうなった？」ということを押さえるということです。詳しいのは別に書いたのでそちら見てくださいませ。
http://d.hatena.ne.jp/okachimachiorz/20120219/1329652555
2.アーキテクチャを押さえる。
原理原則は「システムはIOだ」のバカの一つ覚えで乗り切る。すんませんが、経験でしかないのでアレですが、汎用機だろうと、オープン系であろうと、分散であろうと、最終的にはIOで詰まると絶対にシステムは死にます。
全体的なアーキテクチャは時代の流れのなかで、どんどん複雑になり、そして一旦、簡単なものにリセットされる傾向が、ここ30年くらいあります。まぁその都度、車輪をつくっているという説もあるのですが、それで食べているのがIT業界という側面もあるので、あまり文句を言っては罰があたりますね。考えるべきは・・
2-1.どこがボトルネックになっているのかを見極める「手段」を確保する
どのベテランも最終的は同じ見方になるのですが、解釈の仕方とか、仮説検証のスタイルがそれぞれ固有に違います。なので、個々人でそういうポリシーを持っていくことが大事になります。とにかく、IOの確認は「階層的にかつ構成的に！」そして、「困難は分割せよ！」のポリシーで順に丁寧に分解していくことが基本になると思います。一般に腕がいい、というエンジニアの人は、この分解のスピードが異常に速いですね。別にF1なみにスピードを出す必要はないのですが、カローラ位になっておく必要があります。徒歩はまずい。
ハード・ソフトの関係なく、IO視点のアーキテクチャでみれば、各IOは階層構造になっているし、また同時に並列構造になっています。ぞれぞれのIOのノードがどういう原理で、そもそも限界性能はどのようになっているのか、は把握しておく必要あるでしょう。また、そこに「原理的にどのような要素技術が採用されているのか」は押さえておくべきだと思います。
実装的にどこまでおさえるかは、根っこまで追っかけると終わらないのですが・・・業務屋レベルでは、アルファーな人たちの人柱動向と、実機実証とテストPGの結果はせめて書けて見られるぐらいにはなっていればOKだと思います。ただし、必要なデータ量と計算量から逆算することで、どの程度の仕組みと、対応するコスト（時間・人・金額）を算定できるだけの基礎知識は必ず必要になります。
2-2.パフォーマンス・チューニングの限界を押さえる。
勘違いしてはいけないのは、パフォーマンスを上げる手法を全部マスターしろ、という訳ではありません。もちろん、実際に上げられるノウハウは必要になりますが、これは完全に実装依存です。使う仕組み・ハード・ツール・ミドル等々に依存します。
限界までIOを上げるノウハウはある程度は知っておく必要がありますが、最終的には、「アプリケーションの仕様」に依存するということも理解しておく必要があります。下位レイヤーの限界を上位のセマンティクスを制限することで解消する、ということは基本的なテクニックです。非正規化によるパフォーマンス問題の解消などは好例でしょう。ただしこれはセマンティクスを制限する以上、一歩間違えると、圧倒的に拡張性やメンテナビリティが下がることがあります。普通に受け入れるべきトレードオフとして、何が何と交換条件になるのかは把握しておく必要があると思います。これは、そのパフォーマンス向上の単位当たりの限界的なコストを把握するためにも、その限界は知っておくことにつながります。
2-3.最終的にどの値が正しいのか？押さえる。
別にACIDでも、Eventuallyでもいいのですが、結局、その値が正しいのか？ということがわかることが大事です。極論をいいます。最後の最後で、どの値が正しいのかわからないという信頼できないシステム、アプリやミドルは、どんなに最先端であろう、魅力なフィーチャーがあろうと、凄い人がこれはすげーと評価しようと、まったく使えません。・・・ぐらいの勢いで、最終的にどの値が担保されるのか、見極めるべきです。
いろいろなプロダクトはありますけど、「んで、障害時にはどの値が正しいのか、どうやってわかるの？」って聞いて答えにつまる仕組みは、関わるだけ時間の無駄です。あとこの部分をより上位層で解決しなさい、というミドルが時々散見されますが、エンタープライズ・ユースでは「まったく使えない」ので勘違いしないように。
2-4.障害対策としての「アーキテクチャ」を理解する。
障害と品質ロスのトレードオフについては、絶対に押さえておくべきです。障害の起きないシステムは存在しません。（動いていないシステムは障害は起きないのですが、それは置いておきます。）したがって、当たり前ですが、まずは障害の発生率をできる限り（予算の範囲で）押さえる必要があることと、起きた場合の損害および、復旧コストを確実に理解しておく必要あります。・・・正直、自分の仕事のほとんどはここの算定に頭を割いていることが非常に多いです。
残念ながら障害コストと対策については大抵、期待値に基づく「最適化」がかならず入ります。どこまでプラグマティックに割り切るかは、ユーザーさんの基本の立ち位置によるので、最終リスクの担い手の判断にゆだねるしかありません。
障害はアーキテクチャでカバーアップすることが基本です。結果、コストとの見合いなります。命の値段まで計量化されるこの時代では、リーガルリスク前提で考える必要もあるでしょう。ただし、期待値の計算結果や損失関数は絶対にユーザーにわかりやすい形で提示すべきです。・・まー経験的には、言い方間違えると激怒されますけど。
後付けで「あーあ、言わんこっちゃない」というのはそれはそれでスタンスは正しいのですが、不作為によるペナルティーは道義的に発生することもあるし、天網恢々疎にして漏らさずのことわりもあるので、君子危うきに近寄らずとか、君子じゃないのに気取っている暇があったら、障害の対策と比較衡量を絶対にまとめておくことです。
3.コードは読み書きできるように絶対にしておく
たぶんPMクラスになるとコードを書いたり、読んだりすることは圧倒的に減ります。ただし、絶対に読めるようにはなっておかないとまずいです。まじでまずいです。もちろん、圧倒的な実装力というのはあればあるに越したことはないですが、コードは最低限書くか、読めるようにしておく状態にしておけばいいです。読めませんというのは無いので、そのときは、「初めてのナントカ」でもなんでもいいから、暇見つけて読むか、写経（全部とかやらんでいいです）すること。これは暇をみてやればいいです。いまどきトレンディーな関数型言語とかは、まずは最低限でよろしいかと。（コード量が減るのは確かなので。）そのうえで・・・
4.とにかくひたすら設計する。実装までいくとマジで時間が足りないので、あとはインフラに時間を振る。
細かいエクセルとかは可能な限りネグる。報告書は自分であとでテストとかに使えるようにして無駄にしない。設計する人は大抵実装することになる、というかテストケースを書きまくるはずなので、その辺をやる。課題管理報告とか進捗報告とか、全部可能な限り最低限にして、良い意味でネグる。（大体、人の書いた報告書で、進捗管理とかリスク管理とか、まともな人間であれば、普通は信用しません。そんな通り一遍な報告・形式で状況がわかるはずがないです。20-30分顔を合わせて話す方がよっぽど状況はわかります。）
多分ですけど、この先って実装はDSLか、オフショアか、パッケージ（のようなフレームワーク）の再利用に限定されていく気がします。そうしないとペイ・ラインにのらない・・・なので、多分、業務屋は手を動かすことは少なくなると思うのです。（あ、逆にDSL自体を書いたり、パッケージを作る人とかは凄い実装力がいると思います。）なので、業務系の人間は、より仕様・設計の力量は必要になると思います。
その上で、インフラは、もうまじめに勉強する。意外に実は業務屋はインフラに関わる機会が多いです。実プロジェクト上はどうしてもアプリよりに時間を振ることになるのですが、時間を割くべきはそっちではないです。アプリ実装か、インフラか？で二者択一になるのであれば、「業務屋としては」インフラを押さえてください。なぜか？簡単です。業務屋＋インフラの人材はこの先、ますます必要になる上に、ますます貴重になるからです。
業務屋で大事なのは、仕様（設計）とインフラです。最新言語情報とかどうでもいいので、インフラに時間振ってください。（あくまで業務屋視点ですよ？）これは先に書いたように、最終的にはシステムはIOに行き着く、ということの裏返しです。
業務屋は、設計->インフラ->アプリの順です。逆じゃないっす。・・でもこれは最低限のコードが読み書きできる、という前提です。
5. 素人考えでいいから、かならず疑問をもつということ。
最後に一般論です。ただし、いきなり口にだすとバカ扱いになるので注意です。大半のことは理解するので精一杯で、疑問をもつ余裕はないことが多い。そこをなんとか、疑問をもって口に出す事です。最近「質問をしないやつからエンジニアは機能劣化する」という名言を聞きました。しかりです。考えることを放棄するのは実は簡単で、そしてそうなると元には戻れなくなります。割と確実に戻れません。
以上です。以上が出来ていれば、まぁどの業界でも生き残ることはできるし、お客さんにも重宝される。別に Hadoopとか使えなくていいっす。・・・でもこれって、２０年くらい変わってないと思うんですけど、違います？
・・・余談ですが・・・・
んじゃー実装で勝負って人はどうするって話ですが、割と汎用的な層を取り扱うエンジニアをめざすべきです。例えばミドルウェア・エンジニア、フレームワーク構築、パッケージ開発等々をめざすべきです。以下２点です。
・割と汎用的な処理が書ける能力（または、そういった実装に関われる能力）をちゃんと、みにつける。ただし、オレオレParserで自分DSLとかは、DSLでもなんでもないので、その辺は基礎技能をしっかり身につけてください。そのためには、ちゃんと勉強しましょう。理論と実装は車輪の両輪です。両方を押さえる事で、他の人たちが何を考えているのか？今まで何が出来ていて出来ていないのか？が分かります。まー、こればっかりは終わりがないんですけどねぇ・・・
・ミドルウェア・フレームワーク・パッケージ開発にかかわれる職場をみつける。別にグーグルにいけとかAWSにいけとか言っているわけではないです。そんなクラウディーなところに行ったところで、全員が基礎レベルに関われるわけではないです。ミドル系の職場少ないです。そもそも、それほど人が食えるマーケットではないです。頑張って探してもぐりこむしかないです。・・なので、現在そーゆー場所にいる人は、なるべく自分のかかわっているミドルが世で使われるように頑張ってください。ちょっと間違えるとアッという間におとり潰しになる貴重な職場です。まー、とほほなんですけどね・・・
・・・単純な業務アプリを一からカリカリ書いていくという仕事は多分少なくなります。そういった実装だけで食べていくというのは非常に辛い時代になっているのは事実です。
まーそんな感じだと思います。
