『完全SIer脱出マニュアル』の著者が考えた、エンジニアがSIerを去る3つの理由
こんにちは、『完全SIer脱出マニュアル』著者のgamiと申します。
僕は新卒で入社した富士通を1.5年で退職し、当時40名くらいのスタートアップ企業にエンジニアとして転職しました。 富士通のときは「仕事つまんねー」と絶望していましたが、転職してから「心から楽しいと思える仕事」の存在を知りました。 そのときの経験から「楽しく働く人をもっと増やしたい」という思いで、ポッドキャスト配信や勉強会登壇をしてきました。
そして、2019年6月に『完全SIer脱出マニュアル』という不穏なタイトルの商業書籍を執筆させていただきました。 僕にとってこの本を書くことは、これまでの活動の集大成となるものでした。
発売から9ヶ月が経ち、この本に対する反応も落ち着いてきました。 また僕の心の中でも「SIerの仕事つまらんと思っているエンジニアに対して、楽しく働けるように支援する」というテーマに一区切りがつきました。
タイトルは釣りで、この記事にはもうちょっと広く次のような疑問に答える内容が書かれています。
- なぜ『完全SIer脱出マニュアル』なんて刺されそうな本書いたの？
- なぜエンジニアはSIerを去るのか？
- 『完全SIer脱出マニュアル』への反響は？
- 商業出版ってぶっちゃけ儲かるの？
- これから取り組みたい、エンジニアリングにまつわる本質的な課題とは？
これは、『完全SIer脱出マニュアル』の出版経緯や反響について紹介しつつ、これまでの活動や考えをまとめるための記事です。
なぜ『完全SIer脱出マニュアル』なんて刺されそうな本書いたの？
『完全SIer脱出マニュアル』を書いた理由を一言でいうと、「かつての自分のようにSIerにいて仕事つまらんと思っている人に対して、楽しく働くための選択肢を示す」ためです。
自分自身のSIer転職
僕は2015年新卒で富士通という大手ITベンダーに入社しています。 文系大学生だった僕は、もともと公務員志望でした。 なんとなく、「替えの効かない行政のITシステムをより良いものにすることで、多くの人がハッピーになるのでは？」という漠然とした仮説がありました。 その後、めでたく公務員試験に落ちた僕は、「行政システムを作っているIT企業にSEとして入れば、結局は希望に近い仕事ができるのでは？」と思って富士通にSEとして入社しました。
富士通では自治体向けのパッケージ開発チームに配属されました。 まともにプログラミングをしたことがなかった僕は、研修や現場で実際にプログラムを書くことに楽しさを感じていました。 しかし一方で、SIer特有の身分社会、Excel仕様書の印刷納品、手動テストとExcelスクショ、などにモヤモヤしていました。
色々あって外の世界の「モダンなソフトウェア開発」を知った僕は、「私のソフトウェア開発古すぎ？」と絶望しました。 入社した当時から一生を富士通に捧げる気はそんなに無く、「数年くらい働いて、イマドキのITの知識を付けてから身の振り方を考えよう」と思っていました。 しかし、「ここで学べるソフトウェア開発は、現代のスタンダードではない」ということを知り、だんだんと「もっと早く辞めないと人生もったいないかもなー」という考えに変わっていきます。
転職活動を始めた当初は、「自分程度の人間が、モダンな開発現場でスキルも身に付けながら働くなんて本当にできるんだろうか？」と不安に思っていました。 しかし、運よく2社から内定が出て、その中の1社に転職しました。
今でも働いているその会社は、当時40人くらいのスタートアップで、SaaSプロダクトを開発している会社でした。 スタートアップらしく課題だらけでしたが、優秀なメンバーが「本質的に価値ある事業やプロダクトとは何か？」、「それをつくるために自分がやるべきことは何か？」を常に考えていることに衝撃を受けました。 社会課題に直結する会社のミッションがあって、そのための事業があって、事業にプラスになることをとにかく考えて実行する。 その「不純物の少ない仕事」が、僕にとっては新鮮でとても楽しいものでした。 そこではじめて、富士通での仕事が「本質的な価値提供のためのアプローチとしてとても不純物が多い」ことに気付かされました。
多くの人が同じことで悩んでいる
ひょんなことから、同じくスタートアップに転職した新卒時代の同期と、ポッドキャスト配信を始めることになりました。 僕たちにしか話せないことを話そうということで、番組タイトルの正式名称を「SIerのSEからWEB系エンジニアに転職したんだが楽しくて仕方がないラジオ」（略して「しがないラジオ」）と決めました。 最初はパーソナルティ2人だけで話しているポッドキャストでしたが、次第にリスナー数が増え、そこから番組にゲストを呼べるようになりました。
SIerから転職したエンジニアを中心にゲスト収録を続けていると、あることに気付きました。 それは、「SIer界隈のエンジニアの悩みや転職の経緯などがあまりにも似通っている」ということでした。 これまで僕は、自分自身の富士通時代の悩みや転職活動のプロセスを、自分に特有のものだと漠然と考えていました。 しかし、出会ったSIer界隈出身者の多くが、「本質的な価値につながらない仕事の多さ」や「非効率な開発プロセス」に辟易し、転職を決意し、より楽しく働ける環境に移っていました。 SIer界隈で働くリスナーからの反響の多さも、多くの人が同じことに悩んでいることを裏付けていました。
それに気付いてから、ポッドキャスト収録でSIer界隈出身者がゲストに来るときは「この人の話の中で、どこがリスナーと共通の悩みか？その解消のために再現性のあるプロセスは何か？」ということをひたすら考えながら話を引き出すようになりました。
同人誌版『完全SIer脱出マニュアル』
その頃、Twitterではエンジニアの知り合いがやたらと「技術書典」の話をしていました。 聞くところによると、「技術書典」はアウトプット意欲の高いエンジニアが集まって技術同人誌を頒布するお祭りのようでした。 興味が湧いたので2018年4月に開催された技術書典4に一般参加してみました。 知り合いの本を買ったりして楽しみましたが、「やっぱりサークル参加しないと面白くないな」と感じました。
そこで次回の技術書典5では、ポッドキャストの相方と一緒に、ノリと勢いでサークル申し込みをしました。 申し込んだ時点では何を書くか決めていませんでしたが、「まあ書くとしたら、これまでの活動の一大テーマであるSIer転職系かなー」と決めました。 このブログ記事でもわかるように、僕は「せっかくアウトプットするなら釣りタイトルでもいいから多くの人に興味を持ってもらいたい」という考え方をしがちです。 執筆していたSIer転職系同人誌についても、『完全自殺マニュアル』にかけて、『完全SIer脱出マニュアル』という激しいタイトルを付けました。 ただし内容については、SIer界隈で仕事に悩んでいる人のモヤモヤを吹き払うような具体的な情報を、これでもかとぶち込みました。 自分自身の経験を根幹に据えつつ、ポッドキャストを通じて知り合ったたくさんのSIer出身者の体験談を元に肉付けしていきました。
技術書典5当日、在庫を抱えて帰ることを覚悟して印刷した200部の『完全SIer脱出マニュアル』は、たった1時間で完売しました。 当日の様子は、このブログ記事に興奮気味に綴られています。
この1時間は、本の執筆やこれまでの「しがないラジオ」の配信で苦労したことがすべて報われていくような、ものすごい多幸感に包まれていました。 脳内物質がドバドバ出てきて、正直泣きそうでした。 生きてて良かった。
紙版の在庫が切れたあとも、同人誌『完全SIer脱出マニュアル』はPDF版をダウンロード販売していました。 2018年10月から2019年6月までの9ヶ月で、合計1,841部を売り上げました。 インターネット上でも好意的なTweetや書評ブログが散見され、『完全SIer脱出マニュアル』というアウトプットが想像以上に評価されたことを実感しました。
『完全SIer脱出マニュアル』商業出版へ
2018年12月、多くの技術系商業書籍を執筆している知り合いから、突然Twitter DMが来ました。 「お世話になってる出版社が著者を募集してるらしいんで、プッシュしときました！」という内容でした。 そのDMに対する僕の返信は、（今では完全に忘れてましたが）次の通りでした。
プッシュしていただいてありがとうございます！光栄です！ 『完全SIer脱出マニュアル』は、テーマ的に商業で出すと一気に嘘っぽくなる気がするので同人誌のままでいさせてあげたい気持ちです。 かと言って、他に書けそうなテーマがあるかと言われると正直パッとは思いつかないっすね。 本を書きたい気持ちはありますが！
『完全SIer脱出マニュアル』を書いた目的は、あくまでも「かつての自分のようにSIerにいて仕事つまらんと思っている人に対して、楽しく働くための選択肢を示す」ことでした。 日本のSIerがこれまで数十年積み上げてきた功績にケチをつけたり、SIerにいて仕事楽しいと思っている人の人生を否定したりするつもりは全くありません。 しかし、『完全SIer脱出マニュアル』という書籍が同人誌ならまだしも商業書籍として世に出回ることによって、タイトルが一人歩きして、悲しむ人が出てくるんじゃないかという不安がありました。
自分だけでなく出版社にも「SIerを否定するポジション」という色が付くように思えて、迷惑をかけるんじゃないかという懸念もありました。 しかし実際に出版社の編集の方とお話ししたところ、特にそんなこと気にしていないようでした。 タイトルを変えることも考えましたが、この本のミッションはなるべく多くの「SIerにいて仕事つまらんと思っている人」に対して知るべき情報を届けることだなーと思い出しました。そのためにはやはり『完全SIer脱出マニュアル』という尖ったタイトルを一人歩きさせることが必要だと判断しました。 また、SIer全体を否定しているというタイトルの印象をなるべく払拭できるように、内容もなるべく「エンジニアが働く場所としてのSIer批判」に限定して書こうと試みました。 もちろん「SIer全体を否定された」と感じる人をゼロにはできないでしょうが、「その感情をバネに頑張ってくれ」と割り切ることにしました。 ちなみに、同人誌版ではポッドキャストの相方にも付録部分の執筆をお願いしていましたが、商業版は僕の単著という形で出しました。
そんなわけで、もともと同人誌として頒布された『完全SIer脱出マニュアル』は、「SIer脱出のその後のキャリア」について2つの章を加筆した上で、2019年6月に商業出版されることになりました。 全国の書店やAmazonで販売中です。
- 作者:池上純平
- 発売日: 2019/06/22
- メディア: 単行本（ソフトカバー）
なぜエンジニアはSIerを去るのか？
タイトル回収の意味も込めて、SIerやそこを去るエンジニアについても書きたいと思います。 そもそもSIerで働くエンジニアに特有の不満や悩みが無ければ、『完全SIer脱出マニュアル』という本がここまで読まれることもなかったはずです。 僕のこれまでの経験や活動から、自分なりの考えをまとめます。
「SIer的」なやり方に合理性があった時代
この記事で何度もSIerと表記していますが、その定義はとても曖昧です。 SIer（システムインテグレーター）について、『完全SIer脱出マニュアル』では次のような企業を指していると説明しています。
- 中・大規模なシステムの受託開発案件を、比較的大人数で実施している
- 自社内だけではなく、たくさんの協力会社の人員を組み合わせてシステム開発をする
- ウォーターフォール型開発、Excel仕様書、枯れた技術を好んで使う
- SIerのエコシステムの中でサービスを提供するSES企業なども含める
システムの開発案件を、開発能力の少ない企業や団体から受託し、協力会社から人材をかき集めて、期限を決めたウォーターフォール型のプロジェクト管理手法を用いて開発するような企業や事業をイメージしています。
まだITシステムが一般的では無かった時代、SIerのような存在がシステムを開発することには十分に合理性がありました。 オフィスの内装を外部の業者に発注するように、企業が業務システムを外注するのは当たり前のことでした。 最初にITシステム化が進んだのは、企業内部の業務を自動化・効率化するような領域でした。 すでにある簡単な業務をITシステムに置き換えるだけであれば、プロジェクト初期に発注者と受注者で要件を全て固めてしまうことができたと想像します。 あとはシステムを要件通りに作って納品するだけなので、受注者の中で独立して開発プロジェクトを回しても、開発するものに対する認識のズレは比較的生じにくかった。 このような状況の中で、開発プロセスをガチガチに固めて誰でも一定のパフォーマンスが出せるように標準化されていきました。
いまのSIerの何が問題か？
しかし、システムに対する要求は時代とともに高度化、複雑化していきました。 それは次のような理由からです。
- 単純な業務がシステム化され尽くされ、より複雑な業務ロジックを扱う案件が増えた
- さらに企業内の業務だけではなく、生活者や顧客のクライアントが使うサービスまでソフトウェア化され始めた
- インターネットの普及などを背景に、ニーズが多様化し変化するスピードが上がった
システムに対する要求の広がりを説明するために、SoR（System of Records）、SoE（System of Engagement）という分類がよく使われます。 従来はERPなど記録のためのシステムがほとんどでしたが、顧客とそのクライアントとのEngagementを高めることまで求められるようになりました。
こうした変化により、既存のSIerのやり方では太刀打ちできない案件が増えました。
- ステークホルダーが増え、受注者の中だけで意思決定できない局面が増えた
- システムの評価基準として、信頼性やコストだけではなく、UXや外部連携の柔軟性などが求められるようになった
- プロジェクト初期に要件を全て決めても、プロジェクトを進めるうちに求められるものが変化してしまうことが増えた
端的にまとめると、多くのSIerは「受ける案件の不確実性が明らかに増したのに、過去にうまくいっていた手法から抜け出せずその不確実性を適切に扱えていないことで、発注者の期待以上のものをつくれる確率が大幅に下がっている」という状況に陥っているように見えます。
「SIビジネスの罠」
ここまで述べてきたような問題がSIer内の個々の事業部や現場社員の振る舞いによってすぐになんとかなるものであれば、ここまで広く問題として認識されなかったはずです。 ここには、SIのビジネスモデルにおける「罠」ともいうべき構造上の問題があるように思います。 それは、「SIビジネスにとって顧客のエンジニアリング・リテラシーを奪うような振る舞いをすることが、短期的にはプラスに働く一方で、長期的には自分の首を絞めてしまう」という問題です。
私が富士通時代に関わっていた行政の分野でも、かつて情報システム部門に開発ができるメンバーがいて一部のシステムを内製していたような自治体もあったようです。 少なくとも、まだ今ほどシステムが標準化されていない時代においては、業務知識を持った顧客側の担当者がシステム開発の現場に深く入り込み、一緒になって開発を進めていたはずです。
しかし、SIerは顧客から業務知識を吸収していきました。 中には、「顧客側担当者よりも顧客の業務要件に詳しいSE」も生まれてきました。 こうして顧客は「システム開発に関するほとんどの業務をSIerに丸投げしても問題ない」と思うようになりました。 SIerにとっては、より多くの領域を任せてもらうことで発注金額が増えたりロックインしやすくなったりします。 顧客にとっても、恒常的に発生するわけではないシステム開発の人員を自社で確保したくはないので、SIerに丸投げできるならありがたかったはずです。 こうしたSIerと顧客の共犯関係によって、短期的な利益のために顧客はシステム開発の現場から遠ざけられたのです。
発注者がエンジニアリングについて無知になったことによる最大の問題は、システム開発の「手段」や「プロセス」に関する変化を起こしづらくなったことです。 エンジニアリングの知識がない顧客は、自動テストを導入すること、OSSを活用すること、世の中に広く使われているWebアプリケーションフレームワークに乗っかることなどのメリットを理解できません。 よくわからないものを変えてプロジェクトが失敗するのは怖いので、「今までと同じように作ってくれい」という意思決定になりがちです。 受注者であるSIer側が顧客を説得すればいいはずですが、工数見積もりで案件の売上規模が決まる場合、「プロセスの改善によって生産性を上げよう」というモチベーションは受注者側には発生しません。 状況を打破するには発注者が「そんな生産性が低く変化にも弱い開発プロセスで開発されては困る」という声を上げるしかないのですが、SIerに対して開発を丸投げし続けてきた発注側企業の中には、それを言えるだけの知識がある担当者や役員は残っていません。 開発プロセスの改善が行われないというのは、より価値あるものをより早く作って欲しい発注者からすれば、明らかにマイナスです。 また受注者たるSIerにとっても、「本質的に価値あるものづくりのプロセス」からいつまでも目を背けていると、リテラシーを身に付けた顧客や自社の従業員からそっぽを向かれてしまうかもしれません。 長期的に見ると、こうした振る舞いはSIer自身にとっても大きなリスクをもたらしているように思えます。
なお、ソフトウェア開発にまつわる時代の変化については、この資料に詳しいです。
www.slideshare.net
また、エンジニアリングの歴史、ウォーターフォール開発の位置付けなどを理解するためには、『エンジニアリング組織論への招待』がおすすめです。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者:広木 大地
- 発売日: 2018/02/22
- メディア: 単行本（ソフトカバー）
エンジニアがSIerを去る3つの理由
ここまで長々と書いてきた問題によって、マクロ的に見てSIビジネスが構造的な問題を抱えているということがわかったと思います。 この問題が、SIerの中で働くエンジニアへのモヤモヤにつながっていきます。 案件やチームによってそのモヤモヤの内容はもちろん異なりますが、大きく共通するのは次の通りです。
前述のように、顧客のエンジニアリング・リテラシーが無い状況においては、開発プロセスの改善に関して顧客と合意する難易度が上がります。 エンジニアとして理想のエンジニアリングを追求しようと、たとえばテストやデプロイの自動化、Gitの導入などを進めようと思っても、評価されるどころか反発を受けたりします。 生産性を上げると、工数見積もりの世界では売り上げが下がってしまうからです。
せめて価値あるプロダクトを作ろうと思っても、要件に書いていないことを実現するための工数は受注者にとって無駄なコストでしかありません。 どんなに使い勝手が悪いシステムであっても、目指すべきUXについて予め要件に記述されていない限りは、使い勝手をよくする開発を受注者側の判断でするモチベーションは生まれにくいでしょう。 そして、目指すべきUXをシステムができる前に全て詳細に定義するというのは、ほとんど不可能に近いように思えます。
つくるものの改善もつくるプロセスの改善も封じられてしまうSI事業の世界において評価されている社員を見ると、とても「エンジニア」とは思えない仕事やスキルセットの人であることがほとんどです。 もちろん、SIビジネスを上手く回して売り上げを上げる立ち回りができれば、事業への貢献度合いが高まり評価されるかもしれません。 さらにいえば、SIビジネスの構造的欠陥を解消していくような活動をSIerの中にいながら強い意志を持って実行に移していくことができれば、社会的にも大きな価値を生むことができます。 しかし、それらをエンジニアとして働きたいと思っている自分自身がやるべきかというと、そんなことを気にしなくて済む現場に転職した方がよっぽど早くて確実です。
こうして、エンジニアになりたかった人たちはSIerを去ることを考え始めます。 というわけで、『完全SIer脱出マニュアル』はそんな人に向けて書いた本でした。
『完全SIer脱出マニュアル』への反響は？
SIerにいてモヤモヤしている個人からの反応
『完全SIer脱出マニュアル』という本を出したときは、タイトルがあれなだけに賛否両論あるだろうなあと思っていました。 蓋を開けてみると、ブログやTwitterや対面でいただいたフィードバックは、ほとんどが好意的なものでした。 気になる方は、「完全SIer脱出マニュアル」でググるといくつかの感想ブログがヒットします。 もちろん、転職に関する記述がWebエンジニアやベンチャーに寄りすぎているなどの部分的な批判はありました。 ただ、「ただ闇雲に転職を進める内容じゃないのが良かった」という反応や、中には「自分のキャリアに光が差しました」と対面で言ってくれた方もいました。
特に、『完全SIer脱出マニュアル』の冒頭の方に書いた「SIerのエンジニアの一日」という項目が、意図せず読者にぶっ刺さるケースが多く見受けられました。 あくまでも僕が富士通時代に働いてた頃の仕事をイメージして書いたものでしたが、中には「自分の仕事を背中越しに見られているのかと思った」という人もいました。 せっかくなので、「SIerのエンジニアの一日」の項目を全文引用します。
- 8:40 出社
- SIerの朝は早い
- 8:45 メールチェック
- 社内の非同期コミュニケーションのほとんどは、メールで行われます
- チャットツールも全社導入されていますが、マネージャーは誰も使っていません
- 9:00 「Excel」で設計書の修正
- 担当する仕様変更の設計書（Excel）が前日の会議レビューを通ったので、指摘事項を修正します
- 10:00 ソースコードの修正
- 12:00 昼食
- 社員食堂で上司やトレーナーと一緒にランチをします
- 13:00 手動テストの実施
- 18:00 紙納品のために設計書を印刷
- 顧客から設計書の紙納品を頼まれたので、大量のExcel設計書を1つずつ開いて印刷します
- 印刷した紙は、綺麗にファイリングして段ボールに詰めていきます
- ちなみに、この設計書が顧客に読まれることは無いそうです
- 20:00 帰宅
この記述を見て、「タイトルが怪しいから疑いながら読み始めたけど、ここを読んで自分の境遇を理解してくれている人が書いていると感じて、ちゃんと読む気になった」と言ってくれるケースがありました。 とてもうれしかったです。
SIerの企業サイドからの反応
書籍を出したときは、SIer界隈の偉い人や採用に関わっている人から何かしらの反応があったり刺されたりしたら面白いなあと思っていました。 しかし残念ながら、僕の観測範囲内ではそのような人からの反応は見つかりませんでした。 理想的なケースとして「SIerから講演を求められる」とかまで想定しましたが、そんな声がかかることは全くなかったです。
逆に、SIer出身の優秀なエンジニアが欲しいベンチャー界隈では、SIerからの転職という文脈でイベントに呼ばれたりしました。
商業出版ってぶっちゃけ儲かるの？
余談として、せっかく商業出版を経験したのでそれについても書いておこうと思います。
発売までの流れ
出版社や書籍の内容によっても異なると思いますが、僕は編集の方とは1回しか対面で会わずに、メールベースでやりとりしながら執筆を進めていきました。 最初に「このくらいの時期までに原稿があるといいですねー」みたいな締め切りを切ってもらいました。 あとはその締め切りを目指して、同人誌の原稿を元にひたすら加筆修正を繰り返していきました。
初回の原稿はMarkdownで入稿させてもらいました。 世の中にはGitHubで原稿を管理してPull Requestで修正を共有する世界もあるらしいですが、そこまでは手が回っていないようでした。 初回の原稿をメールで共有したあとは、いったん書籍のフォーマットに流し込んでもらい、その後はPDFベースでひたすら赤入れをしていきました。 ある程度完成の目処が立った時期に表紙のデザインが上がってきて、「OKです！」と言ってしばらく待っていたら本になっていました。 思ったよりもずっと呆気ない感じで、全国の書店やAmazonでの発売が開始されました。
売上と印税
僕は同人誌と商業出版を両方経験しました。 商業出版の場合、同人誌のダウンロード販売と違ってリアルタイムで正確な売上部数を知ることはできないようでした。 半年に一回とかの頻度で印税通知書が送られてきて、そこで初めてどのくらいの部数が売れているかを知りました。
前述のように『完全SIer脱出マニュアル』は同人誌版ですでに1,841部も売ってしまっていました。 それもあってか、商業版の方は半年間で762冊くらいしか売れていないようでした。 （ぜひ買ってください！）
利益についても、同人誌と違って売上に対して決まった印税の割合しか入ってきません。 僕の印税割合はなんとなく伏せますが、印税の相場である10%だとします。 その場合、1,800円の『完全SIer脱出マニュアル』が売れても、180円/冊しか利益が入りません。
一方、同人誌版『完全SIer脱出マニュアル』は1冊1,000円で売っていました。 紙版は印刷代など諸々で1冊当たり350円くらいの経費がかかったので、利益は650円/冊でした。 さらにダウンロード販売については、委託先であるBOOTHの決済手数料3.6%くらいしか経費がかからないので、960円/冊も利益が入ります。 売るためのチャネルがちゃんとあれば、単純に儲けだけを考えると商業出版よりも同人誌の方が圧倒的に良いです。
商業出版のメリット
一方、商業出版をすることのメリットも2つありました。
1つは、自分だけではリーチできない人たちに対して認知させることができるということです。 発売される前はあまりピンときていませんでしたが、商業出版すると普通は全国の書店に自分の書いた本が並びます。 富山にいる知り合いから「gamiさんの本、書店にありました！」と言われたときは、とても驚きました。 また、出版社や電子書籍ストアなどが僕の知らないところで『完全SIer脱出マニュアル』を紹介してくれるなど、本を売ろうとしてくれる人が僕以外にも増えました。 繰り返し書いているように、『完全SIer脱出マニュアル』は儲けるためではなく「SIerにいて仕事つまらんと思っている人に対して、楽しく働くための選択肢を示す」ために書いた本です。 そんな自分が広めたい情報や考えを、色んな人の手を借りて広めることができました。 「商業出版は儲からない」とよく言われるし僕もそう思いますが、自分の考えを広めるためには広告費を払うのが普通だと思えば、逆にお金を貰えるのが不思議なくらいかもしれません。
2つ目のメリットは、自分の実績になるということです。 もちろん同人誌を書いたという事実も、キャリアにとってプラスになることだと思います。 しかし、商業出版になると編集者のチェックが入ったり、そもそも売るに値する内容かどうかの判断が発生します。 出版社の合意の元で書籍として世の中に出したコンテンツということで、商業書籍の方がより実績として評価されやすいと感じました。 実際、書籍執筆の活動などによって「一定のコンテンツを生み出せる人だ」という評価がされて、カンファレンスへの登壇依頼が来たりしました。
これから取り組みたい、エンジニアリングにまつわる本質的な課題とは？
最初に書いたように、『完全SIer脱出マニュアル』という書籍を世に出せたことで、「SIerの仕事つまらんと思っているエンジニアに対して、楽しく働けるように支援する」というテーマに対して、一定の「やり切った感」を感じてしまいました。 もちろんまだまだ世の中には「SIerの仕事つまらんと思っているエンジニア」はたくさんいるはずですし、今後も増えていくでしょう。 しかし、僕の中ではポッドキャストや書籍の中で十分に「じゃあどうするべきか」について発信をしたつもりなので、「あとはまあ自分で頑張ってくれい」という気持ちになってきました。
「SIerにいるエンジニアのキャリア支援」に区切りがついた今、次に僕が取り組みたいテーマは、すでにある程度決まっています。 それは、「非エンジニアに対するエンジニアリング教育」です。 上述した通り、SIビジネスが多くの不幸を生んでいる直接的な原因は、顧客のエンジニアリング・リテラシーがあまりにも低いということです。 顧客企業がエンジニアリングについて正しく理解をしていれば、変化に弱い昔ながらのシステム開発プロセスを続けているSIerには見向きもしないはずです。
もっと言えば、SIerやエンジニアに頼らなくても非エンジニアがエンジニアリングによって生産性を上げるための環境は、十分に整いつつあります。 世間ではNo-CodeやLow-Codeが取り沙汰され、コードをあまり書かなくてもWebサイトを公開したり簡単な自動化をしたりできるサービスがたくさん登場しています。
今まで、エンジニアリングの力はエンジニアによって独占されてきたように思います。 しかし、本来「エンジニアリング」というものは、誰にとっても有用なものであるはずです。
『エンジニアリング組織論への招待』では、「エンジニアリング」について次のように説明しています。
エンジニアリングという行為は、何かを「実現」することです。実現のために、不確実性の高い状態から、不確実性の低い状態に効率よく移していく過程に行うすべてのことです。
デザイナー以外にとってもデザインの力が重要であるように、不確実性の時代において、エンジニア以外にとってもエンジニアリングの力はますます重要になってくるでしょう。 たとえば、日本で働く誰もがWebの仕組みを理解し、コードを書かずにどこまで自動化できるかを知り、簡単なSQLやJavaScriptを書けたら、生産性は大きく向上するはずです。 技術的な投資についての意思決定も、精度が大きく上がるでしょう。 希望的に見れば、よりたくさんの人が自分のやりたい本質的な仕事に集中できるようになり、多くの「楽しく働ける状況」を実現できるようになります。 また、非エンジニアがエンジニアの仕事をより理解することによって、エンジニアがより高度な課題解決に集中できる世界に近づきます。 そんな社会を作れるように、まずは個人活動から、「非エンジニアに対するエンジニアリング教育」に取り組んでいきます。
さいごに
僕がSIerを退職したのは今から約3年半前です。 このたった3年半の間で、「楽しい仕事」というものを知り、似たような境遇の人と知り合い、かつての自分に役立つアウトプットをするようになり、『完全SIer脱出マニュアル』という本を書き、そしていま次なるミッションに対して決意を新たにしています。 僕にとっての「完全SIer脱出」は、ただSIerを辞めることではなく、自分なりの楽しいキャリアを見つけるところまでを指しているつもりです。 『完全SIer脱出マニュアル』という本をきっかけに、多くの人が自分なりの人生のミッションを見つけ、もっと楽しく働けるようになることを願っています。
