【CTOmeetup】CTOに求められる能力と限界(前編)~CTOの定義、役割、重視すべきポイントとは~

2018年12月13日に開催されたCTO meetupのテーマは、「CTOに求められる能力と限界」。第一線で活躍する敏腕CTOが集い、そもそもCTOとはどういった役職なのか?という根本的な定義から徹底議論を行いました。企業規模やフェーズによって変化していくCTOの役割、求められる能力、立ち回り方など、現在CTOとして問題解決に取り組んでいる方、CTOの導入を検討している経営層、将来CTOとして活躍したいエンジニアを対象に大変興味深いディスカッションの様子をレポートします。
(掲載されている所属・役職は開催当時のものです)

【ご登壇者】
●株式会社LITALICO /執行役員CTO 岸田 崇志 氏
●BizteX株式会社 /取締役CTO 袖山 剛 氏
●株式会社FABRIC TOKYO /執行役員CTO 中筋 丈人 氏

【ファシリテーター】
●Sansan株式会社 /執行役員CTO 藤倉 成太 氏

登壇者のご紹介

分野、フェーズ、規模、経歴の異なるCTOが集結

CTOmeetup 藤倉:Sansan株式会社でCTOを務めております、藤倉と申します。大学卒業後に新卒でSIerであるオージス総研に入社し、4年目にアメリカの子会社へ出向。20代後半はアメリカで働いていました。帰国後は自分のサービスと呼べるものを作りたいと思い、Sansanに転職。エンジニアとしてインフラからアプリケーション開発までさまざま手がけ、そこから開発組織のマネジメントにも幅を広げ、現在CTOとなった形です。
本日は「CTOに求められる能力と限界」というテーマですが、果たして能力と限界が本当にあるのか、CTOの実態を詳らかにしていく場にしていければと思います。みなさん、本日はどうぞよろしくお願いいたします。

岸田:株式会社LITALICOでCTOを務めております、岸田と申します。LITALICOは福祉事業を手がける企業で、あまりテクノロジーの活用が進んでいない領域で、インターネット事業を立ち上げるという部分に面白さを感じて参入し、ゼロベースから組織づくりに携わって現在3年目です。転職する以前はグリー株式会社でエンジニア30名の時点で入社し、最終的には会社規模2000名ほどの組織で内製エンジニア部門を統括する立場も経験しています。社外CTOとして技術アドバイザーも務めておりますので、その観点からお話ができればと思います。どうぞよろしくお願いします。

袖山:僕はBizteX株式会社を現在のCEOと一緒に立ち上げ、現在で2年弱になります。それまではSlerとしてグループウェアパッケージの開発をするアリエル・ネットワークで10年ほど働き、最終的にはゼネラルマネージャーとしてマネジメントを中心とした業務を行っていました。退職後は起業を考えていたところ、現在のCEOと出会い「CTOをやらないか」と誘われ、会社を創業しました。当社ではエンジニアでなくとも簡単にパソコン業務を自動化する仕組みを作れる、というコンセプトでクラウドRPAを開発しています。創業したばかりのCTOならではの課題などをお話しできるかと思いますので、どうぞよろしくお願いいたします。

中筋:株式会社FABRIC TOKYOの中筋と申します。いわゆるファッションテック系のサービスを展開しており、CTOを務めて現在3年弱です。経歴としては高校卒業後に陸上自衛隊に入隊し、その後Slerとしてアマゾンで働いた経験もあります。どうぞよろしくお願いします。

藤倉:CTOの役割はフェーズや事業規模に左右される、という前提があるので、今回は会社の設立時期や組織体系、フェーズが異なる方にお越しいただいています。
袖山さんの組織はエンジニアが10名未満、中筋さんは十数名程度。岸田さんは会社としての歴史は十数年ほどありますが、エンジニア組織自体は立ち上げから3~4年で、50名規模。僕の場合は会社としては12年目で、ものづくりのメンバーは180名ほどです。今回は、そんなみなさんのフェーズや立ち位置の違いを理解しながら聞いていただくのが良いかと思います。

CTOmeetup能力と限界

フェーズごとに求められるCTOの能力と限界

CTOとは、変化していく役割を柔軟にこなしながら成果を出す存在

藤倉:ではまず、各パネラーのみなさんがCTOという役割をどう定義づけているのか、という質問からスタートしたいと思います。袖山さん、いかがでしょうか。

袖山:特に創業CTOは、「事業に対して成果を出すことができる、テクノロジースタイルの経営者」と定義づけています。開発やマネジメントスキルは必要ですが、そもそも事業が成立して、成長する可能性を提示できるということが大前提です。

中筋:フェーズや状況に応じて自分の役割をスイッチさせながら、事業にバリューを出せるかどうかという観点で定義しています。例えば私がFABRIC TOKYOにジョインした最初期、メンバーはフロントエンドエンジニア1名、デザイナー1名、業務委託のエンジニアが2名でした。最初の業務内容は、サービスの利用規約の改訂です。読んだときにめちゃくちゃな内容だったので、私が直したんです。「これはCTOの仕事なのか?」と思いつつもこなしました。ほかには一時期マーケティング部門にも携わってKPIの作成なども行いました。本当にいろいろなことを求められます。ですから、いかに自分の能力や役割を組織にアジャストさせて貢献できるのか、という部分が大事ですね。

岸田:やはり「役割を果たせるかどうか」が第一になると思っています。CTOはコーディングスキルの高い人という一般的なイメージがあるかもしれませんが、実際的にコーディングはCTOの役割の一つでしかありません。特に急成長している会社であれば役割もどんどん変化していくので、コーディングやシステムのアーキテクト以外にも組織や事業全体を見たときのバランスやメンバーの育成、開発のプロセスなど、さまざまな要素を組み合わせながら”組織全体のアーキテクト”として臨機応変に変化を出せるというのが、CTOとして望むべき姿ではないでしょうか。

技術に対する責任を持つための技術選択における意思決定の範囲

藤倉:「テクノロジーを使って事業の成果を出す」という部分についてはみなさん同意見ですね。では話を変えて、例えば僕は日々コードを書いていませんし、書くべきではないと思っていますが、みなさんはいかがでしょうか?

袖山:僕は現在1割書くかどうかというくらいです。だいぶ減りました。

中筋:私も割合で言えば減りました。どちらかというと、新しい技術を取り入れるときに一ヶ月ほど無理やり時間を作って参考実装を書き、「こうしたらいいぞ」と共有したりします。

岸田:組織がまだ小さいときは事業の深度が高い部分もカバーする必要があるためコードを書いていました。現在は周辺技術をきちんと把握しておかないと、意思決定でミスが発生する可能性もあるためコードに触れて、情報をキャッチアップするための時間を意図的に作っています。些細な意思決定のミスは数ヶ月、数年単位の事業の遅れにもつながりますので。

藤倉:技術に対する責任を自分が持つ場合に自らコードを書くということですね。では、技術に対する意思決定はどのくらいされていますか?

岸田:新たな技術にチャレンジするときは、守るべき部分と攻めるべき部分を分けて、組織のプロダクトマネージャーに選択してもらいます。熟考して選択するということはオーナーシップを持ってもらう上でとても重要だと考えています。仮に失敗したとしても、そこはCTOとして自分が尻拭いする。そういう役割だと思っています。その積み上げが、今後大きなサービスを作る際、プロダクトマネージャーが重要な意思決定するための良い経験になると思っています。

袖山:当社は創業時に優秀なエンジニアを招いたので、基本的には僕が全部決めるというよりは、エンジニアも含めて協議するようにしています。

中筋:私は2018年の10月からチームを4つに分けたのですが、そこからはエンジニアに任せるようにしました。ただ、自分の経験則として絶対失敗することが目に見えているときは口を出すことがあります。とはいえ、一度失敗させるのも重要ですから、「自分が尻拭いできる範囲内で意思決定してもらう」というのは、非常に同意できますね。

CTOmeetup能力の限界

技術的負債の返済タイミングをどうすべきか?初期段階から求められる計画性

藤倉:最初にあった「技術で事業に成果を出す」という話に関連して、経営目線の技術選択とは一体何だ、という疑問が出てくるかと思いますが、みなさんのポリシーがあればお伺いしたいと思います。

袖山:経営視点で言うと、プロダクトの最初期に起こる技術的負債の視点が一つあります。技術的負債は、プロダクトの成功がある程度見えてきた段階で初めて「返済をする」というフェーズに差し掛かります。プロダクトが失敗すればただのゴミになるだけですからね。これを踏まえて初期段階においては、後々返済せずに済む、あるいはある程度開発速度が維持できる範囲の負債でおさめる、ということを主眼に開発者と協議すべきです。プロダクトは世に出てお客さんに使われないと全く意味がありませんから、プロダクトが失敗しないという前提で後々の技術的負債の問題をかなり意識します。

岸田:僕が経営視点で心がけているのは、3ヶ月後、6ヶ月後、1年後のサービスのあるべき姿を道筋立てて考えておくことです。どんな方向に進んだらいいのかをあらかじめイメージしておきます。特にスタートアップは流動的ですので、変化があるときにどう対応するかをイメージしておくことが大事だと思っています。成功確度を上げるために、組織内で「問い」が発生したときに、それに答えられることを常に意識しています。

中筋:私の場合は「いかにお金をかけずに開発するか」という視点を大事にしています。ベンチャーキャピタルから出資を受けている場合、シリーズBになると数字に対するコミットメントが強く求められますから、事業計画に対してどうやってKPIを達成するのかが重要になります。限られたリソースと資金でいかに数字を達成するかが大事なんです。不要なものは開発しない、作る場合もなるべくMVP(実用最小限の製品)的につくることを重視しています。

岸田:時間とお金に制約がある中で開発するのは良いサービスを生み出すポイントの1つだと思いますね。制約があるからこそ工夫しますし、自分自身も限られた期間で開発するためのスキルアップをしたいというモチベーションにつながります。スタートアップ時は特に、UI一つにしても無駄な遷移を減らすといった工夫が面白いですし、それが醍醐味だと思っています。

藤倉:袖山さんがおっしゃったように初期段階のステージであるほど技術的負債も返せる範囲を考えなければいけませんし、どんなふうに返済計画を立てるのかが求められますね。技術的負債というとネガティブなので、「技術的借り入れ」と言うくらいがいいかもしれません。

中筋:それでいくと、うちのプロダクトはECがCakePHPだったのですが、一昨年前、別のフレームワークに変更するという判断を意図的にしなかったんです。それよりも事業進捗を出すことを優先しました。その後、2018年の10月になってLaravelにリプレイスするプロジェクトが始まったのですが、これもある意味返済計画だと思っています。適切な時期に返済するのが非常に大事ですね。
リファクタに関しても、エンジニアは「リファクタしたい」と言うんですが、私は「お金で解決できるから後にしよう」と言います。お金をかけて人を集めればリファクタはできますから。肝心なのはそれをいつやるのか、という部分です。

岸田:技術的負債を返済する中でインフラやデータベースの知識が身につきますし、学べる部分もありますよね。成功するサービスを見ていると、コードの綺麗さだけでなく、プロダクトとしてもアウトプットできているかが重要で、全体のバランスが整っていないと事業として成功しないんだなということもわかります。走りながら組織で柔軟に対応していくというか。

袖山:リファクタしやすいコードかどうかもあります。例えばデータベースのテーブルの設定なんかは渋いので、そのあたりのハンドリングが必要だと思うのですが…。

中筋:その点に関しては「リファクタリング自体を目的にするな」と言われることがありますね。リファクタリングによって生産性が上がる、バグが少なくなる、という話があったとしてもそれ自体を目的にしないのは大事だと思います。

藤倉:ここまで、みなさんは経営に携わる立場のCTOとしてお話をされていますが、会場に来ている方たちに認識いただきたいのは、技術力をないがしろにしてはいけないということです。むしろ技術力を持つことは大前提です。正しい返済計画も技術力があればこそ立てられます。逆に技術力がないと返済期間が延びたり、不要な借り入れをしなければならないことになります。
ただ、人によって得意不得意がありますし、超人的なエンジニアばかりを集めるわけにもいかない。そこをどうバランスを取りながらやっていくべきか、という話ですね。

岸田:もう一つ経営視点に関して言えば、CTOが目的思考がないと、手段が目的と化して途中で「今なにをしているんだっけ」ということになることが多いです。何に向かって走っているのか、視座を考えて振り返ることができる人は強い気がします。

袖山:そういう意味ではビジネスサイドへの橋渡しが非常に重要だと思っています。今開発しているものがビジネスとしてどういう成果を上げるのか、具体的にどれくらいの売上があるといいのか、現場の肌感をどう伝えるのか。
僕が今の会社に入社した頃の問題は、社内の受発注関係でした。エンジニアが依頼してくる相手に対して「あいつらが…」と言い出す。そこで、いわゆるプロダクトに関わる部分はすべてエンジニアがやる、という形に働き方を変えました。スケッチを含めたプロトタイピングはもちろん、フロントエンドからKPI設計に至るまでエンジニアが行います。そうでないと、自分たちが事業にコミットしていると感じられない。自分たちが会社の中のどういう数字にコミットできているのかを橋渡ししてあげるのが大切だと思います。

CTOmeetup能力と限界

事業規模に適したエンジニア組織を作り出すため、CTOが考え出すべき戦略とは

藤倉:ではここから事業規模とエンジニア規模をどう理解してマネジメントしているか、という話に移りたいと思います。利益から予算を決めて採用するという方法はありますが、ベンチャーは将来の収入がわかりませんから、エンジニアを採用できないという話になってしまう。そういった部分で、みなさんの採用戦略やポリシーがあればお聞きしたいと思います。

岸田:大量採用した際の失敗事例があります。1つのラインに対して急激に5人だったのが10人、20人になったとき、いわゆる団子サッカーのような状態になってしまって、役割が不明瞭になり誰がボールを蹴って得点を決めたらいいのかわからない状況に陥ってしまった。そこで、まずは1つのプロダクトの中でも3人チームをいくつも作り、短期、中期、長期と分類しました。短期の人は直近の一週間や一ヶ月単位の開発。中期の人は数ヶ月かけて、ユーザーがサービスに飽きたときの施策を入れる。長期は半年から1年にかけて新しいアーキテクチャや新プロジェクトをつくるという形にしました。現在はそのあたりのバランスを含めて採用をしています。スケールする段階において、チームメンバーが速度を維持したまま走れるような体制をつくることはとても重要だと痛感しました。

袖山:当社はシリーズAに到達した後くらいのフェーズで、プロダクトマーケットフィットを追っている段階です。ですから、まず全社的なOKR、いわゆる目標設計を行い、その中でエンジニア組織のキーになる数字は何か?ということを定め、実際にエンジニアにその数字を追ってもらう、という仕組みで動かしています。 よくエンジニア側から「このKPIにはどういう事業的意味があるんですか」と聞かれますが、きちんと「プロダクトマーケットフィットを達成するためのオブジェクティブがあり、それを分解していくとこういう数字になり…」と説明できるように設計しています。

中筋:まさしく今日、CFOと予算を含めた3~4年後の話を詰めていました。当社はベンチャーではありますが、商品の企画、生産、店舗の運営、EC、チャネル開発など規模が壮大です。工場を買収してスマートファクトリー化しよう、という話も出ました。
そんな中で大事にしているのは、あるべき姿からの逆算です。そこに対して私がロードマップを引き、予算を組み、開発チームを作る。現在の課題は、それらをすべて私がこなしているため、私自身がボトルネックになっているということですね。

藤倉:開発はいわば果実を収穫する前の栽培のフェーズなので、そこにどのくらいの予算やリソースをかけていいのか、方程式はありません。ただ、ここまでは数字や予算に重きをおいた話になっていますが、エンジニアはお金ではない、という点は重要です。お金とは違い、「色」を持つ人間ですから、採用したエンジニアには成果を出してもらえるように向き合い続けなければなりませんし、そういった視点で開発組織を見ていかなければいけませんね。

Sansan藤倉さん

「本人のキャリアと会社としての成果の両面をすり合わせる」評価制度の意義と課題

藤倉:さて、エンジニアを採用したら当然評価しなければなりませんが、その部分で気にされていることはありますか?

中筋:当社の場合はOKR制度と、会社として3つのバリューがあり、その行動指針に即した行動ができているかどうか、をベースにしています。OKRが6割、行動指針が4割ですね。
気をつけなければいけないのは、数値的な結果は出ていなくても、他者から見てがんばっていると思える人をどう評価するか。結果ベースなら本来評価されない部分をどうケアしていくのか、現在模索中です。

袖山:評価制度を入れたのはいつ頃ですか?

中筋:2年くらい前ですね。OKRを入れたのは去年です。OKRは最初の2、3回はうまくいかないという話がありますが、OKRがMBOになってしまうといった事態もあり、まさしくそのとおりでした。

袖山:うちはまさにこれから導入しようとしているところです。行動指針のようなビジョン評価は非常にあいまいで難しいと思うのですが、どういう基準で評価されているのでしょうか?

中筋:例えば行動指針の一つに“Always Why, Always Run”というものがあります。「常に考え行動せよ」という指針ですが、おっしゃる通り評価はかなり定性的になります。クォーターの頭にエンジニア本人に行動指針に対して具体的にどんな行動を取っていくのかを定義してもらい、クォーターの終わりにマネージャーとパフォーマンスレビューするのが現在のやり方ですが、正直まだ穴は多いです。Amazonでも採り入れていた360度評価を加えられるといいと思うのですが、現状はそこまでできていないですね。

岸田:事業や組織の成長に伴い1年ごとに評価制度のやり方は変えてきていますが、やはり組織がある程度大きくなっていくほど必要度は増しますね。うちがやっているのは、本人が半年後にどのようにになっていたいか、という部分のヒアリングです。個人の方向と会社のビジョンが一致すればするほど大きなパワーがでますから。極力自己実現したい内容に即したタスクを割り振り、本人にも「これを達成する」と宣言してもらう。会社としてもその人のキャリアを評価したいし、個人として成功してほしいという気持ちが大きいんです。その上で、半年後に会社に対してコミットしてもらえたら非常に良いですよね。そのすり合わせに時間を使っています。本人の成長軸による自己実現と、会社としての方向が極力一致するようにする。評価される側が、この会社に1年いてこれだけスキルがついた、と感じられるととても素敵ですよね。同じ仲間と働く中で成長できることがスタートアップの醍醐味だと自分は思っているのでそのような環境を目指しています。プロダクト開発は人が資本なので、それが会社にとって翌年、翌々年のバリューへとつながっていくためです。

袖山:1on1は定期的にやっていると思いますが、その中で評価のフィードバックもするのでしょうか?

岸田:どちらかというとキャリア相談に近い形で1on1をしています。本人がゴールまでの階段を緻密に作れない、段数がわからないとすれば、そのステップを細分化するためのプロセスとして1on1を設けています。

藤倉:エンジニアの評価は成長促進と結果評価、2つの視点があると思いますが、1on1は成長促進の意味合いが強いのかもしれないですね。ただ、成長したからといって必ず結果が出るわけではないですし、成長しなくても成果が出る場合もあります。成果の評価に関しては本人の納得感も重要です。本人の評価と他者の評価がずれてしまったときは、方向性を調整する必要がありますね。

質疑応答

スクラム原理主義はプロダクトの開発を阻害する危険性を孕んでいる

質問者:開発プロセスとして、スクラムやアジャイルなどのフレームワークは活用していますか?

袖山:最初はスクラムをやろうとしましたが、メンバーが会社に来ないことが多いのでスクラムもどきですね。

中筋:システムがいくつかあり、ECはスクラムで、生産管理を行うシステムはウォーターフォール的です。適材適所ですね。

岸田:うちは過去にもいろいろやりましたが、スクラムでやると原理主義的になってしまうケースが多かったように思います。先程の目的と手段の話かと思いますが、チームのレベル感、事業のステージに合わせて導入の深度はコントロールしています。

藤倉:スクラムはもともとプロダクトをいかにクイックに小さい段階の繰り返しで開発を進めるかという話だったはずが、原理原則に縛られて「ウィークリーの振り返りには丸1日使うべきだ」となると、手段と目的がめちゃくちゃになってしまう。そこは気をつけるべきですね。

中筋:スクラムはプロダクトマネージャー、エンジニア、デザイナーという構成で綺麗にチームを作れないとワークしなくなってしまいます。そのあたりのハイアリングもうまくいっていないといびつな形のチームになり、スクラムそのものがフィットしない。現実を踏まえてアジャストする必要がありますね。

藤倉:スクラム的な役割分担でいうところのPO(プロダクトオーナー)をプロダクトマネージャーが担うケースがあると思いますが、我々の世界は小規模のプロダクトを並べていって何か当たればいいというものではなく、「このプロダクト1本で世界を取る」という、勝つか負けるかの勝負をしています。その中でプロダクトの意思決定をスクラムチームの中でしろ、というのはナンセンスです。そういう意味でもスクラム原理主義は難しいですね。

中筋:改善をぐるぐるまわすフェーズで導入する分にはいいと思います。別のフェーズで大きな開発をする段階になったら別の手法にすればいいんじゃないでしょうか。 CTOmeetup能力と限界

ビジネスサイドと密接に絡んだCTOという立場の動き

質問者:CEOやCOOは技術サイドにどの程度関与していますか?また、CTOはビジネスサイドの施策にどの程度関与していますか?

袖山:CEOは技術サイドにほとんど関与していません。何をしているのかは常にCEOに共有しています。逆にCTOとしてはビジネスサイドの企画に対してそれなりに口を出していて、CEOに対して「それが本当にビジネスとしてうまくいくのかどうか」という観点で言いたいことは言っていますね。言い合える仲であることが大切なのではと思います。

岸田:プロダクトはチーム全体として成功するかという部分が大きいので、その中で自分たちが貢献できる部分を明確に定義した上でグロースを目指しますし、月次レポートや、技術的負債、もとい借り入れの返済に関する展望も含めてロードマップとして共有しています。事実を伝えるというだけではなく、それが実現したらどのような素晴らしいことが待っているかなど、ビジョンも含めて伝えるようワーディングを気をつけています。ですからビジネスサイド的な動きは普通にやっているのではと思いますね。

中筋:先程説明したように、数年単位での理想像があった上で私がロードマップを引いているという意味では、関与というよりは協働しているという感じですね。ビジネスサイドにもかなり関与していて、よくない施策やよくわからない設定のKPIは積極的に潰します。

企業の成長フェーズにおいては、緩やかに役割をシフトしていきたい

質問者:企業が大きく成長するフェーズにおいて、自分でコードを書く段階からきっぱりと役割をモードチェンジしたのか、緩やかにシフトしていったのか、過渡期の話をお聞かせください。

袖山:エンジニアが2名しかいなかった最初の1年はとにかくコードを書いていましたが、徐々に変化していきました。最初のきっかけは採用です。技術ブランディングをしようか、エージェントを使って採用をしようかとトライしても、中途半端では全く採用できないんです。本気で売り込みをしないと無理だと判断して徐々にコーディングの割合を減らし、最終的にリソースの7割を採用に使いました。

岸田:僕は両方経験があります。一気に切り替えると文書化できないものを引き継げず失うものが多かったので、今は業務のメインとサブ担当をつけることで、計画的に切り替えるようにしています。コードを書いていても自分がボトルネックになってしまい事業リスクが大きくなったり、コーディングにかけられる時間が1日2時間という中で実装するとコードの全体像が徐々に把握できなくなるため、スピード感を出す上でデメリットの方が大きいと判断し、任せたケースもありました。

中筋:スタートアップにおいてはいろいろな事件が起きるので、緩やかにシフトできないこともあります。私の例で言うと、ある日突然マーケティング部の部長も兼任してくれと言われました。もちろん経験はありません。さらに会社の資金が危うくなり、業務委託の方を減らしたら正社員のエンジニアが体調を崩してしまい、自分がマーケティング部の部長をやりながらコードも書く、という事態になってしまいました。自分ではこうしたいという思いがあっても、外部要因によってできないことはあるので、なかなか難しいですね。

岸田:そのときに必要なことをやるという覚悟が重要だなと思いますね。

袖山:正直CEOよりやることが変わっていく気がします。

藤倉:ありがとうございます。第一部は以上とさせていただきたいと思います。

後半記事に続きます>>


この記事を書いた人
加来麻衣子
加来 麻衣子
flexy マーケティング
ハイスキルのエンジニアやCTOの方にインタビューしたり、flexyメディアの記事を書いています。 〜プロフィール〜2005年上智大学文学部哲学科卒業。オーストラリアからの帰国子女。大手人材会社を退社した後、IT分野で起業。31歳でハワイ現地法人を設立し、投資家兼経営者ビザで渡米。代表取締役として、ワイキキビーチ近くでリテールストアーの運営しながら、海外進出企業コンサルティング、グローバル人材育成の教育分野をハワイのオアフ島にて行う。3年間の海外生活を経て2017年7月にサーキュレーションに参画。Photoshop、Illustrator、Adobe Ae、JavaScript、HTML、CSS、PHPやります。

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

flexyでご案内できる業務委託案件

React

テーマ クラウド入居者管理システムのフロントエンド開発(リモート可)
勤務日数 2-3日/週
報酬 4万円/日
必要スキル React
勤務地 東京
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

Go

テーマ 家族型ロボットのサーバサイド開発
勤務日数 3-4日/週
報酬 5万円/日
必要スキル Go GCP
勤務地 東京
リモート 相談可

AI

テーマ AIを活用した新規事業立ち上げの技術顧問
勤務日数 週1日〜
報酬 5万/日
必要スキル Python、AIの知見、新規事業立ち上げの経験
勤務地 東京
リモート リモートと常駐のMIX

PMポジション

テーマ 複数のプロダクトごとにPMを必要としているため急募
勤務日数 2-3日/週
報酬 5万円/日
必要スキル PMとしての経験、PHP、JavaScript
勤務地 東京
リモート リモートと常駐のMIX
お仕事をお探しの方へ

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)