3. 伊藤忠商事・CTCのデータ活用で生きるスキル 求人の必須条件と経験の伝え方
「統計ができる」と言えても、それだけではどの仕事に合うかわかりません。伊藤忠商事の内製分析組織が支えるのは、業務上の相談からデータの整備や分析までです。一方、伊藤忠テクノソリューションズ（CTC）の中途向け開発職には、設計や品質を指導した経験まで明記した求人があります。必要な力を調べるときは、まず求人票で応募条件を確定し、そのうえで目指す仕事に生きる経験を探すと整理できます。
公式求人から読み取れる必須・歓迎の境界
必須要件の例はCTCの中途開発職
CTCの「開発分野・システムエンジニア（事業グループ不問）」は、顧客向けのアプリケーション開発や製品導入を担う中途求人です。必須欄には、設計を含むプログラミング経験が5年以上あること、サブリーダーとして開発者への指示や設計指導、品質確認ができること、顧客・ベンダーとの交渉を含むコミュニケーション能力が挙がっています。言語の指定はありません。この要件が適用されるのは、この開発職への応募です。
歓迎要件は責任の広がりを示す
同じ求人の歓迎欄には、30人月以上のプロジェクトでのリーダー経験、開発のリーダーまたは補佐としての管理やベンダー調整が挙がっています。人月は仕事量の単位で、人数だけを示す値ではありません。たとえばリーダー経験を説明するときは、人数、期間、任された判断を一緒に書くと、読み手は規模も役割も理解できます。
伊藤忠商事の新卒募集要項は総合職とビジネスエキスパート職の応募条件を示しています。ここにCTCの開発経験年数を写し込むことはできません。ITC BICCの支援内容からも、同組織の中途採用に固有の必須・歓迎要件はわかりません。以下は公表された事業を理解し、自分の経験を振り返るための考え方です。
課題設定の力は、分析の前に交わす質問に表れる
「在庫を減らしたい」と相談されたとします。少なくとも、どの商品を、どの拠点で、どの程度の欠品まで許容して扱うかで答えは変わります。店舗には欠品を避ける理由があり、倉庫には保管費を抑える理由があります。両者の目的を書き出し、どちらか一方に負担を移す改善案になっていないかを考えるところから、分析を設計できます。
事業を理解していることは、業界用語をいくつ使えるかより、観測値についてどんな仮定を置いたかに表れます。「売れた数」を「欲しかった数」として扱ってよいでしょうか。棚が空だった時間帯は、欲しい人が来ても販売数が増えません。発注の相談であれば、在庫が切れた日を識別できるか、識別できない場合にどんな誤差が残るかを最初に聞く価値があります。
伊藤忠商事と日本アクセスの発注の事例では、小売の販売・在庫などと卸の入出荷、商品別の発注単位などを組み合わせています。企業をまたぐデータが必要になる理由を、この事例に即して説明できます。応募時に同じ食品業界の経験がなくても、自分の業界で「現場に聞いて初めてデータの意味がわかった」経験を振り返ってみましょう。
分析設計と統計の力は、何と比べるかでわかる
予測の成績を報告するなら、比較相手を用意します。需要に曜日差があるなら、先週の同じ曜日の実績を使う方法も有力な基準です。学習期間を長くした複雑なモデルが、この単純な予測より良いのか。改善が特定の商品や催事に集中していないか。誤差が大きい日を実際に開き、何が起きたか説明できるところまでが検証です。
効果を測る分析では問いが変わります。発注方法を変えた翌月に在庫が減っても、季節による販売増や仕入先の納期短縮が影響したかもしれません。比較できる拠点を選ぶ、曜日の構成をそろえる、導入前からの変化を見るなど、偶然の差を施策の成果と読み違えにくい設計を考えます。比較対象を作れないときは、観察できた変化と、理由についての仮説を書き分けます。
データ処理にも判断が伴います。ある拠点だけ記録のない日が続くとき、それを販売ゼロとして埋めると、その拠点の需要を低く見積もります。元の記録が抜けているのか、休業だったのかを確認し、結論が変わりそうなら扱いを変えて比較しましょう。欠損を何件除いたかと、除いた記録がどこに偏ったかを説明できれば、数字を作った過程が伝わります。
もう一つ練習したいのは、集計の分母を説明することです。返品率が上がったとき、分母を出荷件数にするか出荷個数にするかで、まとめ買いの多い取引先の見え方は変わります。自分が選んだ定義を示し、別の定義でも傾向が保たれるかを確かめてください。定義を変えると結論が逆転するなら、その違い自体が、業務担当者と相談すべき重要な発見になります。
提案力は、相手が選べる形にして示す
現場に「誤差が下がった」と報告しても、そのまま発注を変えてよいかは判断できません。「通常商品は推奨値を使い、販促対象は担当者が確認する」という案なら、試せる範囲と残る負担がわかります。さらに、誰がいつ判断するか、意見が分かれたらどの数字を見直すかを決めておくと、提案が次の行動につながります。
資料の作り方にも工夫の余地があります。店長には、今日確認する商品とその理由を一枚にまとめます。分析担当には、推奨値の計算方法、例外処理、誤差の分布を残します。一つの発表資料にすべてを盛り込む必要はありません。誰に何を渡したかで自分の仕事を整理すれば、会議の回数を並べるより、協働の中身がよく見えます。
実装・運用を見通せる人は、引き渡し条件を決められる
現場に渡す前に、使ってよいデータの範囲、数字が届く時刻、更新に失敗したときの扱いを決めます。前日の値を再表示するだけでは、今日の計算結果だと誤解されるかもしれません。更新日時を表示する、異常がある場合には推奨を止めるなど、利用者の判断に影響する条件を開発者と相談できれば、分析担当として実装に貢献できます。
運用に入った後は、計算が正しく動くことと、その結果が役立つことを別々に追います。使われなくなった理由が精度なのか、締め切り後に届くからなのかで、直す箇所が違います。業務に入れる前の仮説を記録し、利用者の声や操作記録から見直した経験は、改善を継続する力として説明できます。
面接で見せやすい、小さな引き渡しの例
分析結果を別の担当者に渡した経験を一つ思い出してください。月次報告を後輩に引き継いだ場合なら、数式を説明したことに加えて、どの数字が急に動いたら元帳を開くかを伝えたかがポイントです。翌月、後輩が自分で異常に気づいて修正できたなら、引き継ぎが機能した具体例になります。逆に毎月質問を受けたなら、判断基準が文書に残っていなかった可能性があります。どこを直して質問が変わったかまで話せると、説明力と改善力を一緒に示せます。
新卒と経験者では、同じ力を何で示すかが違う
学生なら、研究の問いをどう絞ったか、予想と違った結果をどう調べたかが材料になります。論文を読んで再現した場合も、どこまでが先行研究で、何を自分で変更し、どんな条件で成績が変わったかを切り分けられます。企業の利益に換算する必要はありません。再現できた範囲と限界を正確に伝えましょう。
経験者なら、チーム全体の成果と本人の責任を二段に分けます。たとえば担当者の作業時間が減った案件では、集計期間、人数、削減時間の測り方に続けて、自分が変更した手順を書きます。別部門が担ったシステム改修は協働先の成果として記し、改修を進めるために自分が渡した仕様や検証結果を示すと、役割を過大に見せずに貢献を伝えられます。
最後に、経験を一つ選び、「誰が何に困ったか」「どんな比較で判断したか」「誰に何を引き渡したか」「何が未解決か」を四行にしてください。面接で深掘りされても答えが具体的なら、その経験は応募書類の中心に置けます。求人の必須欄と照合するのはその次です。仕事を理解するうえでの強みと、応募条件を満たす根拠を、それぞれ自分の言葉で伝えられます。