Please enable JavaScript.
Coggle requires JavaScript to display documents.
ＭＹ振り返り (Try (誰が何をしっているのかをまとめる (プロジェクト内で、情報共有する方法を決めておく (社内用のプロジェクト要綱を作ってもら…
ＭＹ振り返り
Try
プロジェクトに参画するメンバーを
ある程度固定化する
新しい案件に、もともといた人が取られないように
プロジェクトに対して、誰が何に責任を持つのか、みんなで話しあう。
プロジェクト開始時に情報共有の方法を確立し、チーム内に展開する
案件内だけでなく、出来るものは会社全体に情報共有をする。
見積もり手法を確立する必要あり
開発標準
プロジェクト開始時にプロジェクトの説明をしてもらう。
プロジェクト開始時に体制の明確化をする(してもらう。)
メンバー内で負荷分散ができるようにする
プロジェクト序盤はチーム内で話し合う場を多く設け、会話ができる空気を作る
プロジェクト内に最低1人は有識者がほしい
誰が何をしっているのかをまとめる
プロジェクト内で、情報共有する方法を決めておく
社内用のプロジェクト要綱を作ってもらう
便利なツールがあれば利用する
誰に何を聞けばよいか、
知っている人を作る
余裕があれば、リーダー以外に作る
誰が何を知っているか、自分から知る
Keep
個
体調管理
稼動が高いが、体調不良者は
少なかった？
薬を常備するようになった
うつになる人がいなかった
Java、Webの勉強ができた
社内プロジェクトだからこそ
できたこと
開発～単体テストまでの
流れを経験できた
嫌でもできるようになった
やらないと身の危険を
感じる状況も助けた
手伝っている余裕がないのも
実力がついた要因
責任感を持って臨んだ
課題の解決策を個人で出せた
若手でも責任感を持って
仕事に臨んでいた
特になにもしないのに、
責任感があった
若手が優秀だった
初期段階は、自分の作業だけ
７月頃、チーム体制を
作ってから変わった
危機感があったから
危機感しかなかった
作業効率について色々
考える機会が多かった
やみくもに頑張る人が多かった
理由を聞いて、無駄を省いた
本当に必要な残業なのか
チーム内で使えそうなツールを作れた
(VBAの勉強もできた)
工数の削減に貢献できた
テスト結果の集計が楽だった
下級者が自らVBAマクロを
作成しはじめた
技術面で他メンバーの
先導となることができた
最初のころ、知らないことが多かったが、
任されたので、勉強した
新しい技術を学べた
人に伝えられるくらいに、
掘り下げられるようになった
自信がついた
技術リーダーとしての自信
リーダーの期待にこたえ続けた
リーダーが期待することが
よい結果になった
やってほしい事が明確に
伝えられていた
下級者を下につけて作業ができた
自分の作業だけでなく
周りを見れるようになった
責任感が生まれた
気持ちが引き締まる
自分の成果物の精度があがる
下級者からの指摘がもらえる
下級者と打ち解けた
チームのモチベーション維持が出来た(PH3から)
プロジェクトメンバーと
対話することを心がけた
メンバーの考えや
負荷を把握することができた
勝手に雰囲気がよくなった
しゃべるメンバーが
参画した
６月を乗り切ったことが
よくなった原因？
区切りがあったことがよかった
チーム
プロジェクトが終われたこと
後半はチームとして回る環境づくりが出来たこと
体制つくり等
色んな試みが行えたこと
ツールの導入
寺島ツール
Outlookのタスク
会社に広めたい
OneNoteでTips
TODOリスト
朝会、夕会の実施
良い雰囲気
メンバーに恵まれた
設計、開発、単体テストの流れが経験できた
情報共有がよくできていた
積極的に情報発信する
メンバーがいた
会社
若手メンバーの育成ができた
若手を育てる、中堅層が
育った
要員確保ができた
優秀なBPを入れることができた
会社の持ち帰り案件
の実績を作れた
Problem
個人
会社としての作業の
やり方が分からなかった
レビューがあるのかないのか
体制はどうなっているのか
誰に相談すればよいのか
見積もりについて説明会を
開いてもらうべきであった
何を作るのかの説明がなかった
最後まで、何が正しい見積もりなのか
微妙なところがあった
雨宮さんが、全体の説明をした
自分の作業に集中して、
ほかのチームが見えていなかった
自分で解決済みの問題点にぶち当たっている人に気づけなかった
初期段階では、朝会などで共有していなかった
外部設計/環境(DDL)が間違っていることが多く、また現行を見るしかない等、前提条件が満たせていないことはもっと追求すべきであった
追求してよいことがなにか曖昧であった
初期段階で追求できなかった
そういうものだと思っていた
雨宮さんに頼りすぎた
そもそも、それが間違っていた
雨宮さんの立ち位置が曖昧であった
でも、頼らないと進まない
設計と実際に作成したい
内容の齟齬が多かった
設計したのがグリフィンのメンバー
東陽町で修正すると、雨宮さんに負荷がかかる
現行ツールの調査が甘かった
外部設計書を信じすぎて、現行差分が出ているのに気づかない等があった
調査は、内部設計と製造をしつつ実施していた
調査工数は取れていない
引継ぎがされていない
序盤に一人で抱えすぎた
全員始めましてで、メンバーのスキルがわからなかった
とりあえず頑張るしかなかった
チームで作業を開始する際に
ルールを決めておくべきだった
変数名やメソッド名の命名等、統一が取れてなくて
余計な修正をすることがあった
見積もりの妥当性の判断ができなかった
最終的な金額がICSの提示した金額になった
SESでやるべき案件であった
教育のために持ち帰った
チーム
序盤に情報共有が出来ていなかった
手戻りが多くなった
同じ問題で悩む人が多くなる
体制が不明確だった
雨宮さんのポジションが不明
小滝さんがどこまでやればよいかわからない状態
誰をキーマンにするべきかわからない
どこに相談すればよいかわからない
序盤はチームへの提案が皆無だった
リーダーの意見に何も意見が出ない
教育プロジェクトと言われていたが、
教育する人がいなかった
結局、雨宮さんに頼った
勝手に育ってもらうポリシー
勉強しようとする気持ちも足りなかった