スポンサーサイト

  • 2018.05.03 Thursday
  • -
  • -
  • -
  • -
  • by スポンサードリンク

一定期間更新がないため広告を表示しています


残酷な世界で生き延びるたったひとつの方法

評価:
---
幻冬舎
---
(2015-04-10)
コメント:自己啓発のイデオロギーへの違和感に対する解説

JUGEMテーマ:読書

 

積ん読になっていたが、やっと読んだ。

主張のロジックがしっかりしており納得感が高かった。

若者を教育するときには気をつけるようにしようと思う

 

■「やってもできない」には理由がある

・人間に固有の8つの知能と1つの候補
 仝生貪知能
 ∀斥数学的知能
 2山敕知能
 た搬留親暗知能
 ザ間的知能
 η酳的知能
 対人的知能
 内省的知能
 実存的知能
・知能も遺伝する
・経済社会では´△優れている者が成功する
・ダメでも生きていける比較優位の理論
 →能力競争で一番にならなくとも比較優位を活かせる分野で仕事を得られる

 

■能力主義は道徳的に正しい
・能力主義に対する二つの主張
 →やってもできない人が一定数存在する中で努力して能力を向上させることを強要することは道徳的に正しくない
 →能力主義になるのは避けられないのだから、それに対応することが効率的に幸せになる手段である
・能力主義は差別のない平等な社会築くための基本インフラ
 →比較優位を明らかにするために、能力を評価する仕組みが必要となる
 →能力が比較できなかったら、自分の比較優位を知ることができない
 →比較優位が不明なため、´△優れている者が全ての仕事をこなし、それ以外の者が失業する
 →故に能力評価を導入し比較優位を明らかにすることが、差別のない平等な社会を築く基本インフラとなり得る

 

■ぼくたちは幸福になるために生きているけど、幸福になるようにデザインされているわけではない

 

●高望みをせず、比較優位が活かせる分野で得意なことを活かせということ

 


ロジカル・シンキング(論理的な思考と構成のスキル)

評価:
照屋 華子,岡田 恵子
東洋経済新報社
¥ 2,376
(2001-04-01)
コメント:論理的な思考の基礎が記されている。応用はこの基礎の組み合わせに過ぎないため、この基礎がマスターできれば、ほとんどの課題に対応できるようになれるはず。もっと、早くに読みたかった。

JUGEMテーマ:読書

 

普段、自分の中で実施しているロジックの整理がそのまま解説されている内容であった。自分の考え方を他人に伝える際に明確に形式化できていなかった部分が補完された。
けっこう苦労して、今の位置までたどり着いているのだが、苦労して七転八倒している時期に、この本と出会いたかった。


■何のために相手に伝えるのか
 〜蠎蠅法嵳解」してもらう
  ・業務連絡、事務連絡等
 ∩蠎蠅法岼娶や助言、判断などをフィードバック」してもらう
  ・相手の考え・要求を引き出す場合
  ・相手の情報を基にした判断・助言を得たい場合
  ・相手の持つ情報と自分の持つ情報の差異を確認したい場合
 A蠎蠅法峭堝亜廚靴討發蕕
  ・相手に具体的なアクションをとってもらいたい場合

 

■ロジックに落とせていないときの特徴
 自分で書いたり話したりしていると、どうも具体的でない、と思ったら、それは、「問題が具体的に解けていないことなのだ」と考えるべきだ。そして、自分はどこまでわかっているのか、現象をどこまで掘り下げて分析できているのか、いまわかっているにもう一度、「なせそうなっているのか」「どうしてそういうことが起こったのか」「なぜそういえるのか」を自問してほしい。
問題が解けているということは、どうすれば良いかを具体的に考えられているということだ。

 

■ロジック
 理論とは、結論と根拠、もしくは結論とその方法という複数の要素が、結論を頂点に、縦方向にはSo What?/Why So?の関係で階層をなし、また横方向にはMECEに関係づけられたモノである。

 ・主張の構造が、縦方向にはSo What?/Why So?の関係で表されていることが重要
 ・横方向の要素がMECEの関係になっていることが重要

 

■ロジカルシンキングを身につけるためには
 ・結論を頂点に、縦方向と横方向に構造化していく訓練をするしかない
 ・正しい訓練を積めば必ず身につけることができる
 

 


図解モチベーション大百科

評価:
池田貴将
サンクチュアリ出版
¥ 1,512
(2017-06-12)
コメント:脳味噌の癖を生かして、自分自身をコントロールする方法

JUGEMテーマ:読書

 

新人育成と自分自身のコントロールのために役に立ちそうなテーマをピックアップ

 

■ゴールを間近に感じさせる 
 ・ゴールが近付くとモチベーションが上がる 
 ・終わりが見えそうな物事は、なかなかやめられない 

■価値観と行動を結びつける 
 ・自分は今なにを大切にしているのかと行動指針を明らかにする 
 ・全ての行動に意味が生まれる 

■6つのニーズ 
 ・安定感 
  安定を求める。他人のコントロール欲につながる 
 ・変化 
  今までとは違う体験をしたいニーズ。飽き 
 ・重要感 
  特別な存在でいたいニーズ。勝利、他人下げ 
 ・つながり 
  誰かに愛されたい。周囲との一体感を持ちたい 
 ・成長 
  自分のレベルを上げたい(内面的) 
 ・貢献 
  誰かの役に立ちたい(内面的) 

■思い込みの再評価 
 ・理由を聞かれると思い込みが強化され 
  「なぜ」は過去に意識を向ける 
 ・目的を聞かれると思い込みが軟化する 
  思い込みの合目的性の再評価が必要 

■特異性信用 
 ルールのしたがってそのチームのために働き、目標達成に貢献することによって得る信用 
 特異性信用が低いと発言を受け入れてもらえない 
 村社会? 

■目標設定理論 
 ・具体的で難しすぎず受け入れられるレベルの目標の場合、やる気を出す 
 ・目標は数値で表す 

■共通の目標 
 ・強力が必要な場面を共有したほうが信頼関係が芽生えやすい 
 ・敵対する者同士にあえて難しい共同作業をさせる 

■コントロール欲 
 ・自分でコントロールできることがあると幸せで健康的な生活を維持できる 
 ・決められることは自分で決め、やれることは自分でやることに自由がある 

■否定的な言い方には説得力がある 
 ・提案には否定も加える 
 ・相手の否定を先回りして、解決する 
  
 


The DevOps 逆転だ!

評価:
ジーン・キム,ケビン・ベア,ジョージ・スパッフォード
日経BP社
¥ 2,376
(2014-08-12)

JUGEMテーマ:読書


ユーザ企業がIT部門を抱え、自らの事業に必要なITソリューションを自ら開発・運用している会社を部隊としている
日本のユーザ企業ではIT運用管理部隊のみを抱え、ITソリューションの開発にはITベンダーを利用する形態が多いため、日本の一般企業とは事情が異なる。

3000人規模の自動車部品製造販売会社で、ミッドレンジシステム運用部長のビルパーマが、IT運用全体のVP(バイスプレジデント)に任命される。
社運をかけたフェニックスプロジェクトが遅れている。別のVPが開発部隊を管理統括している。
運用部隊は開発部隊に対し、開発環境・テスト環境・本番環境を提供する責務を負っている。
また、運用部隊は、本番リリース、本番環境へのパッチ適用、本番システムに対する小規模な変更作業も担当してる

■IT運用の現状
・本番変更のたびに予期せぬ不具合が発生し、システムがダウンする
・システムダウンが発生すると復旧までに時間を要し、ビジネスに多大な影響が出ている
・誰が、いつ、何を、どのように変更したが管理されていない
・変更に対する影響範囲の調査が実施されていない
・承認なしに変更作業が実施されている
・ソースコードの構成管理がされていない
・ビジネス部門から運用部門の担当者に作業が直接依頼される
・キーとなる作業担当者に作業が集中している

■改善に向けて
・4つの仕事のタイプと3つの道に沿って業務を改善する

■仕事の4つのタイプ
「ビジネス・プロジェクト」
→ビジネスの要請により遂行される
「内部プロジェクト」
→IT運用上必要な技術的な作業
「プログラム変更」
→機能拡張や内部統制上の要請により遂行される
「予定外の仕事」
→障害対応等の作業

■3つの道
1.開発から運用へのスムーズな仕事の展開
2.運用から開発へのフィードバックの強化
3.上記1と2の継続と強化

■改善の手段として
・ザ・ゴールのTOCを参考に
・アジャイルも取り入れる
・継続的インテグレーションにも全社的に取り組む

ゴールドラット博士の論理思考プロセス

評価:
H.ウイリアム デトマー
同友館
---
(2006-02)
コメント:TOCの論理思考ツールの紹介

JUGEMテーマ:読書

「制約条件の理論」
■制約
 ・物理的制約
 ・ポリシー制約
■制約条件を継続的に打開するために
 1.制約条件を見つける
 2.制約条件を最大活用する方法を決める
 3.ステップ2の意志決定に全てを従属させる
 4.制約条件の能力を高める
 5.惰性に陥らないようステップ1に戻る
■品質改善の活動レベル
 1.何もしない
 2.小さな改革を行う←TQMの活動は主にここ。複数の対策を打つため効果がわかりにくい
 3.大きな変革を行う
 4.最初からやり直す
■マネジメントとは
 ・「何を」変えるのか
 ・「何に」変えるのか
 ・「どのように」変えるのか

「TOC思考プロセス」
■現状分析ツリー
 ・システムのゴールと境界を決める
  →問題の宣言を「なぜ?」から導く
  →「なぜ人員が定着しないのか」等
 ・原因、マイナス面、なぜ悪いかをリストアップ
 ・好ましくない結果を決める
 ・グループ化、関連づけ
 ・検証&掘り下げ
 ・好ましくない結果の見直し
 ・悪循環ループの発見
 ・根本の発見、不要の取り除き
 ・ターゲット確定
■雲
 ・対立を明確化
  →二律背反
  →二者択一
 ・対立(前提)→要件→目的
 ・対立する立場に立たせている誤った仮定を見つける。前提を疑え
 ・一旦、共通する上位の課題に抽象度を上げ、再度下ろしてくる。論点のすり替えが起きないように要注意
■未来実現ツリー
 ・仮説のシミュレーションを実施
 ・現状分析ツリーに仮説をインジェクションする
 ・ツリーを下から上に見直す
■ネガティブブランチ
 ・未来実現ツリーの逆
 ・仮説をインジェクションする
 ・結果をシミュレーションする
■前提条件ツリー
 ・目的の障害を洗い出し、その対策を前提条件として構造化していく
 ・PERT図になっていく
■移行ツリー
 ・実行計画→「INPUT→処理→OUTPUT」の構造
 ・前提条件ツリーの中間目標を実現するためにINPUTと処理を記述する
 ・WBSっぽくなる?

「所感」
・ザ・ゴールの中で使われていた論理思考ツールが詳細に説明されていたが、使いこなすには経験が必要な印象
・より具体的な事例に基づいているので、ザ・ゴールの中で語られている部分の方が、わかりやすいかも
・各論理思考ツールの特徴が明確に語られているので、それだけでも読む価値はあると思う

 

TOC/CCPM標準ハンドブック―クリティカルチェーン・プロジェクトマネジメント入門

JUGEMテーマ:読書

「問題提起」
■プロジェクトマネジメントの問題点
 ・同じPJは二度とない 
 ・不確実性が高い
 ・QCDはトレードオフの関係
■計画の問題点
 ・計画時に全ての要素を詳細に定義することが困難→段階詳細化
  →詳細が不明のまま計画を作成する必要がある
  →計画の精度のばらつきが大きくなる
 ・各作業の作業期間見積もりのサバ読みが段階的に積み上げられていく
  →目標とした期間に完了できない計画となる
  →強制的に期間が短縮される
■遅れる原因
 ・学生症候群
 ・悪いマルチタスクキング
 ・早期完了の未報告
 ・パーキンソンの報告
 ・変動制と従属性による「遅れ」の伝搬
■プロジェクトマネジャのジレンマ
 ・プロジェクト毎の個別最適化

「TOP/CCPMの紹介」
■TOC(継続的改善の5ステップ)
 1.制約条件を見つける
 2.制約条件を徹底活用する方針を決める
 3.他の全てをステップ2の決定に従属させる
 4.制約条件を強化する
 5.惰性に注意しながらステップ1へ戻る
■CCPM
 ・計画時のサバ読みを全て排除
 ・サバ読み分をまとめてバッファとして管理する
 ・タスクの完了に必要な日数と残っているバッファの日数を管理することでプロジェクトを管理する
 ※サバ読み分を排除した見積もり日数の決定方法は組織として決める必要がある
  →明確な解はない。経験値に基づく?見積もりに対し一律50%の期間とする?

「バッファマネジメントの手法」
■アジャイル開発
 ・アジャイルのプラクティスの紹介

「所感」
・ザ・ゴールで取り上げられたCCPMにつて、もっと掘り下げられていることを期待したが
 ザ・ゴール1,2,3のサマリでしかない印象をもった。
 詳しく知りたければザ・ゴールを読み、簡単にサマリを知りたいならこの本を読めばいい感じ
・CCPMを実践するためにアジャイルに行き着くのなら、別にCCPMは必要ないように感じる
 チームの速度が測定されタイムボックスの中でこなせるタスクの量が明確になっていれば
 バッファの管理は必要なく、タスクの管理だけで十分と思われる
・ITプロジェクトの制約条件とは何か?
 ITプロジェクトでは時間経過と共にワークセンタ(工程)で情報が処理され次のワークセンタに渡されると考えている
 この場合、どのワークセンタが制約条件になっていたかを知るためには、PJの完了を待たないといけないのでは?
 同じPJは2度とないため、過去のPJで制約条件を見つけたところで次のPJに活かすことが難しいのでは?
 ITプロジェクトを対象とした場合のTOC/CCPMに対しての上記の疑問に対する解答は見あたらなかった。
 もしかしたら単一PJのみを管理するマネージャにTOC/CCPMを適用するのは難しいのかもしれない
 
 

Apache Strutsアプリケーション開発入門

評価:
四次元データ
ソフトバンククリエイティブ
¥ 2,604
(2005-01-26)

 
JUGEMテーマ:読書

strutsという言葉は聞いたことがあったが、詳しい内容は知らなかったので、入門書を読んでみた。

何のことはない、単純に画面と画面から呼び出されるアクションの橋渡しをするフレームワーク。

それほど機能は多くない。

単純にMVCのControlを提供しているだけ。アプリケーション開発でキモとなるModelの設計は別途しっかしやる必要がある。

MVCのControlとModelの橋渡しには、リフレクションを使うか、DIを使った方がよさそう。
次は、SpringかSeaSarあたりを調べてみよう。

Struts機能メモ

考え・書き・話す3つの魔法

評価:
野口 吉昭
幻冬舎
¥ 1,000
(2009-04-23)
コメント:思考の整理が簡単にできる方法がシンプルに書いてある。

JUGEMテーマ:読書

とりあえず、なんでも3つに分類することで、不思議とすっきりとまとまるというお話し。

■わかりにくい話
 ・憶測と事実が混在している。
 ・結論が見えない。
 ・内容が抽象的。
 ・話のロジックが組み立てられていない。

■3つのフレームワーク
 ・主張を伝えるための枠組みとして3つのテーマを用意する。
 ・3つのテーマに沿って、根拠と事実を記述。
 ・3つのテーマの決め方がキモ。

■フレームワーク例
 ◇ディスカッション
  ・目的
   ディスカッションの目的を明確にする。
  ・定義
   用語の定義を明確にする。
  ・着地点
   ディスカッションの着地地点をどこに設定するか明確にする。
 ◇伝わるために
  ・自分軸
   自分の理念やポリシーを持ち、自分の意見をきちんと主張できること。
  ・相手軸
   相手の立場に立って、物事を考えること。
  ・幽体離脱軸
   一歩引いて、自分軸と相手軸のバランスを上手く取ること。
 ◇今後の企業の方向性
  ・していこと
  ・すべきこと
  ・できること
 ◇考え方
  ・結論を明確にする。
  ・その結論のための根拠を用意する。
  ・結論と根拠が事実に基づき、納得できる関係にある。
 ◇3C
  ・Customer→顧客・市場
  ・Competitor→競合
  ・Company→自社
 ◇4Pのうちの3P
  ・Product→商品
  ・Price→価格
  ・Promotion→販売促進
 ◇ロジックツリー
  ・Whyツリー
   「なぜ?」ということを考えるときに使う。
   問題から原因を探る。
  ・Howツリー
   「どうやって?」ということを考えるときに使う。
   課題から解決策を導く。
  ・Whatツリー
   「それって何?」ということを考えるときに使う。
   構成要素の分解に使う。
 ◇自己紹介
  ・仕事関係
  ・家族関係
  ・趣味関係
 ◇自己アピール1
  ・長所
  ・短所
  ・トータルの自分
 ◇自己アピール2
  ・自分が思う自分(自分軸)
  ・他人が思う自分(相手軸)
  ・未知の自分(俯瞰軸)
 ◇結婚式のスピーチ
  ・新郎の職場
  ・新郎の仕事ぶり
  ・新郎と新婦の出会い
 ◇提案
  ・Why、なぜこの企画が必要なのか
  ・What、企画の内容は何なのか
  ・How、どのような実行プランがいいのか
 ◇プレゼンスキル
  ・プレゼンス
  ・シナリオスキル
  ・デリバリースキル
 ◇PREP法
  ・Point→結論
  ・Reason→理由
  ・Example→事例
  ・Point→結論
  
 
 
 
 

定量的品質予測のススメ

評価:
---
オーム社
¥ 1,200
(2008-10)
コメント:ソフトウェア品質の測定方法がよくまとまっている。

JUGEMテーマ:読書 

品質とは
    ISO/IEC9126
        信頼性
        保守性
        移植性
        効率性
        機能性
        使用性(ユーザビリティ)
    特性群
        副特性
        機能特性
        非機能特性
品質予測
    要求分析・設計
    プロダクト
    プロジェクト

品質管理単位
    ソフトウェアシステム
    サブシステム
        100KL〜300KL
        母体規模に依存
    業務機能
        数KL〜10KL
        階層構造を取ることもある
    プログラム
        100L〜1KL
        I/Fクラスの管理は工夫要

測定量
    全工程
        規模
            FP
            LOC
        作業工数
            人数×時間
    設計工程
        レビュー回数
        レビュー工数
        レビュー対象規模
        レビュー指摘件数
        レビュー指摘密度
            指摘件数/規模
        レビュー工数密度
            工数/規模
        レビュー指摘効率
            指摘件数/工数
    テスト工程
        欠陥数
        欠陥密度
            件数/規模
        テスト項目
        テスト密度
            項目数/規模

測定モデル
    閾値モデル
        標準値から外れたものを見直す
    ゾーンモデル
        標準ゾーンから外れているものを見直す
    関数モデル
    トレンドモデル

定量的品質予測のススメ

システム開発現場のファシリテーション ~メンバーを活かす最強のチームづくり~

評価:
新岡 優子/前川 直也/西河 誠/小田 美奈子/上田 雅美
技術評論社
¥ 1,869
(2008-01-30)

JUGEMテーマ:読書

■ファシリテーションとは
 「俺についてこい」的アプローチではなく、メンバ一人一人の強み弱みを理解し、
 メンバ同士の相乗効果を引き出しながら、チームの目標達成活動を支援するアプローチ
 である。

 □チームの協働プロセスに責任を持つ
  チームは、形成期(Forming)→混乱期(Storming)→規範作り(Norming)を
  経てようやく機能を開始する(Performing)に達する。

 □メンバ同士による相乗効果を引き出す
  1対NからN対N型のコミュニケーションへ移行させていく。

 □チームの目的達成を支援・促進する
  チームは自ら問題を解決する能力を持っている。

 □フェアな立場でチームに働きかける
  判断や処理が偏らないようにする。

■最高のチーム作りのための5つのステップ
 1.信頼関係を作る
 2.情報の共有
 3.学び合う風土、相互サポート
 4.コミットメント
 5.勇気とサポート

■見える化
 □ソフトウェアかんばん
  ToDo、Doing、Done
  プロジェクトのリズムを一定にしてから見える化する
  リーダが指示するのではなく、全員でタスクを考える

 □KPT
  短時間でやる
  PDCAの実践

■ファシリテーショングラフィック
 「ファシリテーション・グラフィック−議論を「見える化」する技法」参照


search this site.
categories
archives
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
<< June 2018 >>
Amazon
selected entries
recent comment
recent trackback
links
profile
others
mobile
qrcode
sponsored links
counter
ブログパーツUL5
ranking

にほんブログ村 本ブログ ビジネス書へ

powered
無料ブログ作成サービス JUGEM