スキルの前に領域が必要だと感じた日
案件と人材のフィルタは、スキルを先に並べるよりも、領域から選ぶ方が仕事の違いを自然にたどれると私は考えました。
この発想が出てきたのは、2026年6月24日にサンプル画面を見ながらフィルタについて話していたときです。
画面を共有した私は「これがやっぱりちょっと必要かなって思っていて」と切り出しました。
そこで考えていたのは、スキルの選択肢を増やすことだけではありませんでした。
案件が開発なのかインフラなのか、あるいはヘルプデスクなのかという大きな違いを先に分ける必要があるという話です。
人材についても同じで、この人がどの領域を主にしているのかが最初にわからなければ、その後の条件を選びにくくなります。
開発とインフラではスキルの地図が違う
開発とインフラを同じスキル一覧で扱うと、必要な選択肢と関係の薄い選択肢が混ざるため、探しづらくなると感じました。
打ち合わせでも私は「開発とインフラって全然スキル違うじゃん」と話しています。
開発を選んだときに見たいのは、JavaやPython、C#といったプログラミング言語です。
一方でインフラを選んだときは、クラウド、オンプレミス、ネットワークという分け方が先にあり、その中に各技術の選択肢があります。
つまり、スキルは常に同じ一覧から選ぶものではなく、先に選んだ領域によって見える内容が変わる方が自然です。
「一番最初にこれが来るのよ」という言葉は、領域をフィルタの先頭に置きたいという感覚をそのまま表しています。
ただし、この時点では理想の見え方を話していた段階です。
「できるかどうかとかってのを置いといて」と付け加えたように、実現方法まで決まっていたわけではありません。
領域の次に工程を置きたい理由
領域を選んだ後は、要件定義や設計、開発、テストといった工程で分けると、担当してきた仕事の段階を見やすくなると考えました。
同じ開発領域でも、上流から関われる人を探している案件と、実装やテストを中心に任せたい案件では必要な経験が違います。
案件側では、どの工程を任せたいのかを確認したいです。
人材側では、どの工程を経験し、どこまで対応できるのかを確認したいです。
領域だけでは広すぎますが、いきなり細かなスキルへ入ると仕事全体の位置が見えにくくなります。
そこで領域とスキルの間に工程を置けば、仕事の大きな区分から具体的な経験へ順にたどれます。
これは項目を増やすためではなく、営業担当の方が案件と人材を見比べるときの順序を画面に反映するための整理でした。
PMとリーダーとメンバーを役割として分ける
工程とは別に、PM、リーダー、メンバーという役割を分ける必要があると考えました。
案件側ではリーダーポジションなのかメンバーポジションなのかを確認し、人材側ではその人がリーダーを担えるのかメンバーとして入るのかを見たいからです。
打ち合わせではPMをどこに置くかで少し迷いました。
最初は「PMはちょっといいや置いとくわ」と話し、開発やインフラの中に含まれるため、領域として扱うのは違うのではないかと考えました。
その後に話を続けるなかで、PMの下にリーダーがいて、その下にメンバーがいるという並びが見えてきました。
この整理なら、PMは開発やインフラと並ぶ領域ではなく、仕事の中で担う役割として置けます。
分類に迷った項目は無理に押し込まず、何を表す言葉なのかを会話しながら分け直しました。
商流制限と経験年数も外せなかった
領域、工程、役割だけでなく、案件側の商流制限と人材側の経験年数も確認できるとよいという話になりました。
案件側では、どこまでの商流を対象にするのかという条件があります。
人材側では、特定の領域やスキルに何年関わってきたかが判断材料になります。
ただし、これらを領域や工程と同じ階層に置くのか、別の条件として並べるのかまでは、この打ち合わせで決めていません。
私は「経験年数があるとよりいいかな」と話しており、必要性を感じながらも、画面とデータの両方でどう扱うかは検討中でした。
フィルタを増やすほど探し方は細かくなりますが、入力や判定の負担も増えます。
必要そうな条件をすべて並べるのではなく、何を先に選び、何を補助条件にするかまで考える必要がありました。
AIにどこまで判断させられるか迷った
フィルタの形を思い描けても、メールの文章から領域、工程、役割、経験年数をAIが安定して判断できるかは別の難しさがあります。
私はこの点を「どこまでこうAIで見て判断していけるのかな」と口にしました。
開発やインフラのように比較的大きな領域でも、メールの書き方がいつも同じとは限りません。
工程や役割は、明確な名前で書かれる場合もあれば、担当内容から読み取らなければならない場合もあります。
経験年数についても、数値がそのまま書かれているとは限りません。
そのため、画面に項目を置けることと、裏側で信頼できるデータを用意できることを分けて考えました。
「こう探せたらよい」という理想と「AIがどこまで判断できるか」という現実の間に、まだ確かめるべきことが残っていました。
案件と人材をいきなりAIだけで比べず、段階を分けて候補を絞る考え方はこちらで紹介しています。
AIマッチングはどう案件と人材を結びつけるのか｜2段階フィルタの仕組み
まずサンプル画面で確かめることにした
AI判定やデータ加工へ進む前に、まずサンプル画面でフィルタの順番と見え方を確認することにしました。
打ち合わせでは「このサンプルの画面のところをここの仕様に一回しましょう」という進め方が提案されました。
先に画面へ領域、工程、役割を置けば、実際に選ぶときの順番が自然かを目で確認できます。
開発を選んだ後に開発向けのスキルが並ぶのか、インフラを選んだ後にインフラ向けの分類へ進めるのかも確かめられます。
その画面を見て「こうしたい」という認識を揃えてから、裏側のデータをどう加工するかを考える順番です。
裏側を先に作り込んでから画面の違和感に気づけば、直す範囲が広がります。
だからこの場では、完成形を決めたことにせず、サンプル画面を使って考えを確かめる段階を挟みました。
受信メールの件数上限について同じ打ち合わせで考えた内容は、開発日記#1にまとめています。
【開発日記#1】受信メールが「とんでもない数」になる問題とどう向き合っているか
処理する場所そのものを見直したローカル処理案は、開発日記#2で振り返っています。
【開発日記#2】ローカル処理という発想｜検討して一旦見送った理由
まとめ｜順番を決めてから仕組みを作る
今回のフィルタ設計で私が大切だと感じたのは、細かなスキルを最初から並べるのではなく、領域、工程、役割という順番で仕事を整理することです。
開発とインフラではスキルの体系が違い、同じ領域でも担当工程や役割が違います。
商流制限や経験年数も必要な条件ですが、どこに置き、AIがどこまで判断するかは簡単に決められませんでした。
だからこそ、まずサンプル画面で選び方を確かめ、認識を揃えてから裏側のデータ加工へ進むことにしました。
この順番なら、実現できるかだけでなく、営業担当の方が本当に探しやすいかを見ながら設計を続けられると考えています。
