平 雄飛 | BizFreak CEO | 新規事業専門

東北のソフトウェアエンジニアの力で、日本を変える。― PKSHA Technologyグループインと、その舞台裏 ― どうぞ、ご一読ください！ note.com/taira_yuhi/n/n62ebc…

コードは自分たちで設計する。 でも、開発の「進め方」や「成果の測り方」は、誰が決めるのか。 AIで実装が速くなっても、要件を決める難しさや品質への責任は消えない。 それなのに、人月・人日だけで仕事の価値を測り続けていいのか。 僕らは、タスクの複雑さをストーリーポイントで捉え、AIと人間の担当範囲も見えるようにする「バクソク」を開発し、実案件で検証している。 誰かが決めたルールに従うだけでなく、自分たちで定義し、プロダクトにして、現場で確かめる。 次の開発の当たり前は、エンジニア自身の手でつくれる。

値引きしても、仕様書は勝手に短くならない。 機能も、納期も、必要なテストもそのまま。 安く受注しても、仕事の難易度は下がらない。 もちろん、値引きが合理的な場面はある。 だからこそ、どこで調整するかも決めたい。 提供範囲を見直すのか。 進め方を変えてコストを下げられるのか。 利益を減らす判断を経営が引き受けるのか。 ここを曖昧にしたまま受注すると、 いつの間にか現場の頑張りで成立させる話になってしまう。 値引きの原資を、現場の「何とかします」にしない。

「それ、いつ売上になるんですか？」 研究成果を見るとき、この質問だけで価値を判断するのは危うい。 今すぐ使い道が見つからなくても、将来の技術の土台になる発見はある。 ただし、事業にするなら話は別。 誰が使うのか。 何にお金を払うのか。 採算は合うのか。 そこから逃げるわけにもいかない。 僕らはTOHOKU AI GROUPに参画し、先端研究と企業・自治体の課題をつなぐ役割を担っている。 研究の価値を、短期の売上だけで決めない。 でも、事業化すると決めたら採算まで考える。 「今は事業にしない」と「価値がない」は、まったく違う判断だ。

「一緒に大きなことをやりましょう」 この言葉だけなら、誰でも言える。 でも、事業パートナーを選ぶなら、その先を話したい。 誰のどんな課題を解くのか。 今、なぜ実現できていないのか。 互いの強みをどう組み合わせるのか。 そこまで掘り下げると、同じ未来を語っていても、考え方の違いが見えてくる。 もちろん、金額や条件も大事。 ただ、条件が合うことと、一緒に事業をつくれることは別だ。 組む相手を考えるとき、未来の話の大きさより、その未来をどこまで深く考えられるかを大事にしたい。

反対した人にだけ宿題が増える会議は、だんだん静かになる。 「この納期だと品質が心配です」 「じゃあ、代案を考えておいて」 もちろん、懸念には根拠が必要だし、代案を考えることも大事。 でも、指摘した人がそのまま対策の担当になるなら、次にリスクを見つけても、発言するハードルは上がる。 本来、会議で決めたいのは、 そのリスクを受け入れて進むのか。 追加で検証するのか。 対策が必要なら、誰が担うのか。 反対意見を歓迎するなら、代案の担当まで「言った人」で決めない。

「AI人材を育てた。でも、戻ってきたら何を任せる？」 ここが決まっていなければ、本人がどれだけ学んでも、会社の仕事は変わらない。 実案件を経験するだけでも足りない。 その経験を、帰任後にどの業務で活かすのかまで考える必要がある。 ボルテックスと取り組む「Vターンシップ for AX」では、企業の社員が在籍型出向で僕らのAX案件に参加し、帰任後の推進を見据えた構想書も作成する。 ボルテックスも、帰任後の役割設計を支援する。 育成は「何を学ばせるか」だけでなく、「戻ったら何を任せるか」から逆算して考えたい。

「30秒だけ確認いいですか？」 聞く側は30秒のつもり。 でも、聞かれた側の負担は30秒では終わらない。 不具合の原因を追っていた。 複数の設計を比較していた。 質問に答えた後は、調査の経緯や判断の前提をもう一度頭に戻す時間が必要になる。 「すぐ返せる」を優先しすぎると、「まとまって考えられる」時間が削られていく。 もちろん、障害対応や誰かの作業を止めている相談は、すぐに対応した方がいい。 問題は、急ぐ連絡も待てる連絡も、同じように割り込んでくること。 相談しやすい組織と、いつでも割り込める組織は違う。

「このビール樽を開けるまで、今日僕は帰りません！！」 酒類メーカーの営業時代、深夜の店でそんな延長戦を自分から申し出ていた。 でも、業界の猛者と比べると、僕はお酒が弱かった。 そこで武器にしたのがExcelだった。 仕組みをつくり、仕事を効率化して、売上を伸ばす方法を試した。 他の要因も重なったけれど、ある部門で社内トップの評価を受け、表彰もされた。 お酒に強くなることだけが、営業の勝ち方じゃなかった。 それからは1、2軒飲んだら帰宅。 代わりに社内で叫ぶようになった。 「ITやろうぜ、IT！世の中、マジ仕組みだから」

顧客の話をする会議は増えた。 でも、顧客の話を聞く時間は減った。 組織が大きくなると こんな逆転が起きることがある。 売上も進捗も報告される。 顧客の要望も資料にまとまる。 でも、何に迷っているのか。 何を諦めているのか。 そこまでは伝わらないこともある。 管理を整えるのは必要。 ただ、顧客がいつの間にか 会議の議題にしか登場しなくなっていないか。 顧客について話す時間と 顧客を理解する時間は別です。

専門家を呼ぶのが遅いと 小さな確認が、大きな手戻りに変わる。 例えば、外部APIを使うシステム。 実装が進んでから 「この仕様では必要なデータが取得できない」 と分かれば 画面やデータ設計まで見直すことになる。 だから専門家を呼びたいのは 問題が起きてからだけではない。 技術の制約を前提に 仕様や納期を決める前だ。 もちろん、すべての会議に呼ぶ必要はない。 大切なのは 後から変えるほど影響が広がる判断を見極め 必要なタイミングで知識を借りること。 相談のタイミングも プロジェクトの設計の一部です。

「このAIは高精度です」 そう説明されても 導入する側は何を任せていいか判断しにくい。 例えば、書類を読み取るAI。 通常の書類では問題なくても 手書きやレイアウトが崩れた書類では 確認が必要になる場合がある。 顧客が知りたいのは 「AIにもミスがあります」という注意書きではない。 どんな条件で間違いやすいのか。 どの書類は人が確認すべきなのか。 間違いが起きたらどう対処するのか。 そこまで説明できて初めて 顧客は安心して使い方を決められる。 AIの性能を説明できることと AIを仕事で使えるようにすることは別。 弱点まで伝えられることも技術力だ。

「まだ検証中です」 新規事業で厄介なのは この言葉をいつまでも使えてしまうこと。 顧客の反応が薄ければ「まだ知られていない」 使われなければ「機能が足りない」 売れなければ「営業が弱い」 どれも可能性はある。 でも、確かめずに次の投資理由にしてしまうと、いつまでも結論が出ない。 だから、事業を始める前に決めておきたい。 何を確かめるのか。 どんな結果なら方針を変えるのか。 どこまで試したら撤退も考えるのか。 撤退条件は、挑戦を諦めるためではない。 続ける理由を、後から作らないためのものだ。

「今回だけ」の追加対応が 何年も残るコストになることがある。 その顧客だけ違う表示。 その顧客だけ違うデータ形式。 その顧客だけ必要な例外処理。 実装するときは小さな変更でも 共通機能を改修するたびに 個別仕様への影響を確認する必要が出てくる。 一社への対応が増えるほど 新しい機能の開発より 既存の例外を守る仕事が増えてしまうこともある。 だから、特別対応を考えるときは 作る工数だけでは足りない。 その仕様を、いつまで維持するのか。 ほかの顧客にも使える形にできないか。 顧客の要望に応えることと 開発を続けられる状態を守ること。 両方を考えて判断したい。

AIに「根拠は？」と聞く。 出典が出てきて安心する。 さらに「本当に正しい？」と聞く。 でも、それでは 同じ相手に答案も採点も任せている。 確かめたいなら 元資料を開いて、AIの説明と照らし合わせる。 出典が付いたのは 確認が終わった合図ではない。 確認する場所が分かっただけです。

「自由にやっていい」と言って 毎回ゼロから考えさせるのは違う。 申請の判断基準。 リリース前の確認項目。 トラブル時の一次対応。 前にも答えが出たことなのに 担当者が変わるたびに議論し直す。 それは裁量というより 判断のやり直しです。 繰り返す判断は仕組みに残して 新しい問題は現場が決める。 良い標準化は 自由を削るのではなく 自由に使える時間を取り戻す。

現場が優秀なほど 会社の問題が見えなくなることがある。 毎回、別の表を作って確認する。 詳しい人に聞いて答え合わせする。 最後は手作業で数字を合わせる。 それでも仕事は終わる。 大きなトラブルも起きない。 でも、それは問題がないのではなく 誰かが毎回、問題を引き受けているだけかもしれない。 だから、顧客に何が欲しいかを聞くだけでは足りない。 「今はどうやって、その仕事を終わらせていますか」 当たり前になった手間の中に 本当に解決すべき課題が隠れている。

「アプリを作れるか」より 「そのアプリを使ってもらえるか」。 以前、不動産の新規事業で 情報を届ける仕組みを検討したとき 僕らが提案したのは、ブラウザから使えるWebアプリ（PWA）だった。 利用する企業によっては アプリをインストールするだけでも 社内での申請や承認が必要になる。 せっかく良いものを作っても 使い始めるところで止まってしまっては意味がない。 だから、技術の選択は 開発のしやすさだけでは決められない。 誰が、どんな環境で使うのか。 導入するときに何が障壁になるのか。 作れるものを提案するだけでなく 使い始められる方法まで考えたい。