運営管理
運営とは会社のオペレーション。いわば会社の取扱説明書の考え方。
工場のオペレーション
工場ではQCDが大事だが、Deliveryが最も重要。これが1次管理。
「工場の３部門それぞれでQCD」
| 部門 | QCD |
|---|---|
| 設計部門 | 全ての製品をプラスティックにすれば原価さがる。品質も良いだろう。納期は・・ |
| 調達部門 | 原価の低い、品質の良いプラスティックをどこから調達しよう。納期短く。 |
| 生産現場部門 | 全てプラスティックなら、似たような作業の連続で品質が上げられる。 |
【作業管理】
工場の生産性は、従業員が移動に時間を掛けていると生産性が落ちる。万歩計をつけて、どれだけの時間を歩くことに費やしているか確認すべし。長時間を移動に費やしているなら、これは減らすべき。これは、作業管理である。
【ものつくりの道具３M】
- 人（Man）
- 材料（Material）
- 機械（Machine）
生産管理の用語は、JISで定義されている。
店舗のオペレーション
店舗は客数と客単価が大事。
どこに店を出して、どうやって客を呼び込むか。
店に入った客にどうやって商品を見せるか。
当たり前のことを当たり前にやる。というのが運営管理。
顧客がレジに来た時の購入商品と、顧客の情報、家族構成などと、商品棚の構成などの分析を行う。これによって、店内の棚配置や商品構成の変更を行う事が出来る。これがPOSシステムを使った売り上げ分析である。
財務・会計って？
大きく二つの分野がある。会計（アカウンティング）と財務（ファイナンス）である。
会計
会計とは、過去の財務データを使って、経営のチェックを行うことである。
会社とは、営利社団法人（儲けることを目的（営利）とした人の集まり（社団）で、死なない1個の人格（法人））である。
いわば一生死なない人である。人間ならば、死ぬときにどういう人生だったかという振り返りをするが、会社は死なないので、定期的にチェックする必要がある。これが1年毎に訪れる決算である。
会社にとって大事なことは、以下の2点。
- 儲けること
- 死なないこと（信用維持：つぶれないこと）
そこで、儲かっているか、死なないかのチェックを1年毎の決算でやるのである。
財務分析とは、経営の健康診断である。（儲かってる？つぶれない？）
財務管理とは、健康診断後の治療である。（マネジメントせよ）
財務管理では以下のことに注意しなければならない。
【勘定あって銭足らず（黒字倒産）】
利益は出てるが、手元に現金が無ければ倒産してしまう。
財務
企業価値を正しく測定する為に、DCF（Discounted Cash Flow ）法を理解しよう。
投資リスクも考えよう。
これで、企業価値が出せる。らしい。
コミュニケーション管理：バベルの塔崩壊の理由
人月の神話と言えば、バベルの塔の表紙絵であるが、そもそもバベルの塔が何故崩壊したかはあまりよく知らない。
バベルの塔崩壊の理由
うーん。なんだっけ？
バベルの塔は、神の怒りによって、破壊されたじゃなかったっけ？
よく知らないです。はい。
旧約聖書の創世記の記述はこうです。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
「世界中は同じ言葉を使って、同じように話していた。東の方から移動してきた人々は、シンアルの地に平野を見つけ、そこに住み着いた。彼らは、『れんがを造り、それをよく焼こう』と話し合った。石の代わりにれんがを、しっくいの代わりにアスファルトを用いた。彼らは、『天まで届く塔のある町を建て、有名になろう。そして、全地に散らされることのないようにしよう』と言った。」
「主は降って来て、人の子らが建てた、塔のあるこの町を見て、言われた。『彼らは一つの民で、皆一つの言葉を話しているから、このようなことをし始めたのだ。これでは、彼らが何を企てても、妨げることはできない。我々は降って行って、直ちに彼らの言葉を混乱させ、互いの言葉が聞き分けられぬようにしてしまおう。』主は彼らをそこから散らされたので、彼らはこの町の建設をやめた。こういうわけで、この町の名はバベルと呼ばれた。主がそこで全地の言葉を混乱（バラル）させ、また、主がそこから彼らを全地に散らされたからである。」
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
うん。別に神が「バベルの塔」自体を、壊した！とか、人間の傲慢さが招いた失敗とかいう話じゃあない。なんかそんな話をよく耳にするけど。
むしろ、神は、「彼らは同じ言葉でうまくコミュニケーションを取っており、このまま放っておけば、上手く完成しそうだ。」と言っている。
そこで、神は、「共通の言葉をなくして、コミュニケーションを遮断し、プロジェクトを失敗に導いている。」
つまり、コミュニケーション管理で失敗するなと言いたいわけである。
コミュニケーション管理に必要なもの
人月の神話では、以下の３つがコミュニケーションには必要である。と述べている。
+ 非公式な会合、折衝
+ 公式なミーティング
+ プロジェクト手引書
非公式な会合、折衝
非公式な会合とは、ようするに誰かと二人で立ち話とかのこと。
非公式な話し合いは、チームのモチベーション向上や、人間関係の構築に有効だ。
公式なミーティング
公式なミーティングは、進捗や問題点の情報共有と、問題解決、何かしらの決定の為に行うべきものである。
公式な会合での決定は、個人間の非公式な会合による妥協防止や、問題放置によるPJ遅延に対して有効である。
しかし、会合で何かしらの決定を行う時、かならず反対意見を持つ者はおり、ストレスや鬱憤が蓄積する。この解決の為に、定期的な振り返りミーティングを行う必要がある。人月の神話ではこれは半年周期で長時間の振返り実施を推奨しているが、アジャイルプラクティスのように2週間程度のイテレーション期間の終わりにKPTで短時間でやるのが効果的で良いのではないかと思った。
プロジェクト手引書
プロジェクト手引書は、チームメンバが共通の認識の元に作業を行う為に必要なコミュニケーションツールでもある。人月の神話ではプロジェクト手引書という分かりづらい表現になっているが、用は、プロジェクト開発計画書、要件定義書、各種仕様書、設計書などのプロジェクトで作成される文書類を指し示す。
また、プロジェクトの最初の段階で、プロジェクトで作成するべき文書類の構成を定義しておくことも、メンバ間のコミュニケーションの為には良い。これは、誰が何に対してどこまでの範囲で作業を行う責任を持つかという共通認識確率に役立つ。
バベルの塔の教訓でも分かるように、プロジェクトメンバ間で共通の言葉をしゃべる事は、コミュニケーションでの失敗を防止し、プロジェクトを成功に導くためには非常に重要である。
チーム編成に見る品質確保手法
人月の神話（人月の神話 - Wikipedia）では、小規模開発でも大規模開発でも、外科手術チームのような少数精鋭のチーム編成を行うことを推奨している。
外科手術チーム
外科手術チームとは、役割分担がはっきりとしたその道のスペシャリストの集まりである。
ちなみにこれは、チーム全員が精鋭なのではなくって、精鋭のチーフプログラマをささえる2流、もしくは1流の集団というのが正しい。もちろん、全員が精鋭ならいう事ないが。
設計実装の実務を行うのは、チームプログラマと、それを支える副執刀医である。それ以外の人はこの二人のサポート役という位置づけである。
編集者というのは、ドキュメントを作る人のことである。
また、チームに必ず必要な人材として、下記の2人が示されている。外科手術チームに当てはめれば、執刀医チーフプログラマが技術主任（アーキテクト）であり、管理者が制作主任（マネージャ）である。昔よくいたプレイングマネージャとは下記の両方を一人二役でこなす人のことである。
【チームに必要な人材】
- 制作主任（マネージャ） ⇒管理者
- 技術主任（アーキテクト）⇒チーフプログラマ
非凡なプログラマーと、平凡なプログラマーの生産性の差は10倍にもなるという事なので、平凡なプログラマを集めてSW開発するよりも、この体制で臨む方がよいだろう。
また、10人のプログラマで開発を開始してしまうと、その間のコミュニケーションにかかる時間的コストが大半を占めてしまうが、執刀医と副執刀医だけでメイン作業を進めるならその時間も減らせる。これは大きい。
しかし、大規模開発の場合、たった10人のチームでは、どうあがこうと時間だけが過ぎて行って、いつまでたっても完成しないという事態になる。人員はそれなりに必要になってくる。
大規模開発でのチーム編成
大規模開発でも外科手術チームの生産性を使ってシステム開発を行うにはどうするべきか。
単純である。このチーム編成を複数作り、それを統括するチーフプログラマの集団という別チームを用意するのである。
そして、最初の概念設計段階では、このチーフプログラマの集団だけのチームでPJ運営を行う。
そして、概念設計が終わって、実装へ入る段階で、人員増強して、大人数プロジェクトとして運営するのである。
大規模開発で必要なコンセプトの一貫性というものを、上記のチーフプログラマが担保する為のチーム編成である。
コンセプトの完全性の担保
コンセプトの完全性こそ、システムデザインにおいて最も重要な考慮点だ。
上記の言葉は、まさにその通りだと思った。40年以上前から、これが真理なんだと思うと、心強い。設計コンセプトは二の次で、実装品質のみを高めようとする動きがあるので、それは違うだろうと思ってたところだった。
機能 対 コンセプトの複雑さの比率がシステムデザインの究極の試金石である。
貴族政治によるコンセプトの完全性の死守
SW開発は、アーキテクトが貴族政治を行って、プログラマに指示を出す形で、アーキテクチャ（コンセプト）の一貫性を死守することが品質を確保する上で重要だとブルックスは主張している。確かにさまざまなコンセプトが入り乱れたSW開発を行うと、それはスパゲッティコードの出来上がりである。
アーキテクトは、システムの概念設計を上流で行い、下流のプログラマ達へそれを伝え、そのコンセプトが崩れる事が無いように頑張らないといけない。
しかし、実際には、コーディングフェーズとなると、実装者から、様々な意見、提案が為される。しかしその中には、コンセプトを変えてしまうものも存在する。その場合には、毅然として、その変更要求を跳ね除けなければならない。敬意を持って。
つまりトップダウンで行った概念設計の死守である。
これによってコンセプトが保たれ、複雑性に起因する不具合や進捗遅れなど、様々な問題が低減される。
ここで重要なのは、あくまで低減であって、解決ではないということである。
ブルックスの法則と、進捗遅れの対策方法
人月の神話（The Mythical Man-Month: Essays on Software Engineering）の中で有名なブルックスの法則。
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」
そんなこと言っても、実際にプロジェクトが遅れていたら、まずは人員追加投入という話が出てくるのが現実だ。
なら実際にどうするべきか、何が問題なのか。
PMBOKのタイムマネジメントでも、スケジュール短縮の方法としてのクラッシング（資源追加投入）は、あまり良い結果にならないと示している。
そもそも進捗遅れの原因はどこにあるものなのか。
工程遅れの原因
- 見積りがちゃんとできていない。（プログラマはみんな楽観主義。たぶんこれでいけるよーってやつ-(^^)）
- 努力と進捗を混同している。（人と月が交換出来ると思い込んでいる）
- マネージャーが見積りに自信がないから工程面での頑固さにかける（ちゃんとしたものを作るには時間がかかるという信念）
- 進捗がきちんと監視されていない
- スケジュール遅延したら、要員を追加する。（火に油を注ぐがごとく）
工程遅れの対策案
見積りがちゃんと出来ていないとかの根本的な話題は今回はおいておこう。スケジュール遅延が発生したらどうするかという点を今回は深堀する。
まずは、QCDのうち、納期も作業量も変わらないと仮定すると、出来るのはコスト面の調整だけである。
PMBOKでは、スケジュール短縮技法として以下の２点が挙げられている。
進捗遅れの事例
12人月かかるPJに3人が割り当たっている。
毎月末にチェックポイントがあり、2か月たって1か月遅れであることが分かった。
つまりタスク１を1か月で終わらせる予定が、2か月かかってしまったという事になる。残りは２か月で9人月分の作業がある。
クラッシングを検討
＜対策１＞
前提：見積りがまずかったのはタスク１のみとする。
対策：残り9人月で2か月だから、単純計算なら4.5人必要。1.5人足りない。よって2人追加。
そんな直ぐに仕事出来るわけないから、勉強期間で＋1か月。既存人員もこれに手を取られる。
この時点で、人員追加しなかった場合と同じく1か月遅れのスケジュールである。
さらに、人が増えたことによる作業再分割やコミュニケーションロスによる遅延が増えるかもしれない。
さらにさらに、タスク２、３の見積りも甘ければ、さらに期間が必要になる。
つまり、この事例の場合、クラッシングだと、人員を追加してもしなくても進捗は変わらないか、悪化する。
＜対策２＞
前提：見積りがまずかったのはタスク１のみとする。
対策：1.5人月分が工程上は溢れる作業量となる。このため、これを既存の3人で仲良く3等分して残業実施。
1.5×140H / 3 = 70H で、2か月あるので、ひと月35時間の残業をすればカバー出来る。
余計な教育工数が発生しないので、残業承認されるならば、これが良い。
ただし、タスク２、３の見積り精度が高いことが条件になる。
ファストトラッキングを検討
仮にタスク１～４の内容が下記であった場合、ファストトラッキングの実施は可能。つまり、設計が終わらない内に実装を開始してしまえばよい。しかし、直ぐに分かる通り、前工程である設計に変更が入れば、その時点で、実装工程のファストトラッキングは無駄になる。SW開発ではほぼほぼ成功しなさそうな対策手段である。
| タスク名 | 内容 |
|---|---|
| タスク１ | 仕様 |
| タスク２ | 設計 |
| タスク３ | 実装 |
| タスク４ | テスト |
QCDの前提を見直す
人月の神話では、工程遅れに対しては、基本的に仕様削減で対処せよという見解で書かれている。
つまり、QCDのうち、Qを見直して作業ボリューム自体を減らせということである。
精神的な余裕も出てくるから、これが出来るならベストだ。
PMBOK的に言えば、スコープ定義の変更になる。このため、これを実行に移そうと思えば、プロジェクトのスコープ定義に関わったステークホルダ全員（もしくは、対象要求定義に関わる人）とのスコープ縮小の合意を取っておく必要がある。
そうしないと、勝手に仕様削減して何事だ！という手戻りが発生してしまう。
