Please enable JavaScript.
Coggle requires JavaScript to display documents.
振り返り 2019/4～2020/3 (:star:読み手・聞き手のことを考える ドキュメント、プログラム、etc 全て一緒…
振り返り
2019/4～2020/3
:star:
読み手・聞き手のことを考える
ドキュメント、プログラム、etc
全て一緒
変数の用途は1つだけ
用途が分かるように変数名をつける
自分が書いたものを見直す癖をつける
レビューありきでやらない
プログラム中に直値を使わない
変更にも強くなる
相手の前提知識によって
説明内容な表現方法を使い分ける
名前やコメントだけでなく、
構造的に見やすいプログラムを書く
(構造的な可読性)
変数名やコメントはあくまで補助
アルゴリズムがシンプルなものは
コメントがなくても読みやすい
入力⇒処理⇒出力の流れを意識する
ここがうまくできないのはそもそもの設計が悪い
例)任せる役割をもう少し分担する
プログラムは常に何かしらの「データ」を
受け取り、加工し、出力する
「なんとなく」でやらない
仕事には必ず目的がある
意図をもってプログラムを書く
モブワークではなぜそう書くのか
説明できないとすすまない
違うやり方で同じことができないか考えて
よい方を選択する
コメントには処理内容ではなく
なぜその処理をするのか意図を書く
無駄な一点判定は避ける
その「一点」に意味がないなら範囲判定にする
成果物を変更するときは全体を
理解してから手を加える
変更がどこまで影響するのか把握する
自分のやりたいことを
はっきりさせてからとりかかる
例)フローチャート、アイテムPFD、箇条書等
定期的にゴール・目標とあっているか確認する
:star:
完了条件(最終的にどんな状態に
なっているべきなのか)をはっきりさせる
例)「解消」か「改善」か
便利なツールをただ使うのではなく
ツールがどんな処理をやってくれているのか知る
テストやデバッグでは「どんな不具合を検出したいのか」
「このテスト・デバッグによって何を保証したいのか」
をはっきりさせる
発表
スライドの前後がつながるようにする。
話が変わる場合はタイトルを挿入するなど、
明確に伝わるようにする。
周りの人の資料を見てみる
時間をおいて資料を見返す
会話のつもりで発表する
覚えるのは「話す内容」ではなく
「スライドに書いてあること」
発表中の時間経過・話の優先度によって
話す内容を変える
問題はより根本的な解決に
つながるようにとらえる
(見える・探す・創る問題)
「何を」よくするための目標・アクション
なのか考える
本質的な解決になっていないなら
「改善」ではなくただの対処「対処」になってしまう
問題⇒改善だけでなく
できていること⇒改良することも必要
「とりあえずやってみる」
「じっくり考える」
両方大切
プログラムを動かす前に意図通り
動きそうか静的にプログラムを追いかける
:star:
いきなり問題の原因を特定しようとしない
まず原因の大体の切り分けをする
例)ソフトorハード？入力or作業方針or自分の作業ミス？
確実に正しい、と言えることを積み上げて
原因箇所を絞っていく
できていること・できていないこと・わからないことを整理する
:star:
学びを得たときに、それを取り入れるための
具体的なアクションまで考える
精神論だと目に見えないから
評価できなくなる
実行したアクションがよかったか振り返る
相手に何を伝えたいのか意識する
ドキュメントでも会話でも「どのレベルまで相手に伝えたいか」を明確にする。
やったことだけでは相手は妥当性が判断できない
「なぜ」こうすればいいと思ったのかを説明する
:star:
「これをやったからこうなった」ではなく
「こうするためにこれをやった」
作戦を立てる上での前提条件も説明する
アウトラインを考えてから詳細を考える
課題やリスクがないか事前に
全体を見通して把握する
成果物を修正するときは修正前のものを残しておく
何を・なぜ変えたのかも残せると
後から見返しやすくなる
「作業」≠「仕事」
「どう進めればいいか考える」ことと
「実際に手を動かす」ことは同時にやらない
プログラムはイレギュラーなときに
どう動かすかが重要
大きな成果ではなく
小さな当たり前を積み重ねる
自分の意識次第でどんなことからも学べる
「楽」することを考える
部下(後輩)力
先輩といい関係を築く
先輩のいい部分を引き出す
進捗は「成果物」と「日程」2つの面から決まる