バッファマネジメント

バッファのとり方については、CCPMの考え方が好み。プロジェクトにおいて大幅なバッファがあると、もったいない、その期間でもっと他の事ができるのではないかと思ってしまう。結果リリース間際でドタバタし、余計なコストが嵩む。そっちの方がもったいな…

レッテル貼り（いい意味で）

人にレッテルを貼って、コントロールする方法がある。悪く使う事も出来るが、良い使い方を検討したい。ストレングスファインダーの使い方としてチームに導入してみた事がある。プロジェクト内のメンバーの資質を元に、プロジェクト内の意思決定の一部を移…

身を守るために、危険に近づかないと言う選択と、危険に近づくことで学習し危険回避能力を高める選択とがある。グラップラー刃牙の渋川先生も、前者の通り本当の護身術とは危険に近づかない事だと仰っている。しかし、それは後者を多く経験することで学習…

結論としてはプロジェクト特性によって選択すれば良いと思う。限られた条件の元、目的をどのように完遂するかを考える事がより重要である。日本のシステム開発だとウォーターフォールの方がより上手く行きやすいケースが多いと感じる。その中でアジャイル…

エンジニアのチームメンバーには、よく遅刻をする人がいる。裁量労働制で、みなし残業な会社で遅刻をするなと怒られる。そんなに迷惑掛けていないはずなのに、なぜ遅刻をしてはいけないか、メンバーを観察し考えた。本人は遅刻したくないと思っているが、…

受託開発のプロジェクトの発注側担当者がプロジェクトにおいて、何を目的としているかを知っておく事は重要。大体の場合プロジェクトは会社のために行うが、担当者は上司や自分の評価を気にしている事が多い。担当者が怒るとき、何に対して怒っているかで…

自分のマネジメントスタイルを知ることは、マネジメントしていく上で重要かもしれない。他の人がうまくやれるやり方と自分がうまくやれるやり方は違う。違いを知るのにストレングスファインダーは役に立つ。自分は戦略、運命、適応、アレンジが上位にある…

とある先輩が「コミュニケーションとは暴力だ」と言っていた。最初は受け入れ難かったが、意識的、無意識的問わず相手を思い通りにコントロールする行動と言う意味で正しいような気がしている。

開発者もビジネスを理解することで、開発のどの部分に力を注ぎ、どこを簡略化できるか判断しやすくなるため、理解できたほうが良いと考えていたが、とある先輩に、「エンジニアがビジネスを理解したらエンジニアでは居られなくなるよ」と言われ、なるほど…

チームを作るとき、チームへの所属意識を高めるために、安全な場を作れるようにする。ハーズバーグの二要因理論の衛生要因やマズローのより原始的欲求が満たされているかを確認し改善する。具体的には、会議の場での公平な発言権や個人攻撃をしないように…

相手や状況に合わせて物事を抽象化、詳細化して認識したり説明できる能力が役に立つ。システム開発では、詳細な話では非エンジニアは結論が出しにくいため、抽象化しプロジェクトのゴールに照らし合わせる事で、意思決定をしやすくする。

お金儲けと社会に還元する方法を、寄付やNPO支援などを通じて考えてみた。たくさん稼いで税金を支払う、たくさん稼いで興味の強い社会課題に投資する、社会に還元されやすいビジネスモデルを構築する（下記の書籍はコレ）、 NPOに寄付をする、 NPOのプロ…

基本的なテンプレートがあるので、それを埋めてみる。形は多少違えど色々な書籍などで言われてるらしい。背景、現状、ゴール、課題（現状とゴールのギャップ）、解決策、実行計画これらをシンプルにまとめる事で、プロジェクトの骨子が出来上がる。

プロジェクト終盤に高稼働になると、焦って無駄なタスクが増えていく様に思う。敢えてプロジェクト中盤に期間限定のデスマーチを創出し終盤までに沈静化を狙う。 SIで多く見られる誠意ドリブン開発にも有効。

ITのプロジェクトに参加するとき、納期、コスト、品質のどれを優先するかを決裁者に確認しておく。どれも捨てられない場合、ウォーターフォール式ディフェンスでチームを守ったほうが良さそう。

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解ゆとりの法則ゆとり世代ちょい前の自分としては、ゆとり世代と一緒に仕事をする機会が多くなる。ゆとりをうまく活用する方法を学ぶ必要があるのではないかと、読んでみた。