経営メモ > 開発マネジメント
ITエンジニアが不足してるっていうより、ある程度大きなプロジェクトで全体をちゃんと把握して仕切れるマネジャーがいない
7payの失敗もこれだと思う。

経営メモ > 開発マネジメント
営業なら、質☓量☓責任の掛け算。
開発も、スキル☓スピード☓正確さ(責任)の掛け算。
「原価を安くして、利益率を上げる」ということが開発にとってどういうことか?
に対する答えをもって、それを実践している開発と、何も考えていない開発では、
同じ開発でも全く違う。
経営メモ > 開発マネジメント
昔は1日かければ1日相当のものが、5日かければ5日相当のものが作れたのですが、もはやそんな時間と仕事の関係はすでに崩壊しています。短時間でものすごい実装ができてしまいます。もちろん高いスキルがなければそんな結果は手に入りません。
経営メモ > 開発マネジメント
サービス開発をしている場合は、他社との競争になる
他社より先行するか、品質がずば抜けているか?など競争優位が必要になる
それを担う開発組織は、市場のスピードやクオリティーにあわせて体制を作ることが必要
マイウェイ的な組織は向いていない

経営メモ > 開発マネジメント
管理は守り、経営は攻め。
守りと攻めは同じ人が出来ない。
開発の組織も全く同じ。
経営メモ > 開発マネジメント
「出来ない」と言う人と「どうしたらできるか」を考える人が居る。
どうしたらできる派は、チャンジャー。
当然ながら、リスクがあるし、失敗もある。
その失敗を許容できなければ、企業成長はない。
結構な意思決定が必要。
やろうとしていることが、どれだけビジネスインパクトがあるかで判断して、意思決定するのがベスト。

経営メモ > 開発マネジメント
プログラマーに求められるスキルは、抽象的なものを抽象的なままで扱う能力。
経営メモ > 開発マネジメント
ガートナーは企業の情報システムを、業務システムとしてビジネスを支える「記録レイヤ」と、他社との差別化を実現する「差別化レイヤ」、そして新しいアイデアを実装する「革新レイヤ」の3つに分類しています。
開発の人材も3分類に合わせてPG、SE、PMを用意する必要がある。
経営メモ > 開発マネジメント
技術選択をするときに、その技術が人気があり、未習得の場合は、スキル向上力が高い技術者ほど採用したがる。
しかし、その技術が自社のビジネスにおいて有益か、また利益貢献するかは別問題であり、
仮に、その技術をすでに習得している技術者は、技術そのものの有益性を判断して採用しないという判断をすることがある。
経営メモ > 開発マネジメント
専門家ではない多くの人々がソフトウェアを使うようになると、最初から何を作るのか完全に決めてから開発をすることは不可能。それに対応できる仕組みと人材が必要になる。
経営メモ > 開発マネジメント
IT活用は「業務の効率化やコスト削減」のウォーターフォール型から、「ビジネスを創出し、新しい仕事や価値を次々に生み出していくこと」を目的にしたアジャイル型に。それに対応できるIT人材が足りない。担い手もSlerから自社開発に。
 #IT人材
経営メモ > 開発マネジメント
SIの世界では責任の所在が時折曖昧になり、その文化からウォーターフォール開発が根強い。
ウォーターフォールは、SIer文化が生み出したもの。
スパイラルやアジャイルも同じ。前提にカルチャーがある。
経営メモ > 開発マネジメント
開発者は2つのタイプがいる。
既存に従う開発者と既存にしたがわない開発者。
既存に従っている限り、自らリスクを負う必要はない。
負の資産は、既存に従う開発者によるもの。
 #負の資産
経営メモ > 開発マネジメント
アジャイルが機能する条件は、メンバーの構成。エンジニアが少ないチーム構成に最適。ITに誰もが関わる時代になっとので時代の流れ。
経営メモ > 開発マネジメント
時間タスク型の管理(日々やることを決める)
経営メモ > 開発マネジメント
開発に求められるスキルは、大きなタスクをブレークダウンして、小さなタスクに分割する能力

経営メモ > 開発マネジメント
開発スパンが長く、人の入れ替えが起こるレベルだと、開発体制から考える必要がある。

経営メモ > 開発マネジメント
リーダの仕事は、管理じゃない。
納期に遅れないようにすることだし、品質を担保すること。
経営メモ > 開発マネジメント
開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なる(速度と品質はトレードオフ)
品質にも分野があって、設計、疎結合、独立性、レスポンスなど、優先順位を決めるが必要

経営メモ > 開発マネジメント
不確実性がある状態でプロジェクトを進めていくと、人は確実なものから対処しがちです。
その結果、不確実性を心に秘めたまま日々を過ごすことになる。
経営メモ > 開発マネジメント
エンジニアは、こだわりが強く、これが絶対にベストだと思うと、まったく譲らない人が多い。

経営メモ > 開発マネジメント
人はコントロール不能、組織や構造はコントロール可能。
経営メモ > 開発マネジメント
課題解決するたびに、次の課題が見つかる。なので課題はなくならない。
トリアージで対応する(負傷者を重症度、緊急度などによって分類し、治療や搬送の優先順位を決めること)

経営メモ > 開発マネジメント
開発マネジメントはコストと品質のマネジメントに尽きる。
コストは見えやすいが、品質が見えずらい。
品質を語れない人に開発マネジメントをやらせてはいけない。
経営メモ > 開発マネジメント
〆切直前にならないとタスクに着手しない
経営メモ > 開発マネジメント
「何をやるか」が決まっていないのに、なぜか納期だけ決まっている
これに文句を言う開発がいるが、現実的にはよく起こること
納期から逆算して、何をすべきかをタスク化してやるしかない。
経営メモ > 開発マネジメント
マイクロマネジメント(業務のあらゆる手順を監督し、意志決定の一切を部下に任せない)
経営メモ > 開発マネジメント
重要なのは、目標に対して達成しているかどうか?
頑張っているとかは、本来はどうでもいい。
また、適正な目標設定できるかどうかはマネージャーの仕事。
また、達成度が図れるような目標設定が必要。
経営メモ > 開発マネジメント
正しい問題さえ設定できれば、あとは皆が解決してくれる(これがマネジメントの仕事)
経営メモ > 開発マネジメント
マネージャーの指示に従わない部下への対応。論破するなら、手法と技術スキルが求めれれる。
経営メモ > 開発マネジメント
住宅なのか、高層ビルなのかをまず判断する
高層ビルなら、一級建築士が必要
プロジェクトマネジメントは不確実性をいかに解消するかだけ、小さく分ける方法がリスクが減る