抽象度をどこまで上げればいいのかということと、オブジェクト指向的アプローチがSIで流行しない理由
以下のブログを読んでみて、自分もポエムを書いてみたくなりました。
プログラムって、機械と人間の両方が読むものなんですよね。ですので、そこには表現の抽象度という概念があります。機械よりのものは抽象度が低いとし、人間よりのものは抽象度が高いとされています。
で、この抽象度というものを、どのレベルに持っていけば、みんなが幸せになれるのでしょうか。
抽象度を極端に下げていくと、機械語とかアセンブリになるんですが、それはあまりにも人間側に都合が悪すぎて生産性が低くなってしまいます。なので、一般的な業務システムなんかはJavaとかで作るのが普通ですね。
これはプログラミング言語レベルの抽象度の話ですが、プログラムの構造自体を工夫して抽象度を上げていこうという考え方もあります。
オブジェクト指向分析設計とか、今流行のドメイン駆動設計がそれにあたります。業務の言葉を使ってプログラムを書いていったり、プログラムの作りを業務のモデルと繋がるようにしようとする考え方ですね。
一般的に、この抽象度というものは高くなればなるほどいいと思われています。たしかに、プログラム自体が実際の業務の構造を表現していた方が、わかりやすいと思います。
しかし、SIの文脈でいうと、これは微妙かなと思うんですよね。どこまでも抽象度を上げていけば、プログラマがハッピーになるかというと、そうでもないような気がします。
だって、そもそもの話ですが、プログラマって業務わかっていないですからね。
SIのプログラマが読む詳細設計書は、完全なシステムの処理ベースで書かれていますし、業務色が完全に抜けてしまっています。要はトランザクションスクリプトです。
その状態でプログラマが、やれドメイン駆動でやるとか言っても、まず、インプットの詳細設計書が抽象度が低すぎちゃって、そこから抽象度を上げる方向に逆翻訳をしなきゃならなりません。
プログラマって、SIプロジェクトの中でも、抽象度が低いレベルの仕事を担当する人たちなので、一概に、抽象度を高めて、かっこいいプログラムを書く方法を教えても、彼らにとって豚に真珠のような気がしてなりません。
オブジェクト指向分析設計が全く流行しなかったのって、このあたりが原因じゃないかと思うんですよね。
まぁ、今は、オブジェクト指向分析設計は完全に死語となってしまって、ドメイン駆動設計の時代ですが、１０年後、それがどういう文脈で語られるものになるのか、すごく興味がありますね。
フリーランス準備のために会社員をやることの是非
ネタにマジレスです。
フリーランスになるための準備として、会社に入ることが有効かどうかということについてです。イケハヤ氏の主張としては、「会社に入っても力つかなくね？」ということみたいですが、まぁこれは完全に煽りでしょう。会社員としてやってても、もちろん力つきます。人それぞれでしょうが。
まぁ、イケハヤ氏は、生き馬の目を抜く世界に入るっぽいので、会社員なんかでぬるぬるやってたのでは、ぜんぜんだめってことなんでしょうねぇ。
それはともあれ、これを踏まえたうえでですが、わたしはやはり、「初めは会社員からがいいと思うよ」ってのが本音ですね。もちろん、SIのエンジニアという文脈に限定した話ですが。
まず、新人研修という制度がおいしすぎます。お金をもらいながら、プロの研修講師に教えてもらえるわけですから。企業向けの研修ってお金かけてますからね。それを業務時間中にお金をもらいながら享受できるってのはすごいことですよね。
あと、未経験の人間が仕事を取るってのはすごく難しいことですが、会社員なら会社が勝手に仕事をくれます。言われたとおりにやっていれば、職歴が自動的に作られていくわけです。これもすごいことです。
新卒でフリーランスでやろうと思ったら結構大変ですからね。営業のカモにされるかもしれませんし、最初はすごくグダグダになりそうです。それをふまえると、ある程度社会人経験を積んでから独立したほうが効率がいいと思います。
ってか、フリーランスであること自体にもこだわらないのが本当にフリーランスだと思いますけどね。どういう雇用形態ではたらくかなんていうのは、結局その場その場で最適なものを選択すればよいのです。
会社員になった方がいいと思うのだったら、会社員になる。それが本当の自由な働き方だと思いますけど。
似たような話は以前のエントリでもしていますが、会社員のほうがコネが作りやすい場合があるんですよね。それを踏まえたうえで、初めからフリーランスでやるか、会社員でスタートすべきなのかは、個人の評価関数で決めればよいと思います。
物差しに自分を合わせるのではなく、物差しを選ぶ。これができるのがフリーランスの強み。
このエントリに激しく同意します。特に以下の部分は全くの同感です。
ITエンジニアと職場の相性
ITエンジニアはプロジェクト、ロール、業種ごとに要求されるスキルが全く異なります。
分かりやすいところでいうと、ネット系の開発会社は開発生産性・コード重視で、SI系は品質・ドキュメント重視とかがありますね。
一方、ITエンジニア側でも得意不得意がありますので、ある分野ではかなり優秀なのに、ちょっとポイントがずれたアサインをされてしまうとお客さんからクレームが来てしまうくらい評価が悪くなってしまうこともあります。
さらに、このスキル面の相性より重要なのが、人間関係の相性です。現場の人間と気が合うかどうかです。
スキル的には優秀なのにあまり評価されていない人はどのプロジェクトにも必ずいますが、大概現場のキーバーソント仲良くなれてないのが原因だったりします。
もっと気軽に職場を変えていい
低い評価をされてしまった場合、どうにか頑張って、現在の職場で評価を上げるということも一つの方法ではあります。しかし、我々フリーランスエンジニアは半年や数年で職場を変えるのが普通です。それを踏まえ、費用対効果の観点から考えると、評価されない現場で疲労するより、職場自体を変えてしまう方が効率の良い対応策だと思います。
現場からは顰蹙を買うかもしれません。特に忙しい時期に人が減るのは困るでしょう。しかし、すでに評価が低いならば、何も恐れることはないのです。だって、これ以上失うものはありませんから。
ここが会社員エンジニアとフリーランスエンジニアの大きな違いです。
会社員エンジニアでは、プロジェクトの評価が、プロジェクトを跨いで持ち越されてしまいます。会社というデータベースがありますからね。何か変なことをやらかすと、「◯◯さんって、あの案件でダメダメだったらしいですよ」という評価がずっと付いて回ってしまう。
一方、フリーランスはその心配がありません。なんなら職場でウンコを漏らしたっていいんです。
というのは冗談です。が、頑張っている割に評価されていないと感じたならば、評価されるプロジェクトへ移った方がいいです。その方が、気持ちよく仕事ができます。せっかくの人生ですから、楽しく仕事したいですよね。
まとめ
世間は様々な物差しで我々を測りますが、我々が物差しに合わせる必要はないのです。むしろ、自分が最も評価される物差しを選ぶことこそが重要なのではないでしょうか。
セブンイレブンバイト罰金問題にみる日本人の狂った労働感覚と、その対処法
セブンイレブン加盟店がやらかしてしまいました。
病欠したアルバイトから、ペナルティーとして罰金を取っていたそうです。
これは完全な労働基準法違反です。
人を雇う立場の人間が労働基準法の基本中の基本を理解していないわけはないと思います。つまり、これは分かったうえでやってるわけで、かなり悪質であると思います。ルールを完全に無視しています。
ところで、本件に限らず、一般的にこの労働基準法というものは、かなり軽視されているものです。
残業代不払いなどの問題はどこの会社でもありますし、最近では電通の問題もありました。
このような、「ルールがあるのに徹底されていない」状態というのは、「ルールがない」状態よりも悪いということは、昔からよく言われていることですが、この現状について、労働基準監督署はどうかんがえているんでしょうかね。ルールを破った人間にはペナルティを与えなければ、ルールの意味がなくなると思うのですが。見せしめのために、このコンビニの店長を百叩きにでもした方がいいのではないでしょうか。
ともあれ、やはり職場の空気が法律や契約よりも重視されてしまう日本人の労働感覚というのは異常であると思います。
ルール軽視の日本の労働環境の中でどう生きていけばよいのでしょうか。世直しをするという手もありますが、それはコストがかかりすぎます。エネルギッシュな人は政治家にでもなって、労働基準法違反は打ち首にでもする法律を作ればいいと思いますが、普通の人にはなかなか難しいです。しかも、何年かかるかわかりませんし。
我々のような一般市民が、このような狂った労働環境の中で、被害を最小限に食い止めるにはどうしたらよいか。それはずばり、組織から適度に距離をとることだと思います。
そして、何らかの間違いでブラックな組織に所属してしまった場合や、所属組織がブラック化した場合、全力で組織から逃げる、これしかないと思います。
私がフリーランスになったのも、「フリーランスは組織から逃げやすい」というメリットがあったからです。よく言われていますが、IT業界はブラックです。このような環境で生き延びるのにはどうしたらよいかを考えた結果、組織との関係が疎結合であるフリーランスこそが最適の働き方であると思いました。
ITエンジニアのスキルはポータビリティが高いです。特にプログラミングスキルは、一度覚えてしまえばどこの現場でも使えます。
つまり、ITエンジニアは、いつ組織と縁を切っても、新たに別な組織とつながりを作るコストが低く、どうにか食いつないでいける可能性が高いのです。
というわけで、日本の狂った労働環境に疑問を抱いている方は、フリーランスエンジニアになったらいいのではないでしょうかね。
商流を制する者はIT業界を制す
労働者の「給与」がどのようなメカニズムで決まるのか、経済学者でない私に迂闊なことは言えないが、少なくとも、プログラマーが作り出す「付加価値」が関係していることは確かだろう。 会社が稼ぎだす全体の付加価値はビジネスモデルであったり、営業力であったり、組織力によって作られる。 プログラミングによって構築されるITシステムがその会社の付加価値にどれほどの影響を与えるのか、というのは、ほとんどの場合、プログラマが決めることはできないし、ましてや最新のフレームワークや保守性の高いシステムを構築したところでそれほど付加価値が増大するわけではない。 プログラマには最低限、現状の組織に合致したITシステムを構築して多少の「効率化」ができればいいとされていて、その「効率化」した分と、労働市場の動向がプログラマの給与を決定していると言える。 そしてそれは、シリコンバレーと比較して惨めになるほど低い。 言い換えれば、日本の企業がシリコンバレーのそれと比較して低い付加価値しか生み出していないということでもある。
プログラマの奇妙な待遇 - megamouthの葬列
ここは完全に同意します。日本のIT業界は工数ビジネスですからね。そもそも、エンジニアの付加価値というものを測る仕組みがありません。
また、以下のエントリでも書きましたが、日本のエンジニアのおおくは量産型ですし、量産型であることを期待されています。
量産型では付加価値を生み出すことができません。また、エンジニアを使う側もエンジニアに量産型であることを期待しているため、付加価値を測定しようなどということを考えません。
これは、IT業界に入ったエンジニアが一番最初に気づくべきところなのではないかと思います。
スキルが上がれば給料が上がるなどという甘い考えは早く捨てなければなりません。現場の同僚エンジニアは貴方がいいコードを書いてくれることを期待しているかもしれませんが、それ以外のステークホルダーは、そんなことはあまり期待していません。客先のデスクに座っておとなしくしていてくれればよいのです。勤怠がよく、問題を起こさなければ十分なのです。
日本のIT業界において、エンジニアが付加価値を産み出すことができない（測定する気がない）以上、分け前も多くもらうには、商流をどうにかするしかないということです。
そうすると結局は、「商流を制する者はIT業界を制す」のです。
中小企業の経営者は自信過剰orサイコパスばかり
自分も同じような経験がありました。一方的に自分の価値観を押し付けてきて、相手がいうことを聞かないと不機嫌になっちゃう人に言い寄られること。
中小企業の経営者ってこういうタイプ多いんですよねー。サイコパシーというかなんというか。
私の場合は、以下のような感じでした。
相手「俺が考えた素晴らしい事業に参画させてやる。フリーの身分で事業に工数をかけてたら飯が食えないだろうから、うちの会社に所属させてやる」
私「いや、会社に入るの嫌なので、フリーのままでいいです。ってか、本業の片手間にやるという約束でしたよね？」
（ってか、会社に所属させてやるって、ずいぶん上からだなw）
相手「１００％の工数フルコミットしろや。それができないなら、お前が金出して人を雇って工数出せ。それじゃ可哀想だから、譲歩として会社に入れてやるっていってるんじゃねーか！」
私「」
というようなやり取りをして、げんなりしたのを覚えています。
フリーランスになってから、上の例以外でも、色々と無理なこと言われて嫌な気持ちになったことはありますね。
まぁ、彼らも必死なんでしょう。必死でやらないとお金稼げませんからね。なりふり構っていられない。
そうすると、結果として、パワーワード生成器になってしまうのでしょうね。周りから見たら完全に自信過剰かサイコパスなんですけどね。
自分はそういう人間にはなりたくないですね。
量産型プログラマの何がいけないのか分からない
完全に乗り遅れましたが、ソニックガーデンの倉貫さんが書いた以下のエントリが話題になっています。
よく聞く主張です。いろんな人から、多分１００回以上聞いてます（だから、今更わざわざ倉貫さんが言わなくてもいいんじゃないかとも思いますが）。
で、私の主張ですが、私はSIという文脈において、アプリプログラマは量産型でいいと思っていますし、量産型プログラマの存在の何がいけないのかよく分かりません。というか、むしろ量産型の皆さんには感謝してるくらいです。
私のお客さんは量産型プログラマ
私は主に大規模SI案件に参画して、「フレームワークチーム」や「アプリ基盤チーム」などと言われるプロジェクト全体の技術支援を行う部署に参画することが多いです。
大規模案件のアプリプログラマは、頭数でそろえられている人たちですので、基本的に技術的にそれほど優秀ではありません。要は量産型プログラマです。
彼らがどうすれば滞りなく実装作業を進めることができるのか、ということを考えるのが私の仕事です。アプリの負担を出来るだけ軽くするアーキテクチャを構築したり、分かりやすーいドキュメントを作ってアーキテクチャを説明したり、初歩的な技術の質問に優しく応えてあげたり、時にはメモリリークを解決してあげたり。
つまり、私は量産型プログラマをおもてなしすることによって、お金をもらっているのです。
ですので、量産型プログラマのみなさんがいなくなってしまうと、私はご飯が食べれなくなってしまうのです。撲滅するなんてとんでもないです。
そもそもSIは量産型プログラマを前提としている
いいんですよ。皆が優秀なプログラマだったら。フレームワークを作る必要もないですし、分かりやすーいガイドラインを書く必要もありません。
個々のプログラマが勝手にやって、ちゃんと動いて、セキュリティ的にも問題なくて、性能要件を満たすシステムを作ってくれるんだったら、それでいいんです。
でも、現実はそうじゃないんです。
馬鹿でかいシステムを数百人、数千人という人員を集めて作っていかなくてはいけない。優秀なプログラマなんてそうそういないですから、量産型を大量に投入するしかない。
そうなると、アーキテクチャやプロセスをきっちりと作って、品質にムラができないようにしなければならないのです。
逆に言えば、優れたアーキテクチャやプロセスで、誰でもある程度のものが作れるようになれば、わざわざ高い単価で優秀な人を入れる必要もないんです。
今のSIはこういうビジネスモデルを目指しているんじゃないですかね。だとすると、量産型を撲滅ってのは、ちょっとピントがずれているような気がします。
まぁ、そのビジネスモデル自体が気に食わないというならば、どうしようもないですがw
まとめ
量産型プログラマがプログラムを量産できるようにするのが、ソフトウェアエンジニアリングです。量産型プログラマが活躍しやすいプロセスとアーキテクチャを構築しよう、という方向で進んだ方が建設的じゃないかと思いますね。
あと、別にSI業界は、プログラミングを舐めてはいないと思いますよ。ただし、アプリプログラマは量産型であると認識されていますし、技術力は期待されていないと思いますけど。
ちなみに、プログラマをちゃんと教育したほうがいいという主張には賛成です。
