クリティカルシンキング
批判的思考
物事を問い直して本質を見つける思考
視点の変換
前提の変換
技法はさまざま。
書ききれないし、大切なのは考え方を知って実践することだ。
自己主張の方法
自己主張は大切である。
自分の言いたいことを言って、いいたいことを言われたら反論して、すっきりして。
自分はそれでよい。
その論が正しければもっとよい。だって自分は正しいことを証明できたのだから。周りが間違わずに済んだのだから。
………という考えは正しいだろうか？
周りには色んな人がいる。
この人は仕事が出来るけどめんどくさい。
この人はプライドが高くて話しにくい。
この人はことなかれ主義ですぐ態度が変わる。
この人は自分の意見に反論されたら、正しくても認めてくれない。
とかまあ色々思う。
この人は上手く引き出せばすごく技能を学べる。
この人は否定せず、理が通ることを述べたら味方になってくれる。
この人はことなかれ主義だけど本気で相談すればどうにか動いてくれる。
この人はそれとなく反論すれば上手く説明しながら、考慮にいれてくれる。
裏返しである。
大切なのは付き合い方だ。
付き合い方が難しい人ほど、自分が強い。
曲げれない。
正しければ何を言ってもいいのだろうか。
声を大きくして、上から論を通して、主張するのは私が「怒った」と言われるときと同じだ。私は怒っているつもりはない。でも周りは私の怒りを感じている。
強い主張は他人を圧迫することになるのだ。
正論を武器にする人にはなりたくない。
誰かの意見を素直に聞きたい。
指摘されたことを聞き入れたい。
そして自分の意見を述べたい。
今の私には相手を否定して自分の意見を述べることしかできない。
幼稚なのだ。
今は方法は分からないけど、とりあえず今日気づいたことである。
私の未来はあの付き合いにくい先輩たちなのだ。
それをちゃんと知っておきたい。
SQLの組み立て(AがあればA、なければB)
SQLの組み立てについて
SQL組み立てるときは、基本的なとこからちょっとずつ組み立てる。
考え方を覚えることで色んなことに対応できるようになるはず！と信じてメモ。
(今回の取得項目)
テーブルJの項目全て
(条件)
①テーブルHの「機械」が指定のもの 。
(テーブルHの条件)
②HとJは、「番号」で結合する。
③ただし「番号」で結合したとき、HとJは、N対1なので、以下の条件でHを一意に絞る。
④Hの「工程」が「02」で始まるものがあれば、その行を使用する。
⑤Hの「工程」に「02」で始まるものがなく、「01」で始まるものがあれば、その行を使用する。
⑥Hの「工程」に「01」「02」で始まるものがなければ、対象外になる。
これを外部結合使わずにやる。
(他にも制限あって外部結合はNGだった。)
Select ＊ from J
Where
EXISTS
(
Select ＊ from H
Where
H.番号 ＝ J.番号
AND
H.機械 ＝(画面指定のもの)
AND EXISTS
(
Select SUB.番号
From H SUB
Where
SUB.番号 ＝H.番号
AND
(工程 like ' 01%' OR 工程 like '02%' )
Having
MAX (SUB.工程)＝H.工程
GROUP BY SUB.番号
)
)
)
①Hから工程が01と02のものをとって
②番号でくくって大きい方をとって
③ひとつに絞れたのでその機械を検索条件に使い
④HとJの番号と結合してJの条件にしてやる
うろ覚えなので書き方間違えてるかも。
でも正直構文とかはどうでもよくて、「場合分け」って言うのを「大きい方をとる」って条件に考え方を変えるのがポイントかと。
ユニオンすれば私も書けたけども、それじゃパフォーマンス悪かった。
先輩が考えてくれた文のがパフォーマンスがよい。副問合せもコストはかかるけど、インデックスがうまくきいたらしい。
発想の転換と段階を踏むことが、SQLを作る上では大切らしい。
oracleバックアップ
Oracleバックアップについて
差分増分
→前回のバックアップからの増分をとる
メリット：バックアップの時間が短い。
デメリット：リカバリの時間が長い。
累積増分
→基準のバックアップからの増分をとる
デメリット：バックアップの時間が長い。
メリット：リカバリの時間が短い。
増分更新
→前回のバックアップからの増分をとり
基準のバックアップに更新する
メリット：リストアの時間が短い。
デメリット：バックアップの時間が長い。
オラクルのおすすめは増分更新。
バックアップのコマンドに「AS COPY」をつけるとイメージファイルになる。
ただし「plus archivelog」は指定できなくなる。これを指定するとアーカイブログのバックアップがとれる。
完全リカバリ
→直前のバックアップと
直前のアーカイブログを戻す。
不完全リカバリ
(最新バックアップまで)
→直前のバックアップを戻す。
不完全リカバリ
(過去の一時点まで)
→戻したい過去のバックアップと
その後のアーカイブログを任意で戻す。
RMANで制御ファイルを戻すと、次にオープンするときにリセットログを指定しないといけなくなる。
リセットログをしたら、同じ内容の別のデータベース。DBIDが違うくなる。
原価、原価、原価
原価ってのは、製品を作ったときにかかったコストのこと。
材料費と労務費と経費でまとめて原価になる。材料費と労務費と経費はそれぞれ直接と間接がある。直接材料費というと、製品の部品の費用、間接材料費というと、部品と部品をはりあわせてる塗料の費用とかそんな感じ。
営業さんとか経営者は、この原価と売値を比べてどんだけ利益が出たかを確認できる。
原価はみっつある。
実際原価：実際単価×実際所要量
→一人あたりの作業費×実際にかかった時間
＋使った材料を買った単価×実際使った量
実績原価：標準単価×実際所要量
→一人あたりの作業費×実際かかった時間
＋普段材料を買う標準単価×実際使った量
標準原価：標準単価×標準所要量
→一人あたりの作業費×作業予定時間
＋普段材料を買う標準単価×予定使用量
標準原価は予定である。
実際原価は結果である。
よって標準原価と実際原価を比べると、単純に今月この製品でどれだけ利益が出たかを知ることができる。
実績原価は比較対象である。
実際原価と実績原価の違いは、実績原価は標準単価、つまり予定の単価を使用して計算していること。
この単価のうち、労務費の方はそんなに毎月変わらない。給料が毎月昇給したりしないように、一人あたりの作業単価は月毎に変わらない。
だから、実質変わっているのは材料の買値ということになる。材料は毎月値上がりしてもおかしくない。
よって実績原価と実際原価を比べると、材料費がどれだけ予定と変わったかを見ることができる。実績原価より実際原価の方が低いときは、それだけ材料が安く仕入れられている。
実績原価と標準単価の違いは、所要量が実績か予定かというところ。
製品を作るとき、大体使用する材料の所要量は決まっている。例えば何かの不備で材料を多めに使ってしまった！いうときでも予定使用量とそこまで大差はないだろう。
あったら結構問題なのかな？その辺は予備とか不良の管理になるのだろう。
所要量で、予定と実績に差が出やすいのは人の手による作業時間である。頑張ったら1時間で終わる作業も、のらないときは3時間かかるかもしれない。
よって実績原価と標準原価を比べると、労務費がどれだけ変わったかを見られる。
実績原価が標準原価より大幅に低いなら、それは労働者が頑張ったということになる。
原価は個別品なら、一受注ごとに確認できるが、量産品なら製品ごとに確認する。
量産品はまとめて一気に作るので、１個の受注にたいしてどうこうという見方は意味がないからである。
以上先輩より｡
まとめんのに30分以上かかった。
