マネジメント
作成日時:2024-08-01以前
更新日時:2024-08-01
指摘をする時
- 個ではなく体制を
- 自分の事は棚に上げる
- SBIモデル
提案を出すマインド
- 不知の自覚
- 「何故」のマインド
- 探求心
- 自分の事を棚に上げる
- どう思われてもいいや
トヨタ生産方式
- リーン
- 誰が来てもうまく運ぶ体制づくり
- 無駄のない基盤
人を介すと情報はロスト/変質する
- 変質しないなら伝言ゲームは成り立たない。
- 認知負荷を下げろ
- 曖昧な伝達をするな
- ドキュメントを書け
- ロストしないから
- リファクタリングもできる
- 会話中に別の話を始める
- だいたい元の話に戻ってこれないので、今の話を終わらせてから話す。
- あやふやな表現
- 1つの文章で複数の受け取り方ができるような表現はNG。
- 答えの出ない質問
- ゴールのない質問
- そもそも聞く相手が間違っている質問
- 主題が無い質問
- 話の主題がコロコロ変わる
- 具体性に欠ける質問
- 文章を全部読まないと主題が分からない上に冗長な質問
- 文章に主語 / 目的語がない。
レビュー
後述のようにレビューは学習の場でもあるという面もあるので、
経験の浅い技術者を訓練のために参加させるのは望ましいこと。
能動的開発
❷ 受動的作業から能動的開発へ
人は誰でも受動的な仕事よりは、
自分から積極的に関わろうとする能動的な仕事の時のほうがモラルが向上するのは当然。
システムインテグレーターの仕事は顧客の注文に応じて仕事を請け負うことになるため受動的作業が多くなる。
しかしながら、だからといってすべて受け身の作業ということではない。受注活動時は当然のこと、
受注後も、顧客に積極的に関わりながら、具体的な提案や議論を積み重ねて、プロジェクトをまとめてゆくのは能動的作業であり、
創造的仕事でもある。しかし担当者、特にユーザープログラム開発担当者の中には、
顧客あるいはSEから言われたとおりにものを作らされていると感じる担当者もいるのも確かである。
こうなると受動的作業になってしまい、モラルを維持することは困難になる。
ユーザープログラム開発担当の人たちも、積極的に仕様決定プロセスに参加し、
設計方式についても積極的に提案を行い、顧客とも直接議論する機会を増やすべきである。
ユーザープログラム開発で培ったノウハウは、必ずやそこで活かされるはずである。
名内泰藏 著, 曖昧性とのたたかい ~体験的プロジェクトマネジメント論~, 翔泳社, 2005
その他
- 学習性無気力
- KPT
- ToBe(理想)-AsIs(現実)
- 「他人は変えられないが自分と体制は変えられる」とコヴィーもカーネギーも言っとる
- 他人を変えるより自分を変えた方が早い
- 他人に期待すんな