【書評】その「エンジニア採用」が不幸を生む

毎度おなじみ技術評論社の傅さんからご恵投頂きました。

その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か?

結論から先に言いますと、僕が今までご恵投頂いたエンジニアのキャリア本で「ベスト」の一冊です。

採用という切り口でエンジニアのキャリアを見つめ直す

本書は「採用」に絞って、エンジニアが企業組織で良いキャリアを築くためには何が必要なのかを問題提起しています。「エンジニアはもっと採用されるように頑張れ」というクソみたいな話じゃなく、採用すると決めた経営陣、それに従う人事担当者、採用されるエンジニア。この3者の立場を俯瞰しつつ採用コンサルティングとして携わってきた筆者が、重厚な論調で痛快に問題点を指摘しています。

エンジニアで生きていくのと、エンジニアを活かす企業組織を作ることは、すごく難しいことはでないか。それが本書の隠れたメッセージのように感じます。

人材紹介会社のビジネスモデルがエンジニアを不幸にする

自社で集めるのが難しいから人材紹介会社を活用するわけですが、向こうも商売です。マッチングゼロだったらお前何やってんのって話になるし、転職しても3ヶ月未満で退職した場合はノーギャラになるケースもあるそうです。技術要素や担当工程が細分化されているエンジニアの事情を鑑みれば、まずマッチするケースが少ない。でこかアンマッチする案件を紹介せざるを得なくなる。その結果、雇用して退職された場合はアンマッチになった理由を検証するのが困難になって、また同じことが繰り返される… そんなことが書いてあります。なかなか、難しい話です。

良いエンジニアを採用できる採用担当者を

不幸なすれ違いを防ぐ為にどうしたらいいか。ド正論は、その企業のエンジニア採用力を上げることです。良いご縁があっても、採用の質が悪ければ意味がない。

エンジニア採用の難しい点は、エンジニアの評価はエンジニアにしか出来ないことにあるのではないでしょうか。数値化出来る要素があまりない上に、経歴ではなく姿勢が問われることが多い。C#の職務経験はないけどAndroidアプリを作れる人だしUnityも慣れたらいけるよね、みたいな判断は素人にはできない。職務経験の向こう側がね、なかなかね。

また、エンジニアはキャリアチェンジをするのが滅茶苦茶難しい。陸に上がった魚は海には戻れない的な。エンジニアを人事にして2〜3年採用業務をやったら、もう開発の現場には戻れない気がします。それを望むエンジニアの方、どれだけいます？ 一般的な人事部門と全く違うあり方が望ましい気がしますし、エンジニアに限らず様々な知的労働者に応用が効きそうです。

ある企業では、エンジニアを採用する時にそのチームのエンジニア全員が採用面接に関わると聴きました。満場一致じゃないとだめらしいです。一歩間違えれば圧迫面接でしょうけど、採用はお互いの真剣勝負と考えている現れですね。

デブサミで「採用」をテーマにしたら面白いかも

次回のデブサミ、どこかのトラックで採用をテーマにしたら面白い気がします。採用で苦労していない組織はないと思うので。取る側がこんなエンジニアがほしいじゃなくて、ウチはこんな人事制度や評価制度でエンジニア像を考えています、という立ち位置で。すでにやっていたらごめんなさい。

技術や工夫を駆使してサービス作った/現場を変えたという話にもう１枚加えるとしたら、キャリアだと思う。エンジニアの祭典で優れた見本市の場として十二分に機能し、エンジニアやってる意味を見つめ直す場にもなっている。同時に、どんな技術を身に着けたら良いかでは語れることに限りがある。社内制度に踏み込んでしまうので「どこまで」という線引きが難しいですが、人事制度まで切り込んで採用に議論する場があれば業界としてプラスに働くように思います。

不幸なすれ違いをなくすために

エンジニア採用が活発になったのは恐らくここ10年のことですから、ITエンジニアのキャリアや採用のあり方にについては黎明期なのかもしれません。試行錯誤が続くと思いますが、現時点でITエンジニアの採用についてまとまって書いてある書籍は本書ぐらいでしょう。自分がどう評価されたいのか、自社の評価軸はどこにおくのか。採用する側は何を気をつけたらいいのか。

本書をあたれば、きっと新しい発見があることでしょう。

その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か?

【書評】はじめよう！プロセス設計

毎度おなじみ技術評論社の細谷氏よりご恵投頂きました。おおきに。

はじめよう! プロセス設計 ~要件定義のその前に

なんでプロセス設計なのか

前作ではじめよう! 要件定義 ~ビギナーからベテランまでという本を書かれた著書の羽生さんが「そもそも材料がないから要件定義なるものができない」という現場が非常に多く、要件定義のその前に考えなくてはならない「プロセス設計」についての本が必要だという考えに至ったと書いてあります。

材料ってそりゃ所属してる会社のビジネスであり自分の仕事じゃないかと思うのですけど、自分の会社が何を商売にしていて、自分達の仕事の意味や課題点を整理して、"こういう仕事に変えていけばいいんじゃない”と落とし込む為の考え方が全く浸透していない。 本書からはそのような問題意識をビンビンに感じました。

ごった煮感が強い

あとがきにも書いてあったのでツッコミますと、本書はごった煮感が強いです。みなさんがプロセス設計に近しい局面にぶち当たった時に役立つ内容が散りばめてある感じで、オムニバスのような仕上がりになっています。プロセス設計のハウツーではなくヒントがたくさんあるので何か1つでも響いてくれたら、という格好。

僕がプロセスを設計する時に考えていること

自分がプロセスを設計する時に考えていることはこの４つです。

• その仕事はどこから来るのか
• 作業を終わらせるために何を判断しているのか
• 終わったら次はどこに行くのか
• 例外(個別対応)はどれぐらいあるのか

この4つを整理すれば概ね問題なく現状を把握できると思っています。あと帳票のチェックも忘れずに。必要だから存在してるので。

で、本書にもありますがToBeを考えるときは逆算で考えます。本書ではバックキャスティングという言葉を使っています。ゴールは追いかけていくもんじゃなく、近づいてくるもの。逆算しないと近づいては来ないです。

企業のITシステムをデザインする難しさ

企業のITシステムを作るのは非常に難しい仕事のはずです。こういう仕事に変えていくとデザインして、それを実現するITをデザインして、実装して提供しなければならない。その工程はひとまとめにして分断させないことが大切です。仕事をデザインしている仕事、かっこいいじゃん。仕事を変えることの大半は仕事の中で流れている情報の流れを変えること。企業のITを作る人はそれを意識しないとね。昔はビジネスアーキテクトとか言ってたよね。素人童貞臭ハンパなくて草不可避です。

マーケットとしては企業のITをデザインするSI領域のほうがWebサービス系の領域よりも全然大きいのだから、プロセスを設計して自社の事業運営にほんとうに必要なものは何かを見定めることがいかに大切なのかってことを、本書を読みながら思いを馳せてほしいなぁと企業のITシステムばっかりやってきた僕は思います。

はじめよう! プロセス設計 ~要件定義のその前に

【書評】エンジニアがフリーランスで年収1000万円になるための稼ぎ方

技術評論社傅さんより恵投頂きました。おおきに。

エンジニアがフリーランスで年収1000万円になるための稼ぎ方

フリーランスで一番大変なのは営業

本書は社員の方がフリーランスを検討し始めたときに最初に読む本、という位置づけです。細かい話は置いといて、フリーランスと正社員はこういう点が違うという抑えから入り、案件のとり方や自分の売り込み方、地雷案件の見抜き方などの実務に入り、最後にフリーランスで長くやっていくためのポイントを紹介しています。

本書に書かれている内容でフリーランスで最もハードだと感じたのが、営業です。僕もまだまだですが、仕事を取ってくるというのは思いの外難しいものです。ほんとにもう。筆者の方は「自分で営業する」「クラウドソーシングを使う」「エージェントに頼る」の3つがあるとおっしゃっており、最終的にエージェント活用に落ち着かれたようです。

自分で営業しても自分のことを知らない人間はまずスルーだし、万が一引っかかっても仕事を出してくれるかは別問題。間に誰も入らないというメリットは、裏返せば請求から回収まで全部自己責任。クラウドソーシングは地雷も競合も多いので骨折り損のくたびれ儲けになりやすく、どうせ手数料等を支払うのならそのお金でキチッとした仕事先と人脈を構築するためにエージェントを活用するのが最も安定していると書かれておりました。

本書の最高のパワーワードは「自分でWebサービス作って儲けようとして1年間無収入で作ったけどゴミしか作れずウン百万溶かした」です。自社サービス開発をやるのは全然ありだと思いますが、順風満帆だとしても開発が終わってリリースして結果が出るまで2年ぐらいかかりますので、その期間どうやって生きていくのかを考えるのが先になると思われます。

安定とは動かないことではなく、動じないことです。フリーランスでも正社員という形態はメリット/デメリットがあるだけで、善し悪しはありません。どちらの立場を選んでもご自分の立ち位置を振り返って動じないのなら、素晴らしいことです。

エージェントでもクラウドソーシングでも、案件の目利きと自分の技術の伝え方は絶対に必要になります。フリーランスは自分で仕事を取ることからスタート。案件の取り方、見極め、そして継続。本書のコアはそこにあります。ご興味がある方はぜひお手にとってご覧ください。

エンジニアがフリーランスで年収1000万円になるための稼ぎ方

余談

フリーランスから更に進むと事業運営を行う組織へと変貌を遂げます。僕自身もそうですが、僕の周りでは「自分の食い扶持は自分でできるけど、目指す未来のために(できればお互いの食い扶持を共に稼ぎつつ)事業運営を行える人との出会い」にぶつかっている方が多いです。グルグル回ると自分の今の仕事すらネガティブになってしまうので良くない。ここを超えると個人事業から会社になれるのかなぁ。

medium.com

プログラミングの学習に最適なWebサービス「CODE写経」

僕が作ったものではありませんが、面白いコンセプトだなぁと思ったので紹介します。(株) レベルエンターの代表、山本さんがおひとりで開発されたサービスです。その名も「CODE写経」です。画像をクリックするとサービスのページにジャンプします。

写経はハードルが高い

プログラムの文法に不慣れな初学者にとって、写経は少しハードルが高い。カッコを付け忘れるとか半角を全角で書くとか変数名をtypoするとか、コピペではない手段でプログラムを書こうとすると色んな罠があります。不注意と言えばそれまでですが、何が不注意だったのかもわからないのは可哀想です。

とにかく動くプログラムを書かないと、学習を先に進めることは出来ない・・・ 

山本さんはプログラミングを教えるお仕事をされているので、間違えずに写経ができるサービスがあればと思ってこちらのサービスを開発されたそうです。

操作動画

youtu.be

Chromeでしか動作確認とっていないので、Chromeでやってみてください。

プログラミングの学習効果の向上を目指す

プログラミングを教えている教育機関や企業を対象に、オリジナルの教材を提供しているとのことです。教材とコードをご用意頂き、レベルエンター社がCODE写経にパブリッシュ。そちらを使ってワークショップや研修などを行えば、より高い学習効果が期待できるというわけです。ログイン不要のでもアカウントもあるので、とりあえず触ってみてはいかがでしょうか？

今後の展開に期待しています。

起業に向いている人の特徴を１つだけあげるとすれば「ストイック」な人

cild.hatenablog.com

この記事に賛同してしまうような人が最も起業に向いていないなぁ...。イケハヤの劣化コピーかと思うぐらい適当なことしか書いていない。

職場の空気すら読めないのにどうやって商談の空気を掴んでいくんだって思うけど、大丈夫かな。自分でやった方が早いと思っちゃう人は、作業と仕事の区別がついてないので起業に向いていない。仕事が目の前にあればあるだけやってしまう人は、自分がボトルネックで取引先に迷惑をかけるし、無駄に消耗戦を戦って安く買い叩かれるので、起業に向いていない。休日にゴロゴロすることも出来ないぐらい逼迫してるなら、やってても楽しくないのでキチッと休めるサラリーマンの方が良い。まだまだ書けるけど、バカらしいや。

こんな調子で書いてしまうとアレなので、僕がこれだけは間違いないなと思う「起業に向いている人の特徴」を１つあげます。ストイックな人です。複合的な言葉になってしまうのですが、要はこんな特徴がある人です。

１つ目は、「自分で決めた目標や基準を、自分の勝手な判断で取り下げない」ことです。今日はこの作業までを終わらせると決めたら、それを明日に持ち込まないこと。割り込みが入ろうが関係ない。サービス残業も関係ない。自分がそこまでやると決めたら、完璧でもなくてもいいからまず終わらせる。区切りをつけて前に進む。

僕もそうですけど零細企業の社長は雑用も多くなるので、仕掛りの作業って増える一方。起業したら割り込みもサービス残業もない。代わりはいない。終わらせないと積み重ねることも出来ない。ここで脱落する人、すごく多いと思います。請けたけど納品バックレなんてよくある話なので。

2つ目は、「これが今のベストなのかと、常に問う姿勢があること」です。そこには2つの側面があって、ひとつは自分たちの仕事のやり方はこれでいいのかという点と、もう一つはこの顧客に納品する成果物はこれがベストなのかという点です。仕事のやり方に課題がないなんてことはあり得ないし、(色々すっとばすけど)これが出来たらベストっていうのが見定められないと迷走します。

もう１つの顧客の観点で言えば「お客さんがこういったから」という鵜呑みにしているのがマズいです。お客さんが欲しいからこういうのを提案 or 納品しますでは、バカの一つ覚えにしかならない。要望と要件は違います。僕のようなIT系は不定形な成果物を商品にしているので、特にそれを感じます。ベストを考えていくと、より鮮明に成果物の内容が見えてくる。やる意味が無いから辞めようと良い意味で撤退することも出来ます。仕事は選ぶものです。

3つ目は「一人の時間を持て余さないでいられること」です。僕も修行中ですが、起業したらどれだけ自分を見直すことが出来るかがすごく大切だと感じています。自分の判断や価値観によって、事業を行う方向性が大きく左右されるからです。なので、ひとりの時間をじっくりと考え事に当てて考え続ける必要があります。とても憂鬱な行いですけれど。

社長になっちゃたら、上手くいかないことは自分に原因を求めるしか無くなります。あいつが悪いとか取引先がクソとか時代が悪いとか言っても、どうしようもない。事業が立ち上がらない/回らない理由を外に求めても、各々の立場があるので自分には合わせてくれません。自分たちが変わるしかない。だから会社は倒産するわけですので。前職では、毎月のように管財人の弁護士からFAXが会社に来ていたなぁ。

魚は頭から腐ります。頭から腐らないように、瞑想と運動と野菜を摂取して心身をヘルシーに保つ必要があると著名な先生は口を酸っぱくして警鐘を鳴らしております。

おあとでよろしいようで。

【書評】虹を待つ彼女 〜AIが織り成す心の螺旋階段を駆け下りていくミステリー〜

友人が横溝正史ミステリ大賞を受賞されまして、その処女作を読了したので感想を書きます。ネタバレしないから大丈夫です。

虹を待つ彼女

twitter.com

あらすじ

舞台は渋谷のスクランブル交差点から始まります。カルト的人気を博した女性ゲームクリエイター水科晴は重度の病に侵されていました。その彼女が選んだ最期は、自身が作り上げたオンラインゲームの標的となること。ゲームに登場したゾンビは、水科晴自身。ゲーマーの操作するドローンは本当の銃を詰んだ渋谷のスクランブル交差点の上を飛んでいるドローン。そして、彼女は銃撃されて死を遂げます。

ソフトウエアのプログラマーである工藤は、「フリクト」という人工知能のサービスを開発者。人工知能という制御できないプログラムをプログラムすることに技術者として面白さを感じていたが、フリクト自身は完成されており(色んな理由で)ユーザーが少しづつ離れていった。そんな時、人工知能の別の可能性として「死者を人工知能として蘇らせる」というプロジェクトの発足が決定する。その試作品の対象に選ばれたのは、水科晴。

工藤は水科晴の人工知能を完成させるべく、水科晴の調査を開始する。彼女が衝撃的な死を選んだ理由、断片的なエピソード、開発したゲーム、彼女を知る人物。それらを追っていく中で晴への渇望を抑えきれなくなる工藤の前に「晴の調査を辞めないと殺す」という脅迫者が現れ…

こんな感じのあらすじです。

人工知能の社会性

このミステリーを読む中で考えたのは「人工知能の持つ可能性と社会性」でした。死者を人工知能で蘇らせるというアイデアは近未来的にあり得ますし、短期的には恋愛シミュレーションも作ることが出来る。自律する学習回路があるコンピュータの持つ可能性の大きさと、その可能性が諸刃の剣にならないための社会性。社会のインフラとなり得るために守らなくてはならない制約と言うか秩序というか、そういうものをどう設計したら良いのか。そういったことを頭に巡らせながら読むとより一層楽しめます。

工藤と晴

この二人の思いが交錯する所が本書の面白い所なので多くは語れませんが、うまいなあと思ったのは展開はミステリアスなんですよ。進み方はとてもミステリアス。でも、エポックとなっている出来事は、じわっと感情が揺さぶられる。このバランス感覚が、次へ次へという期待を胸に読み進める力となっているように思います。僕は第一部だけで読んで、ちょっと置いてから一気読みしましたが、ラストの展開は完全に外しました！

虹を待つ彼女

カバーにも書いてあるんですが、この小説には「雨」という人物が登場します。水科”晴”と”雨”です。そして、タイトルには「虹」を待っている人物がいます。晴と雨と虹。僕が一番ぐっときたのは、この3者の関係性でした。皆さんも、晴と雨、そしてそれらが織り成す虹という自然現象の意味を頭に巡らせながら、ラストまで読み進めて欲しいです。完成度の高さに舌を巻くと思いますから。

ミステリー小説なんて西村京太郎しか読んだことがなく、森博嗣ですら完全スルーした僕ですが、ストーリーが良く練れていて面白かったです。この書評を30分で一気に書きあげることが出来ました。ミステリー小説に縁がない方も、是非お手にとってご覧頂けたら。

虹を待つ彼女

仕事の大半はルーチンワークで、楽しいのはごく一部だよ。

休学して起業すれば良かったのに。大卒という看板は一生自分についてくる。片道切符を掴む必要はなかったよね...。済んだことからしょうがないけど。

www.ishidanohanashi.com

レールの乗った人生というのが何を指しているかわからないけど、お仕事はルーチンワークというレールの上を進まねばならない。あなたが憧れている方も滅茶苦茶レールの上を歩いている。社長でもフリーランスでも会社員でもアルバイトでも、みんなに言えることですが、「仕事で楽しいのはごく一部で、大半はルーチンワーク」です。同じことを繰り返すのが仕事の大半。何かを継続することは、同じことを繰り返すこと。仕事を変えたいと思って行動しても、帰結する先はルーチンワークなんですよ。なので、こいつを楽しめなかったら無茶苦茶消耗します。

新卒フリーランスという謎の言葉が一時期バズってた。限りなくニートに近いけど言い方がファンキー。その親玉っぽい方はキャンピングカー生活をされているそうだが、今頃「楽しいことはごく一部」だと痛感しているかもしれない。ブログを書き続けるというルーチンワークから逃れられない。サロン運営もルーチンワーク。フリーランスとして時間を自由に使える所がマブしく見えるかもしれないけど、みんな会社員より働いている。ルーチンワークが会社員よりすごく増えるし、仕事を成立させて入金まで管理するのも大変だし。

ブログを書いて稼げます！というのは能力ではあるけど、職能ではない。「ブログを書く」を麻雀やパチンコに置換するとわかりやすいでしょう。職能は大きく言えば社会の問題解決に役立つ能力であって、それは事業運営をしている組織に属さないとまず身につかない。パチンコで稼げてもその能力を会社の事業に活かせない。なので雇う理由もおカネを払う理由も無い。僕はこんなことが出来るのに何故活用させてくれないんだわからないんだと消耗すると、高知への片道切符をつかんでしまうよ。(察し

仕事で成果を上げている人って、その大半のルーチンワークを陳腐化していないというか、必ず新しい変化や挑戦をどこかで盛り込んでいるように見える。そこがごく一部の楽しい部分のひとつ。プロは同じことを何度も繰り返して正解を常に生み出せるからプロなんだけど、その正解の質はどんどん変わらないと嘘なわけ。奥行きだったり密度だったり、色々さ。

どういう立場で仕事をするかは人それぞれだけど、ルーチンワークで多かれ少なかれ消耗します。起業したら会社員よりさらに消耗するポイントが増えます。そこで不貞腐れず続けて行こう。楽しいことが必ず見つかるはずだから。

「独習Python入門」というプログラミング本を出版します

「独習Python入門――1日でプログラミングに強くなる！」というPythonでプログラミングを学べる入門書を出版します。皆さんご存知の小悪魔女子大生(現在はOL)サーバーエンジニア日記を書かれていた、aicoさんにイラストを頂戴しました。

8月5日、販売開始です。

8月5日、販売開始です。

大切なことでございますので、2回述べさせて頂きました。Amazonで予約受付を開始しています。詳しい目次や電子版の案内等があるので、版元の技評さんのサイトを貼っておきます。

gihyo.jp
Amazonはこちらです。

独習Python入門――1日でプログラミングに強くなる!

画像がまだ反映されない...

本書を執筆したきっかけ

身内にプログラミングを教えてほしいと頼まれて、適当に入門書を買って読み合わせながらやっていたのですが、どうもうまく説明できませんでした。そのギャップを埋めるように補足資料を作っていたら段々面白くなっちゃって、結構な分量に。「ここまで来たら本にしたい」という欲が出たので、技評さんに持ち込んだら会議に通して頂いて書籍にすることができた、という経緯です。

本書の執筆で特に気をつけたこと

本書を書くにあたっては様々なプログラミングの入門書に目を通し、何人かのプログラミング未経験者にレビューを頂きました。また、実際にドラフト原稿でプログラミングを教えて実践形式でレビューを行っています。

スクリーンショットを細かく取る

サンプルプログラムを書籍に記載して「はい、実行してください」の一文で終わってしまうと、そこで脱落される方が相当おられるようです。その為、サンプルプログラムを実行する手順で迷わないことを最重要課題におき、スクリーンショットを細かく取っています。

本を1日で読み上げる人はそんなにいません。1章だけ読んで2章を読むのが2週間ぶり、なんてこともあるはずです。ブランクがあろうが書いてあるプログラムは確実に実行できないとまずいので、プログラムを実行する箇所には全てスクリーンショットを入れました。

また、初学者の最大の難関である「動かない理由が、エラーメッセージから判断ができない問題」についても細かく説明を入れています。

なぞるだけの本にしない

手順に沿ってやれば本に書いてある通りに出来たけど、用語や作業内容については説明が足りていないので「出来たけど、出来るようになった気がしない」という事態にはしたくなかった。

結論としては、こまめに練習問題を入れて徐々に高度な事ができるような形にするのが良いだろう、と思いまして、そういう形式にしました。

解説にメリハリをつける

メリハリとは、考えなくちゃいけない所とそうでない所を明確にしていることを意味します。「じっくり考えてほしい」と「そういうもんなんで頭の片隅に置いといて」というニュアンスを、可能な限りきっちり分けています。考えてもしょうがない所で悩み始めるとドツボにはまりますから、それを防ぐ狙いです。

最低限必要な文法を知って勉強して頂き、コードで書かれている内容をひとつのストーリーとして言葉で説明できないと、自分のやりたいことをプログラムに落とせません。場数がモノを言う所ですが、自分のやりたいことをプログラムで表現するのがプログラミングなので、表現するための手法や考え方をイメージできるよう腐心しています。

よろしくお願い致します！

著者がここまで細かく書籍の背景を書くことはあまりない気がしますが、背景が伝われば読者の理解を助ける一助になると感じたので、頑張って書きました。

電子版も出ます。技術評論社様の電子書籍の販売サイトではDRMフリーのPDFとEPUBが、そして大正義AmazonからはKindle本。準備にお時間が掛かりますので、今しばらくお待ち下さいませ。

8月5日、販売開始です。どうぞよろしくお願い致します。

gihyo.jp

独習Python入門――1日でプログラミングに強くなる!

株式会社 クオリティスタートを設立致しました

5末で前職のエフ・ケーコーポレーションを退職しました。で、会社作りました。6/1に登記申請を行い受理されてから口座開設と税務署への届出等の細かな手続きがございまして、法人としてスタートするのに１ヶ月かかりました。

quality-start.in

StaticPressで作ってS3でホストしてます。WP管理するのがめんどくさくなってしまった。お問い合わせフォームはTayoriというサービスを使っています。

以下、独立に至るまでの経緯を書きましたので、よろしければお付き合い下さい。

独立に至るまでに考えたこと

昨年の今頃から退職は頭にありましたが、次に何をしようと思った時に「これ」というのが浮かなばかった。とりあえず、人に会おう。その中で考えよう。そんな感じで色んな方とランチをご一緒させて頂きながら近況報告をしつつ何をすべきか考えました。

僕がひとりで内製していたこともあり、「業務のわかるエンジニアがいない」という話が特にひっかかりました。

ユーザー企業に対して届けるべき価値は「プログラムをより良く書くこと」ではなく「事業運営に必要なITを提供すること」です。中小企業向けのITシステムは大企業向けの機能縮小版でOK…なんてことはあり得ません。業務の独自性は中小企業のほうが強いのではないかとすら感じます。自社オリジナルの業務を支援する IT を強く求められる傾向があります。

大手は人手でパッケージの隙間を埋められます。中小企業は運用でカバーする(新たに人を雇用する)余裕がありません。ITシステムをわざわざ作ってお金をかけて効率を良くするのに運用の手間がかかるから人を増やせって何事？っていう。

ユーザー企業にエンジニアとして参画する以上、自社オリジナルの業務を支援するITを提供できないと価値が生まれない。でもスクラッチ開発は時間もかかるしリスクが高いしお金もかかる。昨今ではKintoneに代表される「オリジナルのITシステムを可能な限り自動生成を駆使して作ることが出来る仕組み」があります。この辺のサービスをどう活用すればユーザー企業に対する顧問エンジニアをビジネスに出来るのか。

自分がそれをやることで食えるのかどうか確かめてみたいと思いながらもイケるという手応えがなかったので、二の足を踏んでいました。

ルート42株式会社 さんとの出会い

「オリジナルのITシステムを可能な限り自動生成を駆使して作ることが出来る仕組み」でSIやればいいじゃんという内容でブログを書いたら、ルート42株式会社の高橋さんから「ウチはまさしくそれでSIやってます」という連絡を頂きました。え？いるのそんなひと？というのが正直な感想でした。

お話をお伺いしてデモを拝見した所、スクラッチで作ったら億クラスの複雑な業務システムが動いてる。案件をこなして自動生成の仕組みをブラッシュアップしていくうちにここまで来ました、と。

興味があるならウチの仕事をお手伝いして頂けませんかというお話を頂いたので、やりまーすと回答してスタートしたのが昨年12月。お手伝いをしているうちに「これはすごい。新しいSIビジネスが出来る。」という確信が芽生えた。協業させて頂くことで自分のテーマであるユーザー企業の顧問エンジニアに挑戦する素地ができるし、SIは好きなのでやれるだけやっていきたい。色んな仕事ができる道が開けたので独立する決心がつきました。

SIはどんどん自動化されていく

この流れが加速することはあっても、退化することはない。AWSがインフラの構築から始まりそれらを統合的に管理できるプラットフォームへ進化しました。ビジネスアプリケーションの領域も侵食されていくと睨んでいます。

企業が最大限にIT活用をするためには、自分の袖にあったITがベスト。その袖に合わせる作業が大変なわけですが、大変なままであってもいけないと思います。困難な作業ですが、PaaSサービスもこれからもっと進化していくはず。弥◯会計がAWSで動いてそれをlambdaで操作できる時代にならんかな。AWSがlambdaの更に上のレイヤーに行ってPaaSのサービス作るかもしれないし。

先日ブログで「これからは事業会社をIT会社に変革していくのがSIerのミッション」と書きました。

gothedistance.hatenadiary.jp

まずはひとりからのスタートですがこのミッションをクリアできるよう頑張ります。

今後とも、よろしくお願い致します。よろしければ、弊社のWebサイトをご高覧下さい。

quality-start.in

事業会社をIT会社に転生させることが、これからのSIerのミッション

言いたいことがストレートに伝わる良い文章だと思います。

simplearchitect.hatenablog.com

ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。

では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。

確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？

僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエアを作ることがゴールになっている以上、スコープを破綻させることはできない。納期決まってるし、とにかく終わらせないと。検収して頂かないと請求できない。 完成することが基準で対価を頂戴しているわけですから。

ここを無視して方法論の是非の議論を重ねても、意味無いでしょ。ここに切り込んで一括請負じゃなくてエンジニアと二人三脚でアジャイルだよねって実際にやっているのって、倉貫さんぐらいじゃないでしょうか。他に続いた人を知りません。それほどに難しい問いだという理解をしています。

一括請負でギチギチにやるのはお互い不幸なのはよくわかる。それをやる体力もなければ、積んだ工数の金額を出しても通用しない。なので、SIerがそのやり方をみんな辞めたと仮定しよう。請負しないんだから、委任になります。顧客のIT部門に入り込んでその立場で仕事をするのが、主流となる。仮想的な内製部隊として機能していく。こうなりますわな。

嫌なこと言いますけど、上流と下流が分断しているのがSI業界の最もあかん所でかつそれが主流なので、一括請負辞めたら外注管理しか出来ない会社と下請け仕事しか出来ない会社が出来上がって誰得だよねってことになりませんかね？ そんな心配は杞憂ですかね。僕はかなり心配なんですが。

「ウチは一切の請負はしなくて、業務委託でイケてるエンジニアを貸し出します。御社の事業にコミットして、モノも作れますから。毎月XX円お支払ください。」と言われて「なるほど、確かにそれがベストだね！アジャイルにやろう！」 ってなるのかなぁ。 顧客はそれについてこれるのか。 全ての舵取りを顧客に委ねるのが正しいのか。どう説明してご理解を頂くのかイメージが湧かないけど、それしか無いならしょうがないのかな。

これからは事業会社もIT会社になる時代であって欲しい。そうなれと思う。ITを武器にして競争優位を勝ち取って頂けるなら本当に喜ばしい。でも、その為の受け皿にヒビが入りまくっているのではないか。事業会社をIT会社へ変革する為に、SIerとしてできることはなんなのか。それをやるのがSIerじゃないなら、誰になるのか。担い手が変わるのであれば、どう寄り添っていけば良いのか。

こういう議論の先にあるのが、SIの未来ではないのでしょうか。

「事業会社をIT会社に転生させるのが、これからのSIerのミッションだ」という前提に立った議論をしたいので、今後はその目線で記事を書いていきたいと思っております。