初めてのキャッシュフローゲーム
ちょっと友達に誘われて投資の勉強会？的な集まりでキャッシュフローゲームをやってきました。
■キャッシュフローゲームとは？
金持ち父さん貧乏父さんの著者ロバートキヨサキ氏が考えたボードすごろくゲーム
■キャッシュフローゲームの流れ
BS(貸借対照表)とかPL(損益計算書)をまず書いて
サイコロを振って
給料日のマスを通過すれば給料が貰えて
投資イベントのマスに止まったらカード引いて、株や不動産などをカードに書かれた価格で売買できる(けどしなくてもよい)
BSやPLは都度書き換えながら、手持ちの資産を増やしていくゲーム
■ゴールは２つ
最初の目標は不労所得(自分が働かなくても勝手に入ってくるお金)が支出を上回ること
働かなくても生きていける状態
次の目標は最初に決めた人生の目標に必要なお金が手元にあること
お金がないからやりたいことを我慢しなくていい状態
■やってみた感想
ゲーム自体は自分の普段の行動とかが如実に現れて色々気づかされることも多いので、チャンスがあればやってみたほうがよいと思う。怪しい投資話とセットで開催されることも多いらしいので、騙されやすい人断れない人流されちゃう人は止めておいたほうがよさそう。
投資話は金額が小さいより大きいほうが断然有利(ローリスクハイリターン)。現実世界の投資でも元手が大きいほうが有利なのは世の中見てても同じだと思う。ゲーム内だとプレイヤーがお金出し合って有利な大きい投資ができる。現実世界でも同じようにできればと思うけど、詐欺とか持ち逃げとか心配だから、よっぽど信用し合ってないと難しいかな？
ゲーム内だとこの投資話はどのくらいリターンがあるとか株価はいくらぐらいで推移するとか書いてあってリスクとリターンが分かりやすい。思ったのは、意外と現実社会もちゃんと勉強して経験積んで見る目を養えば同じなんじゃないかな？実際のお金が絡むと冷静な判断できなくなるので、みんな損するけど。
なんだかんだでいろいろ勉強になりました！
品質について改めて整理①
■システム開発で大事なことは？
と聞かれたとき、見る角度や立場から様々な意見があると思いますが、間違いなく必要なものの１つは
「品質」
であるというのは間違いないと思います。
他にも「コスト」「納期」とありますが、お互い影響したり、トレードオフの関係だったりする。
■品質とは？
JIS規格によれば6つの品質特性と27の品質副特性
1 機能性
合目的性,正確性,相互運用性,セキュリティ,
2 信頼性
成熟度,障害許容性,回復性
3 使用性
理解性,習得性,運用性,魅力性
4 効率性
時間効率性,資源効率性
5 保守性
解析性,変更性,安定性,試験性
6 移植性
環境適応性,設置性,共存性,置換性
※それぞれの意味は割と言葉通りの意味。
■品質の良いシステムとは？
ちゃんとお客さんの要望通りの機能が全て盛り込まれてて、
業務が絶対滞らないレベルでシステムが稼働し続けて、
お客さんが操作しやすくて、
裏ではマシンの性能を効率良く引き出していて、
システムの保守や移行が可能な限りスムーズに行えるシステム。
裏返すと
■品質の悪いシステムとは？
お客さんの要望通りの機能になっていなくて、
すぐシステムが停止したり、意図しない動作をして、
お客さんが使い方を理解しにくくて
マシンの性能通りの性能(レスポンスなど)が満たされていなくて、
システムの保守や移行が行うのが大変なシステム。
■品質は100%実現しなくてはいけない？
そもそも人によって認識が違ったりするので100%の判断が難しい。
また品質100%のシステムを実現するのは、いくら開発関係者が優れていても、コストや納期の制約などもあり難しいことが多いので、
・品質をどこまで高めるか
・品質のどの部分を高めるか
はシステムの特徴や特性を見て判断する。
１つの指標として４段階の信頼性要求水準
・人命に影響、甚大な経済損失
・社会的影響が極めて大きい
・社会的影響が限定される
・社会的影響がほとんどない
などがある。
開発技術やマシンの性能、利用者数、世の中の求める基準などは時代とともに目まぐるしく変化しているので、その時代に応じた見極めが必要。
■品質が悪いとどうなるか？
発覚するのが
本番稼動前であれば、追加のコストが発生したり、スケジュールの遅延が発生したり、
本番稼動後であれば、システム利用者/利用会社の業務などに支障をきたし、損害が発生したりする。
■品質の向上のためにどう取り組むか？
品質が悪い=不具合がある
という前提で考えると
１そもそも不具合を作らない。
２不具合を見逃さない。なるべく早く見つける。
方法としては
１予防活動
２検知活動
の２つを開発の各工程(要件定義 基本設計 詳細設計 プログラミング テスト)において行う。
続きはまた改めて
参考サイト：
高信頼化ソフトウェアのための開発手法ガイドブック
https://www.ipa.go.jp/files/000005144.pdf
順を追ってイテレーションからラムダ式、ストリームAPIまでを理解
０）最初は昔の書き方
まずList型の場合、繰り返し処理は
for (int i = 0; i < string_list.size(); i++) {
String str = string_list.get(i)
System.out.println(str);
}
って書くけど、この書き方はもう古い
１）まずはイテレーション
ずばりイテレータを使ってこう書く
for(Iterator<String> i = string_list.iterator(); i.hasNext();){
String str=(String)i.next();
System.out.println(str);
}
２）ジェネリックスを使ってみる
さらにジェネリックスを使うとキャストしなくてよくなって
for(Iterator i = string_list.iterator(); i.hasNext();){
String str = i.next()
System.out.println(str);
}
となる。
３）拡張forを使ってみる
さらに拡張forを使うと
for(String str : string_list){
System.out.println(str);
}
と書けるとのこと。なるほど！少し楽！
このように、イテレータを取得して、操作して、イテレータを実行するような処理を「外部イテレータ」と言うらしい。
ここで終わりではなく、さらに覚えなくてはいけないのが...
・内部イテレータ
・ラムダ式
・Stream API
上記外部イテレータを内部イテレータに書き換えるとforEachを使って
string_list.forEach(
new Cunsumer<String>(){
public void accept(String str){
System.out.println(str);
}
}
);
となるらしい。なんか長いし難しい...
これだと並列処理とかもできたりするみたいけど、もう少しすっきりしないだろうか？
５）ラムダ式を使ってみる
上記の内部イテレータを、ラムダ式を使って書くと
string_list.forEach(
str -> {
System.out.println(str);
});
となるとのこと。なんかすっきりした！
1行だと{}を省略して
string_list.forEach(str -> System.out.println(str));
でも可！
ラムダ式の本体を省略して、メソッド参照なんかを使うと
string_list.forEach(System.out::println);
まで省略できるとか。
色々省略しすぎて逆に良く分からなくなってきた。
６）最後にStream API
上記のラムダ式をStream APIを使って書くと
string_list.stream().forEach(str -> {
System.out.println(str);
});
となるらしい。
Stream APIは中間操作と終端操作というのがあって、
string_list.stream()
.filter(str -> str.length <= 5)
.forEach(str -> System.out.println(str));
みたいに書くと5文字以下のstrだけSystem.outするみたいなこともできるっぽい！便利！
中間操作と終端操作は色々種類があるから、使いこなせれば記述もすっきりして便利だけど、馴染みのない人にはフルにラムダ式やStream APIまで使いこなしているコードは理解するのにも一苦労しそう。
最後）まとめ
単純なfor(...){}から始まり → ０）
Iteratorを使うようになり → １）
ジェネリックスで型変換を省略するようになり → ２）
拡張forで記述を省略し → ３）
外部イテレータから内部イテレータになり → ４）
ラムダ式になり、 → ５）
最後はStream APIになる。 → ６）
順を追っていくといろいろ進化してるんだな。。。
【読者メモ】図解 大学受験の神様が教える記憶法大全
最近めっきり記憶力が低下してるので読んでみた。
■PART1 記憶のメカニズムを知ろう
- 年をとると物覚えが悪くなるは思い込み。
単純な丸暗記は子供のほうが得意だが、大人は経験や自分なりの理解を加えて覚えることができる。
- 記憶とは「覚える(記銘)」「覚えたことを保つ(保持)」「思い出す(想起)」の３ステップで考える。
想起には勝手に思い出す「再生記憶」と意図的に思い出そうとする「再認記憶」があり、いわゆる記憶力は「再認記憶」がうまく機能するかどうかにかかっている。
- 記憶のポイントは1.すぐ忘れないように繰り返しインプットすること、2.必要なときに情報が取り出せるよう定期的にアウトプットすること。
- 記憶は起きている間どんどん上書きされていくため、必要な情報が想起しにくくなる。
これを軽減する方法は1.一気にではなく数回に分けて覚える、2.繰り返し記憶する、3.余計なことは覚えないこと。
- 社会人になっても学生時代と同じ記憶法は可能だが、効率よく記憶するためには、1.覚える目的をはっきりさせることで、2.関心興味がわいて、3.自然と注意力が働き脳が勝手に必要な情報を集めはじめる。
- 寝ている間脳は日中働いていた脳の修復をしたり、日中記憶したことを定着させることをしているため、個人差はあるものの一般的には６〜７時間の睡眠をとることが必要。
- 記憶の効率を高めるこつは「イメージづけ」と「関連づけ」1.五感、2.誇張、3.リズムや動き、4.色、5.数字、6.記号、7.順番とパターン、8.魅力的なイメージ、9.ユーモア、10.ポジティブなイメージを活用する。
■PART2 仕事に活かせる！社会人のための記憶術
いくつか抜粋
・目的を明確にいかに関心や好奇心をもつか
・むやみやたらと暗記するより理解して覚える
・書く書く書く、もしくはSNSで情報発信
・メモはポイントやキーワードを矢印や囲みで整理
・復習復習復習、1日後1週間後半年後
・ストーリーで覚える
・音読音読音読、目で読み声に出し耳で聞く
・数字は７桁までしか覚えられないので区切って語呂合わせ
・睡眠はしっかりとる
・類似情報はまとめたほうが覚えやすい
・内容を大中小で考える
・思い出すヒントを用意しておく
■PART3 想起力を高める記憶法
- 記憶とは「記銘」「保持」「想起」の３ステップ。年を重ねるごとに重要になってくるのが「想起」いつでも必要なときに必要な情報を引っ張り出せるか！
アウトプットを目的にインプットする「いつどこで使うか」「何と関連づけて覚えればよいか」
- 名前は付加情報とセットで。大人になるほど付加情報が格段に増加。付加情報にも優先順位をつける。優先順位の付加情報は捨てる。
- 名前を忘れないこつは1.声に出す、2.意識して復習、3.そのときの資格情報とセットで覚える、4.メールの宛名や書類に相手の名前社名役職を毎回書いて付加情報を合わせて覚える
- 記憶定着のステップは1.注目、2.よく理解、3.セットで覚える、復習、練習(リハーサル等)
- リハーサルをして想起力を上げるトレーニング(日本人は怠りがち)
- 思い出すきっかけとなる情報は多いほうがよい。セットで覚えた情報は流れつながりを意識してスムーズに取り出せるよう整理しておく
- アウトプットの機会をとにかく増やす。場数を踏めば緊張が減り想起力も上がる。
- そのまま覚えるよりも自分なりに加工することで情報の価値が増す「周辺情報とくっつける」「エピソードで記憶する」スピーチなどのアウトプットは「シナリオ」を必ず用意する。面白いと思ってもらえる工夫、伝わる工夫。
■PART4 記憶力トレーニング
(割愛)
日頃の心構えを変えて、出来そうなとこからやってみよう。
マジビジプロ ハンディ版 大学受験の神様が教える 記憶法大全 (マジビジプロハンディ版)
- 作者: 和田秀樹
- 出版社/メーカー: ディスカヴァー・トゥエンティワン
- 発売日: 2016/02/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
HR×テクノロジー
http://eventdots.jp/event/583715
ちょっと面白そうだったので行ってきました。
◆HRとは
ヒューマンリソース 人材資源のこと
http://www.weblio.jp/content/HR
HR×テクノロジー(HRテック)とは
ITを使った人材資源の活用に関する取り組み
◆各社状況
社内に開発部隊を持っていなかった
システム開発はグループ会社などに外出し
↓
社内で開発部隊を持とう
何千人いる社員のうち最初は開発メンバー１人とか
↓
従来の文化体質
・人材会社にとって情報は最も重要、とにかくセキュリティが最優先
・開発技術ツールを好きに選定できない
・外部とのネット接続がかなり制約されてる
↓
従来の文化体質に馴染むのではなく、情熱を持って変えていく
↓
もちろん抵抗にあう
↓
徹底的にリサーチして説得できる根拠を揃える
↓
会社としても変わりたくないわけではない
メリットがデメリットを上回れば了承
↓
現在ポリシーを持って組織作り体制を強化しているところ
・まずは情熱が大事、とにかく挑戦
・組織として結果も出すし、個人のやりがいも追求する
・みんなが当事者意識をもつ、スピード感をもつ、コミュニケーションとにかく大事
・新しいメンバーを募集するため、積極的に情報発信している
◆感想というか感じたこと
とにかく情熱を持って技術を追求していく、そしてとにかく楽しむ
何かを変えるとき当然反発はあるけど、地道に根拠を集めれば変えられるのと、時には代替案があったりするので、簡単に諦めないこと
技術のことだけじゃなく、組織作り、ビジネス視点でのことも勉強してて、４人とも仕事に対する情熱が凄かった
小学生並みの感想だけど、とても面白かったし、よい刺激になった
情報セキュリティ10大脅威 2016を読んで素人でも気をつけられること
3月末の公開された情報セキュリティ10大脅威 2016を読んで
むやみやたらに銀行口座やクレジットカードを作らない
―自分で把握できる範囲に留める
―使わなくなったら解約する
むやみやたらに銀行口座やクレジットカードの番号、電話番号等を利用しない(WEB上もお店でも)
―信用度が高い安全なサイトでの利用に留める
―プリペイドカードの購入やコンビニ支払いなども利用してみる
あやしいメールは無視する
―携帯電話やPCの迷惑メールフィルタを厳しめに設定して定期的に見直す
―知らない人からのメールの添付ファイルは絶対に開かない
―知らない人からのメールのリンクは絶対に開かない
―メールのアドレスを確認して変な文字列だったら無視する
メールの添付やリンクは用心して開く
―知り合いからのメールの添付ファイルやリンクを開く場合に心当たりのない内容であれば電話等で相手に確認する
―メールのリンクを開くときはURLがgoogleで検索して最初のほうに出てくる正規のサイトのURLと本当に同じか確認する
できれば手間とお金をかける
―セキュリティソフトはなるべく入れる(できれば有料のもの)
―OSなどのアップデートは定期的にする(アップデートの通知機能をオンにしておく)
―メールアドレスとパスワードのペアは使いまわさない(パスワードの文字数はなるべく長くする)
―インターネットバンクなどで認証方法や入力方法が複数ある場合は推奨されているかめんどくさいほうを選ぶ
―銀行口座やクレジットカードの入出金は毎月確認する
―利用サイトにログイン通知や課金通知の設定があればなるべくなら設定しておく
―気になることがあればパソコンに詳しそうな知り合いやインターネットから情報を入手する
―見逃したTV番組やHな動画は違法アップロードされているものではなく、お金を払って正規の配信サイトやレンタルビデオを利用する
分からないものには手を出さない
―よく分からないアプリをイストールしない(スマホアプリのレビューはさくらも多いので信用しない)
―あまり浸透していないサイトに入会する場合などはご利用規約に一応目を通す(～円請求しますと書いてないか？)
書いてある内容を鵜呑みにしない
―知らないメールの退会はこちら配信停止はこちらは信用しない(クリックすると相手に攻撃しやすくしてしまうだけ)
―あなたのパソコンが感染していますはいったんスルーする(クリックすると相手に攻撃しやすくしてしまうだけ)
また思いついたら追記
【勉強メモ】情報処理試験 プロジェクトマネージャ試験対策
試験まであと１週間
◼︎合格までの勉強時間目安
最低50〜100時間 ※個人差あり
◼︎問題を解くときのポイント
プロジェクトマネージャとしての立場から
１.スコープ マネジメント
２.タイム マネジメント
３.コスト マネジメント
４.品質 マネジメント
５.人的資源 マネジメント
６.コミュニケーション マネジメント
７.リスク マネジメント
８.調達 マネジメント
の何に関する問題を解決すればよいのか理解
本文を読むときは
・プロジェクトの概要
・プロジェクトの目的
・スケジュール
・プロジェクトの現在のフェーズ
・プロジェクトの体制
を意識する
発生した状況➡️リスク・問題・目標➡️取るべき対応の順に考えていく
◼︎午前１ マークシート30問(50分)
免除もしくは勉強０で突破可能だと望ましい
◼︎午前２ マークシート25問(40分)
参考書で基礎知識を学んだらひたすら過去問
常識的な考え方で結構解けるので人によっては勉強時間０でも突破可能
◼︎午後１ 記述式４問中２問(90分)
時間との戦い 先に設問を読んでから本文を読む
こういう場合はこう答えるというパターンは最低限抑えておいたほうがいい
◼︎午後２ 論文(120分)
必ず下地を準備しておく(最低３つくらい)
ある程度マネジメント対象ごとにシナリオを考えておく(時間がなければ対象を絞って準備する)
タイム、コスト、品質、人的資源あたりから
◼︎教訓
一担当者が勝手に変更要求を受けない
プロジェクトの実績や教訓は今後のプロジェクトに活かす
要員の追加で余計なコストも発生する(教育,資源,コミュニケーションなど)
納期に間に合わないときは段階リリースも検討
メンバーの進捗管理はルールを設け、報告を徹底させる
メンバーの進捗報告の裏付けとなる成果物を確認する
進捗遅れの予兆がないか監視し早期解決する
進捗遅れに対する選択肢は部分稼働、要員の追加、稼働時期の延期、ファスト・トラッキングあたり
ユーザ部門間の調整が難航しているときは、支援メンバーの派遣、顧客の上長や経営陣への調整依頼などで対応
ユーザの承認を得ず次工程へ進むのは、出戻りのリスクがあるのでなるべく避ける
進捗は必要に応じて、着手、◯％、作業完了、レビュー完了など細かく管理する
移行は可能なものは前倒しする、事前にリハーサルしておく、移行に必要な時間を見積もっておく
ツールの導入,再利用率で開発生産性が上がる
開発規模の拡大,要員のスキル不足,仕様変更の多さで開発生産性が下がる
性能テストで問題があった場合は設計変更やハード増強などで対応する。リリース直後にそこまでの性能が必要ない場合はリリース後に対応
レビューで顧客の理解が弱い場合、プロトタイプやパッケージの機能を使ったデモンストレーションを行う
テストの工数は新規または修正したプログラムの他プログラムを考慮した重み付けをする
障害密度が基準上限より高い場合は開発体制に問題がなかったか確認する
障害密度が基準下限より低い場合はテストケースに問題がないか確認する
特定の業務知識やスキルが要求される作業はできるメンバをアサインする
新バージョンの実績がない場合は旧バージョンの適用を依頼元と交渉する
様々な顧客が利用するシステムのバージョンアップは各環境での動作検証をする
インターフェイスの変更は極力ないように調整するのが好ましい。変更する場合は仕様書も同時に修正する
システム要件の性能目標は過去の実績から見積し、できるだけ早い段階で担当メンバーが検証できるのが望ましい
ドキュメントの書式は管理基準に明記し、各メンバーに遵守を徹底させる
設計書の記述不足は開発効率の低下に繋がるので早期に解決する(教育,サポート,要因交代など)
内部レビューは事前に資料配布。指摘事項は管理表に記入し、正しく修正された確認をする
顧客がパッケージに合わせた業務改革に抵抗する場合、上層部へ説得の協力を要請する
ユーザレビューの意見交換が不十分の場合は、議事録で決定事項の明記し認識を合わせたり、専門家を参加させ議論を活発になるよう働きかけてもらたりする
システムテスト開始をスムーズに行うため、前段階の結合テストフェーズなどから環境を構築し利用する
同じプログラムの複数のバクの修正はある程度一括で行うと効率がよいが、他プログラムから利用がある場合テストが滞らないか気をつける
新規開発と改修で品質管理基準を別に設定する
既存システムへの改修は修正箇所とは別に影響を受けるプログラム数に一定割合をかけたテスト工数を設ける
開発中システムを利用した別システムの開発案件は開発中システムが稼働して一定期間置いた後に着手するほうが望ましい
請負開発で責任範囲外のボトルネックが発生する可能性が考えられる場合は、契約書等に明記
サービスレベルは後から高いレベルを要求されないよう事前に最大接続数やレスポンスタイム等設定しておく
検討漏れがないようSLA検討委員のメンバーをプロジェクトに加える
メンバーが他業務と兼務している場合は当メンバーの優先順位をはっきりさせておく
開発会社の経験が乏しい場合は、経験豊富なメンバーを体制に加えてサポートさせる
開発会社の規模が小さい場合は、人員の確保に不安があるので規模の大きな会社からのメンバ動員なども準備しておく
開発会社が海外の場合は、文化言語時差による管理工数の増加を見込んでおく
業務要件が複雑で開発保守の難易度が高い場合は前工程のメンバーを後工程にアサインしたり、十分な引き継ぎ期間を設ける
顧客の拠点が遠隔地にあり、リモートでの対応が困難な場合は、拠点の近くの会社への保守業務の委託も選択肢に入れる
大量の個人情報を扱う場合は、経営陣に取り扱いの基本方針を決めてもらい、ルールの周知、監視、情報のマスキングなど行う。不要になった情報は破棄する
開発メンバーが企業特有の用語を理解していない場合は、用語集を作成する
ユーザがシステムを使いこなせるようリリース前にトレーニング期間を設ける
支援を受ける予定だったメンバーがアサインできずに進捗が遅れる場合は、該当メンバーの作業を他メンバーに振ることができないか検討する
部門を横断してチームが組まれているとき、作業場所を合わせた方が、連体感一体感が生まれ作業効率も上がりやすい
進捗回復の追加メンバーは、慣れるまで作業効率が上がらない前提で予定を組むとともに、実際の作業に入る前段階に業務を理解するための期間を設ける
定例会議や報告のルールは統一して明文化する。担当者の負担が大きくならないように決める
距離が離れていて直接の打ち合わせがあまりできない場合は、テレビ会議で意思疎通をしやすくしたり、成果物をネットワーク上のファイルサーバ上で共有して認識の違いがないか確認したりする
部門間で認識に差異がある場合は、経営会議でプロジェクト憲章を決定してそれに従って進めるとともに、情報システム化委員会を設置し部門間の意見を調整する
リスク管理はマネジメント計画 リスク識別 定性分析 定量分析 対応計画 監視コントロールの順序で進める
リスクコントロールは回避軽減、リスクファイナンスは転嫁受容に分類して考える
システムの利用部門が多忙な場合は、後で変更要求が多発してしまう可能性があるため、業務部門の上長に相談しレビューに参加する時間を確保してもらう
取引先の評価基準を明確にして広く募集をかける。評価基準はプロジェクトの特性に応じて重み付けする
取引先の評価で点数が他者に比べて極端に乖離している場合はベンダーに認識のずれがないかヒアリングする
請負契約を結ぶとき仕様や成果物は明確にするとともに後工程での変更については別契約と同意明記しておく
請負開発で顧客から直接指示を出すのは法律違反
依頼元企業に合併吸収など開発が中止になるリスクがある場合は、中断時までの費用をもらう契約を結んでおく
製造のみ請負開発で外出しした場合は設計ミス実装ミスで責任の押し付け合いになるリスクがある
◼︎キーワード
立上.計画.実行.監視.変更管理.終結
ステークホルダ
変更管理委員会
プロジェクト完了報告書
WBS(機能別,作業別)
ワークパッケージ
アクティビティ
スコープ記述書
アローダイアグラム
工程山積表
ファスト・トラッキング
クラッシング
マイルストーンチャート
類似法見積
ボトムアップ見積
ファンクションポイント法(入力画面数,参照画面数,超票数,TBL数,外部IF数)
標準値法
COCOMOモデル法
putnumモデル法
コスト・ベースライン
EVM(アーンドバリュー管理) 時間xコスト
PV planned value
AC actual value
EV earned value
CV cost variance (EV - AC)
SV schedule variance (EV - PV)
トレンドチャート 開発期間x予算消化率
ソフトウェアの品質特性(機能性,信頼性,使用性,効率性,保守性,移植性)
ウォークスルー
インスペクション
品質管理図と信頼性成長曲線
ゴンペルツ曲線(ロジスティック曲線)
QC７つ道具(パレート図,特性要因図,層別円グラフ,ヒストグラム,管理図,相関図,チェックシート)
RAM 責任分担表
マトリックス組織 タスクフォース組織 委員会組織 機能部門別組織
階層別チーム チーフプログラマチーム スペシャリストチーム 民主的チーム
テイラーの科学的管理法
メイヨのホーソン実験
ハーズバーグの動機付け衛生理論マグレガーのXY理論 マズローの欲求5段階説
軽重順序法
コンフリクト
インタビュー法
