「べき論」は人を縛るだけで良いことがないから辞めよう

べき論というのは「義務を果たすこと、理想を実現しなければならないこと」などを強く主張することだけど、何も生産的な要素がないなぁとつくづく感じました。

べき論で自分の考えが無駄に縛られて精神的な自由さが奪われてしまう。べき論はしないことも同時に規定するので、自ら望んで板挟みになるようなもんだ。「すべき」と「しないべき」の板挟みの果てにできるのは「かくあらねばならない」という強烈な固定観念。強烈なリーダーシップを発揮することもあるが、思考の引き出しが１つしかないので、切羽詰まると正論(**であるべきだ)としか言えなくなってしまう。

べき論は終わりがない。言われたら言われるほど、自分に課されている義務や理想が膨らんで負担が大きくなってしまう。本当はミニトマトぐらいの大きさでしかないのにね。そして、その精神的負担は常に付きまとう。終わりが無いから。何を言ってもべき論で返されたら、これほどめんどくさいものもない。すべきと言っているのは自分がそうして欲しいから言っていることが多い。他人が共感できない自分だけの正しさというのは、非常にヒステリックに映る。

べき論では地に足の着いた議論にならない。置かれている立場が考慮されないので、「もう大丈夫」とも言えないし「こうしよう」とも言えない。よくわからないゴールだけが語られ、話の腰を強烈に折ってしまう。「できてたらやってんだよ」「それがダメだってわかってるよ」という憂鬱な気持ちが出てしまう。色々と「○○すべき」って言われたのに全然出来なくて結果が出なくて自分は...って自分を追い詰めてしまう。心の新陳代謝が出来なくなる。最もアカンやつ。あなたに否があるわけじゃないのに。

べき論では捨てていいものが捨てられなくなる。べき論は万能すぎて、森羅万象に対して○○すべきと言えてしまう。勉強はすべきだし、結婚はすべきだし、風邪は引くべきではないし、ミスはすべきではないし、太るべきではないし、仕事は頑張るべきだし。捨てていいものはいくらでもあるはずなのに、べき論が作り出すステレオタイプな理想に潰されてしまう。

僕は中小にいるので会社全体が見えるから特に感じますが、「こうすべき」「やめるべき」では間違いを正そうとしなくなります。べきだったよね〜よね〜ですよね〜で風化して同じ問題が再燃する。責任の追求をしなくても良いから丸く収まるけど、トップのミスとして認めればすぐに改善できるのに。やっちゃダメなことを決めて、やらないことを決めて、やれることにフォーカスする。そうしないと、異なる立場の人間をまとめて組織力をUPすることが出来ない。

人生は「やる」「やらん」「好き」「嫌い」の４つだけで充分です。今日も一日、適当にやってればよろしいと思います。

スクー(schoo)でエンジニアの経営学という講義をさせて頂きます。

スクー様からご依頼を頂きまして、先日の下記エントリで作成した資料について、講義をさせて戴くことになりました。

エンジニアのための経営学という資料を公開しました - GoTheDistance

エンジニアの経営学

• エンジニアの経営学【前編】 湯本 堅隆 先生 - 無料動画学習｜schoo（スクー）
• エンジニアの経営学【中編】 湯本 堅隆 先生 - 無料動画学習｜schoo（スクー）
• エンジニアの経営学【後編】 湯本 堅隆 先生 - 無料動画学習｜schoo（スクー）

4/15 19:00〜22:00で、３回に分けてお話をさせて頂きます。

あの資料は読み物として仕上げたため、講義となるとかなり行間が空いておりました。それを埋めるためにステップ by ステップでじっくりと話ができたらいいなと思っています。

生放送です。リーチ一発生放送でございます。

どうぞよろしくお願い致します。

【書評】はじめよう！要件定義 -ビギナーからベテランまで

著者の羽生章洋さんより献本御礼。

はじめよう! 要件定義 ~ビギナーからベテランまで

本書の特徴を一言で言うなら、「これ以上に必要なことはないが、足りていないことは何もない」という絶妙なバランス感です。サラッと読める分量にしているのに、各章を良く読み込んでいくと気付かされることが多く、豊かな行間があります。

要件定義というテーマはとても扱いが難しくバランスをとるのが難しいのに、本書は170p弱でまとめあげている。しかも、イラストも結構多い。この分量で大丈夫なのかと勝手に思ったが、最後のほうではDB設計の話も出てくる。データ設計も要件定義の範囲として捉えているのも、実装を重んじる羽生さんらしいアプローチだし、そこまで考えないと要件として不十分だよねっていう。

以下、僕自身の要件定義のアプローチと照らしあわせてながら、重要だと感じたポイントを書いていきます。

要望と要求と要件を分けて考える

11pに書いてあるのですが、皆さんこれちゃんと意識されてます？ これすげー重要な絵ですからね。羽生さんのOK出たので、キャプチャ画像貼ります。

まとめると、こんな感じになります。

要望	システムによって叶えたい思い・未来像
要求	要望を叶えるために必要な能力や成果物
要件	要求を満たすために必要な条件

要件定義が出来ているというのは、この「要望⇔要求⇔要件」が分割統治されていることが大切です。つまり、要件に落としこむまでに然るべき理由がそこに存在しているか、その要件でなければならない理由は語られているか、そういうことをチェックするには分割統治するしかないからです。やりたいことと、やらねばならない理由と、要求を満たすためにやらなあかんことが分けて考えられていないと、要求自体の間違いに気が付かないことになります。

最悪なのは、間違った要望に対する正しい要件や仕様です。間違った前提ほど怖いものはありません。

全てのステークホルダーを明確に

要件定義はそのシステムに関わる「全ての」ステークホルダーの要求を可能な限り実現する必要がありますが、その全体像をこうまとめると簡単だよって絵がありました。これはわかりやすい。

システムを中心とし、ステークホルダーでレベル１を作り、その要望をレベル２として書いているマインドマップ、と言いますか。要求一覧表なんかよりもわかりやすい。そのシステムを使うことで別のステークホルダーの負担が増えたり、何かが犠牲になったりするということが、要件定義の過程で結構あります。大抵それが地雷になりますので、早めに地雷を摘むためにも全てのステークホルダーの要求をキチンと整理しましょう。

システム化対象業務の設計ポイント

全体図だけでは設計に移れませんので、ドリルダウンして実際の作業とシステムの関係を明確にしていく必要があります。羽生さんは「行動シナリオ」の作成を薦めています。業務フローとの厳密な違いは正直良くわからなかったのですが、僕の理解では下記の情報が整理された実際のお仕事の流れをまとめたものです。

• その仕事を行う人(役割)
• その仕事の判断・完了基準
• その仕事の受け渡し先

特に自分の仕事が終わった！と判断できる基準が最も大切。知りたいのは行動を決めるための判断基準。その基準を満たせない場合は例外処理やバリデーション対象になる。要件定義の時点でそこまで見ていく必要があります。また、下記の２つも考慮ポイントです。

• 差し戻される場合はどういう時か
• やり直したい・中止したい場合はどうしているのか

この２つも重要なので考慮して下さい。前者は例外処理やバリデーション、後者はCRUDが発生した場合に仕様として足りていないものがないかを確認できます。バリデーションが通っても次の作業に渡せないってこと、あり得ますからね。キャンセル発生とか。受注取って在庫引き当てたけど訂正入ったんで引当を戻して再度引くとか。

この設計したシナリオを元にユースケースが生まれて要件が見え、要件を満たすための仕様を考えるフェーズに移っていく、と。

システム仕様検討はUIファーストで

僕もこのアプローチに大賛成。まずはUIをスケッチしないと。UIが先、データが次。そのUIからこのデータになるには何の処理が必要だっけってのが、プログラム。それは最後。

UIを作りながら作業に必要なデータを洗い出して構成をまとめ、仕事に必要な情報を定義してまとめていきます。一語多義にご注意を。最終的に、必要なのはレイアウトとアクションと生み出されるデータ。これが定義されていないとシステムの機能が正しいかどうか、ユーザーが判断できない。

レイアウト	UI部品。タブ、コンボボックス、テキストボックス、ボタン、表など。
アクション	クリック、スワイプ、キーダウンetcのUIのイベント。
データ	その画面で最終的に作られる or 表示されるデータ。

どの作業中に何をして欲しいかを明確にして、ユーザーが何を判断してどんな仕事を完了したいかを詰めていくのが良いと思います。これがこう出来ていればあなたのお仕事は完了できますよね〜っていうアプローチ。

UI設計は入力系の画面から。まずは何を入れるかを先に決めないと。マスタメンテじゃなくて、行動シナリオの中で受け渡して流れていく情報を作って保存するための画面のUI設計からはじめて下さい。いきなり帳票設計とかやめてくださいね。インプットが決まらないのに検索項目の話とかしないでね。

UIを決める→データを決める→そのデータを作り出すためのプロセスを決める、という流れで僕はいつも考えています。

要件定義は困難だけど楽しい

読み進めていく内に、僕自身の要件定義のアプローチを再考したことで、書評の半分が「オレはこうやって要件定義を進めている」話になってしまいました。要件定義は困難な作業だってことを改めて思い知らされましたが、楽しい工程です。

要望から最終的にシステムに落とすためにはこれだけのことを考えないといけないってのを最大限コンパクトにまとめてあり、UIもデータも定義していなければエンジニアに実装の依頼が出せないよねって「しっかりと」書いてあるのが誠実で良いと感じました。

エンジニアの方には「この要件定義は出来損ないだ、何も作れねぇよ」と間違った要件定義をガツン！と是正して欲しい。ユーザーの方には、エンジニアがシステムを作るに何が必要なのかを知って欲しい。共通言語がないと善し悪しが伝わらないので。そのために、本書をあたってもらいたいと思います。

はじめよう! 要件定義 ~ビギナーからベテランまで

皆さんのプログラムが最大の効果を発揮するために、良い要件定義が出来ますように。

エンジニアにはお馴染みの「こあくま」のLINEスタンプが発売されました

小悪魔女子大生のサーバエンジニア日記の著者、aicoさんが「こあくま スタンプ」を作られました。こあくまがOK返したり、Forbidden返したり、SSHしたりしてますｗ かわいいです。

coakuma sticker - LINE Creators' Stickers

スクショ(一部)

僕のお気に入りはこれ。カシャカシャターン！のドヤ顔スタンプ！ エンジニアでなくてもブロガーさんでも原稿書いたあとにでも使えますよー「進捗どうですか」のリプライにお使い下さい。直リンごめんなさい。

金額は100円です

買ってあげて下さい。僕には１円にも入らないのでご安心下さい（何を

coakuma sticker - LINE Creators' Stickers

BPStudy#91「Baseball Play Study 2015 NPB開幕直前スペシャル」に登壇します。

2015年3月25日(火)です。空けておいてくださいよー。

たぶん、日本初の野球系IT勉強会です。あくまでIT勉強会なので、プログラミングの話もあります。今年もやってしまいます。佐藤社長の英断に感謝申し上げます。

BPStudy#91 - connpass

皆さんも御存知の通り「BPStudy」といえばIT勉強会の元祖であり、今もなお定期的に実施されている歴史のある勉強会です。今回ばかりは、BeProudをBaseBallProudに見立てまして、野球が好きと自負されている皆さんで盛り上がろうじゃないですか。

今回の僕のテーマは「配球」です。キャッチャーがピッチャーに「これを投げろ」と指示をするアレです。配球はですね、OODAを高速で回しているんですよ。なにせ1球ごとにOODA回してますからね。意図次第で、結果は天国にも地獄にもなる。面白くないですか？

僕は出不精でIT系勉強会に行かないので、折角の機会に色んな方とお話したいと思っております。

では、当日お目にかかれることを楽しみにしています！よろしくお願い致します！

追記

友人よりPDCAではなくOODAのほうが正確というご指摘がありました。全くその通りなので、直しました。

参考

社会人の社会勉強: PDCAとOODAとNCW

エンジニアのための経営学という資料を公開しました

良かったらどうぞ。

僕は２年半前から弊社の経営について口を出し始め、実際に会社を変えたくて行動しました。このままじゃ死ぬとわかったからです。そーゆー話をベースに、エンジニアもサービス作って運用して金を稼ぐ以上、知っておいたほうがええんちゃうかなぁと思うことをまとめました。

詳しい話を聞きたい方はTwitterでもメール(gothesenpai at gmail.com)でも、適当に問い合わせて下さい。

何か１つでも得るものがあることを願います。

エンジニアのための経営学 from Michitaka Yumoto

Software Design 2015年01月号に寄稿しました

Software Design (ソフトウェア デザイン) 2015年 01月号 [雑誌]

先日書いた、永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistanceに端を発した特集記事Part2、ソフトウエア開発の未来というテーマで10ページ寄稿しました。

本特集の見どころ

SI崩壊を乗り切ろうとしている３つの方法と謳っておりますが、立場の違う３人の人間がどうやって今を生きようとしているのかを書いています。

トップバッターは、上述の価値創造契約のマネージャー、木下さん。会社として様々な契約形態を駆使してリスクを極小化しながら堅調にビジネスをしているものの、どういう形態にせよ人月という単位から逃れることが出来ない。労働集約的モデルからの脱却への挑戦の一環で、価値創造契約という新しいスキームに挑戦された一部始終が書かれております。

２番手は、ノーチラス・テクノロジーズの代表である、神林さん。木下さんの流れを受け、「いや、請負型のSIが無くならないから。請負でやるか止めるか、その善し悪しを踏まえてちゃんと考えようよ」という論陣を張って俯瞰的にSIビジネスを解説されています。価値創造契約等も含めた新型のSIについても言及されています。

３番手が、私です。ソフトウェア開発の現場からだいぶ離れた位置にいる私が、ユーザー企業にエンジニアが入る意味やその成果って一体どういうものなのか、開発の現場から離れてもエンジニアとして食っていける場所があるのかどうかとか、そういう話を書いています。ここ３年の集大成といった位置づけの記事です。

自分で仕様を決めてガンガン攻めていこう

ソフトウェアが当たり前になったことで、ソフトウェアを使って仕事をする・会社の業務を変えるということも当たり前になってきていると思うんですが、最も大切な仕様を決定できる人間が圧倒的に足りないように感じます。

簡単に言うと、

「ITで解決したいことがある人 >>>>> 課題解決をITでデザインできる人」

っていう図式です。ITを入手して何かをしたい人は増えても、ITで課題解決を「デザイン」出来る人が全然足りていない。デザインと書いたのは課題解決を行うには実装だけでは不十分なので、要件定義や更に上の事業戦略等にもある程度知見が必要なことがあるので、総合的な視点を踏まえてデザインと書きました。

その根本にあるのは技術の目利きであり、それは最低限のプログラミング経験がないと絶対身に付かない。プログラミングが出来るというスキルをテコにして、色んな所で「越境」していく事例が来年以降は増えたらいいなーと思います。

netgeekのRetty社叩きが下衆の極みなので黙っていられなかった件

事の発端はこの記事ですか。

関係者からすれば個人が特定される情報を散りばめておいて匿名で記事を書いてしまう卑屈さに驚きを隠せません。代表からメール来たけど代表いねぇじゃねえか舐めんなよおおおおおってブチ切れて５分で帰るって超絶微妙ですし、ふつー採用担当者がいるもんなんだけど... リクナビのスカウトメールとか見たこと無いのかな？「代表です！よろぴく！面談で僕と握手！応募してね！」を真に受けちゃうのも微妙。

百歩譲って、期待の裏返しから来る些細なすれ違いからブッチーン！って来るのは誰もあるよね、'`,､('∀`) '`,､ って終わる話なのにって思ってたら、これですよ。はまちちゃんがDISりたい時は直リンはダメって言ってた(PVが発生すると更に拡散する恐れがあるから)ので、googleキャッシュで御覧ください。

この悪質な書き方は一体何なんでしょう... 全く関係のない第三者なのに何様のつもりなんですかね。

何が下衆の極みなのか

上記のキャッシュを見てもらえればわかりますが、僕がカチーンと来たのはこの記述。

株式会社Retty（2010年設立、スタッフ30名、資本金4億5千万円）、法に反しなければ何でもありの精神でけっこうな黒いことをやっているではないか。詳しく調べて叩けば真っ黒な埃がもっと出てきやしないだろうか。

おいおいおい、お前ら何様のつもりなのこれ。スカウトメールの行き違いからRetty社が「法に反しなければなんでもあり」ってなんでそんな話になるの？ それは何の因果関係があるわけ？ 悪質なのは些細なすれ違いをした当事者なのか、全く関係ないけどボロクソに非難した第三者なのか。火を見るより明らかでしょう。

Retty代表の武田さんは(出すまでもない)謝罪文を出して説明責任を真面目に果たしているのにも関わらず、「真っ黒な埃がもっと出てくるぞ」と非難中傷をして不当にRetty社を貶めるのは、場合によっては名誉毀損として訴えられてもおかしくないと思うんですけど。

採用プロセスの些細な行き違いをダシに何の裏付けもない拡大解釈をして、この会社はブラックだ何だと悪魔化するのは下衆の極みです。恥を知りなさい！！！！！！！！

それに不必要に代表者の顔写真をバシバシ貼り付けて晒しあげるっていう書き方も、すごく下衆い。匿名で記事を書いて叩く→バイラルメディアとして拾って拡散というのはお約束ルートなのでしょうか。上記の匿名記事すら自作自演だったのではと... だとしたら、すごいね。

詳しく調べて叩けば真っ黒な埃がもっと出てきそうなのは、いやーどちらなんでしょうか。あのような下衆い記事を鵜呑みにするようなことがあってはならないので、黙っていられなかったというわけです。

ここから余談

僕にはバイラルメディアとネットイナゴの違いがわからないので、検索してみました。「バイラルメディアはゴミじゃねぇ！」とおこでいらっしゃるブログが見つかった。そこにはこう書いてあった。

まずはじめに、「バイラルメディアとは何か」というところから整理したいのですが、僕個人としてはこの定義は簡単だと思っています。

「FacebookやTwitterなどのソーシャルメディアからの流入がトラフィックの中心になっているメディア」

これだけです。記事が画像や動画の引用で構成されているだとか、おもしろ系・感動系のコンテンツが中心みたいな話は関係ありません。

バイラルメディアはゴミじゃねぇんだよ

流入経路が第一優先でコンテンツの質は一切問われない定義に吹いた。ソーシャルメディアでシェアされるコンテンツは公序良俗に反する物、スパムアプリ、デマ情報もたくさんあるし、上記のような非難中傷にまみれたコンテンツも含まれます。僕のブログもFB/Twitterからの流入が中心なので、バイラルメディアと言えちゃいます。勘弁して下さいよ。

「価値があるのに埋もれてしまっているコンテンツを発掘するのにシェアが有効→バイラルメディアは価値を見出しているので、ゴミではない」という理屈らしいのですが、バイラルに伝わるインフラとなっているTwitter/Facebookがすごいだけで、お前らやっぱそれに寄生するだけのネットイナゴじゃね？ 情報ソースの拡散なら、それRetweetでよくね？ 何の付加価値があるの？

良いニュースで良い人生を送りたい読者諸氏におかれましては、下記のサイトの情報をあてにしましょう。その情報が確かであると信ずるに値する実績と信頼。これこそがメディアの価値でございます。

まなめはうす

安心と信頼のまなめオチでございました。

WordPressほど頼りになるCMSはないと思います

この辺りの議論が面白かった。

• WordPressで「ささっと作る」で請けれなくなってる現状。 | バニデザノート
• Re:WordPressで「ささっと作る」で請けれなくなってる現状。 | たけのおしごと
• WordPressを巡る理想と現実、あるいは誤解 | notnil creation weblog

ロリポップのWordPress関係の制限には驚いた

ロリポップでホストしたこと無いんですけど、wp-login.phpに対してIPアドレス制限をさせるたりログイン回数に失敗すると業者サイドでロックするのには驚いた。今すぐにロリポップ捨ててさくらのレンタルサーバ スタンダードを使おう！安くて速くて安心だ！

WordPressはコードを書けばなんでも出来るのが良い

WordPressで作れるサイトは多種多様ですので最近ではWordPressで作りますの内容がピンキリで取扱注意ってのはわかるけど、そこでうまく手綱を捌いていくのが腕の見せどころ。その辺の押し引きはキッチリ線を引きつつ、何にカネがかかるのか、何にお金をかけてもいいのかをバランス取らないとねぇ。時には、現実は少しも甘くないことを伝えるのもプロ。

お問い合わせフォームだけ必要であとはHTMLで放置でOKなら、HTMLをAmazon S3にあげてお問い合わせにGoogleフォームを使えば10円コーポレートサイトの完成。それもまたひとつの形。それに、WPの管理画面ってそんなにとっつきにくいかなぁ・・・投稿と固定ページの違いがわからんとかそんなことじゃないの。

CMSとHTMLの違いは明確にしよう

HTMLとCMSの区別がつかないお客さんは多いんでしょうけど、自分で記事を作成してコンテンツを更新するってことは、それ自体にプログラムが内包されているので「車のように持ってるだけでカネがかかる」という現実をありのままにお伝えしようよ。レンサバと契約する理由にもなるから、ページ規模に関係のない話だと思う。

僕もたけさん(@take_it02)と一緒で「なるべくコストをかけずに自分で更新したい」顧客ばっかりです。でも、乗りっぱなしでメンテ無しでも行けますけど、車って老朽化しますから一種の怖さがあるのはわかりますよねっていう話はしています。

HTMLはファイルでしかないけどPHPはプログラムであり、プログラムには実行環境が必ず必要になる。HTMLを作ることにカネがかかることはみんな理解してくれるんだから、もう１歩それを進めてプログラムを動かすって少しも甘くないわ、と。そこをキッチリ詰めてから管理費等の話をしますので、毎月管理費を払ってくれるお客さんもいれば限りなく放置でいいので管理費無しのお客さんもいます。

コードを書けば書くほど、メンテナンスコスト比例して積み上がっていく。HTMLが自転車だとすれば、WordPressは自動車だ。両者の違いは免許が必要なこと。WPを使う免許は要らないけど、使うには専門性が必要。その違いを誤魔化しちゃいけない。

プラグインは諸刃の剣

プラグインを使えばやりたいことがすぐに手に入るけれども、お客さんからすればプラグイン適用したのか標準機能なのかはどうでもいい。プラグインが提供している機能についての改修依頼が来た場合、みなさんどうされているんでしょう。プラグインがフィルターを用意してくれていない場合は、直接書き換えたこともあった。基本的にはコードを書いて対応しています。

僕は自社サイトをWPで運用してて、その中で取引様専用ページを作っています。そのページの中でお取引様だけに製品のカタログPDF等を配布しており、ファイルのダウンローダープラグインを使ってます。そいつがファイルの情報を登録する時にjson_decodeで日本語ファイル名がエスケープされてしまいダウンロード出来ないとか、レスポンス返す時にUTF8でファイル名がエンコードされるからWindowsで日本語ファイル名が文字化けするというクソみたいな問題にぶち当たりました。この程度で済んでよかったｗ

HTMLだけでいいのってランディングページぐらいじゃないかなぁと思います。会社案内等も修正することもあるし、単なる文字をちょっと更新する度に業者に頼むほうがめんどくさいんじゃないですかね。素人が文章を書くようにHTMLを更新できるっていうメリットは大きい。ペライチじゃない限り、僕は基本的にWordPressを使って構築しています。

これからもワンコインレンサバでWPだ

WordPressはコードを書けばなんでも出来るのがいいし、知れば知るほど面白い。インストールして放置しても最低限のことはできるし、コードが書けてWPのアーキテクチャがわかれば、お客さんの色んな要望に対応できるようになるし頂ける対価にも幅が出てくる。WP案件で食ってるわけじゃないけど、僕にとってはWordPressは頼れる相棒のような存在です。ありがてぇことです。

本日でプログラマの定年を迎えました

SIerをDISってブログを書きはじめ、気がつけばプログラマの定年の歳になってしまいました。まだ実感がわかない。Paiza開発日誌のSIerのDISり方が品がないのでちょっとイラついています。DISられるには充分なネタがあるからしょうがないんだけどね。

10年前は自分はコードを書くことは無いなとか思ってたら、ほぼ毎日しょうもないコードを書いていることにびっくりしている。平凡な誰でも書けるようなもんだけど。解決している問題が平凡だからね、LINEのインフラ作ってるわけじゃないからね。しょうがないね。どうでもいいけど、スーツとギークって完全に死語だね。肩身狭いわ。'`,､('∀`) '`,､

で、最近５年間を見て思うんですけど、これからIT業界(システムインテグレーションの業界という意味)のマーケットの成長は鈍化すると思います。ITの世界って、オーダーメイド(受託開発)、既成品の買い切り(パッケージ)、サブスクリプションの３つしかビジネスモデルがございません。大きく言えば。

上記の３つのビジネスモデルの中で伸びる可能性が高いのはサブスクリプションですが、サブスクリプションが当たり前の世界になると、業界内で食っていける人が減る可能性が滅茶苦茶高いです。なんでかといえば、Webサービスでフリーミアムだイエーイという世界と同じように、業界内競争が熾烈になって共食いが発生するからです。共食いの結果生き残った所がコモディティ化の進行に伴い価格を下げていきますので、生き残れる業者が減ります。

そのような状態で業界全体の成長が加速するかなぁ・・・と。

クラウドが当たり前になることで、クラウドの上でソフトウエアを作ることも当たり前になった。その結果、いかにクラウドの上のサービスを組み合わせて最適解を産むかというビジネスが増えた。今現在、SIで元気のある会社ってそーゆービジネスをやっている所が多いように感じます。AWSのサービスを組み合わせるとか、KintoneみたいにPaaSやるとか。

個人レベルでは、ソフトウエアがコモディティになりましたので、高度なプログラミング技術を求められる案件よりも、普通のアプリやWebを作る案件の方が圧倒的に多くなっていると思います。コモディティになるってことは入手しやすいってことですからね。でも、その普通のアプリやWebを作ることが出来る人を育成できる会社が、どんどん減っているのが気がかりです。IT業界を志す方々の裾野は広くなっていくけれども道は細くなるというか。入学するのは簡単だけど卒業する(進級する)のは難しいというか。素人++みたいな人は３年持たずに消えていくような、そんな世界になりそうです。

コードで回りを動かせたらどこでも食って行けることは間違いないので、コードで回りを動かすために何を実装すれば世界が代わるのか、何を身に付ければ作りたいものが実現できるのかを、愚直に考えて行きたいと思います。僕も。

それでは、また。