フレームワークが巻き起こす人材革命
職人が作るものを誰でも作れるようにする、
誰でも作れるものは自動的に作られる、
そして人がいらなくなる。
JavaやVBで曲がりなりにもフレームを作成し、少しずつ満足するものができつつあります。最近は「新しいSEの構造ができれば」という淡い期待と、「ダイナマイトのように良からぬ結果を招くのでは」という不安を抱きつつ、仕事をしています。
フレームワークはオブジェクト指向の持つ「誰かが一度出来た物を再利用する」だけでなく、コーディングにある程度制約をかけることで初級者でもそれなりの品質が保てる所がやはり強みですね。簡単なシステムならばコーディングで自分の出る幕が無くなる日も近いと寂しさも感じます。
フレームワークによって人員が最適化されれば、人数が減っても仕事を成立させられる人材のニーズは高くなっていくでしょう。 「Java 経験あります」「PM 経験あります」というのが最近流行っているように思えますが、流行しているものだけに身を任せると、えてして近いうちに痛い目を見る。流行に身を任せすぎた人は文字通りそのまま流されていく気がします（すでになっているかもしれません）。
■今後どうなっていくのか（希望的観測）
今、わたしが考えている将来の技術者像としては……
○営業型SE 営業スキル＋マネージメントスキル＋開発スキル
契約、顧客折衝、スケジュール管理と対人コミュニケーションが中心の人材。一般的なPMに契約等の法律絡みの知識を揃え、技術者と会話する技術力も備える。顧客が自らこのポジションとなりケースも出てきて欲しいですね。
○開発向きSE マネージメントスキル＋開発、環境構築スキル(多種)
フレームワークから開発環境、DB等開発全般に渡るスキルを持ち開発をけん引する役割。開発の先頭、最後尾をカバーしつつ、スケジュールやメンバーの管理をこなす。顧客の直下に少数で赴き、システム構築を行えるという点で幅広いスキルがあれば何とか生き残れるのではと考えています。
人数削減が進むほど役割は増えていきますので、「＊＊しかできない」技術者は不利になる一方となっていくでしょう。
○技術特化SE 技術を磨き上げた人
専門的な高い知識は決して不要になることはないでしょう。誰か1人できれば良いということは、誰か1人できなければならないことに他なりません。昨年、キャリアカウンセラーの方とお話をさせていただいたことがありますが、やはり狭き門のようです。
ノウハウが隠蔽されていて、技術に触れる場も技術を振るう場も少なくなって来た今では、険しい道であると感じています。
■今後どうするか
フレームワークは、一度作ってしまえばその先はプロジェクト毎に足りない部分を追加するだけとなり、近いうちに手を離れることになるでしょう。このままオブジェクト指向言語一本でのスキルアップは厳しいと考えています。それでもオブジェクト指向言語はこれからも仕事で扱うので、自己学習では処理速度を意識したバッチ系、特にDB絡みの本を読みあさっています。
■なぜバッチか
個々の実力が反映されやすく、フレームワークのように汎用的な処理が記述しづらいからと言うのが主な理由です。現在Java、VBとUI側の処理を中心に作っているため、バッチ処理を身に付けアプリケーション全体に対する視野を得たいという狙いもあります（わたし自身学生時代に「組み合わせ最適化」の研究をしていたのでバッチ処理には元々興味があるという点もあります）。
これまでの経験から、チームで開発する際に「“知識があるかないか”には天と地ほどの差がある」ということは骨身に染みています。リスクを把握する、作業者の力量を把握する、最悪殿を務める等できずにリーダクラスには上がりたくないですね。
また、より良い経験を積むには、よりレベルの高い人と仕事をするのが一番であり、そのためには相手にとって都合の良い方が良いでしょう。一芸特化よりはバランスが取れているほうがより多くの仕事の機会が得られ、その経験から一芸を磨くのが最短だと思います。
最終的には広くそれなりにこなし、専門分野は深くありたいものです。
■終わりに
いろいろな方がコラムで書かれていますが、「仕事がない」「見つかった仕事は作業的なものが多い」というように、仕事から成長する人は少なくなる一方なのではないかと思います。しかし、求められるレベルは日々高くなっていく。そして、最後には淘汰が始まっていく。
パンドラボックスではありませんが、生き残ればその先に何かある……と信じてやっていくしかありませんね。
コメント
ビガー
ビガーです。こんばんは。
このご時世にデスマーチプロジェクト参画中です。私が絡んだからには絶対にビジネスは成功させます。
と、一見まったくｆorsetiさん(ｆって全角なんですね)のコラム内容と関係ない話なのですが、これから生き残るのは、フレームワーク構築能力でもなく、使いこなす能力でもなく、ましてや上辺のプロジェクト管理能力でもないと考えています。
必要なのは、ビジネスを成功させる能力を持つ者であると思います。
最近、ある人の紹介でピーター・ドラッカーの本を幾つか読んでいるんですが、何て自分と考え方が似ているのだろうと。。びっくり。
以下は、個人的にオススメです。
http://bit.ly/94bO00
forseti
ビガーさんありがとうございます。
f全角で登録されてますね・・・。（全く気づいていませんでしたw）
デスマーチプロジェクトお疲れ様です。
最近は忙しさが極度に偏ってる印象がありますね。
> 必要なのは、ビジネスを成功させる能力を持つ者であると思います。
こちらについては全面的に賛成です。
ドラッカーも本は読んでいませんがビガーさんのコラムのコメントから一度ググって見たことはあります。
しかし、一般的に何か行動を起こして現状を改善する際のメリットとリスク、
放っておいてある程度失敗した方が利益になる立場の方が多い現実を見ると
今の自分には遠い存在に見えてしまいます。
「業界はこうなるべきだ」と言うのはどうも苦手なので、
今の身の回りの現状を如何に軌道修正していくかを考えるようにしています。
がると申します。
少々きつい内容で恐縮なのですが。
> 職人が作るものを誰でも作れるようにする
この時点で、私には「非常に無理がある」ように思われるのですが。
とりあえず上述文脈の「誰でも」とは、どの程度の「誰でも」なのでしょうか？
また、その結果「どの程度までのものが」作れるようになるのでしょうか？
forsetiさんのイメージされているあたりにとても興味がありましたので、一筆。
にゃん太郎
forsetiさん、こんにちは。にゃん太郎です。
> 営業型SE 営業スキル＋マネージメントスキル＋開発スキル
そういや、昔教育の時（だったと思う）に「SEの仕事は半分以上は営業だ」と教わった記憶があります。すでに20年近く前なのでどうしてこう言われたのか細かい事は憶えていませんが、未だに私の頭の中では「SE＝技術＋営業」という図式があります。パソコンが爆発的に普及する前の話なので今とは違うと思いますが。
フレームワークに関しては私のコラムでもいろいろな意見がありましたが、個人的には便利さと見えない怖さが同居していて非常に危うさを感じる時があります。特にWindows上でいろいろなソフトが動いているとそれの影響を受ける時が（おそらく）あるので、お客様の環境で発生する不具合がこちらの環境ではどうやっても再現しない事が多くて最近は辟易しています。
上記のように環境起因の不具合（これもおそらく）もあるので個人的には不具合ともうまく付き合うようにする事が必要だと考えています。（うちの場合はパッケージソフトなので、個々のお客様に対しての対応版は基本的に出さないため）
forseti
がるさんありがとうございます。
> 少々きつい内容で恐縮なのですが
多少きつい方がこちらとしてはうれしい限りです。
それだけ思いのあるコメントであると理解しております。
>> 職人が作るものを誰でも作れるようにする
>この時点で、私には「非常に無理がある」ように思われるのですが。
まず、文章構成上非常に問題があった事をお詫び致します。
職人という単語は極端すぎますね^^;
・「職人が作るもの」
開発をしている現在「プロ」と呼ばれている方々作る
一般的なプログラムを想定しています。
「技術特化SE」で挙げているような方々の作業は想定しておりません。
・「誰でも」
インターン生やアルバイトぐらいをイメージしてます。
理想は「WordやExcelが使えれば誰でも」です。
１から１０まで全て「誰でも」とは考えておりません。
しかし、現状プロを名乗るSEが作るプログラムの中で、
ググった結果をコピペする程度で作れ、
かつ基本的な作りが同じ物は多々存在すると考えております。
私の基本理念としましては、
「自分が淘汰される側に立つ可能性があってもSEはもう少し減らしたい」
「本当に職人が残ってほしい」です。
forseti
にゃん太郎さん、ありがとうございます。
にゃん太郎さんの最近のコラムは全て拝見しております。
どれだけ根元に近い理論を物に出来るか？
フレームワークやパッケージ等で隠ぺいされたロジックは調査が極めて困難ですね。
「隠された部分は見れない」事が利点でもありますが、
このリスクは今もこれからも抱えていく必要があるのではないかと思います。
DBやアプリケーションサーバ等、
コーディングの周りにある知識から徐々に手を広げていきたいです。
> 不具合ともうまく付き合うようにする事
現在バグありシステムに機能追加をしており、辟易しております。
バグの無い物を作る事が如何に大事か思い知らされます・・・。
ビガー
ビガーです。こんばんは。
空気読めないコメントしてすみませんでした。
炎上中につき、だいぶラリってしまっているようです。
>フレームワーク構築能力でもなく、使いこなす能力でもなく、ましてや
>上辺のプロジェクト管理能力でもないと考えています。
このコメントは、無視して下さい。
こういう能力が土台となっている上に
>ビジネスを成功させる能力を持つ者であると思います。
これがくるので、能力のステップアップは重要であると思っています。
ドラッカーの話も自分で考え抜いて行動し終わった後の方が、意味が大きいと思います(私がそう)。ただ、最初から知っているといないのでは、成長のスピードが違うと思われるので、お勧めした次第でした。
失礼しました。
forseti
ビガーさん、本当にお疲れ様です^^;
> 炎上中につき、だいぶラリってしまっているようです。
やはり経験豊富な方でもデスマーチはデスマーチなのですね・・・。
少しでも早く鎮火する事をお祈り致します。
エディタなどに「あああ・・・」と１００文字くらい並べるとチョットしたストレス解消になります。宜しければお試しくださいｗ
> ドラッカーの話も自分で考え抜いて行動し終わった後の方が、意味が大きいと思
> います(私がそう)。ただ、最初から知っているといないのでは、成長のスピード
> が違うと思われるので、お勧めした次第でした。
私も後輩に何か教える時に似たような事を考えていますので、非常に共感できます。私も前者に当たるタイプですので、そう遠くない先にお世話になるだろうと思っています。
思想が先行すると暴走するか現実に押しつぶされるかしそうで恐ろしいです^^;
がる
がるです。
> １から１０まで全て「誰でも」とは考えておりません。
> しかし、現状プロを名乗るSEが作るプログラムの中で、
> ググった結果をコピペする程度で作れ、
> かつ基本的な作りが同じ物は多々存在すると考えております。
なるほど概ね、私とforsetiさんとの見解の乖離部分が見えてきました。
私の見解としては「プロとして作成したプログラム」で「ググった結果をコピペする程度で作れ」るものは、ない、と考えています。
具体的に、なぜ「ないと考えているか」と申し上げますと。
えと…比較的わかりやすいところで例題を上げてみますが。
少々「細かい」話になってしまうのですが。
例えば、PHPという言語において。
「ある特定の文字(delimiter)によって区切られた文字列を分割する」という必要があった、とします。そのために、PHP提供の関数を用います。
が、上述に該当する関数にはexplode、preg_split、splitがあります。
素人やプロもどきはとりあえず放置するとして。
「プロ」と呼ばれる人間であれば、上述のうち「今回は何を要求されていて」「そのために、何が最適であるか」を、状況に応じてチョイスします。
この「今回の要求を理解した上で」「上っ面似ている、しかし中身は異なる複数の選択肢から最適のものを選び」それらを組み合わせるという技能は。
それは「ググった」程度では如何ともしがたいものがあり、それができるからこその「プロ」だと思っております。
また。「基本的な作り」の上っ面は似ているものも多々あるのですが。「その根底にあるお客様のご要求と、お客様のビジネスを前提にした今後の展開」は、それこそ千差万別だと思っております。
現段階での性能を重要視するのか、スケール性を見るのか、今後の機能追加が容易である事が最重要なのか、その他諸々。
上述のあたりを念頭に。
私は「インターン生やアルバイトぐらい」の、「WordやExcelが使えれば誰でも」な方々が「ググった結果をコピペする程度で作れ、かつ基本的な作りが同じ物は多々存在する」とは考えていないです。
で。「職人が作るものを誰でも作れるようにする」については、以前暗喩としてBlogに書き物をした記憶があります( http://d.hatena.ne.jp/gallu/20091220/p1 )。
また、 http://d.hatena.ne.jp/gallu/20100118/p1 でも書いたのですが。
ビジネスには各個、皆様の「固有の状況(コンテキスト)」がありますし、それが加味出来る事はプロとして最低限の前提条件だと思っております。
そうして「フレームワークに沿って定型的なお作法によってものを作成する」のは、せいぜいが中級者～上級者程度までにしかなりえず、従って「お客様のコンテキストに合わせる」という必須の部分が欠落するのではないか、と思っております。
フレームワークしかり言語しかりその他しかり。それらは所詮「お道具」でしかない、と思っているので。
そうして。ストラディバリウスを持っていれば誰もが美しい音を奏でられるわけではないのは、どこの業種にいっても同じなのではないかと思うのです。
「よい道具があればそれでよい」のではなく。道具を使う人間の練度こそが総てを決めるのだと、私は今でもそう考えております。
ちと散漫と見解を書いてしまいましたが。どこか一箇所でも、なにがしか、興味を持って貰えそうなところがあれば幸いです。
forseti
がるさん。レスありがとうございます。
料理のリンクについては以前どこかのコメントに載っていましたね。
拝見した記憶があります。
身の回りの状況を見るに、
「めんつゆで料理する⇒冷凍食品をレンジで温めて並べる」
を目指している傾向が非常に強いのではないかと思います。
「上っ面似ている、しかし中身は異なる複数の選択肢から最適のものを選び」
については、「コーディング規約で制限されているので１つしか選べない」又は「リーダ層が選んだ物を全員が何も言わずに従う」が現実だと思います。
それならば判断する人以外は誰でも良いのではないかと考えています。
顧客の要望も
「職人が良い道具で野菜を切ると１０００円だが、フードプロセッサで切るなら質が落ちるけど６００円で出せる。」
と言われれば後者を選択するのが現実だと思います。
「明らかに安いならば多少目を瞑る。
こだわりの部分だけは少し費用を出すのでこうして欲しい」
この条件下ならばある程度自動で作れるのではないか？と考えた結果今回の記事を書いております。
私はその上で「職人」を目指しており、言っている事とやっていることが矛盾していて悩む事が多いです。
しかし、「その程度ならあそこで６００円で作っている」となれば淘汰が進み、日々努力した人だけが残る（事を切に希望）と考えています。
がる
がるです。
返信有難うございます。またしても散文で恐縮ですが。
> 「上っ面似ている、しかし中身は異なる複数の選択肢から最適のものを選び」
> については、「コーディング規約で制限されているので１つしか選べない」又は「リーダ層が選んだ物を全員が何も言わずに従う」が現実だと思います。
> それならば判断する人以外は誰でも良いのではないかと考えています。
なるほど。確かに上述の状態が、そのように「回っている」のであれば、或いは「きちんと回りうる」のであれば、一つの方法だと思います。
そうして。私は、上述のような状態では「まともにプロジェクトが回らないであろう」と考えております、といいますか、過去に上述のようなプロジェクトも少なからず拝見していますが。「回っている」というにはほど遠い状況です。
そのあたりがおそらく、認識の乖離でしょうか。
> 顧客の要望も
> 「職人が良い道具で野菜を切ると１０００円だが、フードプロセッサで切るなら質が落ちるけど６００円で出せる。」
> と言われれば後者を選択するのが現実だと思います。
これについてはYesだと思います。しかし同時に、クライアントは「暗黙のうちに、よい道具で切った野菜の品質」を求めているのもまた、一つの側面としてあると考えております。
あまり比喩暗喩ですと会話が乖離しますので、直接的な表現をしますと。
「とりあえず動くものが作れりゃいいよ」というのが、大抵のクライアントさんの「表向きの発言」です。
ですので、エンジニアの値段を値切り、質を低下させ、とにかく「安く」仕上げようとします。
管理画面などのスコープを削っていく、なんてのも多い話ですね。
しかし実際には
・スケーラビリティに優れていて
・CPUやメモリを食わない、という点において性能が高く
・例えば会員系サイトであれば、相当量(クライアントの心情的には無限)の登録で普通に満足する性能で動き
・変更修正機能追加がたやすく行える
という要求を「暗黙のうちに」求めてくると、私は感じております。
また「当初は目をつぶる」と行っていたはずのスコープや機能が「それがないとまともに動かないでしょ？」とか「普通そういう機能ってあるでしょ」という単語で「後半になって増える」なんて話もザラですね。
ですので。
私は「動けばいいよ最低限でいいよあとはとにかく安くしてよ」という発言を、全くと言っていいほど信用していないです。
もちろん「契約書でがっちんがっちんに縛って」というやり方もあるのですが、それだと大抵「先につながらない」ので。
先につなげるためにも、ある程度きちんとしたものを出したり。またぶっちゃけ、それ以上に「客を選ぶ」事は、とても大切だと思っています。
そうして、そういうスタンスでお仕事を始めると。
「唯々諾々と手足になってくれる」という類のエンジニアでは。私はとてもではないですが、チームが組めません。
そも「自分一人で完璧な指示」なんて出せる自信ないですし。現場のチームの皆さんに「協力して」もらわないと、よいものなんて作れません。
まぁ。「会社を大きくする」とかいう見地だとよぉわからんのですが。
ニッチに「自分自身がくっていく」くらいなら、なんとでもなるんじゃないかなぁ、と思ってます(笑
forseti
がるさん、お返事ありがとうございます。
> 「普通そういう機能ってあるでしょ」という単語で「後半になって増える」
デスマーチの時に良く聞く言葉ですね^^;
周りで聞こえている事は「下手にコピペで適当に作られるなら作らせない方が品質が高い」です。私は「プログラムを作るプログラム」を一度経験しており、結果違うプロジェクトに移動になった事があります。
今現在それに近いことを今度は作る側になろうとしています。
量産型のプログラムならば「高品質」は望めなくとも工期圧縮で出来た質の低いプログラムよりは良いものになると思います。
技術の買い叩きさえ無ければこのような物は必要無いのでしょうが、会社に所属する身としてはデスマ回避の１つの方法として用意せざるを得ない所が悲しいですね・・・。