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

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

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

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

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

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

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

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