電脳土方とエンジニアのボーダーラインを決めるもの
読みまして。
「Railsはプログラミングなんかじゃないよ。Railsだけ勉強していても、本当の意味での開発はできるようにならない」ってことです。
http://sorehito.xyz/rails_is_not_programming/
んで反論的なのも読みまして。えふしんさんのだけど。
それこそRailsみたいなのがなかったらWebサーバ構築 1000万円！などと人件費がかかっちゃって、それだけで息が切れる。そして到達点が下がる。職人さんが得意なのはシステム構築であって、素敵なサービスを作るところではないから。「誰でもできそう」なところを積み上げていくことで、それこそ高度な専門職じゃなくても、もう少し違うスキルを持った人を巻き込むことができる。
もうちょっとビジネス的な視点で言うと、それらを実現するためのコストを下げることが超重要。
Railsを使うことはプログラミングではないのか？という記事について思ったこと | F's Garage
でな。
原理わかんないけどなんか出来ちゃうというものが存在する理由ってのは色々あるんだよね。
- 仕掛けは出来合いでいい。重要なのは提供するものだ
- 大勢を動員しないと到底できない。動員できる人間の質は保証できない
- とにかく早く。プロトタイプ的なものでも良いから
とかね。この視点ってのはほぼほぼビジネス的な視点だよね。
んで。
エンジニアとしてはさ、Railsを使うってことはもう完全に「実装困難な課題を克服しながら新しいテクノロジーを用いたシステムを作る」という仕事ではないって話なのはわかってて、じゃあなんで使うかってそりゃそこに目的があるからだよねって話にしかならない。僕らは職業エンジニアだから、スキルは大前提で目指すは高収益なわけ。Rails使えば問題が解決するんであれば使うし解決しないんであれば使わない。Railsだろうがなんだろうがそれはツールでしかないし、ツールというのは目的に合ったものを選択して使えばいいわけ。
じゃあRailsを選択するのはなんでってのは前に出したとおり。場合によってはフレームワークの設計の一つを学ぶという部分もあるっちゃああるんだろうけど、WebのイロハがわからないとかO/Rマッパーとはなんぞやって人がRailsから何かを学べる前提に立てているかというとそうでもない。教育目的がないのであればこういうお約束でこういう風にコードかけばこういう風に動いてくれるから後よろしくって作業者に振るのが目的だったり、わかっている少数精鋭が単に色んな事を省略したくて別に自分たち自身でサーバーサイドの新しい仕掛けを考えることは今回の仕事はないよねって時に使ったりするわけです。
なので、本当の意味でウェブが出来るエンジニアを目指す人（特に初学者）が学習目的でRailsを使うってのはそもそもRailsの目指すところとは全く噛み合ってないし、かと言ってRails使ったらエンジニアとしての成長がないねなんてことは全然なくてちょっと勘のいい人だったらRailsでものを作りながら仕掛けがなんとかく見えてきて多少の補足に近い勉強をすることでああウェブってこうやって動いているんだな、Railsって何のために使うんだな。もし1から作ったらこういうのがいるんだろうな、ということがわかってくる程度には良く出来ているんじゃないかなって思うんですよ業務で使ったことはないけど。
最初に上げたエントリで「物づくり感がない」と言われているけど、じゃあ物づくりって何よってのが結構重要な問題で、ITって結局作ってるのってサービス（を実現するためのシステム）か（システムを実現するための）仕掛けかのどちらかでしかないんだよね。Railsを使って物づくりしている感がない人は手段と目的が転倒していることがままあるんではなかろうか。ぶっちゃけWebシステムを作る仕事の9割（は言いすぎかもしれないけどサーバーサイド側は特に）は3件となりでも作ってそうなありきたりの仕組みを再生産して「顧客のサービスを実現する」ことをやっているにすぎないよ。そしてそういう状況はいい意味でも悪い意味でもこの世界が電脳土方の世界にまで到達していることを示しているわけ。
じゃあエンジニアとは何かって話になると結局のところ、Railsに限らず、「この部分だけこうやって作ればなんとかなります」じゃなくて、そもそもの全体的な仕組み仕掛けの部分をきちんと把握して、サイジングとかパフォーマンスとかの非機能周りも含めたシステム全体としてどうあるべきかを考えて適正コスト適正スケジュールを考えることが出来る人なんじゃないかと思ったりはしますね。それがRails使っているからできないなんてことは全然なくて、むしろRailsだろうがスクラッチのServletだろうがわからん人（特に勉強しない人）は一生到達しないかもしれない地点だし、そんなん知らなくていいよ俺は顧客と業務要件を切った貼ったすることで生きていくよって人もいれば面倒くさいから一生電脳土方でいいですって人もいれば気がついたらなんとかエバンジェリストって肩書が付いているって人もいるわけで、いずれにしても共通しているのは「現場で何を使っているかなんてことから学べることだけでエンジニアとして成長できると思ったら大間違い」という話です。
みんな勉強しようぜ。
仕事ができない人の取り扱いについて
仕事ができないあなたへ
http://b.hatena.ne.jp/entry/anond.hatelabo.jp/20151101114446
教育ができてないってコメントしている人も結構いるけどこういう事態に直面したことがないのかなあ。それともどんなタマがやってきても俺は教育して一人前に育てることが出来るぜって思っているんだろうかなあ。
というかさ、僕達って教育のプロじゃないわけで、成功体験からしか学べない部分も結構あるわけで、教育のプロがどんなにアレでも取り敢えずの程度までは育てますっていう体制をがっちり引けている会社なんてそうそうあるわけじゃないのでこの増田の直面している問題は手に取るように分かる。
時たま、「こんなの体で覚えるしかないよなー」って思うんだけど、現代社会においてその手の方法はほぼタブーになってきている。で、結果として一部の有能な人材と一部の（かつての社内教育であればもしかしたら歯車程度にはなったかも知れない）使えない人材と、大多数のそこそこの人材で会社は回っていくのだろう。
でも、その使えないラベルを貼られた人たちは今やどうにもこうにもな状態のままでいるしかないのかもしれない。洗脳に近い形で物事を叩き込むことが難しくなりつつある現状で、社会人教育とは何なのか、というのはますます難しくなるのかも。
「基本設計を分担してはいけない」わけねーよという話
こういう話をするときに前提というか設定というかそういうのが雑なままで進めるとさっぱり話のフォーカスが合わない。という話になっている時点で「そりゃ分担したら上手く行かないよな」と思ってしまうわけで、つまりこの話は定量的・定性的な分析ではなくて個人の体験談なんだろうな、と思った次第。
私がとくに不思議に思うのが、基本設計を何人もの要員で分担するやり方だ。DB設計と機能設計と業務設計の担当を分けるとか、サブシステム毎に担当を分けるといった体制がしばしば敷かれる。詳細設計の段階でというのならまだわかるが、基本設計でそれをやってはいけない。
基本設計を分担してはいけない: 設計者の発言
もういきなりわからないのが「何人もの」で、１人じゃないとダメなのか、何人までならいいのかとかそういうどうすべきかの話がわからず、DB設計がインフラの話なのかモデルの話なのかネーミングの話なのかもわからない。え、それ全部一人でやんの？んなわけないよね。出来るとしたら総工数どのくらいのシステムイメージしてんの？業務設計の基本設計とかってそもそも業務要件の落とし込みだよね分担出来んじゃねーの？
なぜか。業務システムにはアーキテクチャ（意図された構造）が求められる。そして、そこに含まれる膨大な定義要素は、統一感や一貫性を保ち、かつMECEな形で切り出されなければいけない。複数の要員で分担などすれば、それらの課題が一挙に難しくなる。
あーこれあれか、アーキテクチャ決めないまま基本設計突入すると死ぬってやつか。知ってるしやったことある（尻拭いを）。でもこれは基本設計を分担してはいけない理由ではなくてアーキテクチャを決めないまま基本設計に突入してはいけないって話でしょ。要はグランドデザインできてねーってことだよね。MECEってなんだよ基本設計かよそれとか。
また、DB構成と機能構成と業務構成は密接に関係しており、相互に矛盾のない形で構造化される必要がある。これらを別々の担当者が扱えばちぐはぐな形にまとまることが避けられない。ようするに手分けして基本設計などすれば、システムは「デッサン」のレベルでたちどころに狂ってしまう。
DB構成？構成って何？インスタンスが複数あるとかクラスタになっているかとかそういう奴？そういうのを基盤領域とか業務共通領域で抽象化して業務本丸には意識させない設計にするとかそういうのが基本設計でありかつ基本設計をする前に決めておくべき全体方針であってそれを決めているから役割分担しても齟齬が生じないとかそういう話じゃないんだっけ。
システムがデッサンのレベルで狂ってしまうとかってアレかデッサンもしないで基本設計してんのか。
とまあずっとこの調子で書いてあることは別にそんなに間違っているとは思わないんだけど、基本設計のレベルで大事なことが決まってないのに役割分担をしてかつ領域間の整合性をとらないという設定そのものが失敗プロジェクトの設定であるし、そうじゃない多くのプロジェクトは文字通り「基本設計を分担して」遂行しているものだ。
エイベックスのJASRAC離脱は業界闘争よりもJASRAC対利用者の問題に発展するか
久々に大きな動きがありましたね。
音楽最大手の一角、エイベックス・グループ・ホールディングスが同協会に任せていた約10万曲の管理を系列会社に移す手続きを始めた。
エイベックスがＪＡＳＲＡＣ離脱 音楽著作権、独占に風穴 ：日本経済新聞
これのポイントはここ。
一方、ＪＡＳＲＡＣは約300万もの楽曲をそろえており、依然として放送局などが音楽を利用しやすくしている。同協会は全国の飲食店やカラオケ店から使用料を徴収する強力な営業基盤も持っており、著作権者にとっても委託を続ける利点がある。
このJASRACによる音楽を利用する営業店からの使用料の徴収は現在ほぼ100%「包括契約」で行われている。これは実際色々な問題を起こしていて、例えば「JASRACに委託していないオリジナル曲」しか使わないと明言したとしても「JASRAC管理の曲」を使って営業できる「可能性」があるだけJASRACがやってきて契約を迫る、という話が合ったりするわけです（ただし有線放送などは例外になっていますが）。ところが、「JASRAC管理以外の曲」が増えてくることによってこの包括契約を迫るロジックがほぼ破綻します。これはとてつもなく大きい問題です。
JASRAC側からすると、個別の曲を例えば飲食店でのライブでどの曲を使っているかを調査するのは高コストだし、飲食店から出してもらう場合に虚偽がないかどうかのチェックが難しいという問題はあるから包括契約にしたいというのは合理性はある。一方でそれは管理側の理屈でしかなく、また権利者に正しく使用料が配分されない（なにせ包括なので誰の曲がどの程度演奏されたか一切把握できない）問題も生まれている。
で、このIT化の世の中で、ある程度省力化する仕組みを生み出すことは出来るだろうというのは再三指摘が合ったはずだけれども、何もしてない。ウェブでの音楽利用についてもっと出来ることがあるはずなんだけどとかね。
業界で競争原理が起きるというのはあくまで権利を委託する（＝使用料をもらう側）の問題であって、これから大きく問題化するのは「エイベックスの楽曲使えないのに包括契約なんて出来るか！！」というロジックが曲を利用する側で成り立ってしまうことですわな。少なくとも今のJASRACの論理に従っていうと、今回の問題はエイベックスの楽曲の市場シェア（これも非常に難しい話だけど）に則って一律契約料を割り引かないと妥当性がなくなるわけなので、JASRACにおかれましては早急にそのような対応をしないかぎり今まで説明してきたロジックが一切合切無になって訴訟の嵐が巻き起こることまで想定すべきかと思ったり思わなかったりします。
追記
ブクマでも既に出ている話ですけれども、
誰も知らない、知られちゃいけない
往々にして、問題というのは隠蔽される。現状の問題を正しく報告する人は煙たがられ、どうせ誰かがギブアップすれば何とかなるよと適当に調子いいことをいう人は重宝される。
ということをどれだけまじめに考えるべきかなんだよな。
あくまでプロのシステム屋として活動するべき人たちは、間違っても「ここは赤字になってもいいから無理難題を飲む」なんてことはしてはならない。もし仮に営業戦略的にそれが可能だったとしても。
「投資として入れます」「勉強されてもらうために入れます」とかそういう理由で過剰に要員を投下することはあるけれども、無理難題を無理難題だということを言わずに飲んでしまうというのは害悪だと思う。なぜなら、それはあなただけの問題ではないから。
「あそこは出来ると言っている。オタクは生産性低いんじゃないの？」いやいやあなたその生産性ってちゃんと見てないでしょ1日48時間くらいになってるでしょそれ的な何かが横行するような現場って、目先の問題を乗り切って後で採算取り戻す行為の中で背任に近いような便宜でも図らないといけないんじゃないのーなんて。
そういう仕事のやり方にならないために、一体何をすればいいのか、常に考えていかないといけないな。
この楽天銀行の対応は流石にダメじゃねーかな
大筋としては正論なんだけど。
ネット銀行経由での詐欺が多発している件で: やまもといちろうBLOG（ブログ）
でもさ、楽天銀行の対応はおかしいと思うよ。犯罪収益移転防止法で口座凍結されちゃうところまではもしかしたら運が悪かったってだけだと思う（としても、楽天銀行ばかり話に上がっているのは楽天銀行の基準が低くて機械的運用をしていることが伺える）。
実際に口座が凍結されることについては銀行もかなり慎重だし、ガイドラインに従って自主的に判断することになっているので逆に言うと楽天銀行だけ（面倒くさいから）厳しくなるってことは十分に考えられる。
銀行で最もコストがかかるのは与信業務だし、正確な与信をするために手間暇かけている（だからそこをソーシャルなアウトソーシングをして担保しようとしているFinTechの一派にビジネスチャンスがあるわけだけど）。そこのコスト削減をするのであれば、「疑わしきは罰する」が簡単なわけですね。
で、そういうところにコストをかけていない＝事が起こった時に割けるリソースが少ないということにも繋がるわけで、普段からバンバン口座凍結していると逆に事務コストが上がるはずなのに上げないでやっていると積み残しがたまっていくって寸法ですね。そうなってんじゃねーの？
銀行がガイドラインに従って自主的に判断している以上、解除できるレベルの念のため凍結に対して顧客クレームが来た時の対応は迅速に出来るはずだし、そうなっていない以上楽天銀行の対応は問題あるとしか言えないなあ。
電脳土方を峻別すべき時代の到来
今更ではあるが、そもそもこのブログにおける技術ネタの一つの軸の話でもあるのでやっぱり言及してみようと思う。
IT業界、特にSIにおける技術者の根本的な問題
多分みんな同じ悩みを抱えていると思うので繰り返し繰り返し書いてきているけれども、僕が社会人になった2000年においてすら、ITの仕事は「是非ITをやりたいから」ではない人材が山程生まれていたし、それから15年経ってIT業界における「Java要員」は単に「StrutsのActionクラスに業務ロジック書けます」でしかなく、HTMLはテンプレートがなければ理解もできず、そもそもWebのステータスコードも知らない。
だからと言って、ベテランコボラーがIT屋としてのベテランであるということもめったにない。今の大半の（いわゆる業務プログラマーとしての）Java要員というのは手厚いフレームワークのもとで業務ロジックを事務的に実装していくだけの、まさにかつてそのように仕事をしていたCOBOLプロジェクトの世界を目指しているだけだ。
今やシステムと言ったら大半はWebだみたいな風潮は業務システム屋において特に顕著であるし、それでいてWebシステムとはなんぞやということを知っている技術者がプロジェクトに何割いるのかという世界であり、答えを言うと平均5%くらいじゃないかという肌感覚があるような問題。
SIっていうのはそういう意味では今も昔も変わらずただ事務的にコードを書く人を量産しているだけだし、ノンプログラミングが推進されるってのも本質的には効率の良さとかには関係なく、コード記述という事務作業を定義書記述に変えただけであり、大抵の場合、製造工程における大半の工数はプログラムではなくテストに費やされている業界においてツールによるブラックボックス化はベンダーロックインと同義であると思うので時代に対して後退であるとすら感じる。
そういう中で、技術者としてどうあるべきか、ということを考えていない人を少しでも考えている人が食わせているという状況であるにもかかわらず、1つの会社の中では製造業におけるヒエラルキーほど格差が出ない構造になっている。それは下請けだとか派遣だとかそういったところにシフトしているのでそれ自体は本質的には健全（役割も責任も違うわけで）なんだけど、実際のところ1階層下の会社というのが単なる人売りの会社でなく、自身がSIerあらんとしているところがこの問題を複雑にしている。ネタとしては単純だけど。
すっごく単純化して言うと、つまりIT業界（SI業界）というのはきちんとした分業ができておらず、会社階層ごとのヒエラルキーがはっきりしない状態のまま、契約としてのヒエラルキーががっつりと多段で存在するというのが大きな問題である。
と言ってもここには一つ大きな問題があって、実際に重機などを扱えなくても建築家として成立しうることとは異なり、システムを作るためのベースの知識・経験というのは最下層の知識も含めた広大な世界のどこをどれだけ把握しているのかに尽きるというところだろう。これは階層が固定できない話でもある。下克上。
ITエンジニアの雇用のあるべき姿とは
というところで本題。このエントリは下記のエントリに対するアンサーとして書いている。
日本のソフトウエア技術者の雇用条件の問題点 | F's Garage
自分は製造業出身なので、大卒、院卒と大卒以外の人たちの新卒事情に、ヒエラルキー的な差があるのは事実として意識しています。
つまり製造業の場合は、設計や開発を行う技術者、と、主にラインでものつくりを行う製造の立場というのがあると思います。大卒は原則、設計、開発や生産管理で、高卒とかだとブルーカラーという立ち位置で給与水準などが違うという現実があるかと思います。
最近まで意識してなかったんですが、それをソフトウエア産業にそのまま適用すると、いわゆるSE職が大卒、生産部隊としてのプログラマ職が大卒以外ということになるみたいですね。
ここで一つポイントなのは設計や「開発」という部分。開発っていうのは製造と等しいのか違うのか。本質的には違うと思う。でも開発ってポジションの定義は少し難しいな。コーダーというのはライン工よりは作業が定型的ではないし、だからコーダーが開発というポジションにオーバーラップすることもよくある。
この事実から読み取れることは、プログラマは時間給によるブルーカラーとして扱われ、職種としては創造的な役割を期待されていないということになります。
完全に分業されていればそのとおりだし、そうあるべきだとも思う。
これはネットベンチャーで働いているとめっちゃ違和感があります。
ネットベンチャーは、指示出ししかできないSEだと持て余します。人の言われたことしかやれないプログラマもそのままでは成長できません。
つまり世の中の採用、育成の方向性が、ネット系の求める人材像にあっていない。
なので、そもそもこの話はちょっと違っていて、「指示出ししかできないSE」という存在自体がIT業界の癌であり悪であるということだし、採用、育成の方向性がそうであるわけでもない。そうじゃなくて、そういう風にしか育たない人間が「SE階層にある会社」にたくさんいるってだけ。と言いたいところだけどやっぱりそれは育成の問題ではあって、なにぶんSE階層にある会社は実際に手を動かしてものを作る機会というのを中途半端に成立しているSIの階層化によって奪われている。どんなに優秀でも現場の経験をきちんと積めない。
というのも実は嘘だ。この業界、少なくともITの仕事を志向していて、ものを作るのが好きな優秀な人材というのはどんな環境においてだって一端の技術者にはなれるはずだ。問題は階層化そのものではない。技術者の成長を拒んているのは本人の志向であったり、現場の無理解であったりというところではある。実際、ここ最近階層が上も下もシステム屋として成立しうる思考・志向を持った若い人材をさっぱり見ない。50人に1人といったところか。
この話のポイントはとりあえず大卒の工学部系出身は、製造業以外だと、なんだかんだ言ってSI系に行く人が多いと思います。それが今の日本のエスタブリッシュだからです。この人達がSEとして、かつプログラマとして、広い世界を作る立場であれば、彼らがネットビジネスをやりたくなった時に、スタートアップやベンチャーは即戦力を得られるので、みんなハッピーです。
ところが、社会に対して真面目であればあるほど、高学歴であったはずのSEがプログラムができないように育てられ、せっかくプログラムを作れるプログラマは主体性に行動しないことを労働契約としてロックインしてしまうのでは、日本のお先は真っ暗です。（さらにこの二者は会社も違うという…人月云々、多重請負云々の本質は、この身分制度ではないのかと…）
というわけで、この話は高学歴でSIベンダーにいった奴らの技術者としての志向の問題で、プログラムができないように育てられているわけではなくて、ただし現場でプログラムをやる環境がイマイチないよっていうことでしかない。それで技術者として体制できないことを教育だけに原因を求めてはいけない。
管理しかできないSEなんてプログラマ以下でしょ。
結局のところ、この問題は一度ヒエラルキー＝どの会社に入るかが決定してしまったらその階層から落ちることがないことが問題なんだと思う。
というわけで、タイトルの話なんだけど、どんな階層の会社であっても「ITエンジニア」としてコミットできていない（事務屋で良しとしてしまう）人材はたくさんいるし、そういう人たちを「プロパー」として養っていかなければならないところにこの業界の凋落が感じられるわけだ。出来る仕事の内容が限られているのに上のヒエラルキーの会社で活動しなければならない人材や、SEとしての視野を持って活動しているのに下のヒエラルキーにいるがゆえにSEとしての活動ができない技術者。このヒエラルキー固定の問題は解決されるべき。だから、労働契約云々という話は間違ってないけれども、人材は流動的だけど会社の立場は固定なんてソリューションは難しい。
僕のイメージ上の絵空事で言うと、上位ヒエラルキーの会社はクズSEをリストラすべきだし、いわゆるPMはどんなにマネジメントスキルがあっても技術がなければ評価すべきではないし、コーダー志向（事務員志向）しかない人材は子会社にでも叩きこむべきだと思う。そこでしっかり席を開けたうえで、下位ヒエラルキーの会社の人が転職できる体制になっているべき。
そうすると、上位ヒエラルキーにいながら個人の志向によりSEとして大成する人間と、叩き上げ技術者がいる会社とコーダーからエンジニアになる修行中の要員と事務レベルのコードしか書けないブルーカラー的技術者が混在する会社に分かれる。結果として人材が育てばふさわしい階層の会社に所属できるように自然とレールが引かれている、というような世の中にでもならないかぎりはこの状況が改善するとは思えない。
もっとも、ここ最近ずっと主張している通り、この巨大SI案件祭りが終わった時に何が起こるかというと、ここでの絵空事に多少近い感じの整理大会が起きるんじゃないかと思う。
