Please enable JavaScript.
Coggle requires JavaScript to display documents.
振り返り 2020年度 - Coggle Diagram
振り返り
2020年度
考え方
問題はより根本的な解決に
つながるようにとらえる
(見える・探す・創る問題)
「何を」よくするための目標・アクション
なのか考える
本質的な解決になっていないなら
「改善」ではなくただの対処「対処」になってしまう
問題⇒改善だけでなく
できていること⇒改良することも必要
大きな成果ではなく小さな当たり前を
積み重ねることで信頼を築ける
仕事は「やらなければならないこと」ではなく
自身が成長するための「手段」
「楽する」ために頑張る
「作業」≠「仕事」
「どう進めればいいか考える」ことと
「実際に手を動かす」ことは同時にやらない
自分の意識次第でどんなことからも学べる
部下(後輩)力
先輩といい関係を築いて、先輩のいい部分を引き出す
:star:抽象的なものほど明確にする(文書化等)
具体的なもの(設計・コード)は言葉にしやすい
抽象的なもの(仕様、達成基準等)こそ言葉にしないと伝わらない
管理
進捗は「成果量」と「日程」2つの面から決まる
:star:上司が知りたいことは
・一日 or 全体の計画に対して順調に進んでいるのか
＝「今順調か」
・未解決の課題やリスク(詰まりそうなポイント)はないのか
＝「この先も順調か」
説明することで自分で自分の状態を理解できる
:star:計画のマイルストーンは「完了するタスク」
だけではなく「状態」も設定する
状態を設定することで、その状態になるために何をすればよいのか見えやすくなる
コミュニケーション
読み手・聞き手のことを考える
ドキュメント、プログラム、etc
全て一緒
自分が書いたものを見直す癖をつける
レビューありきでやらない
相手の前提知識によって
説明内容な表現方法を使い分ける
相手に何を伝えたいのか意識する
自分のやったことだけではなく「なぜこれでいいのか」
という妥当性を説明する
「〇〇をやって△△になった」ではなく
「△△になるために◇◇が必要なので〇〇をやった」
作戦を立てる上での前提条件も説明する
ドキュメントでも会話でも「どのレベルまで相手に伝えたいか」を明確にする
発表
発表中の時間経過・話の優先度によって
話す内容を変える
スライドの前後がつながるようにする。
話が変わる場合はタイトルを挿入するなど、
明確に伝わるようにする。
周りの人の資料を見てみる
時間をおいて資料を見返す
会話のつもりで発表する
覚えるのは「話す内容」ではなく
「スライドに書いてあること」
:star:相手に話が伝わるような構成(アジェンダ)を考える :
発表や説明の目的・概要を伝えてから詳細を伝える
技術
プログラミング
変数の用途は1つにする(使い回さない)
用途が分かるような変数名にする
プログラム中に直値を使わない
⇒変更に強くなる
名前やコメントだけでなく、
構造的に見やすいプログラムを書く
(構造的な可読性)
入力⇒処理⇒出力の流れを意識する
プログラムは常に何かしらの「データ」を
受け取り、加工し、出力する
意図をもってプログラムを書く
違うやり方で同じことができないか考えて
よい方を選択する
無駄な一点判定は避ける
その「一点」に意味がないなら範囲判定にする
モブワークではなぜそう書くのか
説明できないとすすまない
コメントには処理内容ではなく
なぜその処理をするのか意図を書く
:star:コメントは次にそのコードを変更する人に
コードの意図(設計情報)を伝えるために書く
:star:意味的に同義なクローンコードは諸悪の根源になる
実装中のコピペは要注意
ある仕様とその実現箇所は1:1であることが理想
品質保証
テストやデバッグでは「どんな不具合を検出したいのか」
「このテスト・デバッグによって何を保証したいのか」
をはっきりさせる
:star:テストだけで品質保証しない
セルフチェック・レビュー・テストそれぞれで
検出しやすい・しにくい不具合がある
:star:レビュー前に減らすのは「凡ミス」ではなく
「自分が当たり前にできる技術領域」でのミス
「自分が当たり前にできない技術領域」についてレビューすることで、
レビューの場が自身のスキルアップにもつながる
仕事の進め方
「なんとなく」でやらない
必ず目的を理解する
成果物を変更するときは全体を
理解してから手を加える
:star:自身の成果が誰の入力になるのか、
誰かが参照しているのか確認する
自分のやりたいことを
はっきりさせてからとりかかる
例)フローチャート、アイテムPFD、箇条書等
完了条件(最終的にどんな状態に
なっているべきなのか)をはっきりさせる
例)「解消」か「改善」か
:star:仕事の元となる要求に対して
①何を作ればよいか
②①を作るために何をすればよいか
③できたことをどうやって検証するか
を明確にする
定期的にゴール・目標とあっているか確認する
アウトラインを考えてから詳細を考える
課題やリスクがないか事前に
全体を見通して把握する
:star:各論ばかりフォーカスすると
全体の目的が見えなくなる
:star:チームで進めるときは言葉ではなく
見えるもので目的を共有する
:star:仕事の「結果」だけでなく「過程」も成果として残す
成果物を修正するときは修正前のものを残しておく
何を・なぜ変えたのかも残せると
後から見返しやすくなる
過程=その成果を作った背景・根拠が整理されるので
人に説明しやすくなる
「残そう」とすることで自分の考えたことや結果を
整理する＝自分自身の理解が深まることにつながる
その他
便利なツールをただ使うのではなく
ツールがどんな処理をやってくれているのか知る