 
|
はてなキーワード: RDBとは
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
DBってこんなもんか...と思ってたけど、インストーラのヘコさにあきれまくる。
その後 Microsoft SQL Server 2000 の手軽さを知って、こちらにどっぷり。
で、ずっとSQL Server。
そこそこの使い方ならどっちのDBも十分使える上に、Oracleは「くだらない」お作法が大杉。(Oracle Master の為?)
クエリー実行計画が図解でわかりやすい、バックアップやアタッチが超楽。
サポート(修正パッチなど)も料金込みのMSのほうがトータルで安価だし、CubeやReporting Serviceなどもコミコミで使える。
多言語関係もMS SQL Server のほうが良くできてる。
SQL Server のStandard Editionだけでなく、無償版であるExpress Edition も使っているが、
残念ながらこれは外部のPCから接続できない制限がある(はず)。
同じく無償版のOracle DB 11g Expressがあるが、こっちでは他のPCから接続できた。
Universal Installer は相変わらずjavaでできてるからかUIヘコいけど、
「くだならい」設定項目がだいぶ減って楽ちんでインストール完了。時代は進化した。
.NET Framework(OLE DB)で外部からのPC接続もホスト名、ユーザー名、パスワードを接続文字列で指定するだけで、あっさりOK。
tnsnames.oraとかいじることはもう無くてよいのだろう。
俺もいろんな部署転々としたけど、やっぱり歴史のある仕事してるところは古いスタイルで仕事してたよ
てな感じで、腰をすえてやればできることはいっぱいあるかと思う。
古いスタイルの部署・会社は、その分スケジュールがタイトではなく、業務に変更が少ないので
遠大な計画を立てることで一人だけでも結構大きい改革ができると思うんだけど
どうでしょ？
とぼくはおもう
注意しなければならないのは、IT系と一口にいっても、サブジャンルは腐るほどある点だ
Joel Spolskyは５つに分けていた
ソフトウェア開発には、しばしば交わっているがたいていは分かれている、5つの世界があると思う。その5つとは：
http://local.joelonsoftware.com/wiki/5%E3%81%A4%E3%81%AE%E4%B8%96%E7%95%8C
そして、これらのIT企業が、最先端のシステム開発をしているかというと、そんなことはないのである
ファイルサーバに空き容量が無くてローカルに退避する作業に一日費やしたりする
「打ち合わせご希望日を添付のエクセルシートに記載の上ご返信ください。なお、ファイル名は”社員番号_指名_記載日付”の形式でお願いいたします」
ほとんどの現場が、方眼紙状にしたエクセルを印刷して、判子をつく（客の都合でもある）
そんな作業ばかりしているし、本質的なコーディングの作業は1割もないのだ
夢打ち砕かれ
http://anond.hatelabo.jp/20070831005830
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。
http://www5.ocn.ne.jp/~m-shin/windows/windows-vista-proxy.html
WinHTTP(AutomaticUpdateなどが利用)へ、IEプロキシ設定のインポート。
なるほど...と言いたいところだが、
proxycfgのコマンドを残して内部処理だけ変えるってのも、
何かの理由があって嫌だったんだろうな。
むしろ、IEとWinHTTPとで設定が混在するような設計を避けてほしかった。
似た例とすれば
W32TMのNTP設定とGUIの時刻同期設定も微妙に別だし。
開発チームが分散していて統一設計が苦しいのかもしれないが、
PHPerの問題点は、視野が狭いこと。典型的には以下のような悪癖を持つ。
何も知らないからPHPを愛せるんだよ、PHPerは。だからまず、HTML、CSS、JavaScript、SQLを覚えろ。次に、Javaに移行しろ。そんなに難しくないよ、Java。特に大量にコードを書けるPHPerは、速度が出てライブラリ化が容易なJavaの方が向いている。今はVPSがあるので、小規模案件でも問題ない。
15年間ほどPHPはインターネットを支えてきたが、そろそろ設計の脆さが問題になっている。PHP 6の開発が振り出しに戻ったのは、不幸な事故ではない。ウェブで仕事をしていれば、PHPとJavaで共通する知識も多い。PHPerはJavaを覚えてPHPとさよならしろ。そして恥ずかしい悪癖を直すべきだ。
◆日本でしか生きていけないと将来破滅するリスクがあるので、世界中どこでも生きていける戦略のご紹介
日本依存症は、国家依存症の一種であり、会社依存症とよく似ています。
会社依存症とは、ある特定の会社でしか通用しないスキルばかり蓄積して、他の会社では通用しない人材になってしまう病気です。
会社依存症にかかると、その会社の経営が悪化して、どんどん待遇が悪くなり、給料を下げられ、「このままここにいても、少しもいいことがないまま年を取っていくだけ」という状況になっても、ひたすらその会社にしがみつくしかなくなります。
また、会社の都合で延々とつまらない仕事をさせられたり、いまいち納得のいかない降格や減給をされても、なかなか拒否しにくくなります。
上司や同僚と相性が合わず、人間関係がこじれてギスギスした雰囲気になり、毎日会社へ行くのが憂鬱になっても、そこに居続けるしかありません。
なぜなら、その会社を辞めると、ほかに行くところがなくなり、路頭に迷ってしまうからです。
このため、このことがよく分かっているエンジニアなどは、その会社の独自製品や独自環境でしか通用しないスキルしかたまらないような仕事をできるだけ避けるようにします。
そして、「広く普及しており、かつ中長期的に需要があり、供給が不足ぎみで、かつ陳腐化しにくいスキル」を戦略的に蓄積します。
たとえば、以下のようなものが考えられます。
・要求分析、要求仕様定義、システムアーキテクチャ設計、RDBスキーマ設計、サーバの負荷分散設計、各種サーバのパフォーマンス解析・チューニング、デザインパターン、マルチスレッドプログラミング、システム管理、ネットワーク管理
・マネージメント、プロデューサ・デザイナ・経営者・営業・顧客との交渉スキルや連係プレースキル
・普遍性の高いコンピュータサイエンスの基礎
・Unix、RDB、正規表現、Java、Perl、TCP/IP、.NET、C#
日本にはたくさんの会社があり、それぞれが浮き沈みを繰り返しています。
いまいる会社が今後もずっと浮いたままだという保証はありません。
一つの会社に依存しきると、その会社が沈むとき自分まで一緒に沈んでしまい、酷い目に会います。
いまいる会社が沈みそうになったら早めに別の会社へ移れるように準備しておくべきではないでしょうか。
国家に対しても同じことが言えます。
政府は全ての国民を幸せにするような政策を実行するべきですが、必ずそれに成功するとは限りません。
ときに間違った政策を行い、多くの犠牲者を出すこともあります。しかも、その犠牲者を救済するための政策が実行されないこともあります。
もっと最悪なことに、間違った政策で、国全体が沈んでしまうようなことすらあります。
もちろん、そうならないように、われわれは選挙で正しい政策を実行してくれる政治家に投票すべきですが、常に正しい政策を実行してくれる政治家が自分の選挙区から立候補してくれるとは限らず、自分以外の人々が常に正しい政策を実行してくれる政治家に投票してくれるとも限らないというのが、世の中の現実です。
だから、どんなに自分が正しい政治行動を取っていても、おかしな政策が実行され、自分の将来が危うくなるリスクは常に存在します。
たとえば、金持ちばかりが得をし、平均的な労働者が搾取される最悪の格差社会になってしまうかもしれません。
あるいは逆に、今後スキルアップし、キャリアアップし、実力を身につけて高い年収をゲットしようと思っているのに、高額所得者の所得税が大増税されて、酷い搾取に苦しむようになるかも知れません。
あるいは、少子化対策で、実質的に独身税をかけられたのと同じような状態になり、結婚するつもりも子供を作るつもりもない人たちの生活の質がかなり落ちるかも知れません。
あるいは、国の医療システムが疲弊しまくって、まともな医療サービスを受けられなくなるかも知れません。あるいは、まともな治療を受けようとしたら、恐ろしく高い料金を徴収されるようになってしまうかもしれません。
あるいは、地方格差を埋めるため、都市部の住民を徹底的に搾取し、地方にじゃんじゃんばらまくような政治が行われるかもしれません。そうすると、田舎に住む人間の暮らしはよくなるかもしれませんが、今後も都市に住み続けるつもりの人間の暮らしの質が大きく低下するかも知れません。
あるいは、非正規雇用を減らし正社員を増やすという名目で、おかしな規制がかけられ、予期せぬ副作用が出て逆に多くの人が職を失うことになるかも知れません。余波で、自分まで失職するかもしれません。残された正社員の自分に酷いしわ寄せが来るかも知れません。
労働者保護や消費者保護という名目で、過剰に企業の手足を縛るような規制がかけられて、企業の活動が阻害されて経済が悪化したり、企業がどんどん日本から逃げ出すかも知れません。雇用が減り、治安が悪化し、日本が住みにくい国になるかも知れません。
要するに、投資において、全ての資産を一点がけするのが危険な投資戦略であるように、自分の生活基盤となる国家を一カ所だけに限定してしまうのも、極めて危険な賭なのです。
この国にずっと住み続けるのが一番賢い戦略でした。
しかし状況は変わりました。
いまや日本よりも豊かな国や都市がどんどん生まれつつあります。
日本などよりも、はるかに先行きの明るい国や都市がたくさんあります。
本来、この惑星には、たくさんの国家があり、それぞれ浮き沈みを繰り返しています。
いまいる国家が、今後もずっと浮いたままだという保証はありません。
一つの国家に依存しすぎると、その国家が沈んでいくとき、酷い目に会います。
いまいる国家が沈みそうになったら、早めに別の国家に移れるように、準備しておくべきではないでしょうか。*1
こういうことを言うと、「おまえに愛国心はないのか？」と言い出す人間が時々いますが、依存症と愛国心とは別の話です。
これは、結婚において、夫を愛していることと、夫に依存することが異なるのと同じことです。
経済的にも精神的にも自立していることと、夫を愛することは両立します。
夫婦仲は冷め切っていて、夫の暴力に怯えながら暮らしているにもかかわらず、夫に経済的に依存しているためにガマンし続けているような状態は、とても健全だとは言えません。
むしろ、特定の国にまったく依存していないにもかかわらず、その国を愛し、その国に貢献することこそ、純粋に打算抜きの愛国的な行為なのではないでしょうか。
そもそも、「いろんな異性とつきあってみて、そのなかから最高のパートナーを見つけ出して結婚する」というのは、少しもおかしなことではありません。
「1人の異性しか知らず、最初につきあった異性と一生添い遂げなければならない」というのはいかにも古めかしい道徳観念です。これは国家についても同じことです。たまたま日本に生まれたからと言って、日本と一生添い遂げなければならないということはありません。
むしろ、さまざまな国に住んでみて、そのなかから、自分にいちばんあった国に落ち着き、添い遂げる、という人生も十分にありなのではないでしょうか。
日本以外で暮らしたことのない人々の中には、日本だけが世界で唯一暮らしやすい場所で、日本以外には暮らしやすい場所などないと信じて疑わない人もときどきいるようですが、そんなことは決してありません。
むしろ、日本よりもはるかに、晴天の日が多く、気候が温暖で、からっとさわやかで、毎日気持ちよく暮らせる国や地域がたくさんあります。
食べ物も美味しく、人々も気持ちよく、街の各種施設も充実しており、遊び場所もたくさんある快適な都市は世界中にたくさんあります。
どんなところでも、けっこう住めば都なのです。
また、日本以外の国は治安が悪くて暮らしにくいという偏見を持っている人もいますが、どんな国でも、きちんとした安全対策を講じ、危険な地域に近寄らないようにすれば、それなりに安全に快適にくらせるものです。
それに、どうせネット環境さえあれば、世界中どこでも、twitterやtumblrやmixiで遊べるし、ブログのコメント欄でクネクネすることもできるし、2ちゃんでだらだら過ごすことも出来るし、エロ画像をダウンロードすることもできるし、はてブで脊髄反射的なコメントを付けることもできるし、はてなスターを連打しまくって顰蹙をかうこともできるのです。
「わたしは(この国に生まれたというより)この惑星に生まれたのだ」という感覚を持ちながら生きるというのは、広々とした感じがして、なかなか気持ちの良いものです。
せっかくこの美しい惑星に生まれたのに、日本という小さな小さな島国に引きこもったまま一生を終えるのは、じつにもったいないことではないかと思えてきます。
●依存症からの脱出は難しい
ギャンブル依存症、アルコール依存症、買い物依存症、恋愛依存症、セックス依存症、たいていの○○依存症は、そこから抜け出すのに苦労するように、日本依存症も、一度それにかかると、そこから抜け出すのにかなり苦労します。
また、タバコ依存症から抜け出すために、さまざまな方法があるように、日本依存症から抜け出すにも、さまざまな方法があります。
日本依存症から抜け出す一番効果的な方法は、実は、英語力をアップすることではなく、日本の外でも安定した収入源を得られるようにすることです。(もちろん、最低限の英語力は必要ですが)
これに一番効果的なのが、資産運用で暮らせるようにすることです。
利回りのよい債権や株式に自分の資産を分散投資し、運用することは、どこの国に居住していてもできます。
日本の国債や株式で資産を運用していたとしても、日本に住んでいなければ運用できないということはありません。世界中どこに住んでいても、日本の国債や株式で資産運用することは可能です。
それどころか、そもそも、日本の国債や日本の株式で資産を運用しなければならないということはありません。
むしろ、全資産を円ベースに一点がけしてしまうと、今後円安が進んだときに、自分の資産が大きく目減りしてしまうというリスクを抱え込むことになります。
資産は、全世界に分散投資しておいた方が安全だし、世界全体の経済は、多少の波はあるものの、中長期的にはつねに成長し続けているので、正しくポートフォリオを組んで、世界中に分散投資しておけば、それほどひどいことにはなりません。
だから、いったん資産運用で暮らせるだけの資産を蓄積してしまえば、日本依存症からの脱却はかなり容易になります。
ここで、「日本がキャピタルゲイン課税の大増税を行ったら、資産運用では暮らしていけなくなるのではないか？」という疑問がわく人もいるでしょうが、そうでもありません。
まず、税金の徴収には、属人主義と属地主義の二つの方式があります。
日本は属地主義なので、自分が居住している国や地域に税金を納めることになっています。
このため、日本でキャピタルゲイン課税の大増税が行われたとしても、海外で暮らしている限り、影響を被ることはありません。*2
現在、属人主義を採用しているのは、アメリカとフィリピンぐらいなもので、極めて例外的なケースです。
ですから、今後日本が属人主義に変更するリスクは、とても低いと思われます。
また、万一、日本が属人主義に切り換えたとしても、ある程度の資産を持つ人間に国籍を与えてくれる国は、けっこうあります。
日本が属人主義に切り換え、さらにきわめて重いキャピタルゲイン課税をかけてきたら、単に国籍を切り換えればいいことです。
ただ、問題は、資産運用で暮らせるようになるほどの資産を蓄積することが難しい、ということです。
そのため、当面は、収入の全てを資産運用だけで稼ぎ出すのではなく、収入の一部だけでも資産運用で稼ぎ出すような状態を目指してみてはどうでしょうか。
そうすると、日本がヤバくなったので、脱出して海外で職を得たのはいいが、最初のうちはまだ英語にも不慣れで、十分な収入を得られないというようなケースでも対応できます。
たとえば、前述のUnix、Web、RDB、Java、Perl、.NET、C#など、世界中に普及している技術の場合、そのスキルを身につけることで、日本依存から抜け出すことができます。
また、これらに関連する要求仕様定義、オブジェクト設計技術、デザインパターンを適切に使いこなしたクラス設計、プロジェクトマネージメント、スケジュール管理なども、特定の国家に依存しないスキルです。
これらのスキルを身につけたITエンジニアは、さまざまな国で職を得ることが出来ます。
実際、ボクの知り合いでも海外で働いているプログラマーがいます。
むしろ、日本よりも快適に働いているようです。
もちろん、これらの技術は、会社依存症から脱却するための技術としても有効で、きわめて安全性の高い技術だと言えます。
これらの標準的なITスキルは、このように、会社や国家を超越して有効ですが、それ以上に驚きなのは、かなりの長い時間をも超越する力を持っているということです。
たとえば、unixの基本アーキテクチャはボクが知っているだけでも十数年、ほとんど変わってません。マルチスレッドプログラミングやデザインパターンも十数年前に身につけたスキルは、かなりの部分、いまでもそのまま役に立ちます。はるか昔に覚えた、クロージャや再帰を使ったさまざまなプログラミングテクニックも、RDBのスキーマ設計のスキルも、ほとんどが、いまだに現役です。
TCP、UDP、IP、HTTP、SMTP、POPなどのプロトコル類もいまだに基本はほとんど変わりません。新しく登場した.NETやC#にしても、過去にマスターしたスキルにほんのちょっと上積みしたぐらいのわずかな薄皮でしかなく、いままで蓄積した基本スキルはそのまま通用します。Haskellのような関数型言語ですら、似たようなコンセプトのプログラミングアーキテクチャは昔からあり、十数年前にマスターした技術の延長線上でなんなくマスターできます。
このように、長期的に安定した技術やスキルを選んで身につけるようにすれば、会社、国家、時間を超えて、安定した収入源を確保できるのです。
ただ、注意しなければならないのは人材の需給バランスです。とくに、インドや旧共産圏からのプログラマの大量供給は要注意です。
一方で、ヨーロッパ、BRICs、VISTAなど、世界中で急速に経済が発達しており、ITエンジニアの需要が今後も全世界的に巨大化し続けるのは確実です。
ここでのポイントは、下級エンジニアや中級エンジニアは、需要はそれほど拡大しそうにないのに、供給は膨大になると思われるので、リスクが大きいということです。
つまり、下級エンジニアや中級エンジニアの場合、海外に行くと、日本にいたとき以上に悲惨になる可能性があります。安易に日本から出て行くべきではないでしょう。
一方で、上級エンジニアは技術分野にもよりますが、今後、世界中で爆発的に需要が拡大することが見込まれていますが、供給が不足する可能性は十分に考えられます。
従って、自分が今後上級エンジニアになる可能性があると考えている人たちは、この戦略に沿って日本依存症から脱却しておいたほうが良い可能性が高いです。
あと、もう一つ考慮すべき点は、上級エンジニアになるような人は生産性が高いため、今後、高額所得者になる可能性があるということです。
今後、この機運の盛り上がりに押されて、高額所得者を狙い打ちする形で大増税が行われ、酷い搾取の対象にされるリスクもあります。
このリスクに対する保険という意味でも、早めに日本依存症を治療し、いつでも仕事と生活の場を海外に移せるようにしておいた方が安全かもしれません。
日本人が海外で暮らしてみると、さまざまな小さなニッチビジネスのチャンスに気がつくことがあります。
たとえば、日本にはあって当たり前なのに、その国にはない商品やサービス。
それは、日本のやり方を現地方式にアレンジすれば、それなりに繁盛する商売ができるかもしれません。
あるいは逆に、その国のおもしろい商品やサービスで、アレンジすれば日本でもウケそうなもの。
もしくは、現地の安い人件費を利用して、何かを作らせ、日本に持ち込むというパターンもあるでしょう。
実際、ネパールに小さな工場をもっていて、そこで自分のデザインした服を作らせ、日本に輸入して販売しているという女性に会ったことがあります。
こういうビジネスのネタをみつけたとき、スモールビジネスを興すスキルを持っていると、そのチャンスを活かして、その国で商売をはじめることができたりします。
とくに、最近急速に豊かになったアジアの国々では、日本がかなりブランドになっています。
とくに富裕層は、日本のさまざまな質の高い品々やサービスを求め、日本の産物に信仰のようなものを抱いています。
これをうまく利用することで、いろいろなニッチビジネスを作り出すことができるかもしれません。
スモールビジネスのスキルとは、小さな会社向けのマーケティング、マネージメント、経理などのスキルです。
たとえば、どんな小さなビジネスでも、どんな商品を、どんな顧客に売るのか、そのために、商品にはどのような魅力がなければならないのか、顧客は、どういう理由でその商品にお金を払うのか、どのようにして利益が出る構造になっているのか、などのビジネスモデルを組み立てなければなりません。
そして、いざ、ビジネスプランが出来たら、場合によっては人を雇い、契約を結び、信頼関係を作り上げ、法律に則って取引しなければなりません。関係者全員が気分良く仕事できるように、win-winの構造を作り出す必要があります。
また、さまざまな法律を調べ、その法律に則ってビジネスを運営する必要があります。
さらに、会社を設立し、会計ソフトで帳簿を付け、経理と資金の管理をする必要があります。
また、予算計画を立て、融資なり出資なりで資金を調達する必要もあります。
こういう小さなビジネスを最小限の規模ではじめてみて、いざ、顧客の反応が上々だったら、しだいに規模を拡大していけばいいのです。
思ったより反応が悪ければ、早期に撤退するか、あるいは、やり方を変えて再度トライしてみたりすればいいでしょう。
そして、スモールビジネスの醍醐味は、たまたま大ヒットしたときのうまみです。
日本のサラリーマンの頂点とも言える、上場企業の社長の年収でも、たかだか4000万円にしかなりません。
これに比べ、スモールビジネスをヒットさせた場合、実質的に年収1億円を優に越えてしまうということは、それほど珍しくないのです。
実際、ぼくの知り合いにもそういう人がいます。
「たかが自営業」とばかにできるようなもんでもないのです。
自営業は、あたると凄いんです。
どのようなモデルで日本依存を脱却するのであれ、共通して必要なPermalink | トラックバック(0) | 22:10
俺の住む世界はアイティーとやらに支えられているらしい。
アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。
そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。
昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。
パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。
楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。
研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。
現場に出て、本番機に触った。
３０年間親会社を支え続ける偉大なシステムの中身を、わくわくしながら覗いた。
そこには、俺の求めていた世界とはまったく違うものが広がっていた。
俺が産まれる前から、入れ替わり立ち替わり何人もの手によって継ぎ足されたロジック。
何千行にもわたって、似たような処理が何回もひたすら繰り返される似たようなモジュール何十本。
1993年に行う臨時処理のロジックが、今もコメントもなしに埋め込まれている。
仕様がわからなくなれば、キャビネへと走って、黄ばんだ方眼紙に鉛筆で書かれた仕様書を探し、
そして修正履歴のみが書かれているのを確認して肩を落とす。
半年後に臨時で行われる業務に対応するため、いくつかのモジュールについて、処理可能なユーザーコードをひとつ、条件に加える。
与えられた期間は２週間だった。ずいぶん長いなと思った。
何枚もの設計書を書いた。つまり、方眼紙状のExcelテンプレートに同じ文章をコピペした。
追っていったモジュールはどれも、ヒープもソートもメモリ管理も論理演算も出番がなかった。
あるのはただ、IF文とMOVE文とばかりだった。ソースの難易度は使われている命令の数とは関係ないことを学んだ。
テストデータを作るため、階層型DBを何回も辿ってデータをアウトプットさせるモジュールを書いた。資格試験で学んだSQLは、無用の知識だった。
協力会社への仕事割り振りやユーザー対応に毎日忙しそうだった上司が、夜遅くまでの残業続きでくまのできた目を皿のようにして設計書をレビューした。
ロジックを丸々コピペしてソースを修正し、コンパイルし、実行した。
２週間はあっという間だった。
俺のせいで、半年後以降は使われないロジックがソースにまたひとつ増えた。
今回の対応については、Excel方眼紙にレポートをまとめて共有ドライブに入れておいた。
だが共有ドライブの検索には時間がかかるし、Excelシートの中身となれば検索から漏れることも多い。
きっと誰にも読まれないだろう。
２バイト文字が使えない関係上、原則、ソースにはコメントはあまり入れられない。
数年後の新人はきっと、俺の書いたモジュールを見て「このロジックは何だ」と首を捻るんだろう。
数年後の俺はきっと、今回のレポートを共有ドライブから探し回って新人にパスを教えてから、
協力会社の管理に追われる作業に戻って目の下にくまを作るのだろう。
俺がやりたかったシステム開発って、こんなものだったのか。
俺は部署の中で、俺の望む仕事を探し続けた。
先輩たちは忙しくて誰も興味を持ってないけど、自動化できる作業はいくらでもある。
よく使われるExcelシートを改造し、定例作業をクリックだけでできるようにした。
ExcelVBAとはいえ、書いていて心地よかった。引数が明確な関数と変数のスコープと全角文字があったからだ。
COBOLで打つプログラムより、控えめに見て100倍くらいの生産性を発揮できていたと思う。
先輩たちは喜んでくれたが、ただし俺の仕事を、あまり仕事とは見なさなかった。
それでもよかった。業務時間外は俺は相変わらずスクリプトを書いていた。とても楽しかった。
VBAから入って、WSHなんてものを知り、やがてJavaScriptを学び、ネットで資料を探し、はてなを知り、はてブでWeb技術についての記事を読みふけった。
知れば知るほどに、どんどんCOBOLが、メインフレームが嫌いになっていく。
先輩は誇らしげに言う。システムはたいしたことをやっていない。業務知識こそが大事なのだ。
ユーザーより詳しく業務を理解し、適切に提案し、設計する能力。
協力会社を率いて、わかりやすい文書で指示を行い、スケジュールを調整する能力。
人を動かすぶん、責任も大きくやりがいもある。優秀な人材こそが我が社の強みだ。
そんな人材が育つよう、我が社は安定して働ける環境と福利厚生を整えている。
ああ、そうだよ。先輩、あなたは正しい。
俺だってメインフレームの信頼性のすごさはわかってる。
密なユーザーとの関係から生まれるシステム子会社としての強みも認識してる。
それだけじゃない。社内環境も悪くない。給料もいいし休みも取れるし先輩は優しい。
ここは、いい会社だ。
けど駄目なんだ。
３０年前のシステムを枯れた言語でツギハギする仕事じゃ、俺の心はやっぱり満たされない。
ユーザーの業務知識ばかり身につけたって、俺自身の人生には、いいことなんてない。
俺が求めていたのは、この仕事じゃないんだ。
社内の誰も、TumblrもTwitterもやっていない。ライフハックなんて聞いたこともない。
Joostやモバゲーや２ちゃんねるが社会に与える影響について誰も語れない。
休日はゴルフや酒に興じている。自宅にPCを持ってない人までいる。
おかしいことじゃない。普通の人たちだ。
それどころか彼らは、仕事とプライベートを切り分けている、立派な人たちだ。
でも、やっぱり俺の生きていきたい世界は、ここじゃないんだ。
たぶん俺がいるのは極北なんだろう。
ここが、人月計算とExcelとスーツの世界というやつなんだろう。
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。
プログラミング言語は何でもいいから、RDB（リレーショナルデータベース、Relational Database）勉強したほうがいいよ。SQL。
RDB＆SQLですか。現時点ではよく分かってないのですが、勉強してみます。
もし勉強の参考になるページ知っていたら、教えていただければ幸いです。
あと、「SEと交渉して安くする」っていうのは、相手先の会社に敵対的にならないように気をつけてね。最悪のケースは、交渉決裂→他の会社をあたってみる→他の会社のエンジニアは、今のシステムを把握していないので、その分までこめて予算を出してくる→結局、今の会社よりも高い金額を払うことになる/気まずいけど、今の会社に再び頼むってことになりかねない。
なるほど、会社かえるとを引き継ぎ完了するまでのコストが発生するってことですね。
それを考えるとやっぱり今の会社に頼むのがいいのかな
プログラミング言語は何でもいいから、RDB（リレーショナルデータベース、Relational Database）勉強したほうがいいよ。SQL。
OracleとかMySQLとか色々あるけど、SQL言語覚えてればどれも大体は似ている。
業務用システムって、たいてい、データベースのエンジンは他の会社が作っている奴とかオープンソースの奴をそのまま持ってきて、データベースと利用者をつなぐインターフェース部分だけ作っているところがほとんどだから。
あと、「SEと交渉して安くする」っていうのは、相手先の会社に敵対的にならないように気をつけてね。最悪のケースは、交渉決裂→他の会社をあたってみる→他の会社のエンジニアは、今のシステムを把握していないので、その分までこめて予算を出してくる→結局、今の会社よりも高い金額を払うことになる/気まずいけど、今の会社に再び頼むってことになりかねない。
一番やって欲しいのは、既存の現場の問題点の洗い出しをして、どういう機能が足りていないのかを、しっかり説明して欲しい。どの機能を加えると、どれぐらいの作業量が必要そうか、という感覚が、頼む側にもあると、やりやすい。
新しいシステムを外注するなら、複数の会社に頼んで見積もりださせてもいいかもしれないけど、稼動中の今のシステムの改良でしょ？今のシステムとまったら、困るわけでしょ？だったら、今の会社に頼むのが一番速い＆安い＆ちゃんとやってくれる気がするんだけど。
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント
ちょっと囓っただけの素人が自分を過信して陥る三つの罠？
d:id:fromdusktildawn:20081026さんは「共通化とか抽象化ができるようになった中途半端に優秀な』人を対象にしているのに対して、d:id:JavaBlack:20081026さんは『ちょっと齧っただけの素人』を対象（元記事に対してかもしれない）にしているので、適用対象のレベルがそれぞれ違う気もするけど。
d:id:JavaBlack:20081026さんの記事に対するブクマコメントの幾つかやトラックバック先において、『Java屋らしい』との書き込みがあるけれど、具体的に『Java屋らしい』とはどんなことを指すのでしょう？
当方嫌われ者のエンタープライズ開発withJavaな人間ですが、Javaがよく使われるエンタープライズ向け開発などを行っていると、プログラミングは企業入ってから覚えました、っていう人の方がマジョリティだから、こういう“プログラミングのセオリー”のようなものは知る機会がないと言っていい。よほどいい先輩に当たらないと、こういうことすら教えてくれないことの方が多い。
プログラマなら自分で調べて当然、という意見もあるだろうけど、上記“マジョリティ”の彼らは、自宅でコーディングなんてするはずがないし、早くコーディングなんて卒業したい、と考えている人種。
そんな人たちは、こういうことを『知らない』し、『知ろう』とも思っていない。
そういう現場にとっては、
とある程度型にはめて指導することは、とりあえず『最低限のレベル』を守るためには有効だと思うのだけれど。まぁ元記事では『中途半端に優秀な』とわざわざ断っているから、こういうことを最低限知っていて、杓子定規になんでもかんでも共通化したりローカル変数ばっかり使っている人に対しての進言なんだろうとは思いますが。
『Java屋らしい』とは、Javaが静的型付け言語だけに、なんでもかんでも「こうしなければいけない、ならない」と断定してしまう点を指して『堅い（硬い？）』ことを言っているのでしょうか？
あと、『Java屋は長ーいメソッド名が見やすいと感じるらしい』というコメントについては、Java屋がCOBOLerに対して、
なんて書くのは冗長だよなー。とか、xx区分みたいな項目が横並びに何十項目もあるRDBなんて作るんじゃねぇ、とか思う心理と似たようなものなんでしょうか。
そもそもJavaがこんなにdisられるようになったそもそもの理由も知りたい。
教えてLLな人。
分裂勘違い君劇場を、わんさかブックマークする人達というのは何を好きこのんでいるのだろう。浅く、薄っぺ。腹が立つので、ブックマーカーに突っ込みを入れてみよう。ちなみにこのエントリ「日本でしか生きていけないと将来破滅するリスクがあるので世界中どこでも生きていける戦略のご紹介 - 分裂勘違い君劇場」には今現在183のブックマークがついていた。
考えさせられる
そうですか?腹が立つという意味なら同意です。
分裂君の評論能力にはつくづく感心させられるなぁ。
ある意味正しい。きちんとblogの形にまとめてくる能力は評価できますね。でも、なんだかバックグランドとして透けて見える彼の価値観がどうにもよろしくない。プロフィールのところで、逃げを打つあたりも疑問だしネ。
同意。全くその通り。地方のSEにこんな感じのリーダが昔は沢山いた。世間狭すぎる。会社にべったりのスキルを獲得しないで、何をやった気になってるんだろう。大型開発ほど、困難な開発ほど、会社として総力戦になる。自ずと独自製品べったりになる。そんな現場に立ち会っていない。というか、立ち会ったかも知れないが外野として俯瞰していた感じだ。
AJaxが無いのは書き漏らしたのかな。独自製品べったりを嫌うだけあって運用管理ツールは無いな。Apatche, MTが無いあたりは勘定系などのSEなのかと思わせられる。それにしても、「正規表現、TCP/IP」は一般教養だからここに書かない方がいいのでは。iosが無いのはネットはやらない人なんだな。
国家に対しても同じことが言えます。
IT系企業と国家を同列で考えるのはいかがな物か。しかも、文の構成から見てIT企業の考察から類推している(国家破滅の例としてIT企業を出したとは思えない)。
全ての資産を一点がけするのが危険な投資戦略であるように、自分の生活基盤となる国家を一カ所だけに限定してしまうのも、極めて危険な賭なのです。
またも、理由を開示せず類推で話を終えている。投資のポートフォリオをどっかで聞きかじったんだろうが、薄っぺらい。
「1人の異性しか知らず、最初につきあった異性と一生添い遂げなければならない」というのはいかにも古めかしい道徳観念です
古いとしか言っていない。良い悪いの話じゃないのか。古いが悪いのはITだけだよ。価値観なんて人それぞれ、古かろうが主流じゃなかろうが幸福追求に都合が良ければそれでよし。
また、タバコ依存症から抜け出すために、さまざまな方法があるように、日本依存症から抜け出すにも、さまざまな方法があります。
まただ。しかも、今回は「依存症」という単語で一本書こうとした糸口が透けて見える。面白いけど、調査不足。力不足。埋め草が多すぎる。
なぜ、この話題で計算式を出さない。計算してみればあなたの提案がとても難しい物だというのがよく分かるはず。私の資産では年率16％の運用利回りをたたき出さないと生活はできない。平均的な資産運用は5％。企業は年金の運用を2〜5％でやっている。16％の運用ができるなら、日本にいた方がいい。
新しく登場した.NETやC#にしても、過去にマスターしたスキルにほんのちょっと上積みしたぐらいのわずかな薄皮でしかなく、いままで蓄積した基本スキルはそのまま通用します。
仕事は何をやってるんだろう。わずかな薄皮で日々しのげる楽な仕事なんだろうなぁ。スコープも狭いし。
自営業は、あたると凄いんです。
あたらないと書いてるように見えるのだが、気のせいだろうか。
いちいち、けちを付けて申し訳ない。なんだか、今猛烈に反省モードです。しかも、初めて彼の日記を読み切ったのですが、薄っぺらいという感想は変わりませんが好きになったかも(w。愛されるべきSEなんですね。でも、これだと商談取れないぞ。
RDBのプログラムなんだけど、ありがちなこんな二つのテーブルがあるとします。
地方
地方コード 地方名 1 北海道 2 東北 3 関東 4 北陸
地方コード 都道府県コード 都道府県名 1 1 北海道 2 2 青森 2 3 岩手 2 4 宮城
で、このデータをもとに
みたいな出力が欲しい場合って、どうしてますか？
地方テーブルだけを取得するSQLまず投げて、都道府県テーブルを地方コードを条件にしてその地方の数だけ取得するのか
あるいは、二つのテーブルを外部結合して丸ごと取得して、コード値の変化を見ながら出力の内容をコントロールするプログラムを書くのか
どうしてます？
いや、元増田の「分からんから開き直る」という態度はアマチュアでもプロでも害悪でしかないぞ。つーか人としてどうよ。おまけに自分はリスクを取らず増田で無知な人を煽ってるのが卑怯すぎる。
というか、Webでサービスを公開しなくてもプログラミングなんて十分学べる。
今では教科書だって充実している。手元で動かしてみるのも良いし、ソースをブログに貼り付けて反応を待つのも良いし、何でもありだ。ビバインターネット。情報化社会。
むしろ、サービスを公開しなきゃプログラミングじゃないという印象を振りまかれることの方が迷惑。
あとは実際に必要な学習のコストだけど、さっきまでそこで書いてたんだが、
HTMLやシェル(ファイル名)やRDB(SQL)とか、他のプログラミング言語として解釈されそうな文字列をエスケープしてればおkですよ。
これくらいなら、簡単にできるでしょ？一応、高木浩光が言ってることを極限まで簡単にしてみたんだが。
俺の住む世界はアイティーとやらに支えられているらしい。
アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。
そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。
昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。
パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。
楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。
研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。
現場に出て、本番機に触った。
３０年間親会社を支え続ける偉大なシステムの中身を、わくわくしながら覗いた。
そこには、俺の求めていた世界とはまったく違うものが広がっていた。
俺が産まれる前から、入れ替わり立ち替わり何人もの手によって継ぎ足されたロジック。
何千行にもわたって、似たような処理が何回もひたすら繰り返される似たようなモジュール何十本。
1993年に行う臨時処理のロジックが、今もコメントもなしに埋め込まれている。
仕様がわからなくなれば、キャビネへと走って、黄ばんだ方眼紙に鉛筆で書かれた仕様書を探し、
そして修正履歴のみが書かれているのを確認して肩を落とす。
半年後に臨時で行われる業務に対応するため、いくつかのモジュールについて、処理可能なユーザーコードをひとつ、条件に加える。
与えられた期間は２週間だった。ずいぶん長いなと思った。
何枚もの設計書を書いた。つまり、方眼紙状のExcelテンプレートに同じ文章をコピペした。
追っていったモジュールはどれも、ヒープもソートもメモリ管理も論理演算も出番がなかった。
あるのはただ、IF文とMOVE文とばかりだった。ソースの難易度は使われている命令の数とは関係ないことを学んだ。
テストデータを作るため、階層型DBを何回も辿ってデータをアウトプットさせるモジュールを書いた。資格試験で学んだSQLは、無用の知識だった。
協力会社への仕事割り振りやユーザー対応に毎日忙しそうだった上司が、夜遅くまでの残業続きでくまのできた目を皿のようにして設計書をレビューした。
２日後、承認が出た。フェーズが設計から開発に移った。
ロジックを丸々コピペしてソースを修正し、コンパイルし、実行した。
２週間はあっという間だった。
俺のせいで、半年後以降は使われないロジックがソースにまたひとつ増えた。
今回の対応については、Excel方眼紙にレポートをまとめて共有ドライブに入れておいた。
だが共有ドライブの検索には時間がかかるし、Excelシートの中身となれば検索から漏れることも多い。
きっと誰にも読まれないだろう。
２バイト文字が使えない関係上、原則、ソースにはコメントはあまり入れられない。
数年後の新人はきっと、俺の書いたモジュールを見て「このロジックは何だ」と首を捻るんだろう。
数年後の俺はきっと、今回のレポートを共有ドライブから探し回って新人にパスを教えてから、
協力会社の管理に追われる作業に戻って目の下にくまを作るのだろう。
俺がやりたかったシステム開発って、こんなものだったのか。
俺は部署の中で、俺の望む仕事を探し続けた。
先輩たちは忙しくて誰も興味を持ってないけど、自動化できる作業はいくらでもある。
よく使われるExcelシートを改造し、定例作業をクリックだけでできるようにした。
ExcelVBAとはいえ、書いていて心地よかった。引数が明確な関数と変数のスコープと全角文字があったからだ。
COBOLで打つプログラムより、控えめに見て100倍くらいの生産性を発揮できていたと思う。
先輩たちは喜んでくれたが、ただし俺の仕事を、あまり仕事とは見なさなかった。
それでもよかった。業務時間外は俺は相変わらずスクリプトを書いていた。とても楽しかった。
VBAから入って、WSHなんてものを知り、やがてJavaScriptを学び、ネットで資料を探し、はてなを知り、はてブでWeb技術についての記事を読みふけった。
知れば知るほどに、どんどんCOBOLが、メインフレームが嫌いになっていく。
先輩は誇らしげに言う。システムはたいしたことをやっていない。業務知識こそが大事なのだ。
ユーザーより詳しく業務を理解し、適切に提案し、設計する能力。
協力会社を率いて、わかりやすい文書で指示を行い、スケジュールを調整する能力。
人を動かすぶん、責任も大きくやりがいもある。優秀な人材こそが我が社の強みだ。
そんな人材が育つよう、我が社は安定して働ける環境と福利厚生を整えている。
ああ、そうだよ。先輩、あなたは正しい。
俺だってメインフレームの信頼性のすごさはわかってる。
密なユーザーとの関係から生まれるシステム子会社としての強みも認識してる。
それだけじゃない。社内環境も悪くない。給料もいいし休みも取れるし先輩は優しい。
ここは、いい会社だ。
けど駄目なんだ。
３０年前のシステムを枯れた言語でツギハギする仕事じゃ、俺の心はやっぱり満たされない。
ユーザーの業務知識ばかり身につけたって、俺自身の人生には、いいことなんてない。
俺が求めていたのは、この仕事じゃないんだ。
社内の誰も、TumblrもTwitterもやっていない。ライフハックなんて聞いたこともない。
Joostやモバゲーや２ちゃんねるが社会に与える影響について誰も語れない。
休日はゴルフや酒に興じている。自宅にPCを持ってない人までいる。
おかしいことじゃない。普通の人たちだ。
それどころか彼らは、仕事とプライベートを切り分けている、立派な人たちだ。
でも、やっぱり俺の生きていきたい世界は、ここじゃないんだ。
たぶん俺がいるのは極北なんだろう。
ここが、人月計算とExcelとスーツの世界というやつなんだろう。
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。