「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- ココでは、Open棟梁を生み出した「社内サポート」について説明する。
- Open棟梁は、そもそも社内サポートで使用する治工具と言う文脈で誕生した。
- 生産性向上のミッションを持つ組織が社内サポートを経て治工具を開発した。
- 治工具（治具）とは、製造工程を正確かつ効率的に行うための道具の総称。
- 以下は治工具ではなく社内サポートについて。「治工具」提供のメリットが透けて見える。
- ただし「治工具」提供も開発・維持コスト・disconなどのデメリットもある。
- Open棟梁は、OSS化で、なるべくその問題を解消している。
詳細 †
社内サポートとは？ †
- 社内サポートには、問い合わせ対応から、オンサイト対応まで幅広くある。
- 最近は火消し要員プールやメンタル要員待避所的な位置付けもなくなってきているため、対応義務はあまりない。
- 生産性向上ミッションでオンサイトするケースは、若年層のOJT的な側面が大きい。
- 若年層は現場技術や新技術を組み合わせ治工具などを偶然・極稀に生み出すケースがある。
- 振り返ってみると「現場を理解する」とは「現場の営み（常識）を理解する」ことである。
- この「現場の営み」は、必ずしも、技術的に優れている事ばかりではない有象無象を含む。
従来慣行からの変化 †
最近は火消し要員プールやメンタル要員待避所的な位置付けもなくなってきている
- 業務の標準化・自動化：バックオフィスは「緊急対応」よりも「プロセス改善」や「効率化」にシフト
- 専門性の強化：単なるサポートではなく、法務・コンプライアンス・データ管理など専門知識を活かす役割が増加。
- メンタルケアの分離：メンタルヘルス対応は人事やウェルビーイング部門に移行し、バックオフィスは直接関与しないケースが多い。
- 火消し要員の減少：緊急対応はPMOのリスク管理チームが担うことが増え、バックオフィスは「予防的な仕組みづくり」に注力。
社内サポートの慣行 †
有償サポートではないので †
- 有償サポートは、別に立てた予算の片手間であることが多い。
- 若年層のOJTを行うなら、社内サポート用の予算編成をすることはある。
社内ならではの甘え †
現場が偉いと思っている（特に、下請け会社系の方がこのマインドが強い）
- 金を払っていないので無限に時間をかけて良いと考えている（依頼側が）。
- 必要な作業を行わずに、最終回答が得られると思っている（もしくは強要してくる）。
作業代行は嫌われる。 †
MSのプレミアサポートのオンサイトがなぜ高額か？に近い話。
- 現場に行ってまでの作業はコストがかかる。
- そこまでして大した成果が無ければサービス振り出し元にとっては損害。
- 低レベルな作業代行は単なるトライ＆エラーになる（有償なら対価で補填可能）。
- 場合によっては依頼作業の遂行能力が無いケースに対応しているケースもある。
- トライ＆エラーに必要となる現地環境を入手するためダケに現地に行っている。
組織のミッションと考慮すると †
- 「現場が偉い」「本社が偉い」などの、稚拙なマインドがある可能性
- CCに管理職を入れたら解決するかもしれないが管理職が対応しているケースもある（笑）
バック †
- 現場の常識を理解している必要はあるが常に有象無象に対応することではない。
- 若年層なら、OJTはあってもいいが、ベテランになれば、OJTしている場合ではない。
担当 †
担当の問題あるムーブ
- 前提環境の情報やログなどを出さず、問答（一問一答）を延々と続ける。
- 開発系トラブルシュートの話で利用OS、ランタイム、IDEの基本的な操作方法を知らない。
- コチラが依頼したことや指示したことに対して対応せずに最終回答を希望する。
フロント †
- 対応予算は本来フロント持ち（持っていないのは、見積ミス、調達ミス、人員配置ミス）
- スキル不足の人員に開発させている可能性がある。不良を作りこみ続けている可能性がある。
エンジニアが勘違いしている事 †
- 自社事業が解ってない（SI事業は）：「人的資源、金融、保険の三分野におけるリスクテイカー、責任引き受け主体」
- ココで、文脈上のエンジニアは人的資源に過ぎない。ベネフィットを伸ばすならスマイルカーブの両端が対象になる。
現場系 †
- 自分が居ないと成果物は完成しない：実際はチームでの協力やプロセス設計が重要で属人化はリスク。
- 自分の専門領域だけ理解していれば十分：ビジネス背景・UX・運用視点も理解することで価値が高まる。
テック系 †
- 最新技術を使えば必ず良い：実際は安定性・保守性・チームスキルとのバランスが重要。
- 要件は変わらない：実際はビジネス環境や顧客ニーズに応じて変化するのが前提。
コーダー系 †
- 価値があるのは実装だけ：実際は企画・要件定義・品質保証・運用の方が付加価値は高い（スマイルカーブ）。
- ドキュメントは不要、コードを見ればわかる：実際は引き継ぎ・運用・監査でドキュメントが不可欠。
- コードがキレイならプロジェクトは成功する：プロジェクト型案件なら、よりQCD、UXが優先される。
- テストは後でやればいい：実際は設計段階からテスト戦略を組み込むことが品質確保の鍵。
- パフォーマンスは最後に調整すればいい：実際は設計段階で考慮しないと大きな手戻りになる。
- セキュリティは後付けできる：実際は初期設計から組み込むべき。後付けはコスト増。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
