2019年3月にクレディセゾンに来て、ゼロからチームを立ち上げて1年半が経った。「セゾンのお月玉」を始めとして戦略的企画を自分たちで企画し、実装し、改善し、運用していくチームはとても良い感じで動けていて、現在もいくつかの大型プロジェクトに仕掛中だ。2ピザチーム(8人)ひとつでやっているにしてはかなり良い動きができていると感じている。
だが、1年経過した頃から『これは絶対に成し遂げたい』と思うことが出てきた。
1.「事業会社とSIが分かれている問題」と向き合う
それは「事業会社とSIが分かれている問題」をどうにかすることだ。
新規の戦略的企画を作る私たちのチームは完全内製で開発をしている。一方、事業部門のシステムはすべて外部に委託している。
だが、1年経過した頃から『これは絶対に成し遂げたい』と思うことが出てきた。
1.「事業会社とSIが分かれている問題」と向き合う
それは「事業会社とSIが分かれている問題」をどうにかすることだ。
新規の戦略的企画を作る私たちのチームは完全内製で開発をしている。一方、事業部門のシステムはすべて外部に委託している。
最近、事業部門とシステムに関する話をする機会が増えてきて、「それこんな感じで作っちゃえばすごいスマートかつ大した工数をかけずにできちゃうかも？しかもUXを考えるとここはこうした方が絶対いい。それにこれは作ってみて反応を見ながら日々改善していく方がいい」と思えるようなケースが多々あることが分かってきた。
だが事業会社とSIが分かれていることで、企業対企業でやり取りをしなければならず、エンジニアリング以外のマネジメント業務が大量に発生し、開発に必要な期間やコストが膨れ上がる。結果として、本来の目的である「使う人に喜んでもらったり、業務効率を向上させるシステムをまっすぐに考えること」から、「企業間の取引であり、ビジネスとして作るもの」へとマインドセットも引き寄せられて行ってしまう。
気付くと、エンジニアリングの腕を磨いて、それで何かを良くしたかったはずだったのに、マネジメントばかりしていて、さらにミスがあると怒られて、本当に誰かの役に立つのかもはっきりとしないシステムの管理業務ばかりしていた、というようなことが起こり得る。
マネジメント業務を膨れ上がらせる要因はいくつもある。例えばSIer側の作業だけ考えてみても、次のような作業がある。
見積もり、コスト調整、要員調整、
大量のプロジェクト計画書、
内部進捗（SI）と報告用進捗(事業会社)の二重管理、
人月による無意味な見積もり、、、
開発専門部隊が存在する会社だと内部売買の報告資料の作成まで必要になるケースもある。
それにそもそも事業会社とSIとの話がかみ合わず、歯車を嚙合わせるための会議に膨大な時間がかかったりする。
SI観点だけでもこれらの業務が大量に発生するのだ。
当然、相対する事業会社側の作業も含めたらこれらのマネジメント業務のボリュームはさらに膨大なものとなる。
結果として、エンジニアリング以外の業務が大量に発生するだけでなく、事業の当事者と現場で実際に開発するエンジニアとの間にいくつものレイヤーができてしまう。多重下請け構造も考慮するとこのレイヤーはさらに重厚なものとなる。
２．事業とエンジニアリングの距離を極限まで縮める
二ヵ月ほど前から試験的に、「事業部で一番解決したいシステム的な課題」を各事業部にヒヤリングし、それを自社開発できないかを検討してきた。参加者はビジネスサイドで事業責任者である役員や事業部長、そして現場運用を良く知るメンバー2・3人。エンジニアリングサイドは私と、エンジニアチームの中でSI出身のシニアエンジニアでマネジメント経験も豊富で手も動かせる二人の3人。この協議を何度か実施していくうちに、従来のやり方より圧倒的に良くできそうだ、という手応えがつかめてきた。
そこで経営レベルでもこの戦略について話をし、下期（2020年10月）から、「事業部開発内製化大作戦」を展開することにした。
具体的には、6人を1チームとして、「事業部でいま一番解決したいシステム的な課題」にひとつずつ取り組んでいく。6人の内訳は、3人が外部から採用するエンジニアで、3人は内部から社内公募で異動してくるエンジニア候補者だ。事業部の現状を良く知り、事業部とのコミュニケーションパイプともなり、今後会社全体をソフトウェアカンパニーに近づけていく上でのロールモデルともなるという意味で、半分は社内公募のメンバーとしている。この6人のチームを、まずは最大4つ作りたいと考えている。既に各事業部から優先的に取り組みたい課題はリストにしてもらっているので、チームができあがるタイミングや事業部や会社全体から見た優先度を考慮しながら、どのチームがいつから何に取り組むかを決めていく。
そこでこの外部採用エンジニアの3人 * 4 = 最大12人を募りたいというのが今回の募集である。
３．日々の仕事の雰囲気と、求めるエンジニア像
チームのポリシーや日々の仕事の雰囲気については、7月末に出版した「その仕事、全部やめてみよう」に書かれているような環境そのものだ。ありがたいことにとてもたくさんの方が素敵な書評を書いてくれたのだが、「職場の雰囲気が分かる」という意味では、ビジョナル CTO 竹内 真さんの書評や「ソフトウェア・ファースト」及川 卓也さんの書評を読んでいただくとある程度イメージが沸くかもしれない。使う人に最高に喜んでもらえるものを作り上げることや、技術を磨くことに妥協せずに取り組んでいきつつ、しかし一方で仕事は楽しさや笑いに満ちていた方がいい。ひとりひとりが楽しむことと、成果を出していくことと、その両方が実現できれば一番だ。
求めるエンジニア像としては、まず必須条件としてプログラミングをしたい人であること。異常に突き抜けたエンジニアだけを募集しているわけではなく、普通に書けますよ、という人も気軽にお声がけいただければと思っています。SIerにいて、いまはエンジニアリングに注力できていてとても楽しいけれど、少ししたらマネジメント業務ばかりになりそうでこのままで良いのかな、と思っている方などは超ドンピシャです。あるいはちょっと前までエンジニアリングでバリバリやっていたけれどこのところマネジメント業務ばかりで……と言う方もドンピシャです。今回の新チーム発足に際して戦略的企画を自社開発するチームから2名ほど異動しているので、事業部のシステムの方じゃなくて戦略的企画の方の開発に興味があるという方も大歓迎です。
ちょっとでも興味があるよ、と言う方は、正式な面接とかそういうお堅い話ではなく、一度遊びに来る感覚で、ぜひ下記フォームから気軽にご連絡いただければ思います。
さいごに
「事業をエンジニアリングする」という言葉は、ひとつ前のエントリで紹介した「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」という書籍のタイトルにインスパイヤされた言葉です。スタートアップやWeb系では事業そのものにエンジニアが深く関与してエンジニアリングしているケースが多々ある。それを日本の大企業で、いままで外注しかシステム開発の選択肢がなかった場所で、一緒にやってみませんか。
なお、「事業部開発内製化大作戦」は2020年10月から開始しますが、移れるタイミングはもう少し先で……という方も多いかと思います。タイミングについては柔軟に相談していければと思っているので、まずはこちらのフォームから気軽にご連絡いただければと思います。
「まだ募集中でしょうか？」とお問い合わせをいただいております。その後も継続して募集中で、募集終了する際にはその旨を明記するようにします。 2022/6/24
だが事業会社とSIが分かれていることで、企業対企業でやり取りをしなければならず、エンジニアリング以外のマネジメント業務が大量に発生し、開発に必要な期間やコストが膨れ上がる。結果として、本来の目的である「使う人に喜んでもらったり、業務効率を向上させるシステムをまっすぐに考えること」から、「企業間の取引であり、ビジネスとして作るもの」へとマインドセットも引き寄せられて行ってしまう。
気付くと、エンジニアリングの腕を磨いて、それで何かを良くしたかったはずだったのに、マネジメントばかりしていて、さらにミスがあると怒られて、本当に誰かの役に立つのかもはっきりとしないシステムの管理業務ばかりしていた、というようなことが起こり得る。
マネジメント業務を膨れ上がらせる要因はいくつもある。例えばSIer側の作業だけ考えてみても、次のような作業がある。
見積もり、コスト調整、要員調整、
大量のプロジェクト計画書、
内部進捗（SI）と報告用進捗(事業会社)の二重管理、
人月による無意味な見積もり、、、
開発専門部隊が存在する会社だと内部売買の報告資料の作成まで必要になるケースもある。
それにそもそも事業会社とSIとの話がかみ合わず、歯車を嚙合わせるための会議に膨大な時間がかかったりする。
SI観点だけでもこれらの業務が大量に発生するのだ。
当然、相対する事業会社側の作業も含めたらこれらのマネジメント業務のボリュームはさらに膨大なものとなる。
結果として、エンジニアリング以外の業務が大量に発生するだけでなく、事業の当事者と現場で実際に開発するエンジニアとの間にいくつものレイヤーができてしまう。多重下請け構造も考慮するとこのレイヤーはさらに重厚なものとなる。
２．事業とエンジニアリングの距離を極限まで縮める
二ヵ月ほど前から試験的に、「事業部で一番解決したいシステム的な課題」を各事業部にヒヤリングし、それを自社開発できないかを検討してきた。参加者はビジネスサイドで事業責任者である役員や事業部長、そして現場運用を良く知るメンバー2・3人。エンジニアリングサイドは私と、エンジニアチームの中でSI出身のシニアエンジニアでマネジメント経験も豊富で手も動かせる二人の3人。この協議を何度か実施していくうちに、従来のやり方より圧倒的に良くできそうだ、という手応えがつかめてきた。
そこで経営レベルでもこの戦略について話をし、下期（2020年10月）から、「事業部開発内製化大作戦」を展開することにした。
具体的には、6人を1チームとして、「事業部でいま一番解決したいシステム的な課題」にひとつずつ取り組んでいく。6人の内訳は、3人が外部から採用するエンジニアで、3人は内部から社内公募で異動してくるエンジニア候補者だ。事業部の現状を良く知り、事業部とのコミュニケーションパイプともなり、今後会社全体をソフトウェアカンパニーに近づけていく上でのロールモデルともなるという意味で、半分は社内公募のメンバーとしている。この6人のチームを、まずは最大4つ作りたいと考えている。既に各事業部から優先的に取り組みたい課題はリストにしてもらっているので、チームができあがるタイミングや事業部や会社全体から見た優先度を考慮しながら、どのチームがいつから何に取り組むかを決めていく。
そこでこの外部採用エンジニアの3人 * 4 = 最大12人を募りたいというのが今回の募集である。
３．日々の仕事の雰囲気と、求めるエンジニア像
チームのポリシーや日々の仕事の雰囲気については、7月末に出版した「その仕事、全部やめてみよう」に書かれているような環境そのものだ。ありがたいことにとてもたくさんの方が素敵な書評を書いてくれたのだが、「職場の雰囲気が分かる」という意味では、ビジョナル CTO 竹内 真さんの書評や「ソフトウェア・ファースト」及川 卓也さんの書評を読んでいただくとある程度イメージが沸くかもしれない。使う人に最高に喜んでもらえるものを作り上げることや、技術を磨くことに妥協せずに取り組んでいきつつ、しかし一方で仕事は楽しさや笑いに満ちていた方がいい。ひとりひとりが楽しむことと、成果を出していくことと、その両方が実現できれば一番だ。
求めるエンジニア像としては、まず必須条件としてプログラミングをしたい人であること。異常に突き抜けたエンジニアだけを募集しているわけではなく、普通に書けますよ、という人も気軽にお声がけいただければと思っています。SIerにいて、いまはエンジニアリングに注力できていてとても楽しいけれど、少ししたらマネジメント業務ばかりになりそうでこのままで良いのかな、と思っている方などは超ドンピシャです。あるいはちょっと前までエンジニアリングでバリバリやっていたけれどこのところマネジメント業務ばかりで……と言う方もドンピシャです。今回の新チーム発足に際して戦略的企画を自社開発するチームから2名ほど異動しているので、事業部のシステムの方じゃなくて戦略的企画の方の開発に興味があるという方も大歓迎です。
ちょっとでも興味があるよ、と言う方は、正式な面接とかそういうお堅い話ではなく、一度遊びに来る感覚で、ぜひ下記フォームから気軽にご連絡いただければ思います。
さいごに
「事業をエンジニアリングする」という言葉は、ひとつ前のエントリで紹介した「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」という書籍のタイトルにインスパイヤされた言葉です。スタートアップやWeb系では事業そのものにエンジニアが深く関与してエンジニアリングしているケースが多々ある。それを日本の大企業で、いままで外注しかシステム開発の選択肢がなかった場所で、一緒にやってみませんか。
なお、「事業部開発内製化大作戦」は2020年10月から開始しますが、移れるタイミングはもう少し先で……という方も多いかと思います。タイミングについては柔軟に相談していければと思っているので、まずはこちらのフォームから気軽にご連絡いただければと思います。
「まだ募集中でしょうか？」とお問い合わせをいただいております。その後も継続して募集中で、募集終了する際にはその旨を明記するようにします。 2022/6/24
コメント