こんにちは、コーポレートエンジニア(コーポレートIT[CO-IT]チーム) の 横川 です。 この記事は Enigmo Advent Calendar 2023 の 17 日目の記事です。
この記事では社内ITサービスを支えるチームの組織作りをテーマにどのような観点でチーム運営を行っているかをご紹介したいと思います。
コーポレートIT領域は、年々取り扱うサービスや技術が広くなり、様々なスキルセットが要求されてきていますが、本記事は特定技術の話ではなく組織運営にフォーカスした内容となります。 これから社内SEを目指される方や現在コーポレートエンジニアとして活躍されている方々に少しでも参考にしていただける内容となっていれば幸いです。
はじめに
自己紹介とCO-ITチームの紹介
私はITベンダーでネットワークエンジニアとしてキャリアをスタートし、その後セキュリティ製品の代理店にてプリセールスエンジニアを担当してきました。その後、キャリアチェンジし、デベロッパーでの社内SE(情シス)、SaaS提供企業でのコーポレートIT担当を経て、昨年10月よりenigmoにjoinしました。 コーポレートITという大きな領域全体を俯瞰して自社の最適なコーポレートITを自由に作ることができるという環境に惹かれて入社を決断しており、実際にそのミッションに日々向き合える環境で働いています。
CO-ITチームはコーポレートオペレーション本部の人事総務グループに属し、社内ITサービス全般を担当しています。 ブログ執筆時点(2023年12月)では、マネージャ[人事総務グループ部長]を除くとチームメンバーは私を含め3名で現在4人目のエンジニアを募集している状態です。 最終的な意思決定はマネージャが担いますが、当社のコーポレートIT領域の対応は現在私がリードする役割を担っています。
コーポレートエンジニア・社内SE・情シスについて
近年、コーポレートエンジニアやコーポレートITといったワードを見かけることも多くなってきており、従来の社内SEや情シスという表現との明確な違いを説明するWebページ等も増えてきているかと思います。 ざっくり両者の違いは、「見る範囲・視点の違い」とされていることが多く、コーポレートエンジニアは従来の社内SEや情シスのスコープよりも広範囲に及ぶ(企業全体を視野に入れ、ITスキルを活用して提案・企画を行う)と定義されています。*1
コーポレートエンジニアはバックオフィス部門に所属し、会社の売上に直接貢献することはできません(プロダクト部門メンバーの業務効率向上に資することで間接的に貢献する)。企業によっては、プロダクト側に強い優遇(力が強い傾向)があったり、バックオフィス側は利益を生まない部門として不遇な環境になっている場合も見聞きしますが、プロダクト側・バックオフィス側どちらかに優劣があってはならないし、どちらも(会社の成長に貢献する部門として)リスペクトし合える企業風土が醸成できていることが望ましいと感じます。*2
そして、シンプルにコーポレートIT部門が会社から求められることを表現すれば、
自社に最適なコーポレートITをいかに低コスト・最速で実現し、安定稼働を継続できるか
になります。
予算が無限であれば、何も考えず最新で優れたサービスをフルライセンスで導入し、外部の専門ベンダーに要件定義〜運用まで全て外注して、トラブル対応や今後のアップデートも含めて24h365dでフルサポートされるオプションを付帯すれば他社を圧倒するコーポレートITの運用が可能となります。*3しかしながら、自社の社内ITサービスに実プロダクト以上の予算を割ける企業がどれだけあるでしょうか？この点にコーポレートエンジニアの存在意義があるものと考えられます。コーポレートエンジニアは、しっかり自社の状況を俯瞰して会社のフェーズに合わせて、必要十分なサービス提供に日々向き合うことが求められる職種です。
１．組織運営の前提を整理する
私自身が実際に実施していることを含め、組織運営にあたりクリアすべきと考えていることについて記載していきます。
ミッションを理解する
以下にMVVを掲載します。当社のミッションは こちら の通りですが、CompanyのMVVに応じてCO-ITチームでもMVVを定義しています。
会社の方針と現在のフェーズをすり合わせる
ワーディングは違っても、多くの企業のコーポレートIT部門のMVVは当社のものと重なる部分が多いのではないでしょうか。 それは企業活動における基本的な役割が同じであることに起因しますが、MVVが同じでも各企業・担当者の業務内容は例えば下記のような理由によって大きく異なります。
- 会社の規模や方針によって対応範囲やチーム構成が様々である
- 企業規模の拡大や事業成長に伴って縦割りが進み、サービスや製品毎にチームや担当者が限定されている
- 要件定義だけ・設計構築だけ・運用だけのようにスコープが限定されている
したがって、具体的なチームビルディングに移る前にまず現在のフェーズを整理し、組織運営方針についての合意形成が必要になります。その大前提として、社内ITサービスを外注するのか内製するのかの判断を行います。一昔前までは専門のエンジニアが担当せず総務担当者が兼務や片手間で社内システム(情シス)を担当することも多かったように感じますが、昨今では求められるスキルや要件の複雑化によってそういった体制では対応しきれなくなってきているのではないでしょうか。事業規模の比較的小さな企業やスタートアップ企業などプロダクト側にフルコミットする必要がある場合は、社内ITサービスの外注化を行う場合もあるかと思いますが、以下のようなリスクがあるため慎重な判断が求められます。
- 顧客伴走型と謳っているサービスであっても顧客視点の小回りがきくサービスにはなりにくく、他企業共通のテンプレ利用による対応となるリスク
- システム化や仕組み化のベースとなるプラットフォームを顧客側ではなく発注先ベンダー側環境で構築され、顧客側では関知できないリスク
- 設計や設定、ナレッジ自体が顧客側に蓄積されず基本的にブラックボックス化してしまうリスク
- 各種リスクを解決するような契約を試みた場合、自社で専門のエンジニアを採用するよりコストが高くなるリスク
- 発注先都合で突然サービス終了となり、自社の社内ITサービスが停止してしまうリスク
また、社内ITサービスというのは、自社独自の要件を年々積み重ねて構築していく要素も大きいため、例えばIDaaS製品の設計だけ、社内NWの構築だけを切り出すのではなく、社内ITサービス全体のバランスや連携も視野に入れた高い視座で最適なサービス運営を行う必要があります。加えて、各種サービスの発注先ベンダー等との価格交渉や要件すり合わせについても一定の知識が必要になりますので、その意味でも自社で専門のエンジニアを採用して運営していくことは重要であると言えます。
CO-ITチームは、私が入社する直前まで暫定的にマネージャ自身がプレイヤーを兼務し、多くの実務は(ヘルプデスク業務を外注できるような)外部サービスを利用することで社内ITサービスを維持管理している状態でしたが、私は業務状況を確認した上でチーム運営を再設計するフェーズ(初期フェーズ)と判断しました。なお、マネージャとは定期的に「As is」/「To be」について大枠の目線合わせを行っています。*4
プロダクト、スコープ、役割を整理する
大枠の方針がフィックスした後は、少しずつ具体化していきます。まず、プロダクトとスコープの定義です。 一般的には、事業活動において顧客に提供するものをプロダクト(当社の場合、BUYMAというサービス)と呼び、コーポレートITがプロダクト？と違和感を感じられるかもしれませんが、顧客(従業員)に対してサービスを提供する部門である以上当然プロダクトがあって良いと思いますし、意識すべきと考えています。そして、そのプロダクトを提供するためのスコープの定義も併せて必要です。
上記がCO-ITチームのプロダクトと大枠のスコープになります。スコープは大項目のみ表記していますが、例えば今回のような「techブログへの投稿」業務は「ブランディング貢献」の中に含まれるという感じです。 また、スコープは視座や技術的な難易度等々によってピラミッド型になるので、メンバーの役割の大雑把なプロットも行っています。*5
メンバー構成(チームの総リソース)を整理する
ここまででチームが目指す方向性が見えてきたので、次に具体的なメンバー構成や必要リソースの整理に移ります。 なお、この項目については、各企業の人員計画・予算・業績・既存のメンバー構成等々複雑な要素を踏まえた経営判断になるかと思います。 結果だけの記載となりますが、CO-ITチームは、4名体制を目指すべく現在4人目のエンジニアを募集している状態です。
まとめますと、CO-ITチームは以下のように年間の投下リソースで表現されるValue(アウトプット)が会社から求められる期待値をアウトパフォームすることを意識しなければなりません。
裁量と責任、働き方
採用業務を行っているとよく質問を受ける項目ですので、ここで触れたいと思います。 CO-ITチームは、各担当者毎にスコープを限定するようなことはなく、基本的に各自のミッションサイズ(会社が各自に期待すること)に応じてコーポレートIT領域全てに携わる方針としております。*7 ミッションサイズの中で最大限の裁量と責任を持っていただき、自由に業務時間を使うことで最大のValueを発揮いただくのが最良という考えに基づいています。
また、当社はオフィスワーク・リモートワークの選択も一定の裁量が許容されていますので、CO-ITチームでもその範囲内で自由選択としています。 基本的にオフィスワークが必要な業務(デバイスのキッティング等)を中心に行うメンバーは出社頻度が高くなりますが、リモートワークすることでオフィスワークする以上のアウトプットが出せるのであればリモートワークの頻度が高くても良いという方針です。なお、業務スコープの特性上(ITサービスデスクを担当しているため)、必ず一人以上のチームメンバーがオフィスワーク(本社に出社)することで物理的なインシデントやユーザサポート対応を可能にしています。
２．現状を俯瞰する
チーム運営の前提の整理が終わった後は、現状の把握に移ります。
課題を整理する
サービスを整理する
プロダクトを理解した上で顧客に提供するサービスの整理が必要です。近年のコーポレートIT領域はオンプレからクラウド化の流れが急速に進んでいるため、SaaSのことばかりに目が行きがちですが、従来の社内NW運用業務をはじめ、企業によってはオフィスファシリティやセキュリティ領域も含まれます。 また、SaaSによっては他のバックオフィス部門(経理等)やプロダクト側が慣例的に運用しているサービスもあり、各サービス毎で主管している部門は企業によって差異があり、正確な把握が必要です。
コストを整理する
主管するサービスが洗い出せた後は、具体的なコスト感の把握です。 自チームが提供するサービスのコスト感がパッと答えられないというのは問題外であり、そのコスト感に見合うメリットを会社にもたらしているのかを常に意識する必要があります。 また、SaaSであったとしても、単純にライセンス費用や月額利用料といった費用だけでなく、導入から日々の維持管理に必要な人的リソースのコスト(1人日の単価を具体的に設定した上で年間何人日、何人月の工数が掛かりどのような金額になるのかまで想定)を含めて該当サービスのコスト妥当性が判断される必要があります。*8
CO-ITチームでは、下記のような主管サービスを網羅した一覧を作成・運用しており、提供サービスの総合計を従業員数で割ったサービスコストの算出を行っています。
この一覧には、サービスのコストをはじめ、サポート窓口の情報や稟議・請求書対応、更新のタイミング等々を含め、サービス別に串刺しして比較でき、これだけを確認すれば運用に必要な情報が取得できるように一元管理しています。
なお、現時点では見える化したところまでしか到達しておらず、コストの最適値はどのくらいなのか、今のコストは妥当なのかという分析や評価を実施するフェーズには至っておりません。 近い将来、このコストを一つのパラメータとして適切なサービス導入のガイドラインを策定することを見据えております。
手続き・運用を整理する
次に見積・稟議・発注・請求のような一連のサービス導入手続き、導入後の実運用について把握します。実現したいことは各企業大体同じであるにも関わらず、企業によって利用しているワークフローは様々であり、実現するまでに理解すべきことのボリュームに大きな違いがあります。
会議コストを考え、会議体を整理する
ファシリテーションや会議に関するビジネス書で数多く述べられていますが、「会議コストは非常に大きなもので意味のある会議をすべき(無駄な会議は廃止すべき)である」といった主旨のトピックが記載されています。
例えば、4人のエンジニアが1hのMTGをする場合、そのコストは超ざっくり¥25,000程度になります。*9ですので、その1hのMTGのアウトプットに会社はその金額を払うことになるので、その期待値を超えるValueが必要になります。特に会議は複数人で行うものなので、各自が単独で行うTodoよりも大きな人件費が計上されてしまうことになります。また、とりあえず参加するだけで仕事をした気になってしまうので注意が必要です(会議に参加すること自体にValueはなく、その会議でどのようなアウトプットを出したかが重要)。
ということで、CO-ITチームでは必要な会議体を整理し、チームのフェーズに合わせた会議運営を行っています。
情報共有・ナレッジ化を意識する
まだまだ続きますが、続いてはチームレベルのナレッジマネジメントです。一人情シスのような状態でなければ、基本的に業務を進めていくとチームメンバーへの具体的な手順共有は当然として、各種設計指針やそもそもの要件定義内容等々、チーム独自のナレッジを複数人で共有するシーンが多々あるかと思います。ナレッジ共有を全く行わない(何もかも属人化)のような組織はないと思いますが、共有の仕方に課題感が残っている組織は少なくないかと思います。CO-ITチームでは以下のポイントを実行し運用しています。
- 共有の仕方を定義する
- 共有すべき粒度を定義する
- ナレッジ化に惜しみなくリソースを投下する
タスクを整理する、バックログ化する
そして、最後にタスクの整理です。PJ管理やタスク管理を実施するためのツールや方法は様々なので省略しますが、当社では私が入社前の段階からAsanaを利用していたため一旦そのまま継続利用しています。タスク整理にあたり、ポイントとしたことは、以下の通りです。
- 必ず各タスクの目的を明確化する
- 不明瞭な(誰も自分事としていない)タスクが管理ツール上に表示されていない状態
- マネージャは意思決定のみを担当(タスク担当者にマネージャをプロットしない)
- 全体を同じ箱の中に含め他メンバーの業務状況も見える化する*10
- スポット、割り込みタスクが入ってもチーム全体のタスク一覧に起票する
- 個人のローカルTodoで処理しない、オープンにする
- 基本的に起票する(よほど数分でクローズするようなタスクは例外)
本来であれば、アジャイルの考え方に沿って、チーム全体でスクラムを用いてスプリント毎に同じMissionに向かって組織運営(バックログ消化)を行いたいのですが、CO-ITチームではまだまだそういったフェーズにないと判断し、現状はバックログ化することまでに留まっています。
CO-ITチームの課題
以上の課題整理を行った結果、CO-ITチームでは以下のような課題が見えてきました。 既にある程度クリアできてきているものもありますが、日々最適化すべく現在も業務推進中です。 何をどのように解決したかの話は、また機会があればご紹介させていただきます。
- 資産管理の精度が低い、管理できていないものが存在する
- サービスのスコープ、責任分界点が不明瞭
- ナレッジが点在している、不足している、陳腐化している
- ブラックボックス化(実務の外注サービス依存にも起因)、属人化している
- 業務分析できる基盤が整っていない(定量化できていない)
- 意思決定した背景・経緯・ポイントが体系化されていない
- 中長期的な視点で要件定義・設計・設定が行われていない
- 暫定対応でタスククローズした内容のまま形骸化している
- ユーザ要望を単純に解決することにフォーカスされている
３．将来を想像する
前項の通り、課題は山積みであったため、各課題に対してできる範囲(新規サービスの導入やシステム化・インテグレーションは後回し)で将来を見据えた改善を行う方針としました。
見える化、定量化に向けた(KPI・KGI策定を見据えた)足固め
冒頭で記載したようにコーポレートIT領域というのは取り扱うサービスや技術が広く、様々なスキルセットが求められると言えますが、個々のPJやタスクサイズは小さいことが多々あります。 しかしながら、タスクサイズが小さいからと言って、個々のタスクを全て点で捉えて個別にクローズし続けるといつまで経っても組織運営が最適化されません。 この観点において、CO-ITチームでは将来の対応リソースの削減も見据え、タスクを定量化することに注力しています。
見える化や定量化は多くの企業で実施されているかと思いますが、その粒度や精度については様々かと思います。 CO-ITチームも私が入社する前から全くできていないということではなく、粒度や精度に課題があったという話になります。
私が特に重要視しているのは提供サービス全体での体系化と最小限のリソースを目指す運用サイクルの構築になります。 この観点で言えば、CO-ITチームではまだまだ足固めが必要な状態であり、新規サービスの導入やSaaS間のインテグレーションを考えるフェーズにないと判断しました。 ですので、CO-ITチームではこの一年立ち止まって当たり前のことを実現できる最低限の準備を進めてきました(導入済みサービスはリプレース検討フェーズに移らず基本的に一旦継続利用して精査する)。その中のほんの一例が下記になります。
- 資産管理の精緻化
- 問い合わせ対応のワークフロー改善、見える化・定量化
- 提供デバイスのラインナップ整理とユーザへのガイドライン提供
- キッティング業務のワークフロー化
- 備品貸与ガイドラインの策定
- デバイス提供スピードの向上、提供コストの削減
- 入退社復職休職のような人事イベントに伴うアカウントフローの整理
- 社内手続き・稟議の整理
- サービスの保守期限の統一、サポート窓口の整理
- ナレッジ共有方法の統一、ナレッジの質・量の向上
業務改善の話(SaaSのインテグレーションだけが全てじゃない！)
採用業務で様々なエンジニアの方とお話する機会があるのですが、コーポレートエンジニアを目指されている方には「業務改善」にやりがいや面白さを強く感じられていて、プログラミングを行って自動化処理の仕組みを作ることが全て(若干誇張していますが・・・)という志向をお持ちである方(そういった印象を受ける方)にお会いすることがあります。確かにコーポレートエンジニアの業務の中でSaaSのインテグレーションというのは、より技術的な要素が強く自身の満足につながる、かつ他の方(特に非エンジニア職の方)からの評価が高くなる傾向がありますので合理的ではあります。
しかしながら、一度立ち止まって以下の質問に向き合うことも必要ではないでしょうか。
- 本当にシステム化、自動化することだけが正なのでしょうか？
- 本当に自動化することでコストは下がっていますでしょうか？
参考：運用自動化、不都合な真実
CO-ITチームでは、SaaS運用だけでなく全てのコーポレートIT領域に含まれるサービスにおいて業務改善を行うことが必要であり、実現する方法(コードを書くことが全てではない)に優劣はなく、アウトプットに対する評価は常にフラットでありたいと考えています。例えば、CO-ITチーム内の一例を紹介させていただきますが、以下のような対応も十分一つの業務改善であり、同等に評価されるものと考えています。
- 左側の写真：会議室のモニタスタンドを壁寄せモニタで可動式に変更
- レイアウト変更を容易にするという要件の充足と机上スペースの拡張を実現
- 右側の写真：管理するサーバルーム内の棚に共通の収納ボックスを導入
- 備品管理を最適化(必要な備品に最短でアクセスできる導線の確保とコストの最適化)
サービス導入・施策を開始することについて考える
CO-ITチームではこの一年立ち止まって足固めをしているため主だった新規サービスの導入は見送っている(他にもっとやるべきことが多い)のですが、新規サービスの導入(リプレース含む)業務に魅力を感じるエンジニアの方は多いのではないでしょうか。逆に既存のブラックボックス・複雑化した環境を考慮して体系的に再整理するような業務は(やりたくないとは口には出さないものの)敬遠される傾向が多いように感じます。
この傾向は、自身の直接的なスキルアップや評価へのつながりやすさに起因するものと思います。加えて、ゼロベースでの設計難易度に比べ、複雑な既存環境の再設計は難易度が非常に高く、ボリュームが大きくなる割にはアウトプットが(新規サービス導入に比較すれば)地味になります。また、実際に稼働しているサービスの場合が多く、放置してもスポットでは課題感が多少あるかもしれないが何とかやり過ごせることが多いことも要因の一つにあるように感じます。
ビジネス書(amazonのすごい会議)の中にもまさに同じような視点のコラムが掲載されていましたのでご紹介させていただきます。 PDCAサイクルにおいてAmazon社ではPDだけの人(立ち上げ屋[企画業務])は重視されないが、日本企業ではPDが重視されがちというものです。まさにコーポレートIT領域でも同じように感じます(下記のような状態です)。
- サービス導入することにだけ大きなコスト・アテンションが払われる*11
- 導入担当者の主観・感覚のままローンチされることがある
- 肝心の設計・設定・運用はレビューが薄い*12
- 問題が顕在化した後に再設計を検討する(再設計の中心人物がヒーローになる。。。) *13
CO-ITチームでは、近い将来新規サービスの導入を必要に応じて行いますが、上記のような課題が残らないようなPJ運営を行うつもりですし、一部の声の大きなメンバー*14だけが新規サービス導入に携わるような組織にならないよう最適な仕組みづくりを日々模索していきます。
チームの安定した運営を考える
チーム運営を安定化するポイントとしては、システム化(人に依存しない運用を構築する)やリソースの安定化(メンバーの頻繁な入れ替わりを防ぐ)といったことが挙げられます。前者については各所で述べられているように感じますが、後者はそれに比較すると情報量が少ない印象です。ここでは後者について深掘りします。
各種サービスのシステム化・自動化が非常に重要であることは自明ですが、それ以上にリソースの安定化は非常に重要です。以下にチームメンバー入れ替わりに関するデメリットを整理してみます。
- 一時的にリソース不足に陥る
- 新規メンバーの採用コストが必要となる
- 新メンバーの立ち上がりに1ヶ月〜半年程度を見込む必要がある
では、逆にメリットがないかと言えばそうではなく、以下のようなチームに新陳代謝が起こるメリットはあります。
- 旧メンバーより更に良い人材がチームに加入するかもしれない
- これまで慢性化や形骸化していた業務に良い影響を与えるかもしれない
しかしながら、安定したリソースでの運用を目指す方がチームとしての総合戦闘力は高いと感じますし、各自のスキルアップやチームの新陳代謝はチーム運営方法によりカバーできるものと考えますので、メンバーの不要な入れ替わりは避けたいものです。メンバーが離脱する理由を考えると、
- 待遇面(給与やワークライフバランス[会社の規定])の問題
- 会社や部署方針との根本的な価値観の不一致
- 会社の業績、業種の市場動向
- ジョブチェンジを目指す、またはプライベートな問題
- 部署内でのコミュニケーションの問題
- 志向の問題(自社ではスキルアップが見込めないと感じる)
- 足元の担当業務の問題(同じ業務ばかり、丸投げばかりされる、不公平感を感じる)
といったところでしょうか。 この中で1-4まではチーム運営ではどうすることもできないものになりますが、5-7を理由にメンバーの入れ替わりが発生するというのは、当該チームのマネージャやリード担当者に責任があると感じますし、こういった理由が発生しないよう常に改善を続ける必要があります。CO-ITチームでは、将来的なチームの安定運営を目指すために日々 カイゼン に向き合っています(具体的な話は機会があれば・・・)。
終わりに
今回は具体的なサービスの設計や設定内容、サンプルコード等のご紹介にフォーカスできませんでしたが、CO-ITチームの将来に向けた足固めは着々と進みつつあります。 来年以降ようやく新規サービス導入や施策などのコーポレートITサービス拡充をスコープとしていくフェーズを見込んでおりますので、(個人的には)ようやく楽しい業務にリソースを大幅に割けるタイミングとなります。
2023年12月現在、一緒にコーポレートITを推進いただける方を募集中です。 上記チーム運営に共感いただける方や同じような視座で物事を捉えられる方とともに一緒に当社のコーポレートITを作っていけることを楽しみにしています♪
今回の記事は以上になります。 最後まで読んでいただき、ありがとうございました。
株式会社エニグモ すべての求人一覧
*1:当社でも数年前まで「情シス」というワードが各所で用いられていましたが、少なくとも私が入社後は意図的に情シスというワードは使用せず、コーポレートITという表現を使用するようにしています。
*2:私個人の視点ですが当社はフラットな環境に感じます。
*3:当然ベンダーには自社の独自要件を踏まえたオーダーメイドの最適な設計でチューニングを行うように追加コストを支払う
*4:CO-ITチームの場合、マネージャと私の方向性が元々大枠で一致していたことと、経営陣とマネージャが既に同様のコミュニケーションを行っていたことで非常にスムーズにすり合わせが完了しています。企業によっては、このすり合わせが非常に難航し、そもそもすり合わせせずに実務に移ることがありますが、後々重大な課題につながるのでオススメできません。
*5:あくまで目安であり、ピラミッドのベースにある項目が頂点にある項目に劣るというような優劣は全くありません。全ての項目がコーポレートIT領域には重要です。また、これは一般的に定義されたものではなく、私自身の経験その他から表現したものとなりますので一意見としてご理解ください。
*6:8時間 × 20営業日 × 12ヶ月 × 4名
*7:ミッションサイズは、全社共通の指標があり、入社時を含め半期毎に行われる評価によって適宜決定されます
*8:あくまで私の個人的な意見ですが、業務として責任を負っている(報酬(給与)を獲得している)以上は合理的な説明責任があります(定量化することは必要です)。
*9:SE費¥50,000／人日 × 0.5人日[0.125人日 × 4名]
*10:チームは同じMissionに向き合っているため、各タスクを項目分けすることはあってもブラックボックス化しない(隠さない)。各メンバーのValueをそれぞれが参考にしたり、評価するために必須。
*11:導入すること自体にバリューはなく、そのサービスで何を実現するかにバリューがある。
*12:マネージャやリードエンジニアは、実担当でなくても高い視座でシステムの重要トピックや仕様を明確化してレビューを行う必要がある
*13:そもそも新規導入時の考慮不足・レビュー不足に起因して問題が発生する場合が多い。問題が発生する前にチームで再設計が議論され、バックログ化されているのが正しい運営であり、ヒーロー(救世主)のような特定個人のスキルセット頼みになるのは問題です。
*14:誤解を恐れずに記載すると、いいとこ取りだけして面倒事は他メンバーにぶん投げるような自分本位のようなメンバーのことを指しますが、業務への慣れ等によって知らず知らずの内に意図せずそのような振る舞いになることもあるかもしれません。お互いリスペクトし合える組織を目指したいものです。
