Please enable JavaScript.

Coggle requires JavaScript to display documents.

仕変T　課題整理 (開発プロセスの点検 (H28赤字原因 (顧客作業が遅延した (作業支援を行う, 顧客作業の見える化),…

- - - - 要件確定後の再見積りができていない
      - 見積ツールの係数がいけてない
        
        新バージョンを作る
      - 実績計上において、概要設計につけるべきものを要件定義に計上してしまった。
      - ACの入力がめんどくさい
  - - - 作業支援を行う
      - 顧客作業の見える化
    - - アジャイル！
        
        完璧主義意識の改革
    - - WBSのテンプレートを作る
    - - UIに関する研修を受ける
      - ユーザーになったつもりでテスト
  - - - プロセス一覧
        
        SA・UI・PG・PT・IT・UT
        
        運用フロー作成
        
        資料収集から
  - - - 資料修正結果の確認
        
        修正を修正した結果まで確認する必要があるか
        
        参加者全員に確認する必要あるか
      - インスペクションを取り入れたい
      - 指摘事項をチェックリストに追記する仕組み
      - 参加人数が多すぎ
      - BPさん一言も発せず
      - レビュア自身のスキルの差
        
        レビュー役割を決める
    - - EVM
        
        EVの取得が難しい
  - - - いきなり詳細な資料は作らない
      - 成果物定義
  - - - 簡単な案件を担当させる
        （担当サブを超えて）
      - 変数の型さえ理解していない
- - - - 画面を大型ディスプレイで見せる
        
        ボタンの挙動まで実装するのは難しい
        
        指摘事項を即座に反映できない
        
        保守環境（UT、Reserve1など）にリリースする
        
        契約T移管案件で試行する
        
        ある程度要件が見えてないと
        プロト作りが難しい
        
        出張経費で試行する
        要求引き出しプロセスの確立後プロト
        
        Balsamiq
      - 仕様案が実態とずれていて
        抜本的な再検討を余儀なくされる
        
        要求について、どこの誰から
        どんな課題を解決したいのかが分からない
        
        そもそも現状の業務が見えていない
        
        現行業務の調査・分析
        
        現場・現物の確認
        
        マニュアルを読む
        
        課題の確認、想いの吸い上げ
        
        アンケート
        
        WEB会議活用
        
        課長会議・ITキーパーソン会議の活用
      - データチェック、メッセージなど細かい内容の確認はしない
        
        修正作業に負荷がかかるのでは
        
        テスト自動化
        
        UT期間の延長
    - - 部別飲み会
        
        ガス抜きさせる
      - 顧客特性の理解
        
        業務部は確定事項を忘れやすい
        不平・不満が多い
        他責傾向
        自分達の利益を守る
        最重要ステークホルダー
        代理店向け機能に重点を置く
        
        営業部・支払管理部・客サは比較的まとも
        
        総務部は頑固
        何でも瑕疵にする
        
        システム部は人手が足りない
        
        監査に抵触しない程度で
        協会業務へ介入
        
        IFTCに振れる作業があるか？
        
        マクロを作る
        
        社員代替
        
        財務部は上林さん頼み
  - - - 利用状況の分析
        
        なぜ使われないのかが分かれば
        魅力的な提案ができるかも
      - 約款改定
        
        後払い他社事例の収集
      - 協会が抱えている課題・ニーズの収集
        
        部門別活動方針の分析
        
        業務品質の向上
        
        新水先案内人
        
        いけてないメッセージの改善（事象、理由、次の操作）
        
        誤交付防止対策
        
        業務運行状況
        ダッシュボード
        
        飲み会での本音引き出し
- - - - エビデンス自動取得
      - セレニウム
- - - - 要件定義書・議事録記載あり
        
        協会が仕様変更を承認
        
        仕様変更
        
        協会が仕様変更を否認
        
        保守対応
        ただし工数がかかりすぎるものは個別相談
      - 要件定義書・議事録記載なし
        
        保守対応
        ただし工数がかかりすぎるものは個別相談
      - サポートデスク進捗会で
        保守・仕変の判断を協会にしてもらう
        経緯の説明も実施する
        
        保守工数厳密に実績工数管理するか
        
        明細を見せたら、何で保守で対応しているの？という
        疑問が出てくるはず
        瑕疵を判断する必要が出てくる
        
        泥沼の戦い
        水掛け論
        
        かなり大変
        
        仕変Tから概算工数をGETする
        
        OTRSで運用
    - - 一般的に仕様変更と思われる案件について
        エビデンスがあっても保守での対応を求められる
        正論は通用しない
        品質には割と寛容
        新技術の導入にも抵抗がない
        
        システムのプロとしてユーザーを
        リードすべき
        
        保守工数もお金をもらっているので
        保守で対応となっても無償対応ではないという考え
        （名より実を取る）
        
        必要最低限だけの対応
        網羅性・効率性を担保しない
        リリースは目一杯先延ばし
        
        年間3億5000万も支払っている
        多少のわがままは巻き取ってほしい
        工数が少ないものは保守対応してほしい
        
        今は耐える時
        きっと未来は見えてくる
        反面教師
        
        直接ユーザーの利便性に寄与しないので
        障害対応はしたくない
        対応してもレアケースなので一部の
        ユーザーにしか恩恵がない