自分が発表した直後の話題がちょっと欠けてる！
ってことで、抜けがあったらフォロー願います<出席した方々
================================================================================
アジャイルプロセス協議会
アジャイルTOC-WG 第4回定例議事録
================================================================================
0.作成者
株式会社 豆蔵 BS事業部 開発技術チーム 進藤 寿雄
1.開催情報
1-1.日時
・2006-10-11（水）19:00-21:00
1-2.場所
・株式会社 豆蔵 セミナールームA
1-3.新規出席者
・チェンジビジョン 水越さん
1-4.テーマ
・思考プロセス（前回テーマ）の補足
・スループット会計
2.次回予定
2-1.日時
・2006-11-21（候補）
2-2.場所
・株式会社 豆蔵
2-3.テーマ
・CCPMの実践例紹介（40分程度、岸良）
・CCPMに関するディスカッション
・これまでと今後の活動内容の整理
3.結論
・
4.宿題・要望
・TOCの実践と成功・失敗事例の収集
5.進行
・思考プロセスの実践例とポイント（増田）、ディスカッション
・スループット会計の概要（相馬）、ディスカッション
・スループット会計の基礎、システム開発における指標（進藤）、ディスカッション
6.議事
6-1.思考プロセスの実践例とポイント
6-1-1.実践例
・4〜5人のプログラマが業務外でWebサイトを立ち上げようとした際の話
6-1-1.現状問題構造ツリーの導出方法
（1）問題点を10-20分程度で、10-20件くらい列挙する（望ましくない状態）
（2）その中から具体的な問題点を1つ選択する
・派生する枝を伸ばしやすいため
・具体的かつ一番嫌だと思うものを選択する
（3）選択した問題点から派生する問題や原因の枝を伸ばす
（4）問題点の中から更に1つ選択し、1つ目と同様に枝を伸ばす
・1つ目の問題点からあまりかけ離れてないものが良い
（5）1つ目と2つ目の問題点から派生した枝を結んでいく
・展開が飛躍している箇所は適宜補完していく
（6）同様の操作を4つ目くらいまで行うと比較的複雑なネットワーク構造になる
（7）枝が大量に交わっている点が根本原因（制約）となるので対応する
・始めから列挙されている問題点は制約ではない
・枝が大量に交わる点は多くて1、2個程度である
（8）ある程度時間をおいて問題点の列挙から行う
・1つの制約に対処すると複数の問題は一気に解決することが多い
・1つの制約に対処した段階で制約は次に移っている
・制約への対処は一度に全て行うことはできない
・スピードと負担が少ないことが重要である
6-1-2.根本原因への対処法
・制約を中心にしてマインドマップを作成する
・制約条件を活用する方法を考える
・コンフリクトがあれば対立解消図等を用いて解消する
・問題を見つける際には現状問題構造ツリーを作る作業に戻る
6-1-3.やってはいけないこと
・問題点を挙げる際は当たり前のことだからと無視しない
・問題解決するといったことや用語等はあまり用いない方が良い
・最初から対立解消図等を持ち出して結論を出してしまわないこと
・全員で根本原因にたどりつくことが大切である
・問題点をとりあえず貼ってしまい、ただ線を繋いだだけの図では隠れた原因は見えてこない（見えてこないから解決できない）
6-1-4.思考プロセスの補足（相馬）
・制約理論は生産の改善が始まり
・ソフトウェアは設計行為であり、大量生産できないため繰り返して改善していくことができない
・思考プロセスは設計行為にも当てはまる行為である
・思考プロセスを実践することは難しい（問題を挙げる人は問題解決できることが多い）
・現状問題構造ツリー等を用いて問題を可視化することで、その改善度合いも提示することができるため、説明資料として有効
6-1-5.質疑
（1）思考プロセス以外で根本原因を特定するためにどんな手法を用いているか
・みな思考プロセスと同様の問題解決は意識せずに実践しているはずであり、思考プロセスはうまくパッケージ化されている（名前付けに価値がある）
・文章やマインドマップを用いて整理している。図は使用しない
・ソフトウェアそのものが問題解決のために存在するもの。設計方法論を使う
・KJ法や思考プロセスには粒度（抽象度）の問題があり、それに対処する負荷が大きい
・KPTを使用している
・KPTは改善の5ステップに近い
・何の問題を解決しようとしているかによって手法の選択は異なる
（2）現状問題構造ツリーを作成する作業はどの程度の頻度で行うのか
・制約の発見から改善を行い、その結果効果が表れるには時間がかかるため、1、2ヶ月程度のスパンになる
・根本原因の解消にはある程度時間がかかるものが多い
（3）対処する問題の選択（優先度）
・一番投資利益率が高いものを選ぶ
・即効性が高いもの
・見つかったものから順次
6-2.スループット会計
6-2-1.スループット会計の概要
・生産工程において、合計時間や原価ではなく工程全体の最大効率を考える
・ある特定の工程だけ改善しても全体のスループット向上には寄与しない
・安価な開発者よりも多少高くてもスループットが高い開発者を入れた方が良いという状況にもっていきたい
・スループット会計の単位がお金だが、これをソフトウェア開発にうまく適した指標単位に変えられないか（スループットを価値変換速度とみる等）
6-2-2.会計の言葉の扱いについて
・既存の会社の会計構造を変えろという話なのか
・財務会計にとって変わるものではなく、原価計算を基本とする管理会計に対応するものである
・キャッシュフロー会計とは何か異なるのか
・キャッシュフロー会計とは企業の経営成績をキャッシュの増減をもとに明らかにする手法。一般的に売掛金をへらし、買掛金を増やし、商品在庫を削減することがキャッシュの増加に繋がる
・スループット会計はスループットの増大、そのスループットを単位時間当たりいくら生み出すことができるかを評価基準にしている
・ABC等との関連はどうなるのか
・ABCは原価計算から派生した計算方法であり、配賦を活動ベースに割り当てている。これは、分類が難しいものを配賦として製品全体に分配した意図と逆行するものである
6-2-3.スループットの定義
・スループット会計は時間あたりの何かに重点をおいた考え方なのか
・スループットはあくまで販売価格-原材料費であるが、単位時間あたりのスループットも把握しなければ最大のスループットは得られない（特に生産ミックス）
この指標としてスループット・ダラーという用語が定義されている
・ソフトウェア開発においては、要求は時間と状況によって変化が大きい。要求を価値、スループットとするなら、速度の観点ははずせない
・提供の遅れによる機会損失の観点も必要（スループット・ダラー・デイズ）
アジャイル開発はこの観点でもメリットが大きい
・スループット会計の指標の単位はお金である。これにあわせようとするなら、計画段階における費用効果（金額）を要求のトリアージに基づいて分配し、その達成度合いを評価できないか。似たような考え方にEVMがあり、定義を少し変える
ことで流用できるのではないか
・スループット会計の視点には、時間と在庫の両方が含まれているのではないか
6-2-4.ソフトウェアの価値
・要求の価値、優先度をどのように評価するかが課題
・パッケージ開発ではどのように優先度付けをしているのか
・社内でキーパーソンの判断のもと優先度付けしている
・SIerの視点からすると、たとえ使われなくても作れといわれたものをつくらなければならない。顧客も含め、最大の価値を得るためにはバリューチェーンがしっかりと形成されていないと難しい
・要求開発の必要性、契約のあり方、適切なスループットの定義等、課題は多く、様々な観点から考えていく必要がある
ってことで、抜けがあったらフォロー願います<出席した方々
================================================================================
アジャイルプロセス協議会
アジャイルTOC-WG 第4回定例議事録
================================================================================
0.作成者
株式会社 豆蔵 BS事業部 開発技術チーム 進藤 寿雄
1.開催情報
1-1.日時
・2006-10-11（水）19:00-21:00
1-2.場所
・株式会社 豆蔵 セミナールームA
1-3.新規出席者
・チェンジビジョン 水越さん
1-4.テーマ
・思考プロセス（前回テーマ）の補足
・スループット会計
2.次回予定
2-1.日時
・2006-11-21（候補）
2-2.場所
・株式会社 豆蔵
2-3.テーマ
・CCPMの実践例紹介（40分程度、岸良）
・CCPMに関するディスカッション
・これまでと今後の活動内容の整理
3.結論
・
4.宿題・要望
・TOCの実践と成功・失敗事例の収集
5.進行
・思考プロセスの実践例とポイント（増田）、ディスカッション
・スループット会計の概要（相馬）、ディスカッション
・スループット会計の基礎、システム開発における指標（進藤）、ディスカッション
6.議事
6-1.思考プロセスの実践例とポイント
6-1-1.実践例
・4〜5人のプログラマが業務外でWebサイトを立ち上げようとした際の話
6-1-1.現状問題構造ツリーの導出方法
（1）問題点を10-20分程度で、10-20件くらい列挙する（望ましくない状態）
（2）その中から具体的な問題点を1つ選択する
・派生する枝を伸ばしやすいため
・具体的かつ一番嫌だと思うものを選択する
（3）選択した問題点から派生する問題や原因の枝を伸ばす
（4）問題点の中から更に1つ選択し、1つ目と同様に枝を伸ばす
・1つ目の問題点からあまりかけ離れてないものが良い
（5）1つ目と2つ目の問題点から派生した枝を結んでいく
・展開が飛躍している箇所は適宜補完していく
（6）同様の操作を4つ目くらいまで行うと比較的複雑なネットワーク構造になる
（7）枝が大量に交わっている点が根本原因（制約）となるので対応する
・始めから列挙されている問題点は制約ではない
・枝が大量に交わる点は多くて1、2個程度である
（8）ある程度時間をおいて問題点の列挙から行う
・1つの制約に対処すると複数の問題は一気に解決することが多い
・1つの制約に対処した段階で制約は次に移っている
・制約への対処は一度に全て行うことはできない
・スピードと負担が少ないことが重要である
6-1-2.根本原因への対処法
・制約を中心にしてマインドマップを作成する
・制約条件を活用する方法を考える
・コンフリクトがあれば対立解消図等を用いて解消する
・問題を見つける際には現状問題構造ツリーを作る作業に戻る
6-1-3.やってはいけないこと
・問題点を挙げる際は当たり前のことだからと無視しない
・問題解決するといったことや用語等はあまり用いない方が良い
・最初から対立解消図等を持ち出して結論を出してしまわないこと
・全員で根本原因にたどりつくことが大切である
・問題点をとりあえず貼ってしまい、ただ線を繋いだだけの図では隠れた原因は見えてこない（見えてこないから解決できない）
6-1-4.思考プロセスの補足（相馬）
・制約理論は生産の改善が始まり
・ソフトウェアは設計行為であり、大量生産できないため繰り返して改善していくことができない
・思考プロセスは設計行為にも当てはまる行為である
・思考プロセスを実践することは難しい（問題を挙げる人は問題解決できることが多い）
・現状問題構造ツリー等を用いて問題を可視化することで、その改善度合いも提示することができるため、説明資料として有効
6-1-5.質疑
（1）思考プロセス以外で根本原因を特定するためにどんな手法を用いているか
・みな思考プロセスと同様の問題解決は意識せずに実践しているはずであり、思考プロセスはうまくパッケージ化されている（名前付けに価値がある）
・文章やマインドマップを用いて整理している。図は使用しない
・ソフトウェアそのものが問題解決のために存在するもの。設計方法論を使う
・KJ法や思考プロセスには粒度（抽象度）の問題があり、それに対処する負荷が大きい
・KPTを使用している
・KPTは改善の5ステップに近い
・何の問題を解決しようとしているかによって手法の選択は異なる
（2）現状問題構造ツリーを作成する作業はどの程度の頻度で行うのか
・制約の発見から改善を行い、その結果効果が表れるには時間がかかるため、1、2ヶ月程度のスパンになる
・根本原因の解消にはある程度時間がかかるものが多い
（3）対処する問題の選択（優先度）
・一番投資利益率が高いものを選ぶ
・即効性が高いもの
・見つかったものから順次
6-2.スループット会計
6-2-1.スループット会計の概要
・生産工程において、合計時間や原価ではなく工程全体の最大効率を考える
・ある特定の工程だけ改善しても全体のスループット向上には寄与しない
・安価な開発者よりも多少高くてもスループットが高い開発者を入れた方が良いという状況にもっていきたい
・スループット会計の単位がお金だが、これをソフトウェア開発にうまく適した指標単位に変えられないか（スループットを価値変換速度とみる等）
6-2-2.会計の言葉の扱いについて
・既存の会社の会計構造を変えろという話なのか
・財務会計にとって変わるものではなく、原価計算を基本とする管理会計に対応するものである
・キャッシュフロー会計とは何か異なるのか
・キャッシュフロー会計とは企業の経営成績をキャッシュの増減をもとに明らかにする手法。一般的に売掛金をへらし、買掛金を増やし、商品在庫を削減することがキャッシュの増加に繋がる
・スループット会計はスループットの増大、そのスループットを単位時間当たりいくら生み出すことができるかを評価基準にしている
・ABC等との関連はどうなるのか
・ABCは原価計算から派生した計算方法であり、配賦を活動ベースに割り当てている。これは、分類が難しいものを配賦として製品全体に分配した意図と逆行するものである
6-2-3.スループットの定義
・スループット会計は時間あたりの何かに重点をおいた考え方なのか
・スループットはあくまで販売価格-原材料費であるが、単位時間あたりのスループットも把握しなければ最大のスループットは得られない（特に生産ミックス）
この指標としてスループット・ダラーという用語が定義されている
・ソフトウェア開発においては、要求は時間と状況によって変化が大きい。要求を価値、スループットとするなら、速度の観点ははずせない
・提供の遅れによる機会損失の観点も必要（スループット・ダラー・デイズ）
アジャイル開発はこの観点でもメリットが大きい
・スループット会計の指標の単位はお金である。これにあわせようとするなら、計画段階における費用効果（金額）を要求のトリアージに基づいて分配し、その達成度合いを評価できないか。似たような考え方にEVMがあり、定義を少し変える
ことで流用できるのではないか
・スループット会計の視点には、時間と在庫の両方が含まれているのではないか
6-2-4.ソフトウェアの価値
・要求の価値、優先度をどのように評価するかが課題
・パッケージ開発ではどのように優先度付けをしているのか
・社内でキーパーソンの判断のもと優先度付けしている
・SIerの視点からすると、たとえ使われなくても作れといわれたものをつくらなければならない。顧客も含め、最大の価値を得るためにはバリューチェーンがしっかりと形成されていないと難しい
・要求開発の必要性、契約のあり方、適切なスループットの定義等、課題は多く、様々な観点から考えていく必要がある
|
|
|
|
|
|
|
|
アジャイルTOC 更新情報
-
最新のアンケート
-
まだ何もありません
-
