その仕事、全体に携わるか？部分的に携わるか？

最近、生成AIってどんな感じなのかな？精度はどうだろう、という確認をこめて ChatGPT や Claude を使ってブログを書いていました。全体的に綺麗すぎて、「生成AIを使った文章」とわかってしまいますね。ということで、今回は生成AIを使わずに 100% だらだらと人間味をだしていこうと思います。心の声も文字にしておきます。

ソフトウェア開発としてどこまで携わるか

こんなことをXで呟いた。ソフトウェアとかハードウェアとかに関わらず「開発」というものに携わってから、ずっと言っていることでもある。何ならソフトウェアという概念がない古(いにしえ)のモノづくりから言われていることなのでは。つまり、こんなこと昔から知見があるがそれを理解できる人が少ない、ということでもあるのでしょうね。

開発するものベースに考えると、「誕生」して「なくなる」までというライフサイクルに注目してみよう。

ソフトウェアのライフサイクル、SLCPというもの

Software Life Cycle Process という考え方がある。(え、何それというかたはITパスポートの参考書をペラペラめくってみましょう)ソフトウェアの開発から運用、保守、廃棄まですべてのプロセスを包括的に管理する枠組みです。プロセスは次のように分けることができます。

プロセス やること
企画 目的や要件を明確にし、全体の計画を立てる
要件定義 満たすべき機能や性能を定義する
設計 要件に基づいてソフトウェアの構造や動作を設計する
実装 設計に基づいて実際にコードを書き、作る
テスト 要件を満たしているか、バグがないかを確認する
導入 実際の運用環境に導入する
運用 日常的に使用し、必要に応じてサポートする
保守 修正や改良を行う。ソフトウェアのバージョン更新も入る
廃棄 不要になった際、削除する。取り除く

皆さん、いかがです？どこを担当されています？

運用・保守・廃棄を経験しない背景と理由

「どこを担当されています？」とわざと書いたのは、「運用・保守・廃棄」を経験していない、またはやってはいるけど正直割合としては下げてしまっている、というのが多いのではと思ったからです。それが悪いのではなく、仕組みとしてそうしている、そうせざるを得ないではないでしょうか。

ざっくり、次のような背景と理由がありそうですね。

役割分担

企業によっては、開発チームと運用チームが別々に存在します。開発チームは新しい機能の開発やソフトウェアのリリースに集中し、運用チームはリリース後のソフトウェアの運用・保守を担当します。この分業により、各チームが専門性を発揮できる反面、開発者が運用フェーズに関与しない

プロジェクトの区切り

リリースはプロジェクトの明確な区切りとなり、その後の運用や保守は長期的な活動となる。プロジェクトの区切りが明確になることで、開発チームは次のプロジェクトに移行しやすくなる

契約や予算

外部の開発パートナーやベンダーとの契約においても、リリースまでを範囲とることもある。運用や保守は別途契約されることが多いかも

リソースの最適化

専門性に基づくリソースの最適化により、開発と運用・保守のフェーズでそれぞれ異なるスキルセットが必要になる。開発者は新機能の設計と実装に集中し、運用チームはシステムの安定稼働やユーザーサポートに専念するとか。

そもそもそんなに長く在籍していない

ソフトウェアといえど、数年間は使われたりします。が、昨今は3年もすれば転職してしまうような時代です。ゆえに、最後まで付き合うことがないのかも知れません。 (ということはですね、最後まで付き合うという経験は価値あることなのかも知れませんよ)

結局のところすべて経験する仕組みを作るのが良いのでは

運用・保守が必要なのは、開発したものが健康で長生きしてもらわないといけない。なんでそれが必要かというと、健全に動き収益を上げて欲しいから。

話がずれてしまったが、分業体制の場合、自身が担当する役割だけではなく全体的にどのような役割をしているのか理解しておくと、全体的にパフォーマンスが上がると思います。1番やってはいけないのは、局所最適になってしまうとか、高すぎる自尊心・優越感・承認欲求からくるポジショントークによる対立構造、本来不要なエネルギーを使ってしまうこと。

そうならないように、お互いの役割を理解するために短期間でも良いからローテーションするなりして「経験」しておくのが良いのかなと思います。ようはリリースまでを担当する人は、たまに運用・保守を担当してみるとか。時には廃棄を担当するとか。結局のところ、人はやってみないと理解できないのです。

運用・保守をやってみると、気づくことがあるかも。例えば、設計で考慮を追加しておくと良いことがあるな、テスト観点として必要なことがあるな、とかリリース前にやっておくべきことを学べたりします。純粋にライブラリのアップデートって大変だとか、もしメジャーアップデートで破壊的変更が入ったらやばくね？とかもあるかも。そうならないようにあらかじめ設計に盛り込んでおくとかもできそうですね。逆も然りです。

まとめ

責任者がいてSLCPの全てをみている方もいるかもしれないし、それがチームとして責任を持っているかもしれない。でもチームメンバーとしてそれを理解した上で、役割を全うできる方が素敵なんじゃないかなと。いやそうじゃなくて、自分の役割さえ果たせば良いのでは？という方もいると思います。それでチームが気持ちよく回るのであれば良い。チームのパフォーマンスが最大化されていればね。今回はソフトウェア開発に関して書いていますが、他の仕事も同じですよね。セールス活動を分業体制でやっていたり、人事制度を設計・運用したりと。

その仕事、全体に携わるか？部分的に携わるか？ 週末に考えてみるのも良いかもです。