« トップ10デッドコンピュータスキル | メイン | [Trac][SVN] Trac+SVNな環境構築。 »

キャリアの方向と技術選択

暫くご無沙汰しておりました、岡部です。暑中お見舞い申し上げます。 連日真夏日やら猛暑日やらで、 ようやく夏が来たものの、亜熱帯に変化しているような厳しい暑さですね。 食欲がなくても良く食べよく眠って乗り切りましょう。 あぁそれと水分補給も忘れずに。

今回は少し遠くを見渡す話です。

技術者のキャリアパスは(特に日本の多くの場合では)限られているのは事実であると思います。 私自身は「創ってナンボ役立ってナンボ」ですから、希望を言えばかなり特殊なきゃアリアパスに ならざるを得ませんが、現実に実践実行していける中期目標を想像しながら悪戦苦闘しています。

話を膨らませすぎると収拾がつかないので、技術者の技術選択が(マネジメント等ではなく) 技術的なキャリアパスに影響するという視点から、 更に絞った話題としてプログラミング言語にスポットを当ててみようと思います。

一口に言語といってもピンからキリまで、 その言語の高級度*1の 幅があると思います。 上は皆さんもよく知っているような数種類の言語と「マクロ」類、下は手書きのCとか(++も無しね^^;) アセンブラといった感じでしょうか。シェルプログラミングとかPC-98のROM-BASICなんかはどの変になるでしょうね・・・

キャリア選択は十人十色千差万別と思いますが、 上記の流れで私ならどうだろうか、考えてみます。

私は各論の上で、工程の最初から最後まで例えば基幹業務システムの受注であれば、 受注のところから相手を観察してその語の話題作りをし、要求を整理し、アーキテクチャの選別と設計、 UI設計、システムの設計、アジャイルコーディングとテスト、導入準備と顧客教育、 試験作動と顧客側担当者の理解度向上、本番作動、トラブル対応、 時間と共に変化する要求へのアジャイル対応、etc.全工程をある程度は理解し手伝いに参加できる状態を 維持するように心がけています。

そうすると、時間も労力も限られているので、全体的に浅い能力と経験 ということになりますから、主力たる技術の選択が必要になってきます。 *2

私の場合であれば、カードは・・・
ハードウェア・ハードプラットフォーム
PC自作・サーバ構築・ネットワークアーキテクト及び管理運用
ソフトウェアプラットフォーム
OS
Windows3.1からXPまで(ME除く/残念ながらNT時代のはちょっと不足)、 MS-DOS5~、RedHatLinux7.3~(+Fedora)
OS設定類のカスタマイズ
ネットワーク・DB関連
PostgreSQL、Oracle、BIND、qmail、他多数の(特にネットワーク関連の) フリーないしはオープンソースの方々
言語
C(C++)(LSIC/Borland/Turbo/GCC)、VisualC++(6)
(N88)BASIC、Windows用BASICエミュレータ、VisualBasic++(6)
Java(新人研修で独習Javaを内職してました^^;) エクリプス環境と最近のバージョンも使えないこともないということが、 とある弊社の開発案件で判りましたが、ちょっと厳しいかな? それ以前に仕事でJavaは一度も触れていませんでしたから。 *3
シェルスクリプト(Win-DOS、/bin/sh)
駆使できると快感^^; *4
Perl、PHP
キリがないので省略(ぇ
まぁどんな言語でもリファレンスさえあれば慣れだけですし、 暫く使っていない言語も然りですし。 自分の側の問題は各言語ではなくて根底を 理解してるかどうかだけのことと思います。
規模・スタイル
一人から数十人まで。
ガチガチのウォーターフォールからアジャイルまで。 「パターン」などは知らずに使っていたことを後から気付いたり。
基幹業務システム開発のテクニカルアドバイザーから、 ちょっとしたツールの作成(VBでシビアな通信とサービス化なんかもやりました) やデータ加工バッチまで。
WebもHTML(これはDTDも原文で読みました/未だに手書き)、JavaScript、 Flash*5・ 更には画像やアイコンの調達または作成まで。
偏屈な分、付き合いにくいと相手が思うかも?(^^;

棚卸はたまには良いですが、晒してしまうとさすがに恥ずかしいですね。

しかし私は今のところ、手持ちのカードから次のような主力を構想しています。
  • Perl5を中心とした軽量なアジャイル手法。
    Perl5の選択:CUI・CGI(・そして実はGUIや音も!)
    軽量なスクリプト言語の中で、 メジャー且つ 安定していることから。
    数年前の話なので正しくはないかもしれませんが、 PHP(Ver4後半)は高機能新機能の為に多くの安定性を欠いていました。 なにしろマイナーバージョンがちょっと挙がるだけで関数の仕様すら簡単に 変更(修正)されてしまうので、ベンダーツリーを用意して、都度マージを しなくてはいけないということを経験しています。その頃は日本のPHPユーザ 及び開発陣のMLを常時気にしながら、解説を加えたり要望を出したりしていました。
    しかしそんな監視を開発中ずっと気にかけているなんて可笑しいでしょう? たった1ヶ月の開発だとしても(その後の運用も考えますが)、 とても軽量とはいえなくなります。言語は軽量でも開発者には重量です。
    Perl5はほぼどんなところでも存在していて すぐに動作させてみることが出来ます。 (既存サーバへのインストールや設定の変更が出来ない顧客も結構います。) シェルスクリプトも同様ですし、そして併用しますが。
    枯れている技術は重要な使用上の変更が加えられてしまうリスクも小さなものです。
  • Windowsアプリケーションを作成する手立て
    やっぱり一つは欲しいですね、自作方法を。
    どうやったとしてもWindowsが駆逐されるということは、 今のところ考えられないでしょう。
    私の過去経験から導かれる「楽な」方法は、 VB6+VC++6のDLL+他のDLL+WindowsAPI (場合によってはアプリケーションサーバとシンクライアントの組み合わせ(仮想含む))。
    しかし今後を見据えた場合、 やはり.NETを選択する必要性が強まるでしょう。 顧客のイメージ等も鑑みなくてはなりませんし、 また、実際には旧来のVer6世代でも大抵は困りはしなくても、 いざ乗り換えるとした時には多分大きな仕様変更があるでしょうから、 予め手は用意しておいたほうが良いと考えています。
  • モデリング・アドバイザー(コンサル含む)(長期計画^^;)

プログラマ」が窮屈な今の日本に在っても、 一度立ち止まって、深呼吸し、棚卸と戦略練りをしてみては如何でしょうか?

戦術を練ったり実戦に出るのは、それからでも遅くはないし、十分な準備が出来るでしょう。 自分と競合他社の強み弱みを書き出して議論する方法があったと思いますが、そういうことです。

ちなみに、上記の狙い目の構成例で私がJavaにもRubyにも触れなかったのにも、 ちゃんと理由があります。Javaはいくらでも技術者が居るので、 必要な時に使えれば十分(「必要な時に必要なだけ」)。 Rubyは誕生した頃から頭の隅に置いていましたが、当時は学生で 空き時間や内職中にCやらCMMやらを読むのに忙しく、 結局未だに触ったことがないからです。 また、最近はRoRで既に盛り上がってますから、 こちらも必要なときに必要なだけ用意することにしようと考えています。

要するに、私のキャリアプランはユーティリティ性や適応力や応用力を 関連する全ての分野で最低ラインを維持しながら、 代えの効かない仕事を狙う、といったところでしょうか。

私事の晒しになってしまいましたが、如何でしたでしょうか。 キャリアプランをふと考えてみたり、 技術者が深呼吸できる時間になってくれれば嬉しい限りです。

*1
低級言語とか高級言語と呼ぶのはちょっと気に入らないですね。 せめて下層上層とか。。。
*2
幅広い知識と経験はユーティリティに優れ、広い視野を与えてくれる、一つの解だとは思います。
*3
仕事らしい仕事でJavaに全く触れずに来たものの、社会人1年目の最初の仕事が Web上でPDFを作成するようなソリューションの比較評価だったので、 当時のApache+Javaでサーブレットを作って見た事は在ります。(新人研修時の内職正解(^^;)
弊社入社時にはCUIのJava(まるでCの移植^^;)で課題を提出しましたし、一応。
*4
シェルスクリプトだけで、昔ならCでガリガリ欠かなくてはならないような一連のシステムを 作った実績があります。
*5
特に見栄えの方ではなく、例えば綺麗なUIコンポーネントが一枚のHTMLに個別に存在しても連動して動くなど、 オブジェクティブでコンポーネントなHTTPリッチクライアントを提供できると踏んで実験したことがあります。 それなりの成果は在りましたが、Flashが使える人はデザイナで、プログラム書く人は興味を向けないなど、 即投入できる環境がなかったので、それ以来保留したままですが。 (JavaScriptの駆使でかなりのことが出来ますしね・・・)
岡部 太一
テクニカルデプト システムエンジニア

トラックバック

このエントリーのトラックバックURL:
http://pw.tech-arts.co.jp/cgi-bin/tamt32/mt-tb.cgi/60

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)