![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[Open棟梁 wiki>https://opentouryo.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>サポートについて]] *目次 [#q91f3472] #contents *概要 [#p4f883c5] -ココでは、Open棟梁を生み出した「社内サポート」について説明する。 -Open棟梁は、そもそも社内サポートで使用する治工具と言う文脈で誕生した。 --生産性向上のミッションを持つ組織が社内サポートを経て治工具を開発した。 --治工具（治具）とは、製造工程を正確かつ効率的に行うための道具の総称。 -以下は治工具ではなく社内サポートについて。 --コレを読むと「治工具」提供＆セルフ・サポートのメリットが透けて見える。 --「治工具」提供も開発・維持コスト・disconなどのデメリットもある。 --Open棟梁は、OSS化で、なるべくその問題を解消している。 *詳細 [#s1310f48] **社内サポートとは？ [#k70fa052] -社内サポートには、問い合わせ対応から、オンサイト対応まで幅広くある。 -オンサイトするケースは、生産性向上ミッションで若年層をOJTさせる側面が大きい。 -若年層は現場技術や新技術を組み合わせ治工具などを偶然・極稀に生み出すケースがある。 -振り返ってみると「現場を理解する」とは「現場の営み（常識）を理解する」ことである。 -この「現場の営み」は、必ずしも、技術的に優れている事ばかりではない有象無象を含む。 **従来慣行からの変化 [#j0ce333b] 最近、多くの企業で、火消し要員プールやメンタル要員待避所的な位置付けもなくなってきている。 -業務の標準化・自動化：バックオフィスは「緊急対応」よりも「プロセス改善」や「効率化」にシフト -専門性の強化：単なるサポートではなく、法務・コンプライアンス・データ管理など専門知識を活かす役割が増加。 -メンタルケアの分離：メンタルヘルス対応は人事やウェルビーイング部門に移行し、バックオフィスは直接関与しないケースが多い。 -火消し要員の減少：緊急対応はPMOのリスク管理チームが担うことが増え、バックオフィスは「予防的な仕組みづくり」に注力。 **社内サポートの慣行 [#o063dfb4] 多くは「[[現場が勘違いしている事>#gb5f7680]]」に起因する。 ***有償サポートではないので [#x4fb4636] -社内の無償サポートは、別に立てた予算の片手間であることが多い。 -無償では通常、ナレッジ・ベースも検証環境も十分にはない。 -若年層のOJTを行うなら、社内サポート用の予算編成をすることはある。 ***社内ならではの甘え [#l97cf401] 現場側に過剰な権限意識がある（特に、下請け会社系の方がこのマインドが強い） -原価意識が無く「金を払っていないので無限に時間をかけて良い」と考えている（依頼側が）。 -必要な作業を行わずに、最終回答が得られると思っている（もしくは強要してくる）。 ***依頼・対応が雑になる。 [#pe0827f6] -情報不足の依頼：サポート側で追加ヒアリングが必要。 -手順を守らない：口頭で記録が残らず、再発防止や分析ができない。 -現象の解説を理解しない：段階を飛ばし最終回答を求める。 -暫定対応の乱発：技術的負債が増え、後で大きなトラブルに。 -結果 --根本原因の特定がされず、同じ問題が繰り返される。 --「サポートは魔法の答えをすぐ出せる」という誤った期待値を持つ。 ***作業代行は嫌われる。 [#p99ead07] -稚拙なサポート依頼が作業代行になるケースはサポート振り出し元に嫌われる。 -コレは、MSのプレミアサポートのオンサイトがなぜ高額か？に近い話。 --現場に行ってまでの作業はコストがかかる。 --そこまでして大した成果が無ければサポート振り出し元にとっては損害。 --低レベルな作業代行は単なるトライ＆エラーになる（有償なら対価で補填可能）。 ---場合によっては依頼作業の遂行能力が無いケースに対応しているケースもある。 ---トライ＆エラーに必要となる現地環境を入手するためダケに現地に行っている。 **組織の役割分担を考慮した問題点 [#wffbc589] -「現場が偉い」「本社が偉い」などの、稚拙なマインドがある可能性 -CCに管理職を入れたら解決するかもしれないが管理職が対応しているケースもある（笑） ***バック [#d7f7d328] -現場の常識を理解している必要はあるが常に有象無象に対応することではない。 -若年層なら、OJTはあってもいいが、ベテランになれば、OJTしている場合ではない。 ***担当 [#lbe3d5b3] 担当の問題あるムーブ -前提環境の情報やログなどを出さず、問答（一問一答）を延々と続ける。 -開発系トラブルシュートの話で利用OS、ランタイム、IDEの基本的な操作方法を知らない。 -コチラが依頼したことや指示したことに対して対応せずに最終回答を希望する。 ***管理職 [#j8377af1] 管理職の問題あるムーブ -担当とサポートの間に入りオーバーヘッドになることがある。 -思いの間にギャップがある。 --仲介して、作業指示に変えたい。 --ただし、技術的詳細を理解をするつもりはない。 -ただし、問題以前に法的に担当に直接の指示をしないこと。 --準委任では、受任者を入れる。 --一括請負では、請負業者の責任者を入れる。 ***フロント [#zc0ec1dc] -対応予算は本来フロント持ち（持っていないのは、見積ミス、調達ミス、人員配置ミス） -スキル不足の人員に開発させている可能性がある。不良を作りこみ続けている可能性がある。 **現場が勘違いしている事 [#gb5f7680] 現場（のエンジニアリングとマネジメント）が勘違いしている事 -自社事業が解ってない（SI事業は）~ 「人的資源、金融、保険の三分野におけるリスクテイカー、責任引き受け主体」 --人を集めて一つのプロジェクトを構成する（人的資源） --下請け企業への月々の人件費の支払い（金融） --プロジェクトが失敗したときに損失を引き受ける（保険） -ココで、文脈上のエンジニアは人的資源に過ぎない。 -ベネフィットを伸ばすならスマイルカーブの両端が対象になる。 ***現場系 [#yb3dbd30] エンジニアリングとマネジメント -自分が居ないと成果物は完成しない：実際はチームでの協力やプロセス設計が重要で属人化はリスク。 -自分の専門領域だけ理解していれば十分：ビジネス背景・UX・運用視点も理解することで価値が高まる。 ***テック系 [#dbee56a8] エンジニアリング -最新技術を使えば必ず良い：実際は安定性・保守性・チームスキルとのバランスが重要。 -要件は変わらない：実際はビジネス環境や顧客ニーズに応じて変化するのが前提。 ***コーダー系 [#d75ff07b] エンジニアリング未満 -価値があるのは実装だけ：実際は企画・要件定義・品質保証・運用の方が付加価値は高い（スマイルカーブ）。 --ドキュメントは不要、コードを見ればわかる：実際は引き継ぎ・運用・監査でドキュメントが不可欠。 --コードがキレイならプロジェクトは成功する：プロジェクト型案件なら、よりQCD、UXが優先される。 -テストは後でやればいい：実際は設計段階からテスト戦略を組み込むことが品質確保の鍵。 --パフォーマンスは最後に調整すればいい：実際は設計段階で考慮しないと大きな手戻りになる。 --セキュリティは後付けできる：実際は初期設計から組み込むべき。後付けはコスト増。 IP:155.190.49.71 TIME:"2025-12-08 (月) 12:20:02" REFERER:"https://opentouryo.osscons.jp/index.php?cmd=edit&page=%E7%A4%BE%E5%86%85%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E3%81%A8%E3%81%AF%EF%BC%9F" USER_AGENT:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"
