Pinned Tweet
【本気のエンジニア募集中!最後までお読みください】
「IT企業はどこも似たようなもの」と思ってませんか?
YAZには20年かけて培った、他社とは違う"こだわり"があります。
1. 技術を好きなエンジニアが、技術で評価される
マネジメント以外のキャリアパスもしっかり用意。TrueColorsで技術力を「見える化」し「コードを書くのが大好き」な人を正当に評価します。
2. 新技術への挑戦を推進する
2009年、Android OS1.6の時代から「きっとできるよ」と飛び込み、今の強みに。「新技術勉強会」「もくもく会」で常に最新技術に触れる機会を創出しています。
3. 地方拠点×リモートで働く場所からの解放
「優秀なエンジニアこそ、働く場所にしばられない環境を」という考えで、東京以外にも拠点を展開。7割のメンバーがリモートワークで活躍中です。
4. 個人の成長が会社の評価につながる
「社員の成長なくして会社の成長なし」が信念。目標立案、プロジェクトアサイン、フォロー、評価を徹底し、エンジニアの成長を加速させます。
5. 本物の繋がりを大切にする文化
リモート推進の一方で「人と人との繋がり」も重視。BBQやボルダリングなど、健康経営を取得したYAZは、体を動かしながら交流する機会を積極的に設けています。
YAZが求めるのは「技術が好き」「人と繋がるのが好き」「勉強好き・素直・プラス思考」なエンジニア。経験や年齢より、そのマインドを大切にしています。
「輝く人材を輩出し、輝く社会を創造する」
一緒に技術の力で世界を変えていきませんか?本気のエンジニア、待ってます!
内定者研修で、ある学生の作業画面を覗いて驚きました。タスクを受け取った最初の動作が、考えることでも調べることでもなく、AIに全体の段取りを聞くことだったんです。
AIネイティブって「AIに詳しい世代」ではなく「AI前提で段取りを組む世代」だと思っています。観察していると、速さの源はツールの知識ではありませんでした。
・ゴールを決めたら、まずAIに任せる範囲から設計する
・自分の頭を使う場所を、先に絞り込んでいる
・「自分で全部やる」という選択肢が、最初から無い
私たちの世代は、自力でやる段取りを組んでから、AIを後付けします。彼らは逆で、AI込みの段取りが標準装備。順番が逆なだけで、できあがる仕事の速さがまるでちがう。
ツールの習熟は追いつけます。前提の違いは意識しないと追いつけません。
だから私は最近、着手する前に一度だけ自問します。「これ、最初からAI前提で組んだら、どこから始める?」
ネイティブに追いつく方法はたぶんこれしかありません。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
まさにコレ😙
オフショア開発の上位版
ここだけ踏まえておけば
日本語問題ないし即レスなので最高🥳
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
AI駆動開発、手戻り対応はシビアだからなぁ。まんまトークン消費に跳ね返る。対応は速いから発注側は混乱しそう。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
要求仕様の定義の不完全さに対するアンチテーゼとしてのTDDは、AI時代になってより有効に機能すると思う。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
結局、こういう失敗エピソードがいちばん勉強になる。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
広告でも、まったく同じことが起きています。
代理店に「いい感じに集客して」と丸投げして失敗した会社は、いまAIのおまかせ配信でも同じ失敗をしている。相手が代理店からAIに変わっただけです。
AIに渡す前に決めておきたいのは3つ。
❶何を成果とするか
❷どの数字で測るか
❸どんなお客様に来てほしいか
ここが曖昧なまま任せると、AIは間違った成果を効率よく集めます。
頼む相手が変わっても、問われるのは頼む側の判断。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
ぶっちゃけそうな面もあるが、必要なことであればペンディング管理し、リスクとして共有して、必要な情報を工程途中でも柔軟に取り入れる余地の有無ってのも大きいんだよなぁ。
つまり、「工程管理」が大事。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
(´・ω・)それはそうです。バカには遂行できないのです。
(オフショア開発ガチ勢の意見です)
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
考えるのが嫌な人がオフショアに頼むからなー。ちょっと考えたらそんなことしないだろうし、じっさいお客さんはプライドだけ高くて金は使いたくないバカばっかりだったもんね。
まあ頭を使えるんだったら自分で作るしな。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
じつは、弊社の理念「輝く人材を輩出し、輝く社会を創造する」は、きれいごとから生まれた言葉ではありません。怒りから生まれた言葉です。
私がエンジニアだった2000年頃から、ずっと引っかかっていることがあります。海外ではソフトウェアエンジニアが手厚い待遇を受けているのに、日本では薄給で、環境も整っていない。IT産業全体の立ち位置も、低いまま。技術が好きで、腕もあるのに、職業としての誇りを持ちにくい。
この構造を、まず自分の会社の中から一つずつ裏返したかった。だから理念の主語は「事業」ではなく「人材」です。
20年以上経って、まだ道の途中です。ただ、エンジニアの価値を上げるという仕事だけは一度もブレたことがありません。
理念は、飾る言葉ではなく、怒りの置き場です。
この理念に込めた想いは、Wantedlyに1本の記事として残してあります。創業の原点は、ここです↓
wantedly.com/companies/yaz/p…
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
AI駆動開発で怖いのは、仕様が曖昧でも、それらしいものが短時間でできてしまうことです。
従来の開発なら、確認や調整に時間がかかることで、曖昧さに気づく機会もありました。
AIでは、その確認を飛ばしたまま実装が進んでしまうことがあります。
だから私は、開発速度を上げるほど、判断と検証の責任を明確にすべきだと考えます。
誰が要件を承認するのか。何をもって完成とするのか。問題が起きたらどう戻すのか。
AIがコードを書けても、その判断まで引き受けてくれるわけではありません。
つくる力が強くなるほど、つくってよいかを判断する力が問われる。
ここを外してはいけないと思います。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
システム開発の話かと思って読み進めたら何となく既読感、、、。いやいや、これ仕事してる人全員に当てはまる話やん
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
受発注者の言語化能力が低いと、仕様が曖昧になりがちです。
結果、成果物が、発注者が想定していた期待値とずれて揉めます。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
オフショア開発ってなに…と思ったら、ちゃんと記事で解説されてた。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
「相手が海外のチームからAIに変わっただけ」という見方、とても面白いです!
AIに仕事を任せるときも、うまくいくかどうかは「何を作るかを先に決めきれるか」で決まる。私も毎日AIを使っていて、本当にそう感じます。
オフショアの失敗から今に通じる教訓を引き出す視点、さすがです!
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
「なんで1年目はテスト作業ばかりなんですか」
毎年、新人エンジニアから聞かれる質問に、いまは胸を張って答えられます。AI時代にいちばん効くスキルの訓練だから、です。
AIがコードを書く時代、人間の仕事の重心は「書く」から「検証する」へ移っています。
AIの出力は、動くけれど、正しいとは限らない。その差分を見抜く目がどこで育つかというと、テストなんです。
・仕様と実装のズレを疑う目
・「動いた」と「正しい」を区別する基準
・自分のシステムを多角的に攻める想像力
テスト設計の甘さは、自分への甘さと比例します。逆に、ここが厳しい人は、AIのコードレビューでもそのまま強い。
地味な工程は、消えていく工程ではありません。AIが書けば書くほど、検証の価値だけが上がっていくので。
テストは、下積みではなく、品質という専門職の入口です。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
AIは言葉を代弁するけど、AIに話しかける言葉を紡ぐのは人間。でもAIで言葉を紡ぐ力は落ちてる。このループに気づいてる人は、自分で言葉をひねりだすことを日常で意識してる。このあたりの意識の差はこういうビジネスシーンで顕著に出そう。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
このシーンにぶつかる案件をまさに垣間見ました。やりたいことをクリアにしないまま投げて出来上がるのは曖昧なものが出来上がるのは自明ですよね。
それを作る側に委ねるならばあなたは何者ぞ?ということに。
AIだとすぐ結果がわかるから曖昧チェックに使って気づくのも一手。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。
やじゅ社長🍎田中康之|エンジニア採用強化中! retweeted
自分も過去にオフショアで失敗しました。
失敗しても良い範囲で始めていたので軽く済みましたが、原因は相手ではなく、こちらの仕様の伝え方でした。
相手がAIに変わっても、同じ失敗は起きる。「オフショア」を「AI」に読み替えると、とても分かりやすい話です。
おもしろい法則を見つけました。昔オフショア開発で失敗した会社は、いまAI駆動開発でも、同じ失敗をしています。
オフショアの失敗原因は、だいたいこうでした。
・仕様を曖昧なまま投げて、出てきたものに驚く
・「言わなくてもわかるだろう」の暗黙知が通じない
・手戻りのやり取りで、安いはずのコストが膨らむ
AI駆動開発の失敗、まったく同じ構造です。相手が海外のチームからAIに変わっただけ。
共通する教訓はひとつで、作る前に要件を決めきる力が、作る力より先に試されるということ。揺るがない要件があれば、外部設計も内部設計も自明に決まっていく。曖昧なまま走ると、相手が人でもAIでも、時間だけが溶けます。
開発の相手は変わり続けますが、頼む側の力は、ずっと同じものを問われています。























