Introduzione 

Prezi AI.

Il tuo nuovo assistente di presentazione.

Perfeziona, migliora e personalizza i tuoi contenuti, trova immagini pertinenti e modifica le immagini più velocemente che mai.

Caricamento del contenuto in corso...
Caricando...
Trascrizione

保守ってトラブル対応だけしてれば良いんですか?

いいえ違います

トラブル対応「も」するチームでした

保守予算が月何十万かあってその枠で

 各クォーター毎の改定(保険の新商品とか既存障害修正とか)

 トラブル対応(夜間バッチが落ちたヨー)

 各種問い合わせ(データがおかしい!印字がおかしい!昔OKだした仕様だけどおかしい!)

大手Sierで見た!

ウォーターフォール×下請け構造の闇

(o・∇・o)べり〜やみ〜

自己紹介

warning!

このプレゼンはノンフィクションですが、実在の人物・団体名とは一切関係ありません

間違って出てしまってもそれはフィクションです

・名前:**祐*(身の安全のためマスキング)

・年齢:17歳(※アイドル換算適用後)

・近況

 ギー**ボ*野のエバンジェリストになってしまった!

・今回はプレゼン資料としてpreziを使ってみました

ご静聴ありがとうございました

すべての現場が平和でありますように(-人-)

最後に・・

・顧客とSierの相互不信

・ウォーターフォール型の限界

・このままだとやばい

問題点はウォータフォールとかアジャイルとかよりも下請け・孫請け構造にあるんじゃないのかなと思った

とはいえ超巨大システムを今更アジャイル化できるのかな?という気がする

→今でも品質は保たれているので、別の手法には切り替えられないんじゃないのかな

今の不幸な状況はまだまだ続くのかな

これが僕が新人の頃から行っていた現場のざっくりイメージデス

←お客様(保険会社)

←保険会社のシステム子会社

結果的にこの体制は変わらない!

←大手Sier(ITゼネコン)

僕のいたチームの主な業務

僕が頑張ってる間にもこの人たちには毎月お金が入っていきます

中抜き業者

 大手Sierと仲良し、保険会社の合併対応で謎の巨大バッチシステムを作った後、リリース一ヶ月前になって全員逃亡

僕が派遣された会社が保守を引き継ぐことになる、その後も体制図上だけこの位置にいる

保守作業

←某国のオフショア

(何かとやらかす、プログラム知識に関しては結構優秀だったりするが相当いい加減)

←僕が派遣された会社

 他に仕事がないからすごい頑張る、めっちゃ優秀、一切妥協しない

←僕、一昨年の10月

 ぐらいから死んでた

なんのために生まれて〜なにをして生きるのか〜

というわけでますます残業時間が増えます、タスクは毎日増えるけど

工数は1day8H、単純に人が増えても業務知識がないと何もできない

分からないまま終わる

そんなのは嫌だ!

24:30

後続ジョブも稼働を確認(念のため確認落ちたことを見たことがない)

まだ最終はあるが、だいたいラーメン食って帰ろうという流れになる。

今日も家系おいしいにゃ〜♪

23:30

ジョブも実行が終わる・・まだ電車はあるけど

後続の大事なジョブを確認して帰ろうという流れになる

23:00

 既知の障害ならテスト環境でプレランも終わり

 本番のジョブを修正して反映、実行依頼

うまい!

22:30

 ようやくアベンドしたデータがテスト環境に落ちてくる

 もちろん、ジョブにしくじりがあれば作り直し

3:00 へろへろになりながら寝る

22:00頃

① 各種申請書を出す→社員さんの確認承認

②色々なジョブを作る→社員さん確認承認

ざっくりとしたクォーター毎の改定イメージ

ここに本番トラブル作業が入ってきます

21:10 障害を検知!(オペレーター→Sierの社員→僕たち)に電話がかかってくる

こんな感じで、ジョブが一個落ちると一晩×3人ぐらいが崩壊します。

そして、翌日には障害対応フォローだとかなんだとかがあってもう1日失います。

当然、障害対応なんてスケジュールに入ってないのでこちらがずたずたに遅れていきます!

4月1週目キックオフ!

4月2週目概要設計・外部設計完了

4月3週目内部設計完了

4月4週目詳細設計完了

5月2週目単体テスト完了

6月頭連結テスト完了

6月下旬ユーザーテスト完了

7月中旬リリース

そんな僕が生きていけたのは声優さん

のおかげでした

問題点:本番環境にからデータを取ってくるのにJCL(シェルみたいなの)を作って申請しなければならない、定番の障害でも全部テスト環境でプレランして確認しないといけない、一つ一つがとにかく時間がかかる→安全性>時間

対応策:

 既存の障害は対応手順書を作る

  ・データのアップデート手順

  ・ジョブのひな形を用意

 システム全般に詳しい要員の育成

  オンライン入力〜サーバーB/T〜ホストB/T

  業務全般の把握

 ミスらないように徹底的に調査する

  →見積もり段階でほぼ詳細レベルまで調査する、もちろん見積もりの工数はない

問題点:

とにかく動きが遅い!

同じ話を何回もしないといけない!

障害発覚からリリースまで早くても3週間はかかる!

状況によっては直し方まで全部分かっていても

別途テーマ化でずっとほおって置かれる

その間に別の障害が起きたりテーマ対応にバグが見つかったとか、オフショアがやらかしたとかで

タスクばかりがたまっていく

声優イベントで「圧倒的成長」

声優さんに「圧倒的感謝」

というのはまた違う話・・

COBOLはプログラミングの知識で読むんじゃない!

業務知識を以て処理を推測しながら読むんだ!

もしこれが新規の障害だったら・・・

翌日1日掛けて原因が分かるまで調査

働きたくないにゃあああ

月単XX万の使い放題プランなんだからきびきび働くにゃあ!

ちなみにどちらもネコキャラなのに魚が嫌いなアイドルという共通点に今気づきました

調査結果はだいたい以下のことを書きます

・現象:バッチが落ちた!

・直接原因:なんかデータがおかしいから

・根本原因:データのセットに不具合

・修正方法案:セット仕様を修正

・既存データの対応案

・修正にかかる日数

①チーム内レビューします

5人×1.5Hぐらい

もうこの時点で障害発覚から一週間ぐら経ってます!!!

②Sierの人とレビューします、全く同じ話をします。6人×1.5Hぐらい

その間にもバッチは落ち続けたり

やばいデータを作り続けます

もちろん、通常の改定作業も引き続き行います

③sierの人がお客様と話をします

 スケジュールとか詰めます

 お金はよく分からない

問題点2:

基本的に下請けと元請けは相互不信の関係にある

単体テストなどは全部完璧なエビデンスを作って

責任を押しつけられるようにできてる(レビューしたよね!OKだしたよね!?)

問題点3:

戻り作業が許されない

連結で障害が出たら調査

・報告

・詳細設計書の修正

・単体テストケースの作成

・ITケースの修正

これらを全部社員さんのチェック確認

そんなスケジュールはない!

Scopri di più su come creare presentazioni dinamiche e coinvolgenti con Prezi.