先日、プロジェクトマネジメント学会の勉強会に参加しました。参加者はITベンダーを中心としたシニア層の方々で、本日はその中で出た『技術的負債』『プロジェクトの成功における保守・運用』　に必要な要件の2点について思うところを書いてみたいと思います。

参加した勉強会のテーマは「ITシステムの保守性について議論しましょう！」となっており、

概要は

プロジェクトの成功を運用・保守フェーズに広げて評価しているか？「保守性」に焦点を当て, システムそのものだけでなく,サービス・業務, 事業の観点から企画・構築時に考えるべき要件, 運用・保守時の要件, システム再構築時の要件について議論しましょう、という大変興味深い内容。

実務の中での学習や経験を体系化したいという思いは以前から強くあり、学会のような場に行くと、同じようなプロジェクト管理に探求心と実務経験をされている方との話の為、お話も大変参考になり、刺激にもなります。

当日は、講師の方がなぜ本テーマを選んだのかという背景に始まり、保守・運用目線での問題プロジェクトとのかかわり方についてもお話がありました。その中で、『技術的負債を増やさない為に生成AIをどう活用できるか』というグループセッションがあり、講義の内容について感想文のように書くよりは、そのセッションの中で、技術的負債というおもしろいキーワードが出てきましたので、ここからはその内容について私なりの解釈を含めて書いてみたいと思います。

はじめに、　技術的負債　とは　・・

要約すると、リリース後の残課題で設計やコードに関わる開発の積み残しということのようです。

つまり、ドキュメントや設計不備、開発者の暗黙知となり、開発方針や設計方針のような言語化できていないもので、リファクタリングする際に必要になる手間とコストという事にも置き換えられるかも知れませんね。

この技術的負債は、実はプロジェクト期間でもQCDのDを重視するあまりにQが取り残されていく中で後々出てくる課題で、よくある流れだと、設計書に書いていない⇒レビュアーが質問⇒設計者が回答⇒設計書に書かれず、質問したレビュアーと設計者以外はわからないままFixされ、いつの間にか暗黙知になるケースや解釈が発生して、仕様の理解誤りから後続工程に影響するようなクセのあるものです。

ちなみにこの技術的負債について、講師の方からは、①実行ログの問題　②システム構成図など全体像がわかるドキュメントがない　③ライブラリ構成などのソースが整備されていない　大きく3点に集約されるとの事で、保守性の向上がポイントと考えるようになった理由も大変参考になりました。

ここからは、プロジェクトの考え方になりますが一方、保守・運用目線で必要な観点を要件定義時にどこまで組み込めているかというのは、システム開発の管理に携わる中で、意外と大切で、業務要求を方針や方向性にまとめる際に後回しになることで、事後で時間に追われてしまう問題でもあります。

では結局、システム化をするための企画段階で、どこまで保守・運用を考える必要があるのか、というのは利用ユーザーと用途を明確にする中で、要件化に分岐してその運用を考える体制やリソースを充てる事が大事で、現状、要件定義段階ではあまり考えられていないプロジェクトが多いのも事実です。

一方、設計書のレビューに参加する際も、『どういう意図や狙いで』その仕様にしたのか、というのは実は暗黙知でドキュメントに落ちていないことも多いので、設計方針を事前に擦り合せるか、設計書内でその意図を書いておくことで防げるのかなと思っています。

プロジェクト管理時の対策としては、

①システムのTo beに対してどのような運用を行うかの目標設定QCDのQに組み込み評価ができるように企画フェーズから動く

②保守運用観点でシステム（サービス）性能に対する要求は概要レベルでも要件定義に組み込む

③設計指針や品質の指針・ガイドライン（がある企業はそのガイドラインを）企画段階で具体化して非荷室要求や技術的負債の発生要因にならないよう定める

具体的には、計画書・要件定義書など管理方針を定める前の企画概要の検討フェーズで上記のような指針・方針をプロジェクト前に明文化。設計レビューもレビュー観点を事前に提示してその観点に沿ってまとめておく必要があるということですね。

プロジェクト管理は、突き詰めると学問になると思っています。途上だから面白く、システム観点の管理とコミュニケーションや人の管理を軸にした管理では全くアプローチも異なってくるので、そのような語らいができる方と一緒に仕事が出来たらと思っています。