A 仕事術 - user000422/0 GitHub Wiki

優秀

■問題解決能力問題に対して複数の案を提案できる。

■技術探究心の強い人

・成果を出している

・学習意欲の高さ

・コミュニケーション力の高さ

・自発的・能動的に動く

・課題発見力チームの課題や業務プロセスの改善点を発見できる能力。

・勤務態度の良さ・ストレス耐性がある・清潔感

■工数見積指南 ・導入予定のライブラリは環境に適合しているか（バージョンによってインストール不可）・設計書、DBテーブル定義書は更新されているか、存在しているか・画面数で考える（ファンクションポイント法）・機能数・プログラム規模・環境・保守費用 … よくあるパターン開発費の15%

■基本設計 システムに実装する機能やデータを明確化する。操作画面のレイアウト。プログラミングのルールの策定。

■詳細設計 システムに必要な機能の内部仕様を定義する。入出力。APIとの連携。

企画構想 -> 基本設計 -> 詳細設計（入出力・EDP） -> プログラミング -> テスト 単体テスト … ソースではなく、設計書から仕様書を作成すること。ソースは見るな。

■自分用のWBSを作成する 自身のスケジュールを細分化して把握するメンバー全てのスケジュールもざっくり把握しておく

■DB環境 本番環境など重要なDB情報をGUIツール「A5M2」に登録しないこと（必ずCUIで行うこと）

メールでファイルの送付 ログインパスワードが必須のファイル共有サービスを使用 URLを教える。

プロジェクト用のテーブル定義書のみを集めたブックを作る開発リソース用シートを作成すると便利。パス、ファイル名、画面名、機能名などの

業務知識を叩き込むのは有用。お客様とスムーズなやり取り、信頼を得る。

■要件定義書や設計書などの例 https://pm-rasinban.com/rd-write

■HRTの原則 謙虚（Humility）、尊敬（Respect）、信頼（Trust）

■プロジェクト中のインシデント共有 プロジェクト中の問題ごとは後々工数請求や交渉の材料になるため貯めておくこと PMが確認できる場所に貯めるのも良い

■WBS プロジェクト・スコープ記述書を基にWBSを作成する（PMBOKガイド第6版）

■目的と手段 目的と手段を混同しないこと。目的の下にツリーで手段が付随する

■knowledge is power（知は力なり）

■PM理論 リーダシップは「目標達成能力」と「集団維持能力」という2つの柱で構成されているとする理論

■孤独力？ リーダーになると一人で決断しなければならない場面ばかりである。「同調、なれ合い、いつも誰かと一緒」このような人間は一人で考え決断する能力が恐ろしく低い。

■お土産 日本にはお土産外しという陰湿な文化があるため基本はお土産の用意をしないこと（仲の良い人向けとかも特にダメ）

■昇給が7月の理由社会保険料の計算が4，5，6月で行われるため。

断り方代替案を出す。交渉する。

■電話 もしもし [苗字]です。

交通の危険予測と、仕事のリスク管理は似ている。