2016年6月を振り返る

保守を担当しているシステムのお守り。データとかログとか、動かしていると増えていくものについて、どう処理するのか考えていなかったらしく、性能問題が発生。
「クエリの最適化」「DBのチューニング」など、その手の対応方法はいろいろあるが、「不要データを削除する」のが一番なので、そちらで提案、対応する。日々のサービスの合間に少しずつデータを削除するように仕込んだので、長期戦モード。

もう1件。データの保存先が手狭になったので、新しい保存先に引越しする話。現行データをひたすらrsyncでコピーし続けて3ヶ月。一通りコピーしたものの、3ヶ月もかかると元データ側に変更が生じているので、変更分をまたまたコピー。これまた3,4日かかるので、サービス止めて行うのは無理。新旧の保存先のファイル一覧の比較とDB上に記録されている状態とを比較して、手動で対応することで決着。スケジュールの関係で、切り替え作業は7月実施ということになる。

ホームページ作成のお仕事。元の原稿の絶対量が少ないので、増やすのが一番のSEO対策だな、これは。とりあえず提供された原稿を元に作って、確認依頼。期日を過ぎてからのデザイン変更の打診はやめてほしいなぁと思いつつ、2日程度で対応可能と担当が言うので、対応を進める。が、当然、できるはずもなく、結局6月では終わらなかった。不明点の確認をしても、返事が返ってこないので対応しようがないってのもあったけど、ただデザインを変えればいいとしか考えていないような担当も、問題。取り組み方を根本から変えないと、無理かも。

給料は据え置きということになったので、一気にやる気がなくなった。転職真面目に考えるか。こういう仕事の状況ではやってられないし。

7月に向けて。
ホームページ作成の仕事は終わらせないと、赤字が増大するだけ。保守案件も納期が来るので、時間を確保して対応する必要があるので、予防線を張って仕事をねじ込まれないようにする。

2016年5月を振り返る

GW。運用案件を抱えていると、月次レポート作成なんてものがあったりするので、ぶち抜きの休暇にはならず。しかし、出勤した1日で作成して、残りは有休を使って長めの休暇を確保。

休み明け。連休前に話がでていた改修案件の要件仕様書がようやくできてきたので、見てみる。が、当然のごとく不明点が出てくるので問い合わせる。結局、そもそも改修が必要なのかという話になり、運用で回避する際の問題点を探ることになる。問題点と解決するための改修案、工数を見積もる。

先月話が出ていた案件。結局仕様がfixできず、ズルズル延びていく気配。

こんなグダグダした案件だけでやっていけるような状態ではないので、Webチームのお仕事。ホームページ作成の案件が舞い込んできたので、プロジェクト管理のまねごとをやる。これではお金もらえないよってレベルだったで、ひたすらダメだし。これ、「どうあるべき」かを理解している人が作業者のケツ叩いてやらないと、事業として成立しないだろ。
収益を重視するなら、「今いる人員でできること」ではなく、「プロジェクトに必要な人員を確保する」という逆の発想をしないと。手が空いているからってグダグダなプロジェクトに入れられると、モチベーション下がる。

スポット対応したプロジェクトで、バグが見つかって対応。これ、潜在バグでしょ?svnで手を入れる前のレビジョンのコード見たけど、バグっている。このパターン、テストしていないだろ。

6月に向けて。
次のホームページ作成の案件がきたようなので、対策。今いるメンバーで対応することになるので、鍛える。
いくつか細かい作業の依頼が来ているので、まとまった時間を確保して対応する。
自分がメイン担当となっている保守・運用案件については、改修を行うタイミングでテストコードの作成とリファクタリングを行うようにしているが、その方針を継続する。そのうちcloseされるといわれているものの、案外、そういうシステムって長く使われるものだから。

協調できないスーパープログラマーは他社システムの開発に向かない

システム開発、特に、他システムの開発において、Single Point of Failerは避けなければならない。わかる人が一人に限定されないようにすることだ。会社として、特定の社員に依存するというのはリスクが高いので、避けるべきことだ。

一方、プログラマーは、人によって能力が大きく異なる。腕のいいプログラマーであれば、要件を適切に処理するプログラムを短期間で作成するし、腕が悪いと、いつまで経ってもバグ修正が終わらない。だから、生産性ということを考えると、スーパープログラマーはとても優秀な人種なのだ。

ただ、いくら腕が良くても、他人と協調できない人はシステム開発に向いていない。その人に依存してしまうとSPFになってしまう。また、次のシステム開発を行うために、誰かに引き継ぐ必要も出てくるのだが、引き継ぎが上手くいかないのだ。

本当に能力が高い人は、他人が引き継げるレベルで仕事をするのだろう。だが、中途半端なレベルだと、他人が見てもさっぱりという仕事の仕方をする。引き継ぐ側の問題のように受け取りがちだが、引き継ぎ元の人間が、他人に適切に説明できるほど理解していないということの現れなのだ。

自社システムであれば、何か問題があったとしても、自社の問題で済む。だが、他社システムの場合はそういうわけにはいかない。「会社として」対応しなければならない。既に他のシステム開発の担当となったプログラマーを連れ戻してきて、対応させるのか?いくつのものシステム開発を担当し、それぞれ、問題が起きるたびに連れ戻されて、それでも短期間に仕上げられるのか?

結局、適材適所ということになるのだろう。でも、トータルコストで考えた場合、この生産性の高さでどこまで管理コストを埋められるのか?リスクを取れる、自社システムを担当するというところで落ち着くのではないだろうか。