自社サービスを運営する場合、
どんどん機能追加をしていくことが求められます。
基本的に完璧なサービスは存在しなくて、
ご利用中のお客様からの不満や要望がどんどん出てくるからですね。
お客様の
要望を無視すれば、離脱にもつながりますし、改善の機会も逃してしまいます。
ライバルが存在している場合は、いつかライバルに駆逐されてしまうことになります。
なので
自社サービスで収益を目指す場合は、
常に機能の追加を行う宿命ってやつを燃やして暴れ出すことになります。
規模こそ違いますがLINEやFACEBOOKなんかでも常にサービスの改善を行っていますもんね。
自分たちの運営しているホームページ作成サービス、デキテルも同じです。
500社に満たないユーザー数なのでLINEなんかに比べると全く少ないんですが、それでも多くの要望をいただきます。
お客様の要望を元に改善を行ってきたためにデキテルが生き残れているので、基本的に皆様のお声はとてもありがたいんですね。
その要望を満たすために、システムチームが常時、機能追加を行っている状態です。
デキテルのコード数は原稿用紙でいうと何枚分?
で、
機能追加を行うということは、
過去のプログラムに手を入れることになるんですね。
過去のプログラムが大きくなればなるほど、手を入れる際にチェックするべき項目が多くなります。
デキテルは、もう10年にわたって複数のプログラマーがコードを追加し続けているサービスです。
なのでソースコードは膨大になります。
400文字の原稿用紙は
行数でいうと20行です。
原稿用紙1000枚分というと膨大な量に感じると思いますが、それでも2万行です。
デキテルのソースコードをすべて合わせると、おそらく100万行ほどになっています。
その中に書かれていることを書き換える作業になります。
変な場所を間違えて変更してしまえば、全部のページが白紙になってしまったり、データが吹っ飛んだりします。
そんなストレスを抱えながら膨大な量のソースを把握しながら書き換えたり追加したりする行為がプログラミングなんですね。
エラー発生時の対応についてのメモ
朝にマネージャーMTGで話した内容のメモを貼っておきます。
システムチームへの依頼方法
システムチームへの依頼方法
–システムチームの希望としては
—-どういう状況で発生するのか
–Aくんからの要望
—-お客様に
—-というのも毎回聞き返しているので、その
—-何時までに回答をもらえるか、を聞く。
—-調査が早くなる
—-いつまでに何をするかを約束しているか、だけ教えてほしい。
–出せる限りは出している
–責任
—-システムチーム
——特定
——–難しい
———-誰の責任?
——情報を聞く
——–根掘り葉掘り
—-マーケチーム
——情報共有
——–どのブラウザ
———-コンパネで分かる
————再現
————–出来る
————–出来ない
——お客様対応
——–いつまで
——–謝る
——–それ以後の対応
—-曖昧
——再発防止策の策定
——名前
——–状況
———-エラー申告
————再現出来ている
————–システムチームに依頼
—————-改修依頼
————再現できない
————–マーケチームで対応
—————-お客様のPCでの再現
—————-思い当たるのは全部対応
——————対応メモを共有
—————-それでも改善しない場合
————–システムチームに依頼
—————-調査依頼
——–何をしないといけないか
——–調査
———-改修
——–エラー前提の調査
—-動作検証
——o
—足りない情報をどうするか?
—-Aくんが負担
——奥野に相談
—-N川さんに振れない
電子書籍にまとめてみました。
「正社員が1年で働く時間は
たった22%ってご存じですか」
代表ブログでアクセスの多い記事をピックアップしております。
幸せに働くとは何か? その答えがここにある。
奥野 勝也 (著), シナジーデザイン株式会社 (著) 形式: Kindle版
Amazonで99円で販売中
Kindle Unlimited会員なら0円
書籍の詳細はこちら