忍者ブログ
カレンダー
02 2025/03 04
S M T W T F S
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
フリーエリア
最新コメント
[10/24 はる]
[09/10 はる]
[09/08 てづ]
[09/08 はる]
[08/18 てづ]
最新記事
最新トラックバック
プロフィール
HN:
KK
性別:
男性
職業:
学生
バーコード
ブログ内検索
カウンター
カウンター
アクセス解析
忍者ブログ | [PR]
一人前への準備~責任と実力~
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。



・なんとなくでデータ分析を始めても何も発見できないし、後から振り返っても何をしたかわからない。
→原因把握なら、なぜなぜ分析の活用。分析着手なら、全体像の把握と段取りの作成が必須。
→年を越して大事な事を忘れてしまってた。。。頭を使わないと生産性のある仕事はできない。今日はデータを触る前に原因箇所の検討と分析データの確認と既存分析の理解を先にやろう。
PR


今は試験の真っ只中です。
やっとゴールが見えてきました。
これも周りの人たちのおかげです。
不足している技術力を身につけ、自分の力で
問題を解決できるようになりたいです。


一か月でCからPTまで完了するという明らかに厳しい計画で頑張っている、2月。

アラームをあげるタイミングが遅くなった事や、試験を意識したコーディングができていなかった事、現物確認と定量的報告を欠いた進捗確認を行っていた事など、様々な原因が考えられる。

ここから学んだ事はたくさんある。

<学んだこと>
①リカバリ方法:
現実ベースのWBSを作成する
→あふれている日数を計算する
→遅れの原因を把握する
  対策:アラームをあげて、増員や休日出勤をお願いする

②後工程を考えた成果物の作成
ED:設計変更などの対応を容易にするために、メッセージ設計書は外部設計書とは別で作成する
C:試験しやすいコーディングが後工程の時短になる(メインメソッドのライン数が多いコードは失敗)
UT:
・環境構築のミスは解析が難しい問題の原因となるため、確認に時間がかけることが必要
・Junitとdjunitのメソッドを併用が可能(addReturnValueで例外発生、機能停止が可能)
 ※VMOのチェックをつける事を忘れない。
 ※ カバレッジレポートを残すことは本来の目的ではないため、djunitで必要以上にとめる事は間違い。
・単体試験は網羅性の確認をする試験であり、後工程に未確認の項目を回すことは失敗の典型例。

③進捗確認の精確性
・定量的報告と現物確認を徹底する組織体制が、問題の発見と的確なリカバリ方法の考案に結びつく。

④電話会議の有効活用
・通常時は、問題の報告、原因の発見、解決方法の提案ができる段階まで考えてから電話会議を行う。
・緊急時は、問題の報告を漏れなく行うための情報整理が完了してから、電話会議を行う。

⑤手戻りを防ぐ
・電話会議や一部での話し合いの結果は、文字化し証跡を残す。

⑥プロジェクトを進める
・試験可能な項目からの消化を徹底する→問題の早期発見につながり最低限の水準への到達時間が短くなる。

先週、環境構築と一部の機能の動作確認が完了したIT、が明日から本格的に開始されるが、今のところ項目消化は順調にいきそうである。問題が発生した場合の対処が自分の腕の見せ所である。まずは、これまでの開発で学んだ「定量的報告・現物確認による進捗確認」「試験可能な項目からの消化」「試験環境の確認の徹底」を確実に実行する。

28日にPTが完了し、チームで喜べるように、気を抜かずに作業していく。
ちなみに一番大事な事と実感した事は、体調管理を徹底する事です。



札幌出張でした。反省会しました。



以下大事なこと。

・まず、反省すべきかどうかから考える。

・反省する場合は、一番ボトルネックになっている事の原因を深く掘り下げていく。

・小手先の解決策を考えるのではなく、今後の仕事でも活きてくる普遍的な考え方を学ぶべき。そこまで掘り下げる。

・ポストイットを使う。
・原因を分析する際は、定量的なデータに基づいて行う。



【学んだこと】

・不明点がなくなるまで調査をする。

→既存のシステムを理解してない状態で成果物を作成した結果、次工程で手戻りが起きてしまい、遅延してしまった。

・ごり押しする

→依頼した作業が進んでいない場合は、メールではなく電話して、つっつく。




チームで仕事するってやっぱり難しいですよね。しかも、メンバーとは電話でしかやりとりすることができない。

今日、外部設計書のコメントが返ってきたのですが、悔しくも散々な結果でした。。。自分が作成したとこもあれば、他のメンバーが作成したしたとこもある。あと、安易に置換をしてしまい文章がぐちゃぐちゃになっている事を指摘され、ほんと自分ダメだなって反省しました。

今回の失敗原因は山ほどあると思いますが、まず挙げるべきことは、チーム内でレビューの視点、考え方がずれていたことでしょうか。主に外部設計書を作成した自分としては、とりあえず全部作るから、他のメンバーしっかりレビューしてくれって気持ちでした。他のメンバーの気持ちとしては、たぶん自分達は他のタスクがあるから誤字、脱字程度のチェックで十分だろうって思ってたんだと思います。しっかりはじめに自分が内容重視の視点でレビューお願いしますって伝えるべきでした。反省します。ここで学んだことは、
・はじめに視点レベルでレビューの認識をあわせる。
・各自別の視点でレビューを担当し、責任をもつ。
・レビュー件数のノルマを定量的に決める。
・他人の成果物の内容は信頼しない。必ず内容をチェックする。既存資料も同様。

とりあえず反省を一つ。


タイトルのとおり、3ヶ月前から勉強していた
「基本情報技術者試験」に合格しました。

入社2年目の終わりまでに合格する事が、
新入社員のノルマに入っているので、
早めに合格できて、ほんと良かったです。

久々に受験番号を確認して合格がわかる試験に合格できた
ので、ほんとうれしかったです。何ども合格結果をネットで
確認しちゃいました。

<後で見返すための記録>
 H22 秋 基本情報技術者試験 合格
  午前 83.5./100
  午後 63.75/100
 ※午前・午後ともに60%以上が合格基準。


次は、応用情報を狙います。




Powered by 忍者ブログ  Design by まめの
Copyright c [ シーワルトの字引 ] All Rights Reserved.
http://mailworld.blog.shinobi.jp/