ソースコードや設計書が属人化している会社

■Gitで管理しているから安心ですか

開発会社ではGitHubやGitLabでソースコードを管理することが当たり前になっています。そのため「コードは残っているから大丈夫」と考える会社も少なくありません。しかし私が気になるのはコードそのものではありません。設計思想です。システム構成です。運用方法です。ソースコードが残っていても、それを理解できる人が一人しかいなければ属人化は解消されていません。

■コードは残っていても引き継げません

実際によくあるのは、ソースコードはある。リポジトリもある。履歴も残っている。しかし設計書がない。構成図がない。運用手順がない。という状態です。開発担当者本人は困りません。自分で作ったからです。しかし別の担当者は違います。コードは読める。しかし全体像が分からない。どこを触ると何が影響するのか分からない。その結果、調査だけで多くの時間を使うことになります。

■私自身が見たケース

以前確認した環境では、ソースコード管理そのものは非常にしっかりしていました。GitHubもある。履歴も残っている。バックアップもある。しかし設計書がありません。構成図もありません。運用手順もありません。担当者に聞けば分かります。しかし担当者以外は分かりません。つまりコードは会社の資産になっていましたが、知識は担当者の資産になっていたのです。

■顧客案件ほど問題が大きくなります

自社システムであれば調査に時間を掛けることもできます。しかし顧客案件はそうはいきません。障害が発生した。改修依頼が来た。サーバ移行が必要になった。その時に設計情報が残っていなければ、まず調査から始まります。顧客は開発会社へ依頼しているのであって、特定の担当者へ依頼しているわけではありません。担当者が変わっただけで対応品質が大きく変わるのであれば、それは運用上の課題です。

■設計書も納品物です

開発会社の中には「コードを見れば分かる」という考え方もあります。しかし私はそうは思いません。顧客へ渡すべきものはコードだけではないからです。構成図。設計書。運用手順。管理情報。こうした情報も重要な納品物です。担当者が変わっても理解できる状態を作るところまでが仕事だと私は考えています。

また昔は「顧客へ設計書を渡すとノウハウが流出する」「顧客へ構成図を渡すと他社へ乗り換えられる」と考え、あえて詳細資料を渡さない会社もありました。しかしそうした姿勢は顧客から必ず見抜かれます。顧客資産に関する情報を囲い込む会社という評判は想像以上に早く広がります。私は長く仕事を続けたいのであれば、顧客へ渡すべき情報はきちんと渡すべきだと考えています。

■私が確認するポイント

私が確認するのはソースコードの有無ではありません。第三者が理解できる状態になっているかです。具体的には、設計書があるか。構成図があるか。運用手順があるか。担当者変更時に引継ぎできるか。顧客へ共有すべき資料を渡しているか。こうした点を確認します。また月に1回程度は設計資料と実環境の差異を確認し、更新することもおすすめしています。

■属人化している会社に共通すること

こうした会社に共通するのは、担当者が優秀なことです。本人に聞けば分かる。本人が対応してくれる。だから問題が見えません。しかし担当者退職、案件引継ぎ、顧客対応などのタイミングで問題が表面化します。その時になって初めて、ソースコードは残っているのに運用できないという状態に気付くのです。

■まとめ

ソースコードを管理していることと、会社として管理できていることは別です。設計書、構成図、運用手順、管理情報も重要な資産です。担当者が変わっても理解できる状態になっているか。顧客へ共有すべき情報が共有されているか。その視点で一度確認してみることをおすすめします。

初回30分のオンライン相談は無料です。

「うちの運用は大丈夫だろうか」と気になった方は、お気軽にご相談ください。