数式の正誤判定で1か月遠回りした話――未知領域の技術調査で間違えたこと

テックリードを担当したプロジェクトで、数式の正誤を判定する機能の技術検証に1か月以上を使ったことがあります。

最終的には、数式をAST（抽象構文木）として扱うことで、必要としていた判定を実装できました。

しかし、今振り返ると、ASTを知らなかったこと自体が最大の問題だったわけではありません。

問題だったのは、未知の技術領域を調査する際に、探索期間、評価基準、レビューのタイミング、打ち切り条件を決めていなかったことでした。

この記事では、どのように遠回りしたのかと、次に同じ状況になった場合にどう進めるかを整理します。

作ろうとしていたもの

プロジェクトでは、ユーザーが入力した数式について、期待する式として正しいかを判定する必要がありました。

単純な文字列の一致判定だけでは対応できません。

例えば、表記が異なっていても、構造上は同じものとして扱いたいケースがあります。一方で、文字列が似ていても、異なる式として扱う必要があるケースもあります。

さらに、途中式を扱うため、最終的な計算結果だけではなく、入力された式の構造も考慮する必要がありました。

私はこの領域に詳しいわけではなかったため、まず実装方法の調査から始めました。

AIに案を出させ、プロトタイプを繰り返した

当時は、主に次の流れで技術検証を進めていました。

1. AIに複数の実装方法を提案させる
2. 提案の中から実現できそうな方法を選ぶ
3. 小さなプロトタイプを作る
4. プロトタイプの問題点をAIへ伝える
5. 改善案を出させる
6. 別のプロトタイプを作る

一つの方法で問題が起きるたびに、条件を追加したり、別の方法を試したりしていました。

AIから提案された方法をそのまま採用していたわけではありません。自分でも内容を確認し、実際にコードを書いて動作を検証していました。

そのため、当時は適切に技術検証を進めているつもりでした。

しかし、実際には、解決方法を探索するループを回し続けているだけでした。

局所的な改善を繰り返していた

最初に試していた方法では、新しい入力パターンが見つかるたびに、個別の処理を追加する必要がありました。

あるケースを解決すると、別のケースで問題が起きます。

その問題を修正すると、以前動いていたケースが動かなくなることもありました。

この時点で、

現在の実装方法ではなく、問題の表現方法そのものが適切ではないのではないか

と考えるべきでした。

しかし、実際には既存の方法を改善する方向で検証を続けました。

プロトタイプを作ること自体が目的に近づき、そもそもの問題設定を見直すタイミングを失っていました。

ASTを使う方法に辿り着いた

AIとのやり取りを繰り返す中で、数式をASTとして扱う方法が提案されました。

ASTは、プログラムや数式を単なる文字列ではなく、構造を持ったデータとして表現するものです。

例えば、足し算や掛け算、変数、数値といった要素をノードとして扱います。

文字列を直接比較する方法では、表記上の差異や括弧の扱いによって、条件分岐が増えやすくなります。

一方で、ASTへ変換すると、少なくとも今回必要としていた範囲では、数式の構造を基準に処理を組み立てられるようになりました。

ASTを使ったプロトタイプを作ると、それまで個別のルールを追加しながら対応していた問題を、より一貫した形で扱えるようになりました。

結果として、この方針で実装を進めることになりました。

ASTを知らなかったことだけが問題ではない

後から、プロジェクトメンバーの一人が、ASTを使う方法を知っていたことが分かりました。

ただし、その人に自発的に知識を共有する義務があったとは考えていません。

私から、

• 数式処理に詳しい人はいないか
• コンパイラやパーサーに関する経験者はいないか
• 現在の方式に根本的な問題がないか

といった形で、レビューを求めることもできました。

それをせず、自分とAIだけで検証を続けたのは、技術調査を担当していた自分の判断です。

未知の技術に遭遇した際、最初から適切なキーワードや経験者を知っているとは限りません。

ASTにすぐ辿り着けなかったこと自体は、避けられなかった可能性があります。

しかし、1か月以上にわたって同じ探索方法を続けたことは、調査プロセスの設計で防げたと思います。

何が不足していたのか

振り返ると、当時の技術検証には、主に五つの不足がありました。

調査期間の上限を決めていなかった

「いつまでに方針を決めるか」を設定していませんでした。

そのため、プロトタイプに問題が見つかるたびに、次の改善を試すことができました。

試せる方法が残っていることと、その方法を試し続けるべきことは別です。

期限を決めていなければ、技術調査は際限なく続けられます。

比較基準を決めていなかった

複数の方式を比較するための評価軸も明確ではありませんでした。

例えば、事前に次の基準を決めるべきでした。

• 対応できる数式の範囲
• 誤判定の可能性
• 新しいパターンを追加する際のコスト
• テストのしやすさ
• 実装の複雑さ
• 性能
• 保守性

実際には、「現在見つかっているケースが動作するか」を中心に評価していました。

そのため、局所的には動くものの、拡張しにくい方式を早い段階で除外できませんでした。

プロトタイプの終了条件がなかった

プロトタイプには、本来は検証したい仮説が必要です。

しかし、当時は実装を改善すること自体が継続的な作業になっていました。

例えば、

代表的な20ケースを処理できなければ、この方式は不採用にする

といった終了条件が必要でした。

終了条件がないため、問題が発生しても、方式を捨てるのではなく修正を続けていました。

外部レビューを早期に入れなかった

未知の領域であるにもかかわらず、一定期間ごとに他のエンジニアへレビューを求める運用を作りませんでした。

コードレビューではなく、

• 問題の捉え方が正しいか
• 一般的な解法を見落としていないか
• 似た問題を扱った経験者がいないか

という、調査方針自体のレビューが必要でした。

標準的な手法を探す工程が弱かった

当時は、「この要件をどのように実装するか」を中心にAIへ質問していました。

しかし、先に調べるべきだったのは、

• 数式処理では一般的にどのようなデータ構造を使うのか
• 数式パーサーはどのように実装されているのか
• コンパイラでは構文をどのように扱うのか
• 類似するOSSや既存ライブラリがどのような設計をしているのか

という、既存技術の調査でした。

個別要件に対する解決案だけを求めたため、一般化された解法へ辿り着くまで時間がかかりました。

AIの性能が原因だったのか

現在のAIモデルで同じ質問をすれば、より早い段階でASTが提案される可能性はあります。

当時よりも、コード生成や技術的な問題分解の能力が向上していると感じる場面もあります。

ただし、今回の失敗をAIの性能だけで説明するべきではありません。

仮に最初から正しい案が提案されていても、その案を選択できるとは限りません。

また、AIが複数のもっともらしい案を提示した場合、どの案を採用し、いつ検証を終了するかは、人間側で決める必要があります。

AIは探索の速度を上げられますが、探索を管理してくれるわけではありません。

• 何をもって成功とするか
• いつまで調査するか
• どの時点で他者へ相談するか
• どの条件で方式を捨てるか

これらは、技術調査を担当する人間が設計する必要があります。

テックリードとして何をするべきだったか

テックリードとしての反省は、最適な技術を最初から知っていなかったことではありません。

未知の領域であると認識しながら、調査方法を管理しなかったことです。

当時、次のような進め方をしていれば、遠回りを短くできた可能性があります。

最初に調査期間を決める

例えば、最初の技術調査を3営業日や1週間に限定します。

その期間内に有力な方式を決められなければ、同じ方法で調査を続けず、調査体制や問題設定を見直します。

評価軸を先に作る

コードを書く前に、候補となる方式を比較する表を作ります。

今回であれば、以下のような観点です。

すべての項目を同じ重みで評価する必要はありません。

ただし、方式を選ぶ基準を先に定義することで、その場の印象だけで判断することを防げます。

プロトタイプごとに仮説を一つに絞る

「正誤判定機能を完成させる」という目的でプロトタイプを作るのではなく、検証内容を限定します。

例えば、

• 数式を安定してパースできるか
• 表記の異なる式を同じ構造へ変換できるか
• 必要な演算子を扱えるか
• 誤った入力を検出できるか

といった単位です。

仮説を検証できたら終了し、検証できなければ方式を見直します。

数日ごとに方針レビューを入れる

未知領域の調査では、実装のレビューだけでは不十分です。

数日単位で、別のエンジニアに次の内容を確認してもらいます。

• 問題設定
• 調査した方式
• 採用しなかった方式
• 現在のボトルネック
• 次に試そうとしていること

コードの正しさよりも、探索範囲に抜けがないかを確認してもらいます。

経験者を探す

チーム内に経験者がいないと決めつけず、質問を公開します。

「この要件の答えを知っている人」だけでなく、

• パーサーを実装したことがある人
• コンパイラを触ったことがある人
• 数式ライブラリを利用したことがある人
• 類似機能を作ったことがある人

まで範囲を広げれば、適切なキーワードを早く得られた可能性があります。

次回の技術調査で使うルール

今後、未知領域の技術調査を担当する場合は、次のルールを使います。

1. 調査開始時に、判断期限を決める
2. 必須要件と、対応しない要件を分ける
3. 候補方式の評価軸を先に決める
4. 既存の標準手法、OSS、論文、ライブラリを調べる
5. プロトタイプごとに、検証する仮説を一つにする
6. 採用条件と打ち切り条件を決める
7. 数日単位で調査方針のレビューを入れる
8. チーム内外の経験者を探す
9. AIの回答だけで探索範囲を決めない
10. 期限までに決まらなければ、同じ方法で調査を延長しない

未知の領域では、最初から正解へ辿り着くことは保証できません。

一方で、正解へ辿り着けていない状態を、長期間放置しない仕組みは作れます。

まとめ

数式の正誤判定機能について、私はAIに実装案を出させ、プロトタイプと改善を繰り返しました。

最終的にはASTを使う方法に辿り着き、必要な実装を進められました。

しかし、そこまでに1か月以上かかりました。

反省点は、ASTを最初から知らなかったことではありません。

• 調査期間を決めなかったこと
• 評価基準を作らなかったこと
• プロトタイプの終了条件を決めなかったこと
• 調査方針のレビューを入れなかったこと
• 経験者を探さなかったこと
• 標準的な解法を調べる工程が不足していたこと

です。

未知の技術領域で遠回りすること自体は、完全には避けられません。

しかし、遠回りを数日で検出するか、1か月続けるかは、技術調査の進め方によって変えられます。

テックリードに必要なのは、すべての技術的な正解を知っていることではありません。

分からない問題に対して、探索範囲、期限、評価方法、相談先を設計し、正解に辿り着いていない状態を管理することだと考えています。