仕様変更との戦い

SEの勤務時間が普通ではないくらい長くなる理由は、

障害と仕様変更だと思っています。

私が現在参画している開発プロジェクトは今月末の現場運用開始に向けて

もう切替準備フェーズに差し掛かっていますが

プロジェクトとして設定した仕様変更の締切を超えてもまだ

ユーザー側から変更要望が複数発生しており、滑り込みで対応に追われています。

このような場合、プロジェクトマネージャ、リーダなどの管理チームとしてどう対応するかをまとめました。

お金を貰えても時間は貰えない

追加要望に伴う追加金額の請求はよく揉める場面ではありますが、

滑り込みの対応はそんな調整もする時間がなく、

ユーザーは「お金は払うからとにかく納期までにやってくれ」というスタンスになります。

ただし、期間がかなり厳しいものになります。

リスクを取ることになる

期間が無い対応には、品質面でのリスクが伴います。

• 間に合わせるためにテストが省略される
• 切替準備と並行している事による資源管理のトラブルの可能性

これらを説明しても、そんなのは開発側の問題だろうと思われますが、

開発側がそのリスクを抱えて作業をするという事をよく認識し、
出来るならユーザー側にも伝えます。

人をどう確保するか

時間も体制も無い所から、仕様変更を対応する体制を取らなければなりません。

しかし、全く新しい人を入れても時間がかかりすぎて間に合いませんので、

今いる人にお願いする事となりますので、何か作業を剥がしてあげる必要があります。

変更作業が出来るスキルがあり、自分以外でも出来る作業をしているという人を探してお願いするように調整します。

デグレードのリスクをどう回避するか

資源の変更状況をしっかり把握することが何より大事です。

誰がいつ何を修正するのか、

構成管理ツールに頼らずプロジェクトとして変更管理を綿密にします。

管理チームだからといってプログラムの修正箇所を把握しておくことで、

少しの変更でも対応できる柔軟性を持つことが出来ると思います。

信頼を高められるチャンスである

このような、プロジェクトにおいて想定外な変更はユーザー側も、無茶を承知で依頼しています。

ここで開発側が頭から拒否するのではなく、リスクを取りつつも確実に対応し、成功に導くことで

ユーザーからの信頼、感謝を勝ち取ることが出来るのだと思います。

システムトラブル発生時に冷静になるには

トラブルに対応の際絶対にやってはいけない失敗

トラブルが発生して連絡があり対応する際、絶対にやってはいけないのが下記の２つだと思います。

• 影響範囲や目処などを間違った内容で報告してしまう
• 誤った対応で二次災害を起こす

これらを引き起こすのは、対応者のスキルより、「焦り」が原因だと思っています。

何故焦ると間違うのか？

それは「判断を早めてしまう」からだと思います。

もう少し時間をかけて確認すれは間違わない事を、

とにかく答えを早く出すことを優先にしてしまう事で間違ったままになってしまうのです。

また、焦るといつもなら気付ける「確認すべきポイント」を見失ってしまう事があります。

例えば、サーバー障害が発生して

ある設定変更が必要になったとします。

その設定を変えるためのコマンドを見つけた時、焦っているとすぐに実行して終わらせたい、と思ってしまいがちです。

このコマンドを実行して、他の範囲に本当に影響がないのか？

コマンドのオプションはこれで正しいのか？

元の設定と変更する場合、何故元の設定だったのか確認しているか？

トラブルでユーザーから「早くしろ、早くしろ、」と言われて焦ってしまうと、

このような当たり前に確認しないといけない事を飛ばしてしまうのです。

どうすれば焦らないで済むのか？

私が考える、トラブル時に焦らないで済む方法をご紹介します。

1. 状況を見える化する

事象、原因、作業分担、進捗を整理し共有します。
これにより、何をすべきか正しく把握できます。

この内容を顧客に報告する場面が多いと思いますので、
正しい情報で、漏れなく整理しましょう。

2. 対応に充分な時間を確保する

トラブルの際、緊急度を決めるのは顧客であるユーザーです。
現場の仕事が止まっていますから、一刻も早く復旧してもらいたいのです。

ですが、そんな顧客の心情に振り回されてはいけません。
どんな状況であっても、作業にかかる時間を一定以上は短縮できないのです。
ましてや、確実に失敗できない場面であるため、
時間はトラブル時でない時より長めに設定しましょう。

特にサービス精神を持った人は注意が必要です。
かかる時間を早めに報告してしまうのです。
そして出来なかったことにより、信頼を無くしてしまう可能性があります。

トラブル時の交渉は顧客との信頼関係によって成り立ちます。
相手の望まない回答であろうと、偽らずに報告するべきです。

時間を確保できれば、対応者の心の余裕が生まれ、
失敗するリスクは確実に減少するでしょう。

3. 判断を急がず、対応の妥当性をチェックする

対応案が見つかったら、すぐに対応して終わらせたくなってしまいますが、

ここは我慢が必要です。

下記のポイントを必ず見直しましょう。

• その対応だけで本当に解決するという事を説明できるか
• その対応によって、他の部分に影響がでないことを説明できるか

説明できる、という表現にしたのは、説明できる=根拠があるということです。

根拠があれば、その内容には充分な妥当性があると言えると思います。

4. ダラダラ考え過ぎない

3. まで行けば、あとは顧客に説明の上で作業を実行しましょう。

作業者同士での議論が深くなりすぎると、

いつまで経っても解決しません。

最悪の場合、せっかく一度対応案がまとまったのに別の案が浮上し、

さらに時間が無くなるということもありえます。

慎重に検討することが大事とはいえ、線を引いてしまうことも大事だと思います。

5. なるようにしかならない、というメンタルを持つ

これまでの注意点を押さえてなお解決しなかったり、

失敗することはあると思います。

しかし、自分だけの責任と重く考え過ぎないことです。

失敗してしまっても、自分はやるだけの事はやった、

今回のことは勉強になった、と思うようにしましょう。

私自身、以前トラブルで焦り過ぎてお客様に大変叱られたことがあり、

今回の記事のような事を考えるようになりました。

メンタル面はまだまだ修行中ですが、すこしずつ落ち着けるようになったかなと思います。

保守運用担当システムエンジニアという仕事のこと

私の仕事は、企業システムの開発と保守です。

不具合や問い合わせの対応、
既存システムの改修が主な仕事です。

保守SEはどういうイメージを持たれているか

ブログに自分の仕事について書くに当たって、
システムの保守って世間一般ではどんなイメージ何だろ？
と気になったのでちょっとググってみました。

システム保守は開発と違って，華々しく「○○システム稼働！」と注目されることはまずない。そういう意味では地味な仕事だ。

【IT業界の職種・仕事が分かる！ITのキャリアプラン50】 システム保守エンジニア：1人で何役もこなす，地味だが収穫の多い仕事

筆者の知る限り、若手のエンジニアに保守・運用はあまり人気がありません。確かに地味な印象ですし、徹夜が続いたり突然電話がかかってきたりといった悪い情報が多いのは事実です。 

システム開発の全体像を一気に把握! 新人技術者のための開発工程講座(6) - 保守・運用 

新人の頃、私も保守より開発がやりたい、なんて言ってました。
それは、ずっと同じ現場で同じお客さんと接していることが、進歩の無い事だと思っていたからです。
システム業界は日々新しい技術を自分のものにしていかなくてはいけない仕事。
ずっと同じシステムのお守りなんて、バリバリ仕事をする事から卒業した人たちしか居ないと思っていました。(今考えると何て傲慢な。。。)

でも、実際私は今、保守運用担当のエンジニアとして、日々悩み、学びながら仕事をし、
成長していると感じているのです。

実際の保守SEはどんな仕事？

保守をしていると、下記のような様々な種類の、毎日違う仕事が舞い込んできます。
しかも、納期は現場への影響度により即日から不急、いつかやって欲しいなど
様々です。

• 仕様や操作に関する問い合わせ
• バグの改修
• システムの機能追加
• バッチジョブのエラー調査
• サーバー高負荷の原因調査
• サーバーの定期点検・交換

…など。

とにかくいろんな種類の仕事が舞い込んでくるので
SEにも色んなスキルを求められます。
しかも開発とは違い、区切りが明確でなく
体制もその時の作業に充分ではない時もあります。

その分、全部自分で決めて自分の力で進めることが出来るのが
保守SEのやりがいのある点ではないかなと思います。

ただ、いつどんな仕事が舞い込んでくるか分からないので
プライベートの予定は入れにくいですし、
突然徹夜しないといけなかったり、夜中電話で呼び出されるというのは
上に掲載したサイトにも悪いイメージとして紹介されていますね。。。

私も急に忙しくなると本当に疲れます。
特に大きなトラブルになると焦るし、顧客も色んな人が色んな事を言ってくるし。
でも、その分動じない精神力はだいぶ身についたと思います。
開発者として色々な現場で経験するのは憧れましたが、一つの場所で人との信頼関係を固めていくのも良いものです。

こうして自分の仕事を見直すと、大変だけど実りある仕事だと感じます。