日立製作所の職務経歴書の書き方｜事業・職種別の実績整理

2026年8月時点の公式採用情報から見ると、日立製作所向けの職務経歴書は、事業領域と職種を二段階で選ぶことが出発点です。デジタルシステム＆サービス、エナジー、モビリティ、コネクティブインダストリーズでは顧客と成果が異なり、SE、PM、設計開発、研究、品質保証でも主証拠が変わります。

日立は、IT、OT、プロダクトを組み合わせ、顧客や社会の課題へ取り組む事業を説明しています。会社の言葉を志望動機に写すのではなく、誰のどの課題に対し、自分が何を判断し、どの状態まで変えたかを示します。

事業と職種を二段階で選び、案件順を決める

最初に、過去案件の顧客、利用者、現場が最も近い事業領域を選びます。次に、応募する職種の仕事内容を動詞へ分け、自分の行動と照合します。

応募する役割	先頭に置く事実	主な成果物
顧客フロント	顧客・社会課題と合意	構想、要件、ロードマップ
PM・PL	責任範囲と意思決定	計画、リスク、品質、移行
アプリ・基盤	要求と技術判断	設計、実装、テスト、運用
AI・データ	業務判断とデータ	評価、モデル・基盤、監視
社会インフラ・OT	停止影響と現場条件	安全、制御、保守、運用
研究・設計開発	仮説と検証	試作、評価、製品化への移管

業界名が同じでも、本人の責任が違えば先頭案件は変わります。社会インフラ案件に参加した事実だけでなく、顧客フロント、PM、基盤、品質保証のどこで判断したかを明確にしてください。

顧客フロントは課題特定と合意の中身を書く

公式のシステムエンジニア職紹介は、顧客課題の特定・コンサルティングから、要件、設計、開発、テスト、運用保守までを挙げています。提案額や会議数より、何を顧客の課題として定めたかから始めます。

• 経営、業務、現場、技術、規制のどこに課題があったか
• 顧客の発言以外に、どの事実を集めたか
• 比較した案と評価軸
• 経営、現場、ITの条件をどう合意したか
• 構想が採用・見送りになった理由

提案が採用されなかった案件も使えます。判断に使われた比較、見送り理由、次に必要な条件を説明できれば、課題を構造化した仕事として伝わります。

PM・PLは案件規模より変更時の判断を示す

案件規模を本人の力量へ直結させない方がよいでしょう。顧客、目的、体制、期間を示した後、スコープ、期限、コスト、品質、リスク、依存関係のうち、本人が責任を持った対象を書きます。

要件追加、設計変更、遅延、品質問題、調達制約などに対し、兆候をどう捉え、選択肢をどう作り、誰の承認を得たかを示します。判断前後の状態が追える記述にすると、管理責任が明確です。

管理対象	職務経歴書へ残す事実
スコープ	追加要求の影響と採否の条件
品質	レビュー、試験、受け入れ、リリース判定
体制	顧客、協力会社、製品部門、開発、運用の役割
移行	切り替え条件、リスク、未解決事項
運用	受け入れ、監視、障害、改善の担当範囲

アプリ・基盤は技術選定と稼働後の責任を書く

アプリケーション経験は、対象業務と利用者の要求を設計へ落とした過程から書きます。機能一覧より、業務ルール、データ、既存システム、性能、可用性、セキュリティ、保守性の制約をどう比較したかが重要です。

プラットフォーム職では、クラウド、サーバ、ストレージ、ネットワーク、セキュリティの名称だけで終えません。可用性、性能、コスト、移行、復旧の条件を先に置き、比較候補と見送り理由を示します。

稼働実績はリリース完了で終えず、移行、受け入れ、監視、問い合わせ、障害、追加改善のうち関与した範囲を記します。稼働前に離任したなら、運用へ引き渡した成果物と未解決事項を終点にします。

AI・データはLumadaの名称より業務判断を示す

Lumadaの公式説明は、顧客体験の設計、商品・サービス開発、利用データの収集・分析、改善をEnd-to-Endで支援する考え方を示しています。職務経歴書では名称を知っていることより、データをどの顧客・業務判断へ使ったかが重要です。

• 何を予測・分類・抽出し、誰が使ったか
• データの範囲、品質、更新、権限
• 評価指標、比較基準、誤りの影響
• 本番利用、監視、例外処理
• 結果を踏まえて変えた業務やモデル

再利用可能なアセットを作った経験があるなら、部品を使った事実だけでなく、適用条件、変更点、品質確認、別案件へ残した知見を書きます。

社会インフラ・OTは停止影響と現場条件を書く

社会インフラ領域で「社会を支えた」と書くだけでは、本人の仕事が分かりません。対象利用者、停止や誤動作の影響、運用時間、法令・標準、現場設備、保守期間など、システムや製品が守る必要のあった条件を示します。

IT・OT連携の経験では、情報システムと制御・運用の境界を書きます。データ取得、制御指示、ネットワーク断、手動運転、保守など、設計に影響した条件を具体化してください。

ここはリメディの見解ですが、日立がIT、OT、プロダクトの組み合わせを事業の特徴としているからこそ、現場の制約をIT要件へ変えた判断は企業固有性の高い証拠になります。単なる大規模案件の経験とは分けて示すべきです。

研究・設計開発は技術成果を製品化へつなぐ

研究開発・設計開発では、論文、特許、試作、図面の数だけで判断させません。解くべき課題、要求、仮説、比較方法、検証結果、次工程への移管を一つの流れにします。

研究では新規性と実用条件を分け、既存手法との差、実験条件、再現性、限界を示します。設計開発では性能だけでなく、コスト、製造性、保守性、安全、規格、供給、環境条件をどう比較したかを書きます。

品質保証・PMOは問題発見後の是正を書く

監査件数や会議運営だけでは成果になりません。基準、対象、検知したリスク、是正の判断、確認結果、標準への反映を一つの流れにします。

PMOは、現場PMの代行か、経営・組織横断の統制かを分けてください。見積・計画、リスク、品質、進捗、ゲートのどこを評価し、どの条件で継続・見直しを判断したかを書きます。

職務要約と主要案件の責任範囲をそろえる

職務要約は、会社紹介より、対象顧客・社会課題、専門領域、責任工程、主要成果を先にします。主要案件は、課題、制約、体制と本人役割、判断、成果物、結果、残課題の順にすると読みやすくなります。

例：交通事業者向け運行システムで、要件定義から移行・運用設計までPLとして担当した。運行継続と段階移行の条件を整理し、顧客、開発、運用部門の合意を得て切り替えへつなげた。

この例文は日立製作所の選考基準ではなく、読者自身の実績へ置き換えるための型です。架空の数値を盛らず、承認や移行など確認できる事実を、面接で説明できる範囲で書いてください。

要約で「構想から運用まで」と書くなら、運用開始、利用部門の受け入れ、監視、障害対応、改善の証拠が必要です。証拠がなければ、終点をリリースや移管までに直します。

提出前に個別募集と照合する

• 応募する事業と職種を一件の募集で確定している
• 募集要項の動詞と、自分の案件の行動が対応している
• 大規模、高信頼、社会貢献という抽象語に頼っていない
• 品質、安全、移行、運用の責任を具体化している
• チーム成果と本人の判断を分けている
• 顧客・設備・セキュリティ情報の守秘義務を守っている

応募事業・職種を絞れない、ITとOT・製品の接続を説明しにくい、守秘義務で成果が抽象的になる場合は、求人票と主要案件を並べて整理します。第三者へ見せる際も、会社名を伏せた状態で本人の判断が読めるかを確認してください。

日立製作所の職務経歴書に関するFAQ

事業領域と職種はどちらを先に決めますか？

まず過去案件の顧客・現場に近い事業領域を選び、その後に本人の責任が近い職種を決めると整理しやすくなります。最終的には個別募集の仕事内容を優先してください。

社会インフラ経験がなくても応募書類を作れますか？

作れます。応募職種に近い課題、技術判断、品質、運用の経験を示します。経験していない公共性や安全要件を持っているように書かず、隣接経験と未経験領域を分けます。

成果の数値を開示できない場合はどうしますか？

承認、要件確定、移行完了、運用受け入れなど、確認できる状態へ表現を変えます。対象、期間、本人の担当も併記してください。