RPG:いっくんのブログ

RPG:いっくんのブログ

以下の内容を配信していきます。
①SE業務内容、成長について
②週末ビジネス業務内容、成長について
③ノージャンル情報配信

Amebaでブログを始めよう!
今週の作業内容

■開発業務

・KO案件対応要件定義書修正

⇒作成完了、提出完了

・TC案件概算見積り修正

⇒作成完了、レビュー完了

・KO案件要件定義書読み合わせ

⇒完了

・新商品6対応リリース日調整

⇒完了(全システム同一リリース)

・新商品6月対応他チーム調整作業


■運用業務

・CG運用改善対応打ち合わせ

⇒完了

・CG運用改善IT仕様書作成

⇒完了

・CG運用改善IT実施

⇒完了

・CG運用改善ITエビデンスまとめ

⇒完了

・CG運用改善リリース用インストーラ作成およびテスト実施

⇒完了

・CG運用改善対応タスク管理

⇒完了

・WSシステムT機能打ち合わせ

⇒調査内容連携完了、資産修正が入る

・定例運用作業×2

⇒完了


■その他

・案件説明会

⇒完了

・指摘事項:停止している案件の進展の有無を確認する

⇒未完了


■予定外作業

・障害対応(3h)

⇒完了

・お客様問い合わせ用資料作成

⇒完了

・CG運用改善対応

 ・IT実施(他社員分)4h

 ・IT用データ準備3h

 ・IT実施用バッチ作成・動作確認・開発機仕込み(1.5h)

 ・ITエビデンスまとめ4h

 ・IT仕様書修正1h

 ・IT再実施1h

⇒完了



■振り返り

・CG改善対応について

⇒他社員の管理について怠ってしまった

⇒状況:自分の作業でも8h/日であった。他社員は、作業時間の見積もりが甘く正確な回答が返ってこない

⇒対策①:6h/日の作業しか与えないことで、作業を持たせすぎない。

⇒対策②:全体の案件の主導権をゆだねてもらう

⇒対策③:他作業も含めた1週間分の作業時間を見積もらせる

⇒対策④:定時連絡をしてもらう

⇒対策⑤:明確な作業手順書および、テストデータ(階層:テストNo\格納フォルダなど置くだけの状態にする)を作成する

⇒対策⑥:上記対策を講じてもプロジェクトが遅延する場合、上長に何時間の作業員が必要な旨を伝える


・見積もり作成について

⇒作成する概算、正式見積もりにおいて工数がx.5 or x.0であるべき

⇒関連機器のインターフェース、機能変更部分を加味した見積もり依頼をすること

⇒営業チームより見積もり依頼が来た際、即日に委託会社に見積もり依頼をかけること

⇒弊社発の要望については、概算の工数に盛り込まない

⇒概算と正式見積りで合計金額が概算より高くならなければ、各項目の工数で発生した端数を切り上げること



✪翌週の業務内容 20150525~20150529 稼働時間32時間

■開発業務

なし


■運用業務

・CG運用改善対応

⇒リリース資料作成(4h)

⇒仕様確認(1h)

⇒リリース作業(1時間)

⇒リリース後確認(2h×2日)

⇒新暗号化USB検証(2h)


・新商品対応4月対応の案件説明会準備(8h)

 ・WSシステム

 ・基幹システム

■その他

・タスク管理は続けること

・18日は日中リリースのため、終了処理の確認を行うためシフト体制かどうか確認すること



■特記事項

⇒5月度残業時間:44時間30分(確定)
⇒6月度残業時間:0時間




以上

今週の作業内容

■開発業務

・KO案件対応要件定義書作成

⇒作成完了、レビュー完了

・TC案件概算見積り作成

⇒作成完了、レビュー完了

・KO案件打ち合わせ

⇒完了

・新商品6対応リリース日調整

⇒未完了(Rシステムリリース日確定次第営業チームへ連携すること)



■運用業務

・CG運用改善対応打ち合わせ

⇒完了

・CG運用改善IT仕様書作成

⇒70%完了(パターン洗い出しおよび、テスト内容の概要記載完了)

・CG運用改善対応タスク管理

⇒完了

・WSシステムT機能打ち合わせ

⇒調査内容連携完了、資産修正が入る

・P資料受領ハンコ回り

⇒完了

・定例運用作業×2

⇒完了



■予定外作業

・新商品9対応正式見積り作成

⇒完了

・CG運用改善動作検証

⇒完了



■振り返り

・KO対応における要件定義書作成の取り組み方について

⇒わからない仕様に振り回され、無駄に時間がかかっていた

⇒作成のポイントは、わからないことを抜きにしてわかるところから埋める

⇒わからないところは、まとめておく

⇒わからないところに振り回されると、作成作業が中断される

⇒中断回数が多ければ多いほど無駄な時間になる


・P資料受領ハンコ周り

⇒現場の運用について調査してからハンコ受領に回る

⇒ググるだけでもだいぶ知識が入ってくる


・見積もり作成について

⇒同一本数の改修が二つ並んでいて金額が同一だと違和感に見えるので、按分させる

⇒SE工数:管理工数でレビューなどを指す

⇒PG工数:作業工数で成果物が伴う作業を指す

⇒各工程で何をどのくらいやるかを把握すること、あまりにも工数と実績が離れる場合上長に相談すること



✪翌週の業務内容 20150525~20150529 稼働時間40時間

■開発業務

・要件定義書読み合わせ打ち合わせ参加(3時間)

・KO対応の正式見積り作成(概算見積りから削るだけなので2時間程度)~提出まで

・新商品6対応のリリース日調整連絡(1時間)


■運用業務

・CG運用改善対応

⇒IT仕様書作成(2時間:コピペで作業時間を短縮すること)

⇒リリース確認書作成(2時間:前回のリリース資料の確認から精査すること)

⇒成果物レビュー(1時間)

⇒IT実施準備(2時間:テスト手順の作成および把握、テストデータ(大量データはなし)準備)

⇒IT実施(6時間:テスト準備)

⇒IT実施結果まとめ(50項目×3分で150分⇒2.5時間)

⇒UTリハーサル(4時間)

⇒対応方法が過不足ないかの確認(2時間資料を読み解き、開発メンバーに確認、上長報告)


■その他

・案件説明会(2時間)

・残業時間超過による予実作業報告(5日×0.5時間⇒2.5時間)

・CG案件のタスク管理(5日×0.5時間⇒2.5時間)


■特記事項

残業時間30時間超過しているため予定外作業は来週に回すこと


⇒予定作業時間:33.5時間




以上

■週末ビジネス 目標設定



ここに宣言します!



私は、以下の約束事を6月までに達成します。


①物販ビジネスにおいて、1000品の出品をすること


②評価値を50ポイントまで増やします。



上記の中間結果については、週報という形で報告します。



達成した暁には、きっと月収が増加するための土台ができているはず!

この気持ちを6月末まで継続させます!


達成できなかったら、読者の皆様厳しいお言葉をください笑



では、出品作業に粛々と入ります^^



■現在状況

出品数:0(目標未達)

評価数:2(目標未達)


 今週の作業内容


■開発業務

・打ち合わせ参加(要求概要の確認)事前準備(影響するアプリの挙動確認、影響箇所をまとめた資料作成)

⇒未着手
・リリース後の確認項目漏れによる作業

⇒完了、資料提出済み

■運用業務

・必要ファイル存在チェック運用引継ぎ

⇒完了、チームメンバーへの引継ぎ完了

・Bサーバリプレイスに伴う準備(テスト仕様書作成×2システム)

⇒完了、Wシステム、Mシステム

・Kシステムの仕様確認

⇒未着手

・Kシステムの資産返却

⇒一部資産の返却漏れがあり

・デッドロック改善対応(修正方針、工数算出依頼)

⇒完了

・チーム向け説明会準備(仕様確認、確認事項のまとめ)

⇒未着手


■予定外作業

・必要ファイル存在チェック調査

⇒着手中、他チームメンバーの協力が必要なため、来週の火曜日まで作業が止まる

・開発案件の他チーム調整作業

⇒完了

・7Wシステムのデータ編集作業

⇒完了

・プリンタ検証

⇒完了


■振り返り

・運用作業において、作業をこなすでなく、作業内容の意義を把握すること

 また、運用する上で課員等へ報告する数値については、変動をしっかり追うこと

 ブレ幅が大きいときは、システムに不具合が発生している可能性があるため


・案件説明会の聞き手としての所感

 運用するメンバーとして必要な情報は以下のように感じた。

  案件バックグラウンド

  データの流れ、データの各所での連携時間

  データの発生条件(今回でいうと帳票データ、川下でのデータ発生)

  システムの変更点

  アウトプットの仕様(現場から問い合わせで項目値の質問がある際に調査がスムーズになる)

  

  次点として、仕様が決まった経緯等も覚えておくとよい


・先週の反省より、上司からの依頼をこなす際に、

 自分で作成したアウトプットに不足している点を確認できた、

 依頼をもらった時点でアウトプットをより明確に聞いておけたことが反省点としてある


・資産返却作業は、自分が思っていた以上に短時間でこなせた。

 取り組んだことのない作業について、苦手意識が強い

 作業内容が見えないため、作業時間の見積もりができないためと思う

 作業をやったことがある人に手順を確認し、自分でより作業時間を短縮できるように工夫する


・上長への捺印が必要な際に、不安点があるため行動が遅くなることがある

 その際は、不安点を相談してみる(前提として、自分でやるべき調査はやった上で手詰まった場合)


・帳票を出力するテストについて

 ログで出力できないポイントがわかっていたにも関わらず、

 似たような項目のテーブルの値を修正したため予定していた時間に完了しなかった

 このことから、修正する項目についてしっかり確認すること

 テスト機での確認のため問題なかったが、大事な時にミスをする恐れがあるので癖付けること

 また、自分が知っていたシステムであったため、軽んじていた部分が強かった


・Mシステムのテスト仕様書作成については、完成度が高い仕上がりになった


・リリース確認項目については、事前にやることが明確にしていたため想定していた時間に完了した


・最近、メールの宛先を入力する際、

 この人はこういう理由で必要であるという意義を感じながら作業をしている傾向がある

 今後も意義を感じながら情報共有していきたい



✪翌週の業務内容 20150525~20150529 稼働時間40時間

■開発業務

・打ち合わせ参加

・打ち合わせ内容の共有:上司、協力会社、必要であればOチーム


■運用業務

・デッドロック改善対応:資料作成(影響範囲記載)、資料校正、上司への説明アポイント

・Bサーバリプレイスに伴うテスト仕様書作成(SJシステム、Kシステム)

・Kシステム資産返却(一部資産返却できていない資産)
・チーム説明会用準備(クライアント資産編)

・必要ファイル存在調査



以上

初ブログということで、簡単に自分の行っている業務を紹介します。

SE業界に興味ある学生さんには、何かしら参考になるかもしれません。



*****************************************************************************

■開発業務

4月リリース案件の追加案件

・打ち合わせ参加(要求概要の確認)

・要件の確認

・影響調査

・影響調査の精査

・見積もり作成

・要件定義書の作成

・連携部署への影響調査

・上司への説明

・開発委託業者の環境準備(パソコンの調達、席確保、入管申請、ソフトウェアの申請)

・開発資産(ソース)の貸出依頼

・詳細設計~結合試験のレビュー

・各フェーズでの上司への説明

・システム試験の事前打ち合わせ

・システム試験の準備(試験で使用する機器の設定、仕様書作成、人員のアサイン、テストデータの作成、可能であれば事前確認)

・システム試験の実施

・問題が発生したアプリの挙動の確認

・システム試験実施評価

・システム試験エビデンス整理

・システム試験実施完了報告

・ユーザー検証準備(試験で使用する機器の設定、仕様書作成、人員のアサイン、テストデータの作成、必ず事前確認)

・ユーザー検証実施

・フィールドテスト準備(テスト実施場所の確認、リリース手順書、リリース確認項目書、リリース資産の確認、インストーラ作成、インストーラテスト、その他資産の作成、リリース周知)

※フィールドテスト・・・一部のユーザーさんにリリースアプリを使用してもらう

・フィールドテスト実施(リリース作業実施、インストーラ反映確認、リリース確認項目の確認、リリース結果の報告)

・フィールドテスト評価

・本番リリース準備(テスト実施場所の確認、リリース手順書、リリース確認項目書、リリース資産の確認、インストーラ作成、インストーラテスト、その他資産の作成、リリース周知)

・本番リリース実施(リリース作業実施、インストーラ反映確認、リリース確認項目の確認、リリース結果の報告)

・問い合わせ確認

・貸出資産返却

・チーム内に案件内容の連携および運用引継ぎ



■運用業務

・現場使用機器のダウンロードチェック

・必要ファイル存在チェック

・定期マスタファイル配布作業

・容量不足端末のメンテナンス

・新機種端末での動作検証

・現場問い合わせ対応

・顧客問い合わせ対応

・KPI改善対応(A案対応、B案対応)


*****************************************************************************


✪今週の業務 20150511-20150515

■開発業務

なし


■運用作業

・必要ファイル存在チェック

・Aサーバリプレイスに伴う影響調査

・定期マスタファイル配布作業

・チーム向け説明会資料準備(システム使用確認、必要資料の選定、資料チェック)

・チーム向け説明会実施

・運用で使用するツールの調整

・Bサーバリプレイスに伴う準備(テスト仕様書作成)

・顧客問い合わせ対応



■反省点、学び

・必要ファイル存在チェックにおいて、報告する内容に上司が求める数値がもれていた。

⇒事前に報告する項目の確認をすること、求められている数値について考えるべきだった


・チーム向け説明において、精度が低かった。

⇒説明する内容は足りていたが、人によっては不要な情報があった

⇒最大公約数の話し方が求められていた

⇒細かい修正概要については、要件定義書を各自読ませることで解消できる

⇒これまで話し方の構成を考える機会が不足していることに気付いた

⇒進め方がスムーズでないため、説明会の記憶が欠落している箇所がある

⇒今後は、アジェンダの各項目に話すべきポイント、参照する資料を書き加える

⇒目標は、チーム内のメンバーに内容を確認し、重要なポイントを覚えていることとする




✪翌週の業務 20150518-20150522 稼働時間:32時間
■開発業務

・打ち合わせ参加(要求概要の確認)事前準備(影響するアプリの挙動確認、影響箇所をまとめた資料作成)
・リリース後の確認項目漏れによる作業


■運用業務

・必要ファイル存在チェック運用引継ぎ

・Bサーバリプレイスに伴う準備(テスト仕様書作成×2システム)

・Kシステムの仕様確認

・Kシステムの資産返却

・デッドロック改善対応(修正方針、工数算出依頼)

・チーム向け説明会準備(仕様確認、確認事項のまとめ)