マネジメントとは？

マネジメントとひと言で言っても、色々な領域が存在する。

マネジメントと言う話で、まず大きく分けられるのが
・プロダクトマネジメント
・プロジェクトマネジメント
・ピープルマネジメント
の３つがある

僕はエンジニアであればここにシステムマネジメントを加えたい。

そもそもマネジメントの価値とは？

正直マネジメントが無くても、ことは進むと思っている。
ただし、そのスピードが遅くなっていたり、チームのパフォーマンスが最大化していない状態。

進むスピードが遅いというのは、止まっているわけではないので問題に手を付けづらい状態である。
遅いというのは相対的な価値なので、閉じた環境では場合によっては問題自体に気が付かないことすらある。
止まった状態になったときに初めて問題として認識して手を付けるのが常だ。
もっと早く手を打てばこんなに問題にならなかった。そう思うことも多い。

つまり、マネジメントとは仕事において、ゴールである価値の提供に対して、チームのパフォーマンスを最大化することだと考えています。

チームのメンバーが優秀かどうかではなく、現状のチームや環境を改善し、最大のパフォーマンスを引き出すことがゴールです。
そのためにプロジェクトを管理したり、どのような人間でどの様な価値観を持つ人間かを理解したり、そしてどのようなものを作るべきかを考えるマネジメントがあると考えます。

システムマネジメントの概念

これもマネジメントのため、ゴールは価値の提供である。
システムを完成させることがゴールではなく、価値を提供しなければシステムの意味はない。
ゴールの価値にたどり着くためにシステムが必要なだけ。

つまりオーバーデベロップメントでは価値提供に届かない部分の開発にコストを掛けている可能性がある。
汎用性や柔軟性を持った開発はコストが掛かる。それが価値に繋がっているかを判断する必要がある。
これはプロジェクトの状況やフェーズによって同じ判断にならないので、随時あらゆる情報の中でバランスを取る必要がある。
柔軟性などを持たないシステムを作った場合には技術的負債になりうる可能性があります。
しかし、価値提供のスピードは圧倒的に早い場合もあります。この部分を判断する必要があります。

次に短期の価値提供戦略と中長期の価値提供戦略は全く別物になります。
通常システムマネジメントをしないチームはビジネスメンバーの要求を最短で開発する短期価値提供に偏る傾向があるのではないかと思います。

システムマネジメントの具体的観点と施策

技術的負債

• 新規開発時の価値提供スピードの低下 (柔軟性・堅牢性)
• エンジニアモチベーションの低下
• 不要な運用コストの発生

よくある認識は上記のような項目であるが、完全悪ではないと言う認識を持つべき
何故ならば、負債を受け入れる代わりに価値の提供のスピードを上げることが出来ることが多いからだ
つまり、負債を受け入れることで受け取れるメリットと負債受け入れによるリスクの認識、そして負債解消の計画をする必要がある。ここが僕の考えるシステムマネジメントの大きな軸の１つであると考えています。

負債を受け入れることは事業のスピードの向上を意味することがあると言うことを認識し、事業全体を俯瞰した上でシステムのアーキテクチャや作りを決定する必要があるということです。

中長期的な計画を持って負債解消をしなければ、いつまでも負債は解消されず、全力で走っていても重りを付けたまま走っているようなものです。目標は全力で走ることではないです。重りを解消するタイミングを計画し、実行することが必要です。

Developer Experience (DX)

• テストコード
• 継続的なインテグレーション
• 最新バージョンのライブラリ/フレームワーク
• Gitなどでのコラボレーション
• ドキュメントツールによる知識の形式化、知識の管理と共有

エンジニアは快適に開発ができる環境を求めています。
快適に開発ができる環境とは、良いマシンや良い椅子などもありますが、システムの開発する上で安心して追加変更出来るようなテストコードや必要最低限のドキュメント、快適なデプロイ環境、チームコラボレーションをサポートするツールや運用など、エンジニアにしか分からない快適な開発体験があります。

ビジネスチームだけでエンジニアの環境改善を行うとやってしまいそうなのが、ひたすらエンジニアに甘い環境を作ってしまうことです。パフォーマンスが出せる良い環境と甘い環境は別物だと考えています。
しかし、エンジニアは環境作成や実行権限を持っていないことも多いので、組織的にはなかなか難しい課題とは思います。

エンジニアの体験(Experience)改善はエンジニアの手で行えると良いですね。

事業展開の想定から考えるアーキテクチャ構成やデータ構成

最初にシステム要件と来る情報は全ての情報が入ったものではなく、最初の価値提供のためのサイズになっていることが多いと思います。
ただ、事業コンセプトと市場状況とアイデアが掛け算されていると、事業方向性のいくつかのパターンとその中での可能性とがいくつかイメージとしてありうると思います。

その中でデータの成長やパターンの増加などをどのくらい許容できるように作っておくかは重要になると考えます。データ項目の増減はデータ分析や機械学習のモデルなどに影響を与えますが、それらの修正の影響をどれだけ許容できるように作っておくか、色々なパターンがあるロジックの部分の拡張性をどれだけしっかり作り込んでおくかなどは、持たせたい汎用性と柔軟性のポイントは事業や追加機能の方向性によって変わると思います。

これはエンジニアリングだけでは解決できない問題であり、事業の視点からシステムを俯瞰して判断する必要があると考えています。

システムマネジメントは誰がするべきか？

完全に組織の形によるものになってしまうと思います。
20人までのエンジニアのサイズであればCTOと呼ばれる人が事業的に重要なシステムをチェックして良いかもしれません。

複数チームで分かれているならばテックリードが中心になって考えるのが良いかもしれませんし、スクラムの考えではチーム全員で考えることかもしれません。
組織構造でサポートするならSREチームがその役割の一部を担っているかもしれません。

いずれにせよ、技術部分に関する投資と価値提供のバランス、短期と中長期のバランスを考え、段取りを作るべき人が居たほうがより良い価値提供につながると考えています。

締め

エンジニアにしかわからない感性の中でのマネジメントが存在していると考えています。
美しいソースコード、美しいアーキテクチャ、美しいシステム。
それらは厳しい要求があっても、すばやく開発ができるものだったり、エンジニアが楽しく開発出来るものだったりします。

それらを上手く決定し進めて、楽しい価値がある開発が出来るようなチームや組織を作れたらといつも願っています。

勢いで色々書きました。
面白かったらいいねくれると、また記事を書きます(笑)