「私、失敗しないので」を目指す「開発・運用」

GMOアドマーケティングのKMです。

前回は、「要件定義」~「設計」について書きました。

GMOアドマーケティングのKMです。前回、エンジニアの職種について記載しましたが、 今回はどの職種にも当てはまる作業工程について書いて行きますね。 はじめにシステム開発は、アジャイル開発などの開発手法がありますが、弊社ではプロダクトにより使い分けております。私の携わっているプロダクトの基本的な流れは下記ですが、各フェーズ毎に落とし穴●があるので、最後までナイスイーン(落とし穴に落下)せずにゴールする為の経験則を駆け足でご紹介して行きます。「要件定義」~「設計」~「開発」~「テスト」~「リリ...

今回は、「開発」~「運用」について書きますね。★がポイントです。
最終ホール●まで落とし穴に落ちず、システムを無事運用開始できるのでしょうか。
あなたの選択肢ー 💡 は?

「開発」

10.★開発内容にマッチする適材適所なメンバーをアサインする事が最重要です。 😎

例えば、データの最適化なら、データベースに詳しいエンジニア。
管理画面改善ならフロントエンジニア。メンバーの意向や適性がある開発案件に
アサインしましょう。スキル成長、品質、スピード全てに繋がります。

●IT業界はスピードが大事で、選択を間違えると競合にも抜かれ、最悪ビジネスが立ち行かなくなります。 🙁

11.仕様の伝達 💡

仕様が伝言ゲームのように違う物で伝わらないよう正確に伝える必要があります。
●文章だけ書いてお願いすると人により誤解や読まれずに見落す場合がある為、
★キックオフMTGで全体の流れや重要点を伝えて大きな誤解を防ぎましょう。

12.開発 😎
★自分が触れた事がない箇所を開発する場合、先ず現状を落ち着いて読み解きましょう。
イマイチに見えるコードの場合、使い続けるか、新規に改造するかの選択肢がありますが、
●改造を行う場合は期日を調整してもらいましょう。無理に進行すると障害発生に繋がります。

「テスト」

13.セルフテスト
変更した影響範囲に対し単体テスト、必要に応じ結合テストを行いますが、
関連する影響範囲に不安を感じたらチームメンバーに確認しましょう。
●思い込みや勘違いのまま進行すると障害発生に繋がります。

14.レビュー依頼
軽微な修正やリスクが少ない場合は誰でも良いと思いますが、急ぎや、
影響範囲が大きい場合、最も詳しい方にレビュー確認依頼を出しましょう。
●誰に依頼するかの選択を間違えると障害発生に繋がります。

15.レビュー(クロスチェック体制) 😎
レビュー担当者がチェックします。★複数人の目を通す事で「気付きが得られ」
「仕様を共有でき」「不具合が格段に減る」為、極力行える体制にすべきです。
●結合テストは依頼者、レビュー者、自動テストいずれも行なわれない場合に障害に繋がります。

「リリース」

16.リリース前の準備
★リリース後にリリース前との差異が確認できる状態にした上で、
関係する開発・インフラメンバーに今からリリースする旨を周知しましょう。
●リリース案内がある事で障害が発生した場合の対応もスムーズになります。

17.リリース作業 ➡
テストを行っても様々な要因で不具合が出る可能性はゼロではない為、
障害が発生した際に影響時間を最小限で済むようにシステム利用が少ない時間帯や
●障害時に素早く対応できるメンバーが居るタイミングでリリースを行います。

★リスクや影響が大きい案件をリリースする場合は、サーバー1台など、
影響範囲が最小限で済むようにリリースします。

18.リリース後 😎
リリース後に問題がないか確認後、リリースが完了した旨を関係者へ周知します。
★利用方法がわかりずらい場合、利用方法を添えて案内するとスムーズに運用に移れます。
●重要な変更を案内しないと、使い方を誤りトラブルにも繋がります。

「運用」

リリースしたぜ :-Pこれで18ホール回ってナイスイーンと全落しなかったら、
ビールでも飲みに行って良いのですが、要望元の意図通りシステムが運用されているか
定期的に振り返りを行い 🙄 意図通りにいかない案件は原因を追求し改善を図ります。

最後に

メンバーの良い点は、どんどん積極的に見習い成長していきましょう。
そういう意味で、チームは複数人の構成で開発する事がオススメです。
選択肢ー 💡 を間違えたら時間は元に戻せないけど、
リリース作業だけはリリース前に戻せる(ロールバック)できるようにしておこう。

次回は、組織におけるプロダクトMとプロジェクトMの役割について書く予定です。 😎