プロジェクトマネージャ★17
952 ：名無し検定１級さん：2013/07/10(水) 10:22:49.63
952
>>951
載ってるよ。でもとてもマニアックな内容で一般への流用は困難です。
載ってるよ。でもとてもマニアックな内容で一般への流用は困難です。
>>953
そうなのか＾＾ｗ
そうなのか＾＾ｗ
そういや会社の同僚や上司、もしくは後輩に
論文添削してもらう人いるの？
資格の勉強は公にせず、コソコソやるもの？
論文添削してもらう人いるの？
資格の勉強は公にせず、コソコソやるもの？
>>957
なんなのお前
なんなのお前
959 ：名無し検定１級さん：2013/07/13(土) 10:35:58.53
>そういや会社の同僚や上司、もしくは後輩に
>論文添削してもらう人いるの？
そんな風土のあるある会社なんてそうそうないと思うし、
そんな力量のある同僚や上司、もしくは後輩もそうそういないと思う。
>論文添削してもらう人いるの？
そんな風土のあるある会社なんてそうそうないと思うし、
そんな力量のある同僚や上司、もしくは後輩もそうそういないと思う。
960 ：名無し検定１級さん：2013/07/13(土) 10:45:00.93
今回のPMも合格者は1485名。もちろん累計だとそれなりの数いるわけですが、
論文添削を頼める人が身近にいるっていうのは、
よほど運の良い場合でしょう。
論文添削を頼める人が身近にいるっていうのは、
よほど運の良い場合でしょう。
ＰＭ合格者って直近１０年くらいだと累計１万人くらいでしょ。
その内、東京大阪に半数として、残りを５０で割ると１県１００人。
その１県の中で、市区町村が１０個あったとして、市区町村でたった１０人。
東京大阪は別として、地方なら結構貴重な存在。
さらにその中で他人の論文をまともに「評価」できる人は限られる。
その内、東京大阪に半数として、残りを５０で割ると１県１００人。
その１県の中で、市区町村が１０個あったとして、市区町村でたった１０人。
東京大阪は別として、地方なら結構貴重な存在。
さらにその中で他人の論文をまともに「評価」できる人は限られる。
自分流で生き抜いてきたPMが多い会社だと、
PM試験勉強してるって言うと、そんなの意味がないと熱く指導されるレベル
PM試験勉強してるって言うと、そんなの意味がないと熱く指導されるレベル
文章が書けるってことだけの証明にはなるな。その程度っておもてていいでしょか
そんなことはないが中小企業のピーキーなPMではなく
大企業の平均的に規格化されたPMを作るための試験。
大企業の平均的に規格化されたPMを作るための試験。
965 ：名無し検定１級さん：2013/07/14(日) 12:12:55.19
962、964の意見は正しいと私も思う。
また、なんかあやしげな資格制度が企てられている。
http://www.ipsj.or.jp/topics/ITshikaku.html
こんなことに協力している企業は情報処理のPMも
それなりに評価していると思う。
>文章が書けるってことだけの証明
かもしれませんが、金さえ入れこめばいつでも受験できる試験より、
1年に1回しか受験できない試験のほうが価値があるとおれは信ずる。
ほぼ丸暗記で合格するベンダ系の資格より、文章を書かせる情報処理試験のほうが
価値があるとおれは信ずる。
拡販目的で誰でも合格させるベンダ資格より、合格率を抑えている
情報処理試験のほうが価値があるとおれは信ずる。
また、なんかあやしげな資格制度が企てられている。
http://www.ipsj.or.jp/topics/ITshikaku.html
こんなことに協力している企業は情報処理のPMも
それなりに評価していると思う。
>文章が書けるってことだけの証明
かもしれませんが、金さえ入れこめばいつでも受験できる試験より、
1年に1回しか受験できない試験のほうが価値があるとおれは信ずる。
ほぼ丸暗記で合格するベンダ系の資格より、文章を書かせる情報処理試験のほうが
価値があるとおれは信ずる。
拡販目的で誰でも合格させるベンダ資格より、合格率を抑えている
情報処理試験のほうが価値があるとおれは信ずる。
俺はとりあえず資格を取って、
「資格なんて関係ないよ」とサラりと言うために頑張ってる。
「資格なんて関係ないよ」とサラりと言うために頑張ってる。
頑張っちゃうとそうは言えなくなる
だから適当にやりなさい
だから適当にやりなさい
968 ：名無し検定１級さん：2013/07/15(月) 21:27:28.81
>965
ベンダー試験、オラクルゴールド持ってる奴でしょーもない奴を思い出したw
本稼働してから、とある１つの遅いSQLについてのチューニングを至急行なわ
ねばならない状況なのだが、開発陣がバグ対応で火の車だったため、
そこで助っ人として白羽の矢が立ち参加することとなったA君。
開発経験は皆無だがDBAとしてDB管理は非常に得意。SQLも当然余裕。
A君にいきなり「勝手に調べてチューニングして」っていうのもあれだから、
まずはSQLをプリントアウトしてPJリーダの私とA君で机上で話をした。
そしたら、100件程度しかないマスタに関するwhere区を発見するや
「うわ〜 not in 使っちゃってるわ〜」といかにもしてやったりの表情w
続けて「この書き方だとインデックス効かねーんでねーの！？」と
LIKEの頭に％が書いてる部分を指摘w
（うん、そりゃ効かねーよ。でも業務要件だから止むを得ないし、それも
件数が少ないマスタだからそれでいいんだよ。）
次に実行計画を見たいと言うもんだからプリントして持ってったら
「あー、やっぱFULL ACCESSになっちゃってるわ」などの指摘w
じゃなくて、売上明細テーブルっていう見るからに怪しいのがあって
件数も10万件超えてんだし、そこ自体か、そのテーブルと結合してるところを
中心に話をしたかったわけなのだが以下略w
ベンダー試験、オラクルゴールド持ってる奴でしょーもない奴を思い出したw
本稼働してから、とある１つの遅いSQLについてのチューニングを至急行なわ
ねばならない状況なのだが、開発陣がバグ対応で火の車だったため、
そこで助っ人として白羽の矢が立ち参加することとなったA君。
開発経験は皆無だがDBAとしてDB管理は非常に得意。SQLも当然余裕。
A君にいきなり「勝手に調べてチューニングして」っていうのもあれだから、
まずはSQLをプリントアウトしてPJリーダの私とA君で机上で話をした。
そしたら、100件程度しかないマスタに関するwhere区を発見するや
「うわ〜 not in 使っちゃってるわ〜」といかにもしてやったりの表情w
続けて「この書き方だとインデックス効かねーんでねーの！？」と
LIKEの頭に％が書いてる部分を指摘w
（うん、そりゃ効かねーよ。でも業務要件だから止むを得ないし、それも
件数が少ないマスタだからそれでいいんだよ。）
次に実行計画を見たいと言うもんだからプリントして持ってったら
「あー、やっぱFULL ACCESSになっちゃってるわ」などの指摘w
じゃなくて、売上明細テーブルっていう見るからに怪しいのがあって
件数も10万件超えてんだし、そこ自体か、そのテーブルと結合してるところを
中心に話をしたかったわけなのだが以下略w
クエリの実行時間は小さな問題のある書き方の累積の結果でもあるわけで、
そういうアプローチもアリだとは思うけどね
売上げ明細の件数増加とかは誰しも経験してるんだろうなあ
計算を楽にしようと、売上げ伝票テーブルとかに明細の合計金額を残したりすると、
数字を二つもつのでバグの温床になったり、プログラムが複雑になったりするし
viewを作って対処すると結構速いんだけどね
そういうアプローチもアリだとは思うけどね
売上げ明細の件数増加とかは誰しも経験してるんだろうなあ
計算を楽にしようと、売上げ伝票テーブルとかに明細の合計金額を残したりすると、
数字を二つもつのでバグの温床になったり、プログラムが複雑になったりするし
viewを作って対処すると結構速いんだけどね
971 ：名無し検定１級さん：2013/07/15(月) 22:22:35.75
>969
合計値で思い出したけど、経験浅い奴でいまだによく遭遇するのが
「正規化厨（ちゅう）」
情報処理試験受けてれば非正規化って常識だと思うが、
正規化が最終形で、そのように極力すべきと思っている奴がいる。
正規化は確かに素晴らしいと思うが、
正規化した場合の利点と欠点を骨身にしみてわかってる奴が少ない。
合計値で思い出したけど、経験浅い奴でいまだによく遭遇するのが
「正規化厨（ちゅう）」
情報処理試験受けてれば非正規化って常識だと思うが、
正規化が最終形で、そのように極力すべきと思っている奴がいる。
正規化は確かに素晴らしいと思うが、
正規化した場合の利点と欠点を骨身にしみてわかってる奴が少ない。
>>971
理想としては正しいと思うよ→正規化
ただ、もし正規化せず値を2重に持つのなら、ストアドやプログラム側で対処するのではなく、
トリガーを設定して編集時に自動的に値が更新されるような方法にするべだと思う
あと、サーバの性能向上などで可能になってきている部分もあるしね
理想としては正しいと思うよ→正規化
ただ、もし正規化せず値を2重に持つのなら、ストアドやプログラム側で対処するのではなく、
トリガーを設定して編集時に自動的に値が更新されるような方法にするべだと思う
あと、サーバの性能向上などで可能になってきている部分もあるしね
973 ：名無し検定１級さん：2013/07/15(月) 22:31:19.19
>970
うーん、どうだろう。
あのままPJに入ってたら机の位置的に周りに聞こえるように
「これじゃインデックス効かねーよ」とか言い出して、
周りの開発陣と険悪な関係になったと思うよ。
開発陣だってそんなこと常識で知ってて、結果そうなってんだからw
開発陣もそういう無知な奴に対して、軽くたしなめてりゃいいものを
いきなり対決モードで対峙しがちだからね。
本番バグ対応で殺気立ってるから気持ちはわかるけどね。
うーん、どうだろう。
あのままPJに入ってたら机の位置的に周りに聞こえるように
「これじゃインデックス効かねーよ」とか言い出して、
周りの開発陣と険悪な関係になったと思うよ。
開発陣だってそんなこと常識で知ってて、結果そうなってんだからw
開発陣もそういう無知な奴に対して、軽くたしなめてりゃいいものを
いきなり対決モードで対峙しがちだからね。
本番バグ対応で殺気立ってるから気持ちはわかるけどね。
974 ：名無し検定１級さん：2013/07/15(月) 22:45:15.90
トリガーはいいね。
あんまりメジャーじゃないけど、あれってある意味最強の共通化だと思うな。
開発チーム要員にその存在をしっかり伝えることを忘れずにだけど。
意外と知らない奴が多くて、後から入ったBPがその存在忘れがちで
バグ生んだりデグレしたり、ちょっと厄介な感じもするが。
合計値算出とかその程度のことにとどめて置かなかったのも悪いかもな。反省。
あんまりメジャーじゃないけど、あれってある意味最強の共通化だと思うな。
開発チーム要員にその存在をしっかり伝えることを忘れずにだけど。
意外と知らない奴が多くて、後から入ったBPがその存在忘れがちで
バグ生んだりデグレしたり、ちょっと厄介な感じもするが。
合計値算出とかその程度のことにとどめて置かなかったのも悪いかもな。反省。
あいちぃ業界ってそういう子供大人のヒト多いイメージはあるな。
A君がまだ２５より前なら許せなくもなくもないが。
A君がまだ２５より前なら許せなくもなくもないが。
いまどき入出力は、すべてストアド経由でしょ？
だったら、バグというからにはコーディングするPG開発チームの話だと思うので、
デクレたりバグの温床にはならないと思うけど
合計値に関してもviewで作成しとけば、過去の未更新部分の合計値に関しては
キャッシュとして残して計算が速くなるよう最適化しているから問題ないと思うけどね
プログラム中にクエリを記述して発行しているのなら別だけどさ
だったら、バグというからにはコーディングするPG開発チームの話だと思うので、
デクレたりバグの温床にはならないと思うけど
合計値に関してもviewで作成しとけば、過去の未更新部分の合計値に関しては
キャッシュとして残して計算が速くなるよう最適化しているから問題ないと思うけどね
プログラム中にクエリを記述して発行しているのなら別だけどさ
977 ：名無し検定１級さん：2013/07/15(月) 23:05:38.67
>976
それってクラサバ型２層の場合じゃない？
それなら共通化目的でストアド経由ってのもわかる。
それ以外の構成なら逆にストアドはあんま使わないかな。
Web でサーバサイドjavaなら、サーバで動くからストアドにしなくても
いいよ的な。DBサーバ別立てなら話は変わってくるが。
それってクラサバ型２層の場合じゃない？
それなら共通化目的でストアド経由ってのもわかる。
それ以外の構成なら逆にストアドはあんま使わないかな。
Web でサーバサイドjavaなら、サーバで動くからストアドにしなくても
いいよ的な。DBサーバ別立てなら話は変わってくるが。
プログラムの中でSQLを記述してクエリ発行してんだ
web系だけど完全に分離してるよ
データベースとの入出力はストアドだけ→DB層
入力→入力チェックやデータ表示時の加工、ストアドの呼び出し→入力用クラスを作成→ファンクション層
出力→出力加工には主にviewの利用→ファンクション層
htmlなどの表示部分→プレゼン層
サーバ別立てだとSQL発行ぶんのトラフィックが少なくなるからという意味だと思うけど、
そういう意味じゃなくてバグの温床や手戻り、修正の手間になるから完全分離
何らかのビジネスロジックの変化があっても、viewやストアドの変更で済むので
入出力の項目が変わらない限りDB側の修正で済む
web系だけど完全に分離してるよ
データベースとの入出力はストアドだけ→DB層
入力→入力チェックやデータ表示時の加工、ストアドの呼び出し→入力用クラスを作成→ファンクション層
出力→出力加工には主にviewの利用→ファンクション層
htmlなどの表示部分→プレゼン層
サーバ別立てだとSQL発行ぶんのトラフィックが少なくなるからという意味だと思うけど、
そういう意味じゃなくてバグの温床や手戻り、修正の手間になるから完全分離
何らかのビジネスロジックの変化があっても、viewやストアドの変更で済むので
入出力の項目が変わらない限りDB側の修正で済む
980 ：名無し検定１級さん：2013/07/17(水) 20:38:40.94
977です。
確認してみたら、SQLはコンパイル不要の
htmlとかの静的なフォルダに入ってた。
ストアドではないけど似たようなもんかな。
確認してみたら、SQLはコンパイル不要の
htmlとかの静的なフォルダに入ってた。
ストアドではないけど似たようなもんかな。
低層の話したけりゃ、APスレとか行けば？
アーキテクトでもなければプロマネでもないな
出直すよろし
出直すよろし
プロマネは低層の話に口出すなよ！
プロマネは黙って進捗管理作業だけしろよ！
低層の内容すら十分に理解できてないプロマネが現場の
作業方式に口出すと現場が混乱するんだよ！
間違った方法で作業するように強制するし
間違い指摘するとキレるし
間違い指摘しないで放置して(予測していた)障害が発生してもキレるし
プロマネなのにWBS管理しないから
WBS作成と顧客への進捗メール俺がやらなきゃならないし
顧客との調整はやってくれるけど、「ミーティング内容はお前ら知る必要がない」って
メンバに共有しないから、お前が顧客調整すると情報が阻害されてかえって邪魔なんだよ！
プロマネは黙って進捗管理作業だけしろよ！
低層の内容すら十分に理解できてないプロマネが現場の
作業方式に口出すと現場が混乱するんだよ！
間違った方法で作業するように強制するし
間違い指摘するとキレるし
間違い指摘しないで放置して(予測していた)障害が発生してもキレるし
プロマネなのにWBS管理しないから
WBS作成と顧客への進捗メール俺がやらなきゃならないし
顧客との調整はやってくれるけど、「ミーティング内容はお前ら知る必要がない」って
メンバに共有しないから、お前が顧客調整すると情報が阻害されてかえって邪魔なんだよ！
てか、隣の席で愚痴いうの辞めてくれる？
仕様変更したんだから、コストが増加がするのは当たり前だろ！
バカの一つ覚えじゃねぇんだから、QCDばっか連呼すんなよ！
「私はQCDの全てにおいて最高を目指します」って、ばかじゃねぇの！
常識的に考えてQCD(+ｽｺｰﾌﾟ)はそれぞれトレードオフの関係だろ！
QCDはプロジェクトの制約条件の中で最適解を求めるものだろ！
40超えたいい年してプロジェクトの基本も理解してねぇのかよ
（しかもお前プロパー社員だろ！）
「この判断は、私の経験に基づいています」って言ってるけど
経験だけを頼りにに判断されても困るんだけど…
PMBOKが最良の方法ってわけじゃないけど
お前のKKDよりはマシだよ
仕様変更したんだから、コストが増加がするのは当たり前だろ！
バカの一つ覚えじゃねぇんだから、QCDばっか連呼すんなよ！
「私はQCDの全てにおいて最高を目指します」って、ばかじゃねぇの！
常識的に考えてQCD(+ｽｺｰﾌﾟ)はそれぞれトレードオフの関係だろ！
QCDはプロジェクトの制約条件の中で最適解を求めるものだろ！
40超えたいい年してプロジェクトの基本も理解してねぇのかよ
（しかもお前プロパー社員だろ！）
「この判断は、私の経験に基づいています」って言ってるけど
経験だけを頼りにに判断されても困るんだけど…
PMBOKが最良の方法ってわけじゃないけど
お前のKKDよりはマシだよ
>>980
クエリを別ファイルに書いて、それを呼んでるだけじゃね？
ストアドの場合は返値も戻せるからちょっと違うかな
可能ならストアドですべてやるのがベスト
ビジネスロジック層の90%以上はストアドかviewで記述する
クエリを別ファイルに書いて、それを呼んでるだけじゃね？
ストアドの場合は返値も戻せるからちょっと違うかな
可能ならストアドですべてやるのがベスト
ビジネスロジック層の90%以上はストアドかviewで記述する
ん？どうした？
987 ：名無し検定１級さん：2013/07/18(木) 07:19:30.56
988 ：名無し検定１級さん：2013/07/18(木) 09:17:24.54
システム監査技術者ですが、何か？
あげ
あげ
あげ
あげ
あげ
995 ：名無し検定１級さん：2013/07/18(木) 16:53:10.92
埋め
あげ
997 ：名無し検定１級さん：2013/07/18(木) 16:54:50.94
埋め
あげ
100get
あげ
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。