読者です 読者をやめる 読者になる 読者になる

UXエンジニアになりたい人のブログ

転職活動はじめてすぐやめた

現代の業務SI開発はフレームワークの奴隷なのではないか説

主張/考え

http://www.flickr.com/photos/94852245@N00/2141693607

photo by seier+seier

まあ奴隷は言い過ぎか。使われてるって感じ?

以下の文面は、アーキテクト兼実務者として、業務SIとかパッケージ部品とかの、7,8人くらいの小規模プロジェクトをふらふらしているひとの視点(言語は主にJavaだけどまあなんでもやる)であることを加味してお読みいただけると幸いです*1

 

最近のわたくしの話

最近、どんな開発/コーディングしてますか?

わたしは、実務者としての作業は、フレームワークの調査ばかりしてるような気がします。問題があったら、何時間かかけてフレームワークを調べて、べたべたなテストコードで動作を確認して、最終的にはすごく短いコードを書く、的な。80%位のコードは惰性でだらだら書いて、20%のコードを書くために80%の時間を使う、的な。

重い不具合はフレームワークの深いところのバグや脆弱性やパフォーマンス不足や不都合で、それを無理矢理直すためにどうするかをまた時間をかけて調べる、みたいな。いわゆるヤク刈りばかりやってるイメージがあります。

結局完成する成果物は、ほとんどフレームワークに任せつつの、ちょびっとずつ謎のロジックが意図を示すコメントと共に入る、みたいなコード。

 

アーキテクトとしての作業も、業務固有の要件や制約を加味してO/RマッパとDIコンテナとwebフレームワークを決めて、業務固有の課題の解決方針を考えたりプロトタイプしたりして、あとはお作法とその他方針を共有する、的な仕事。

結局のところ出来上がる成果物は「フレームワークの使い方」が主。

 

複数人での開発であることや、自分たち以外の誰かが保守や拡張をする可能性を考えると、フレームワークのような共通認識があったほうが効率もいいし間違いも起こりにくいし、もちろんバグも減るので、業務としてはまあ間違った状態にはなってないのかなと思います。

ていうかぶっちゃけフレームワークのおかげでだいぶ助かってます。

 

 

システムに求められる要件とフレームワークの高度化の関係

「現代の」というたいそうな枕詞を使ってますが、システムに求められる基本要件は今も昔もほとんど変わってないと思います。

  1. データの整合性一貫性を確保すること
  2. 効率的かつ保守拡張性に優れたロジックを構築すること
  3. ユーザーに機能と実施可能な操作を認知させるUIを提供すること

まあこんなかんじ。どこになにをあてはめるか、なにでどこを担保するか。それだけ。開発者はこれらの複雑さを解決して管理共有する手段を探し求めていると。

ここから先は想像も入るんだけど、おそらく最初にフレームワークっぽくなったのは、DBMSなんじゃないかな。DBMSが1を確保するための「機能」を製品に取り込むようになって*2、DBMSの理屈とお作法に則れば、システムの複雑さのいくばくかは軽減されるという流れになったのかと。

今40代後半から50歳くらいの元エンジニアは、これにかなり影響を受けたのか、論理データモデルの設計と、そのDBMSへの適用にすごくこだわりがある人が多い事からもそれが伺える*3

 

2については永らく方法論が乱立したり、局所的なフレームワークで生産性向上させてたイメージがあるけど、ブレイクスルーはrailsあたりにあるのではないかと感じる。web系でいうと、jQueryか。

それまでのフレームワーク(struts1とかprototypeとか)はあくまで道具で、その使い道を考える頭が本体だった。でも、ここのあたりからフレームワークが「高度化」して、フレームワークの方が本体で、それを使う頭は従属項になった気がする。言語とかライブラリとか設計理論とかは、複雑性を低減させるけど、それを使いこなす頭が必要。でも高度化されたフレームワークは頭がいらない*4という。

このへんのフレームワークから「プログラマじゃなくても扱える」なんて話がでるようになったし、コードもすごくシンプルになったように思える。

 

今も昔もシステムへの要件は変わらない、と書いたけど、ひとつ違いがあるとすれば、変化の早い時代になって、2については効率よりも保守拡張性が強く求められる様になったことかな。

ソフトウェア産業の規模も携わる人も増えて、とんがった創造性よりも「均質性」が求められるようになったことも合わせて、高度なフレームワークが次々誕生するようになってるんじゃないかなと思う。

 

違和感

CSの世界では、あるレイヤーが下のレイヤーの複雑性を抽象化するってことは昔から行われていた。言語だってネットワークだってそうだ。高度化したフレームワークであってもその基本は変わらない。

でも、たとえばC++やjavaのような高級言語を使ってシステムを作ったとして、そのシステム開発者はC++の奴隷であるか、なんて議論は起こらないだろう。システムの価値はそのシステム内のロジック(アルゴリズム)にあるし、それを創りだした「頭」にあるのは明らかだからだ。

でも現代のフレームワークはどうだろう?フレームワークの“使い方”を考えた「頭」が価値なのか?本体はフレームワークなんじゃないか、って。そういう違和感を感じてしまうのです。

 

自分の仕事の価値がなくなった、的な話とは違うかな。フレームワークが発達しようがしまいが業務の複雑性に起因する問題は発生するし、その問題の解決は難しいし、それが解決できたときは満足感もあるし。けど、なんか種類が変わってる気がするんですよ。

最も重要な資質が「考えられること」から「知っていること」に変わってきてるような。ものづくり屋じゃなくて、組み立て屋になっているような。メーカーじゃなくて、商社になってるような。石を掘って彫刻をつくる仕事ではなくて、掘ってある彫刻を砂の中から探し出す仕事のような。職人ではなくて、工場のライン管理者になったような。

実際、実務においても、うんうん考えて解決案を出したあと、それを実現するフレームワークを探すってよりは、“詳しいやつ”が「それ、あのフレームワークのあの機能で実現したらどうです?」なんてきっかけを与えるほうが多くなってる気がする。

 

必要があって変わってるわけだし、それで実際に恩恵も受けてるし、効率も品質も上がってるし、昔に戻りたいというわけでもないんだけど、一言で言うと「楽だけどつまんなくなってる」んですよね。

うまくつたわったかな?

 

この話については、いろんな反応が予想されそうで、自分のなかでもいくつか反論(下記)が出ていて面白そうなので、投げかけてみることにしました。

  • 自分のコンテキストではそんなことないよ
  • いまに始まったことじゃなくて昔からそうだよ
  • お前がフレームワークで収まるようなしょぼい仕事してるだけだろ
  • 勉強=知っていることを増やすなんて当たり前だろ
  • ていうかシステム・クリエーションじゃなくてシステム・インテグレーションなんだから今の状態の方が正解だ
  • 業務SIなんて業務の奴隷だ
  • etc,etc...

お暇な方は(できれば現在のご自分の立場とともに)コメントいただければ幸いです

 

補足

上のエントリでもコード書きの仕事あんまりしたくないってかいてますが、能力的な問題はさておき、つまんないってのが大きいんですよね。

フレームワークとか今後どんどん高度化して、10年後にはSIerなんて死滅して設定屋になるんじゃないのと危惧してたりもします*5。実際コーディングってどんどん簡単になってますからね。

UXエンジニアになりたいっていうのも、システムに求められる要件3に書いた「ユーザーに機能と実施可能な操作を認知させるUIを提供すること」だけはまだ「頭」が主だと思うからなんですよね。

 

さて、最後に「そんなに創造的な仕事がしたいならフレームワーク作る側に回ればいいだろ」という当然のツッコミに対して小声で、注釈を用いるという斬新な方法で回答しておきますw*6

*1:要するに、コンテキストが狭いのでごめんなさいと言いたい

*2:というかDBMS自体が1とか2の一部を担保するために頭のいい人が考えた概念ぽいけど

*3:どうでもいいけど、この手法を絶対的な概念と捉えているか、ひとつの解決案として捉えているかで開発者としての質が判断できると思う

*4:いやいるけどね。全然いるけどね。種類が違うってことね

*5:DSLだっけ。あの辺でブレイクスルーが起こればあるいは。だいたいビジネスのことをよく知らないのにビジネスロジックを書く専門の職業とか、本質で考えれば意味不明だし

*6:たしかに、フレームワーク作成者は、ここで言う「創造的な」仕事なんだろうと思います。でも、、、、

無理や。

現代のフレームワークは、天才と呼ばれる人が、深い思慮のもとに情熱を注いで、状況の変化や利用者からのフィードバックなどを受けて適宜修正を加えながら、淘汰をくぐり抜けて「今の座」を得たものばかり。そんなものを作るなんて、無理!無理!

それにもう、社内一の技術屋が作った自社製フレームワーク、みたいのはおなかいっぱいなのです。こういうの、なんども見てきましたが、まともなものは一つもありませんでした。実務者としては、こんなの使わなければ何倍も生産性があがるのに、という代物ばかり。なんの思慮も配慮もなく限定的な状況にだけしか対応できない、“憧れてる”フレームワークの劣化コピーがほとんど。自分の能力を過信してこういうのをつくる人間にだけはなってはいけないな、と戒めておるのです。