はじめに
引き継いだプロジェクトでシステムの運用を経験して一年が経つので、開発視点とプロジェクト視点で所感をまとめてみたいと思います。
あくまで個人の所感になります。
開発視点での所感(学び・今後に生かしたいこと)
-
短期より長期目線での開発を心掛けたい
開発速度と品質のトレードオフになるのかなと考えています。
速度重視でシステムを作ったものの「テストなし」「型なし」「多数のコメントアウト」「メソッドやコンポーネントが共通化されていない」という状態だと、後から発生する工数が計り知れないなと感じました。
具体的に発生した工数
- 型定義があれば未然に防げていたバグ対応
- テストがあれば未然に防げていたバグ対応
- 書き方が統一されていないCSSの修正
- テスト導入に向けた一部リファクタリング
- テスト作成
今後は以下の点を意識して開発に取り組みたいです。
- 型定義の導入
- コンポーネントライブラリの導入
- テスト駆動開発
速度と品質のバランスを上手く調整して開発したいなと考えさせられる一年でした。
プロジェクト視点での所感(学び・今後に生かしたいこと)
-
やること・やらないことを予め決めておく
今回のプロジェクトでシステムを開発した目的が「顧客(toB)の潜在ニーズを抽出し、受託案件につなげること」でした。
そのため開発速度を重視してシステムを開発し、いち早く顧客に利用してもらい、ニーズを抽出したかったのですが事はトントン拍子に運びませんでした。
実際に顧客からいただいたフィードバックの一例(ぼかしています)
A社「うちは社員数多いので権限を分けられる機能がほしいです。そしたら導入できそうです。」
B社「○○AIの最新モデルを使いたいです。」
C社「この画面のここを改修してほしいです。使いづらくって…」
プロジェクトの目的である「ニーズ抽出」以前に「システムの使い勝手」が課題となっていました。
使い勝手は顧客によってバラバラです。他の顧客でも上がっている要望から優先度をつけて対応することにしていましたが、あくまで「使い勝手」を良くするための対応であり「ニーズ抽出」を直接支援するための対応ではありません。(使い勝手が良くなることでニーズ抽出しやすくなるという相関はあるかもしれませんが…！)
そして「使い勝手」を良くするための対応には、後から発見されたバグ対応も含まれています。
これらを全て対応するとプロジェクトの目的達成に対して後手になってしまうため、やること・やらないことは明確にしておく必要があるな、と感じました。
ここからはプロジェクトの大まかな情報や業務内容について記載します。
プロジェクト情報
- 前の担当者が突貫で開発し、システムとしてはほぼ出来上がった状態
- 引き継いだメンバーは私含め2名。システムの技術スタックに触れたことがあったため。(一時期は3,4名でたいお)
- システムを顧客に利用してもらい、潜在ニーズを探って受託案件に繋げたい！
業務内容
- システムの改修や機能開発
- システムの運用 ←New
運用面でやったこと
-
顧客環境の構築・更新・削除
- 依頼を受けたら環境を構築し、システム設定・ユーザ登録などを行う
-
バグ改修や機能開発
- 優先度つけて対応
-
ドキュメント整備
- 利用マニュアルのたたき台を作成
- 環境構築の手順書を作成
- 環境情報の一元化
- リースノートの作成
-
社内での調整
- 営業サイドからの質問対応や環境更新日程の調整など
おわりに
運用も大変だと感じましたが、システムを長く使ってもらうには必要不可欠な要素だと思いますので考えやノウハウを身に着けていきたいです。