メモ

３０万部を超えるベストセラー「残念な人の思考法」の著者・山崎将志氏の説 ○分かれ道は優先順位！？ →作業量は一緒でも優先順位で結果は変わる ○「残念な人」は「できる人」になれる！ ○「残念な人」は必要！？ →「できる人」に思いやりの気持ちが生まれる ※「できる人」ばかりではギスギスするので、山崎将志氏が関わる組織では、　５人に１人は「残念な人」を入れる

●「残念な人」脱却法のポイント ○所要時間の把握 ○「間」の時間の活用

副問い合わせ(EXISTS)を使った更新(UPDATE)の注意売上取り消し処理が遅いということで調査していたのですが、構文をみても単純である為、なかなか気がつきませんでした。

結局遅い原因として、副問い合わせ(EXISTS)を使った更新
(UPDATE)において、EXISTSの中に結合条件以外に外側の条件を含めていたため、処理に時間がかかっていたようです。

これにより、別の処理含めても1分→5秒になりました。作成時は件数が少なかったので気が付かなかったのかも知れませんが、反省を含めて掲載しておきます。

ちなみに私が作成したわけではないですが、すぐに気が付かなかったという点では知識不足だったわけです。 UPDATE T_JUCHU_H JH
SET

KANRYO_KBN = '0'      <FONT color=#006400>-- 完了区分 0:未完了　1:完了</FONT>\\

WHERE

  EXISTS  (\\
      SELECT 1\\
      FROM   T_URIAGE_M UM\\
WHERE  UM.JUCHU_NO  = JH.JUCHU_NO\\
  　AND   UM.JOTAI_KBN  = '0'\\
  <FONT color=#006400>--   AND JH.JOTAI_KBN = '0';  ←　EXISTS の中にあると遅い\\

)
AND JH.JOTAI_KBN = '0';　←　EXISTS の外にすることで速くなった 一応Oracleですが、他のＤＢでも同じだと思うので気をつけましょう。

追記：情報が不足してました。
インデックスは、JH.JUCHU_NOのみ、UM.JUCHU_NO と　JOTAI_KBN はありません。実行計画
consistent gets：SELECT(FOR UPDATE句有り)文　実行時のデータ要求
これ以外の項目はほぼ同じ値 EXISTS内： consistent gets 11657696
EXISTS外： consistent gets 1070

進行を妨たげる人に対処する日経SYSTEMSを定期購読しているのですが、２００７/８号の
現場で役立つ実践会議術　第５回進行を妨たげる人に対処する
「演説、敵対、屁理屈、沈黙　困った人へのアプローチ」でした。
少し古い記事ですが会社にあれば読んでみて下さい。
<A href=“http://www.nikkeibpm.co.jp/cs/mag/it/nos/index.html”>http://www.nikkeibpm.co.jp/cs/mag/it/nos/index.html</A>

・「演説系」への対処法

意見を褒めたたえながら、話の腰を折る
「演説系」の人は総じて、人に認められたいという欲求が強いので、
褒めたたえながら話の腰を折るようもっていく。

・「敵対系」への対処法

人同士ではなく意見の対立に転換する
感情的対立は、その場では解消しにくいので、感情的にではなく、論理的な理由
があって意見が対立している別の人に話を振り、議論の矛先を変えてみる。

・「屁理屈系」への対処法

意見を評価したうえで、冷静にジャッジ
「屁理屈系」の人は、プライドが高く論理に強いことが多いので、視点の鋭さを
褒めたうえで、その人の意見については、議論する必要性が乏しいことを
論理的な理由を付けて指摘するとよい。

・「沈黙系」への対処法

議論と仕事の接点を示し、思考を促す
意欲が足りないと決め付けるのではなく、スキル不足と考えて、
議題や出された意見が相手の仕事にどう関係するのかを具体的に示し、
思考を支援する。

タコ調べタコ：<A href=“http://blogs.wankuma.com/rti/archive/2008/05/07/136646.aspx”>http://blogs.wankuma.com/rti/archive/2008/05/07/136646.aspx</A>　　　　　
気になったので勝手に調べちゃいました。ネット調べなので正しいかは不明･･･ ■タコ(蛸)
海洋性の足をたくさん持った軟体動物、足袋の「タ」で足のことであり、
骨がなくて柔らかいナマコの「コ」を取り、タコとした。 ■形から由来
・タコ(凧)
蛸の干物をつくるときに足をひろげた形に由来する
語源：凧を「タコ」と呼ぶのは関東方言で、関西方言では「イカ」と呼ばれた。
　　　　
・３タコ　
三振のこと、およびノーヒットの事
坊主の頭が丸い＝ゼロから派生したと思われる。 ・たこ坊主
頭の様子から坊主をさげすんでいう語、坊主を馬鹿にした呼び名 ・何言ってんだ。このタコ
出来の悪い人をののしること、たこ坊主からきていると思われる。
ボウズと言う言葉を悪い意味で使うとスベルとかゼロの意味があります。 ■胼胝から由来
・タコ(胼胝)
皮膚の角質層が肥厚した状態 ・耳たこ
耳にたこができるという慣用句の略、同じことを何度も言われてうんざりするさま。　
語源としては、胼胝（たこ）からきている。 ■複数あることから由来
・タコ殴り
ひとりの手がたくさんあるかのように次々となぐりつける意味 ・タコ足配線
タコの足のようにコードが四方八方にのびている配線 ・ちゅうちゅうたこかいな
一種の数え歌、８と言えばタコの足の本数

■自分の足を食うことから由来
(生き物のタコは空腹になると自分の足を食べてしまうことから
「自滅的行為」をタコというようになり、さらに派生して
「失敗する」という意味にも使われる。) ・タコは身を食う
自分の財産を食いつぶすことの例え ・タコ配(株式用語)
配当可能な利益が出ていない悪い決算なのに、配当すること。 ■その他から由来
・タコメーター
回転速度計(tachometer)
タコ(tacho)とは速度を意味するギリシャ語のtakhosに由来する。 ・タコ部屋
強制収容所？、他雇(他所から雇われてきた人)からきている？

■動詞的な使用
・タコる
1.「さぼる」を「たこる」と言う静岡方言
2.「失敗する」などの意味
3.気に入らない人間を殴ったり、蹴ったりしてボコボコにしてしまう事

■Linuxの世界での用語
・「初心者、未熟な」という意味で使われる
場違いな未熟者と蔑称に近い意味(タコ坊主から派生と思われる)
したが、自助努力で頑張る初心者たちのことを、一種の愛情を
込めて「タコ」と呼ぶようになった。

技術伝承の断絶が招く危機 IT業界は技術の変化が早いです、せっかく覚えた技術も陳腐化
してしまうことも多々あります。
ですが、ベーシックなところはほとんど変わらないですよね。 IT業界は他の業界と比べても、技術に関する書籍が多いことや
グーグルなどの検索により情報が得やすい環境にあります。
それにより知識に関しては伝達することは出来ますが、一方、
技能(スキル)について知識を駆使して作業を遂行する能力であり、
伝達することが難しいところです。
実体験しないとなかなか覚えない、失敗してこそ覚えたりする。現状、各個人の勘や経験に頼っていることが多いかと思います。
その場合、「技術は盗め」となるわけですが、はたしてスピード
重視の世界でそんな悠長な事を言っている場合では無い･･･
はずです。会社内のコミュニケーションを円滑にして知識の蓄積と共有化する
システムを作り、全体のレベルを上げる体制を作るようにすることが
理想なのですが、現実は仕事に忙殺され、回りのことなどかまって
られないとこでしょうか、
それでも、伝えるための地道な努力を惜しんでなりません。GIVE５乗 勝手に添削 - 技術の盗み方
<A href=“http://blog.livedoor.jp/dankogai/archives/50826413.html”>http://blog.livedoor.jp/dankogai/archives/50826413.html</A>
設計時の見落とし－Google先生も教えてはくれない
<A href=“http://blogs.wankuma.com/yaju/archive/2008/04/07/131967.aspx”>http://blogs.wankuma.com/yaju/archive/2008/04/07/131967.aspx</A>

本題：
日経SYSTEMSを定期購読しているのですが、２００７/８号は
特集１「あなたにも出来る技術伝承　勘と経験の残し方」でした。
少し古い記事ですが会社にあれば読んでみて下さい。
<A href=“http://www.nikkeibpm.co.jp/cs/mag/it/nos/index.html”>http://www.nikkeibpm.co.jp/cs/mag/it/nos/index.html</A> もしその技術が伝わっていたら、プロジェクト遅延やコスト超過
システムの障害発生などの重大なトラブルの裏には、技術伝承の
失敗が隠されていることは少なくないはずです。 技術伝承の断絶が招く危機 ■上流工程
・現状把握　→　問題の洗い出しに漏れが生じる
・要件定義　→　ユーザーの要求が取り込めない
・外部設計　→　後工程で作業の手戻りが発生
・説明・交渉　→　費用負担を巡りユーザーとの関係が悪化 ■実装/運用
・技術問題の解決　→　解決に時間とコストがかかる
・プログラム実装　→　性能要求を満たせず。メンテナンス性が低下
・テスト　→　テストが不十分になる。カットオーバー後に発生
・障害の切り分け　→　復旧が遅延。場合によっては障害が再発 ■プロマネ
・スケジュール管理　→　プロジェクト完了の見通しが立たなくなる
・リスク管理　→　作業が遅延。予期しないコストが発生
・品質管理　→　後工程での修正となりコストが膨らむ
・危険度の推察　→　問題噴出でプロジェクトが制御不可能に

カーソル（キャレット）の幅の変更 Windowsのテキスト入力時のカーソル（キャレット）って、なんで細い線なんでしょうか。
DOSの頃のカーソルは太くて見やすかったのにって思っている方へカーソル（キャレット）の幅を変更してみてください。
やり方は↓ コントロールパネルのユーザー補助のオプション→画面タブ
カーソルのオプション→幅

業務アプリケーションで一時的に、カーソルの幅を変更したい場合
ソースコードは、VB.NET
Private Declare Function CreateCaret Lib “user32” _
(ByVal hWnd As IntPtr, ByVal hBitmap As IntPtr, _

ByVal nWidth As Integer, _\\
ByVal nHeight As Integer) As <MARSHALAS(UNMANAGEDTYPE.BOOL)>Boolean

Private Declare Function ShowCaret Lib “user32” _
(ByVal hWnd As IntPtr) As <MARSHALAS(UNMANAGEDTYPE.BOOL)>Boolean CreateCaret(TextBox1.Handle, IntPtr.Zero, 15, 15)
ShowCaret(TextBox1.Handle) 参考：
<A href=“http://hpcgi1.nifty.com/MADIA/vbnet/wwwlng.cgi?print+200805/08050013.txt”>http://hpcgi1.nifty.com/MADIA/vbnet/wwwlng.cgi?print+200805/08050013.txt</A>

Windows10のテキスト入力時の「カーソルの太さ」を変える方法 http://freesoft.tvbok.com/win10/cahnge_cursor_thickness.html Windows 7で、カーソルの幅を変更する方法について教えてください。 https://121ware.com/qasearch/1007/app/servlet/relatedqa?QID=013592

労働外時間の端数処理「和民」で賃金未払い　２１７人に１２００万円支払う
勤務時間を１分単位で記録せずに３０分単位などで端数を切り捨て、賃金の一部が未払い
<A href=“http://www.asahi.com/national/update/0531/OSK200805310109.html”>http://www.asahi.com/national/update/0531/OSK200805310109.html</A> 時間外労働は、１分単位で計算しなければなりません、３０分未満など単位で切り捨てるなどは本来は認められません。
ただし厚生労働省は、賃金計算で１ヶ月のトータルから３０分未満は切り捨て、３０分以上は切り上げるというのであれば違法としないとしています。
<A href=“http://ha6.seikyou.ne.jp/home/hanappi/hanappi009.htm”>http://ha6.seikyou.ne.jp/home/hanappi/hanappi009.htm</A> １日単位での端数処理(切り捨て)による積み上げと、月単位での合計による端数処理では、当然、金額に差が出ます。※未払い賃金の時効は２年です。 上記は時間外労働でしたが、遅刻の場合に１５分単位で切り上げされていることがあるかと思います。この場合、就業規則に遅刻によるペナルティとして、１５分未満は１５分とするような規定がなされているのであれば、この場合は問題ないと思われます。

時間外労働に入る前に休憩時間が３０分ある場合が存在します、休憩時間の長さについては、
８時間を超える場合には少なくとも６０分の休憩が必要であると規定されています。
６０分を超える休憩というのは特に問題はないですが、休憩時間が長ければ拘束時間が長くなるわけです、休憩時間といいながら仕事をしている方が多いと思われるので、会社側としたら残業賃金を減らすいい規則といった感じを私は受けますね。

年俸制であっても時間外の割増賃金の取扱いについても何ら変わるところはありません。
賃金は月払いの原則がありますので、毎月の労働時間を計算し、時間外労働が生じたならば、年俸とは別に時間外手当を支給しなければなりません。
ただし、時間外労働が毎月ほぼ一定している場合には、あらかじめ割増賃金を年俸に固定残業代として含めて支給することは認められます。
つまり想定していた残業時間以上に残業をさせた場合には、超過分については残業代支払の義務があります。

１０年間泥のように働きなさいという前に、ＩＴ業界の労働環境をまず見直すべきかと思います。
残業を減らす努力と、鬱病になる前のケアをしていなかないと人材はそっぽ向いたままです。
１０年間泥のように働くという意味はいいですが、働かされるのはまっぴらごめんです。
<A href=“http://blogs.wankuma.com/yaju/archive/2008/01/27/119418.aspx”>ＩＴ業は、うつなどメンタルな病にかかる人は他産業の10倍 </A>
<A href=“http://blogs.wankuma.com/yaju/archive/2007/09/25/97762.aspx”>目指せ！残業ゼロの現場</A>

粘菌には迷路を最短ルートで解く能力があるサイエンスＺＥＲＯを毎回楽しく見ております。
５月２４日放送のテーマが粘菌だったのですが、粘菌おそるべし
<A href=“http://www.nhk.or.jp/zero/contents/dsp210.html”>http://www.nhk.or.jp/zero/contents/dsp210.html</A>

実は粘菌には、迷路を最短ルートで解く能力があります。
<A href=“http://www.riken.go.jp/r-world/info/release/press/2000/000926/index.html”>http://www.riken.go.jp/r-world/info/release/press/2000/000926/index.html</A>

迷路のスタートとゴールに餌を置いておくと、粘菌が最短ルートを示してくれます。
原理としては、栄養を双方に送りあって、栄養が多くなれば太くなり栄養が少なければ細くなりやがては消えてしまう。
最終的に太くなったところが最短ルートとなります。
放送ではこの単純な原理をコンピュータ化し、アメリカの道路の最短ルートを解いていました。

生物から原理を学ぶことってありますよね、生物というのは何万年？もかけて進化してきてるけど、実はそんな複雑ではなく単純な仕組み、組み合わせだったりするでしょうね。
でも、その単純さを見つけるのが難しかったりします。

トラブルを最小限にする謝る技術日経SYSTEMSを定期購読しているのですが、２００８/７号は
特集２「トラブルを最小限にする謝る技術」でした。
会社にあれば読んでみて下さい。
<A href=“http://www.nikkeibpm.co.jp/cs/mag/it/nos/index.html”>http://www.nikkeibpm.co.jp/cs/mag/it/nos/index.html</A> NG!
・安易に謝らないのが得策だと考える
　(一方的、無責任に見える)
・謝ってすぐに原因や状況を説明
　(言い訳がましく見える)
・謝る相手はシステム担当者だけでよいと判断
　(トラブルの大小関係なく謝る相手の確認も必要)
・障害に関する事実確認だけに終始
　(解決策に対するユーザーの不満が噴出）　
・ユーザーの感情を逆なでする文面
　(ユーザーに責任転嫁、不快な意見を引用して反論、対応策が無い）　　
・「ユーザーがおかしい」または「すべて自分やる」が前提の解決策
　(思い込み不満を持つユーザーには無責任に見える） Good!
・謝ることを問題解決の手段としてとらえる
・謝ることに徹する
・原因を徐々に説明してユーザーの不満を軽減
　(不満を聞きながら相手の怒りを和らげる説明)
・感情を害さないように配慮した文面
　(お詫びと報告への感謝、調査協力を仰ぐ、ミスは素直に認め対応策を伝える)
・ユーザーの不満の中から事実を見極める
・障害による業務への影響度も確認
　(「いつまでかかるか」を伝える、恒久対策と併せて暫定策を示す）

発注者ビューガイドライン備忘録としてのリンク集発注者ビューガイドライン
<A href=“http://www.ipa.go.jp/sec/softwareengineering/reports/20080710.html”>http://www.ipa.go.jp/sec/softwareengineering/reports/20080710.html</A> 基本設計がなっていない
<A href=“http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=45308&forum=25&start=8”>http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=45308&forum=25&start=8</A> Visual Studioのためのテスト方法論
<A href=“http://www.microsoft.com/japan/msdn/architecture/TestingMethodologyForVSTS/”>http://www.microsoft.com/japan/msdn/architecture/TestingMethodologyForVSTS/</A> テストについてのリンク集
<A href=“http://blogs.wankuma.com/yaju/archive/2007/10/11/101281.aspx”>http://blogs.wankuma.com/yaju/archive/2007/10/11/101281.aspx</A>

ラポートトークとリポートトークデボラ・タネンという言語学者は、
『人の発言にはリポートトーク（report-talk）と、
ラポートトーク（rapport-talk）の２種類がある』と提唱しています。

ここ最近で注目されたのでは、米大統領の民主党代表選挙
オバマ氏　VS　クリントン氏　である。オバマ氏は、聞き手の側に立った「ラポート（共感・RAPORT）トーク」で展開しクリントン氏は、話し手である自分中心の「リポート(報告・REPORT)トーク」で展開した、結果はオバマ氏に軍配があがった。

ラポートトークとは、聞き手との心理的なつながり、共感関係を高めようとする情報中心の話し方で、的確で効果的な言葉の選択、繰り返し、発展、そしてそれを独特の抑揚、リズム、間の取り方で演出するというもので上手い人は、ドラマ性、物語性をもった交響曲を聴いている感じを受ける。オバマ氏は、細かいことは省き、漠然としたもの、新しい明るい未来が始まるという期待感を盛り上げ、いかに聴衆との共感を掘り起こし高揚させるかを重視していた。日本では、小泉元総理もラポートトークでしたね。アップルのジョブスも、ラポートトークによるプレゼンをしているよね。
ジョブズのプレゼンに学べ
<A href=“http://mac.ascii24.com/mac/specials/2006/10/11/665091-000.html”>http://mac.ascii24.com/mac/specials/2006/10/11/665091-000.html</A>
スティーブ・ジョブズ名言集まとめ
<A href=“http://d.hatena.ne.jp/acqua_alta/20070407/steve_jobs”>http://d.hatena.ne.jp/acqua_alta/20070407/steve_jobs</A>

リポートトークとは、客観的な事実を伝えることに重きをおく、情報中心の話し方で、聴衆の心をつかんで話さないような、印象深い言葉をほとんどなく、あるのは、自分もしくは製品が優秀で経験、実績があるかを繰り返し述べるというもの。

ラポートトークとリポートトークは、場面によって使い分ける必要がある。
ラポートトークばかりを使用していては、うさんくさいと思われるし、リポートトークばかりでは、客観的すぎて冷たく感じる。

営業する場合、製品や機能を紹介する場合は、いかに明るい未来が始まるという期待感を盛り上げるラポートトークをした後で、数値などの客観的な事実を見せて
納得させるリポートトークをすることで、お客さんの購買意欲が沸くのではないでしょうか

参考：立命館大教授　東照二　２００８０６１４静岡新聞夕刊　オバマ vs クリントン

メモ.1489508871.txt.gz · 最終更新: 2017/03/15 01:27 by yajuadmin