空配列のjsonの配列と連想配列周りの覚書
へ〜、な感じなので。
元ネタ
http://d.hatena.ne.jp/ajiyoshi/20120912/1347434440
<?php $awk = ['key' => [ 'test' => 5 ]]; var_dump(json_encode($awk)); $awk = []; $awk['key'] = array(); var_dump(json_encode($awk)); $awk = []; $awk['key'] = new arrayObject(); var_dump(json_encode($awk));
$ php t.php
string(18) "{"key":{"test":5}}"
string(10) "{"key":[]}"
string(10) "{"key":{}}"
objectキャストでもいいんだけど、もうちょっとごにょごにょしやすいように、arrayObjectつかってみますた。
これで切り替えもしやすいんじゃなかろうか？ 多分。
composerでエラーったmemo
コマンドを発行
php composer.phar update
以下のエラー
PHP Fatal error: Cannot redeclare class Symfony\Component\Console\Formatter\OutputFormatterStyle in phar:///home/vagrant/acty_server/composer.phar/vendor/symfony/console/Symfony/Component/Console/Formatter/OutputFormatterStyle.php on line 21
で、以下を使ってうまくいった。
全くもって未検証なんだけど。
何となく、APCのキャッシュが悪さをしているぽいのではなかろうか？ という話をしていた。
多分確実に脳みそから抜けるので、その前に、memo。
プリペアドステートメントとエスケープの線引き おいちゃん変
微妙にあちこち賑わっている気がしたので、なんか必要になる前に、おいちゃんの見解を。
まず前提として「適切にもちいられていない」ケースは排除。
具体的には「＊＊をやる、というルールを作っても、守られない/中途半端なら意味がない」ってのはどこにいってもどこまで行っても当たり前のお話なので。
そーゆー基本は「出来ている」前提で。
おいちゃんのスタンスは以下の通り。
・基本はプリペアドステートメントを静的に
・SQLの識別子を動的にしたい場合は「ホワイトリスト」を用意して実装(プラスしてエスケープ、はアリだと思う)
ちなみに「通常の業務やゲーム範囲程度までで、phpMyAdmin的なものは作らない」前提。
一応念のため。
んで。
やはり基本は「静的プリペアドステートメント」のほうが、単純に安心。
エスケープ処理は、まぁ九分九厘ないとは思うのですがとはいえ「実装でミスったらアウト」なので、やはり静的プリペアドステートメントのほうが有難い。
性能について、複数の角度から言及を聞いた事があるんだけど…
まず「パケット数が増える」については、増えるんだろうにしても、それは「セキュリティとトレードオフに出来る関係なのだろうか？」っていう疑問が山盛り。
逆に言うと「真剣に考えた上で、トレードオフせざるを得ないほどのアクセス数(と収益のなさ)」があるんなら、考慮してもいいと思う。
「パケット数」の亜流で「プリペアドにすると速度が遅くなる」って言ってる人を聞いた事があるんだけど、それ、逆。
そもそもプリペアドステートメントは「速度を上げるために考案された」っていう基本背景をちゃんと踏まえてないと危ない。
…まぁ、その頃の基本背景、特にWeb系だと、恩恵にあずかりにくいのは事実なんだけどさ、それにしても。
次に「SQLの実行計画的に遅くなる」についても、概ね上述と一緒。
ちなみにこのケースは「可能性としてはあるんだろうなぁ」という予想の一方で「実際には見た事がない」ので、実際の状況を目にするまでは懐疑的。
そういや余談。
「プリペアドステートメントは軽量化のためであり、しかもPHPでは軽量化の意味もあまりなく、セキュリティ的には無関係です（｀・ω・´）キリッ」とかいう寝言をほざいていた、ガラケーなシステム会社擬さんがいらっしゃいましたねぇお元気してらっしゃいますですかしらん？
Blogネタ的には、 http://d.hatena.ne.jp/gallu/20130606/p1 この辺のエントリのネタとかやらかしてくれて、大変に有難い側面のある会社様でいらっしゃいましたが。
まぁ上述諸々から、静的プリペアドステートメントが「人為的ミスの介在の余地がなくなる」ので、割と心安らかだなぁ、とか思うわけです。
「性能とのトレードオフ」については、否定はしないけど「もうちょっと別の場所で、テーブル設計とかマシンパワーとかキャッシュとかロジックとか仕様とか」でカバー出来るんじゃねぇかなぁ？ って事象ばかり見ているので、可能性としては視野に入れつつも、懐疑的。
お次。
出てくるのが「動的な識別子」と、あと結構耳にするのが「IN」。
まず動的な識別子なのですが。「パラメタの値をエスケープする」よりは「初手からホワイトリスト用意しておく」ほうが、心安らかだと思うです。
なお「ホワイトリストを用意したうえでエスケープ通しておく」ってのは、おいちゃん的にはアリ。ホワイトリストに「ついうっかり」な何かが「ゼッタイに混入しない」とも限らないよねぇ、とは思うしねｗ
ん…この辺から、実装イメージを実際に。
一番ありがちなのは「どれか一つのカラムを対象に検索」的な何か。
<form action="./find.php"> <input type="radio" name="target_col" value="hoge">hoge <input type="radio" name="target_col" value="foo">foo <input type="radio" name="target_col" value="bar">bar <br> <input name="value"><br> <br> <input type="submit"> </form>
すげぇ雑だけど。カラムhoge, foo, barがあって「どれか一つを選んで」検索する感じ。
多分、一部で言われているのは、こんなやり方。
//
$target_col = $_GET['target_col'];
$val = $_GET['value'];
//
$e_target_col = DBが提供しているエスケープ関数($target_col);
$e_val = DBが提供しているエスケープ関数($val);
//
$sql = "SELECT * FROM table WHERE `{$e_target_col}` = '{$e_val}';";ん…valueはもしかするとプリペアドかもしれない。その辺は適宜脳内補完してくださいませ。
おいちゃんが推奨するのは、雑には、こんな感じ。
// ホワイトリスト的な何か
$target_col_list = array (
'hoge' => 'hoge',
'foo' => 'foo',
'bar' => 'bar',
);
// XXX 微妙に雑なのは気にしない
$target_col = @$target_col_list[$_GET['target_col']] . '';
$val = $_GET['value'];
//
if ('' === $target_col) {
// エラー処理的な何か
return ;
}
// プリペアドステートメントの作成、だと思いねぇ
$sql = "SELECT * FROM table WHERE `{$target_col}` = :val ;";
でまぁ、こんな風に丁寧なのは、アリだと思う。
// ホワイトリスト的な何か
$target_col_list = array (
'hoge' => 'hoge',
'foo' => 'foo',
'bar' => 'bar',
);
// XXX 微妙に雑なのは気にしない
$target_col = @$target_col_list[$_GET['target_col']] . '';
$val = $_GET['value'];
//
if ('' === $target_col) {
// エラー処理的な何か
return ;
}
//
$e_target_col = DBが提供しているエスケープ関数($target_col);
// プリペアドステートメントの作成、だと思いねぇ
$sql = "SELECT * FROM table WHERE `{$e_target_col}` = :val ;";
「ホワイトリストコードん中にべた書きすんな」とかについては「サンプルコードだからそうしたけど必要に応じて適宜外にはじき出してね」って感じ。
まぁ、こんな風に「ホワイトリスト」持っていたほうが、万が一の時に「動かねぇ」のほうで気づくので、テストで洗い出せるか、でなきゃお客様の怒声で気づけるので、便利。
ちなみにINの時は、単純にforなりforeachなりで採番した :val_番号 を埋め込んで、あとでどかどかっと値をbindすりゃいいと思う。
…いやもしかしてもっと妙手妙案があるかもしれないけど、あったら教えてくださいませ(笑
んで。
「数的に少ない、レア業務」まで想定するともうちょっと色々あるような気がするんだけど。
割とあちこちに転がってるくらいの業務ゲームだと、こんな指針で今のところ困らなかったので、こんなもんじゃないかなぁ、とか思うです。
…ふと最後まで読んで気づいた「エスケープについて書いてねぇじゃん」ｗ
ん…正直、あんまり使わないので。
おいちゃん的にはこんな感じ。
・識別子を動的にする時は、慎重の上にも慎重を重ねる意味合いで、ホワイトリストに「糅てて加えて」使うのは、あり
・「速度前提に」使うのは、よっぽどの考察によりけりだけど、基本、なし
・エスケープ処理が「どんな事をやっているか」を知るのは大切だけど、基本、自分での実装はせず、提供されている関数なりAPIなりクラスメソッドなりを使う
こんな所かなぁ…うんやっぱり、使わないですむんならあんまり積極的に使う事を考えていない。
いや単純に「プリペアド一本で片付く事」が多いので、あんまりお道具にバリエーションがあっても面倒なだけだなぁ、ってのも強くて(苦笑
以上、多分「いつかどこかで、授業で使うか引用するか」な時用の覚え書きでした(笑
ルールについて
インスパイア元としてはこのあたり。
https://twitter.com/akiranakajima/status/399745448857964544
従来の条例に従うことも、条例の枠を超えて新しいチャレンジを試みることも、両方必要ということが言いたかったです。
https://twitter.com/akiranakajima/status/399780279713161217
条例破るとは一言も言ってませんので、念のため補足しておきます。
上述のやりとりそのものについては。
「条例を破らずに条例の枠を超える、とはこれ如何に？」とかいうあたりからstartがあって色々まぁ思うところもあるのですが、一端「破るとは言っていない」について、直接否定する要素もないので、件の御仁はそのような意図であろう、と推察しておきます。
ただ。
ルール…んと、法律から条令、コーディング規約や各種規則その他について
・頭から盲信して一言半句に至るまで死守
・初手から横紙破りに規則を破りまくり
って両極端が存在します。
あと、亜流として見かける
・曲解と詭弁を駆使して都合良く解釈する
ってのもあって、これも地味に(?)困りもの。
結論から書いておくと、おいちゃん的には
・ルールはその「意味」を理解するように心がける
・おかしなルールには改善を求めるけど、改善されるまでは一端従う。ただし「おかしなルールを従う事によるデメリット」は、ルールを設定した人間に支払っていただく
って感じかな。
まず「盲信組」が一定数存在して、多分単純に「思考を放棄している」んだと思う。
今まで「いい子ちゃん」だった人に多い印象。役所系とか教員系でよく見かけるかなぁ。
彼らの典型的な特徴は「なぜ」が存在しないので、割と会話にならない(苦笑
ルールって「人間が暫定的に取り決めたもの」であって、そのルールの本来の意図(哲学)が、必ずしも「十分に適切に表現できているとは限らない」ので、推敲も修正も必要になってくるんだけど。
盲信系の方々は「一言半句、聖句のごとく唯々諾々と従うべきモノ」って認識があって、故に「ルールの改善」って話をすると「ルールは絶対なのです！」で終わるから、おいちゃん的には疲れる(苦笑
「なぜこのルールが出来たのか？ その背景は？」ってのを考えると少し先に進むような気がするんだけど…どうなんだろう？
ちなみに、おいちゃんのこの辺の感覚は、法哲学をやっている友人(…最近連絡が取れてないなぁそういえば)の話を聞いて培われていったものではあるんだけど。そも、法哲学者自体、彼一人しか知らないので。あのしっかりと筋の通った考え方が「法哲学に起因する」んだか「彼自身の個体性質に起因する」んだかが不明。
ただまぁ「法の後ろにある(はずの)ちゃんとした考え方」に触れる事が出来たのは、今でも「行幸だなぁ」とは思うんだけど。
この派生で「曲解系」があって。この場合もあんまり意味のある会話が出来ないので、可能な限り会話を避ける方が正直無難。
生息区域は、見ている限りだと「べんちゃぁ()」「弁護士」あたりに多く生息しているような気がする。
なんていうか…一言で片付けると「飛蝗」。後先考えずに、後は野となれ山となれ的に「その場所を食いつぶしながら」進んでいく手合いに多いかなぁ。
最後に、まだ気持ちがわからんではないんだけど一番危ないのが「おかしなルールなんだから従う必要などない！」って発想と言動。
多分、baseになっている気持ちにも２種類あって「危機感から、調整をする前にまず動いてしまう」と「既成事実で押し通す予定で手続きを無視する」の２系統。
後者はどっかの通販とかどっかの図書館とかで、あれはゴリ押しの典型なので、一端放置。
結構色々な角度で困るのが「憂慮した結果として早まった行動をしてしまう」ケース。
気持ちがわからないではないんだけれども
・まず、向かっている先が「正解」なのかが不明
・向かっている「正解」が「継続可能」なのかが不明( http://d.hatena.ne.jp/gallu/20120412/p1 )
・「ルールを悪用したり現状維持で改悪したい人たち」へのよい攻撃口実を与えてしまう
などなど、さりげに問題が山積してたりする。
勿論、考察が正しいと仮定すると「そのルールを運用している１分１秒ごとに損失が積み重なる」のは事実だろうし、その損失は場合によっては「リカバリ不能で致命的なダメージになる」可能性ってのは、あるんだけど。
基本的には、そのダメージを背負うのは「その現場を持っている人たち」であるはずで、うちらではないはずなので。
一端、警告と忠告はするにしても、そこで変わらなければ「沈む事を許容しているのであろう」で、見放してしまうのが一番よいと思うのですよ。
下手に中途半端に手を出して
・その介入によって致命的な事象が避けられ
・かつあくまで「致命的な事象が避けられただけなので」一定の損害が出た
場合。
彼らは「致命的な事象はそもそも発生する事などありえず、余計な介入によって損害がでたのだからお前が損害を補償しろ」とか言い出しかねないので。
いやマジで。
あと、別角度からいくといずれにしても「相談可能な人*1」に一度、相談をしてみた方がいいとも思う。
例えば、よい解決策は実は「維持コストが高いとかいう理由で見送られている」可能性だってあるので。
まぁそんなこんなで。
結論としては。おいちゃんは
・ルールはその「意味」を理解するように心がける。そうしないと、判定基準がわからないから
・おかしなルールには改善を求めるけど、改善されるまでは一端従う
・改善に対して明らかに「馬耳東風」な場合、無言かつ全力でその場を去る
って感じになるわけなのですね。
…実際、去った現場について、風の噂その他を聞く限り「予想通りの動きと問題とトラブルが発生している」ので、まぁ「予想って案外と裏切らないもんだなぁ」とか思うことしきり。
まぁ、その問題発生も彼ら的には「望み選んだもの」だと思うので、部外者となった人間がとやかくいうもんでもないだろうしなぁ。
せいぜいが「巻き込まれたくはないし二度とご一緒したいとも思わない」って程度で B-p
この辺の「ルールに対するスタンス」って結構考察として面白いと思うので、現時点での考察をメモり。
*1:いれば
あんまり巧みに口が上手くてもねぇ…
さて http://d.hatena.ne.jp/gallu/20131104/p1 で書いておいてあっさりと反証ｗ
インスパイア元
https://twitter.com/toronei/status/394770706023452672
http://blog.tatsuru.com/archives/001425.php
端的には「スジの悪い相手とはあんまりつきあわない方が良いよ」ってあたり。
まぁ身もふたもないｗ
https://twitter.com/toronei/status/394770706023452672
まあ若い頃から成功した頭が良すぎる人は、「言論は内容が正しければ勝てる」と本気で思ってる人が多いわな。で、「お前は態度が悪い」と話し聞いてもらえなくて終わるパターン。
この辺とっても微妙。
両端に振り切ると「ガチで言い方が悪い過ぎる」から「相手に聞き入れる度量がないから態度や言葉遣いを責めてきている」があって、どっち側に濃厚かが不明だから。
コメントにある
「内容は正しいが、言い方を考えなさい」というせっかくの指摘を「嫉妬乙ww」で片付けてしまう上、「批判されるのは俺の正しさの証明だ」と思ってますます自信を付けるので、結果として自分を俯瞰的に見る機会を逃し続けるという悪循環。
も微妙で、とりあえず「言葉尻を捉える前に内容を正面から受け止めなさい」って指摘にもなり得るので。
勿論「ある程度まで」の言葉遣いってのは大切で。かつその「ある程度」がどの程度までなのかは「相手の住居領域」によるので、難しいところではあるのですが。
ん…シャドウランとかWoDで言うところの「礼儀作法」系スキルが、それ(かえって解らんわい普通の人はｗ)。
とりあえず「あんまり粗悪な言葉は使わない。出来れば、無礼ではない程度に敬語」「言葉の間に気をつけて、詰め寄ったり突き放したりしすぎない」など、いくつか抑えるべきポイントは、ある。
なので、その辺のポイントはある程度気を払った方が、ようは「多数派の人たち」から悪印象を持たれずにすむので。
んと…「悪印象をフォローするコスト」がかからない分、メリットがある感じ。
ただ一方で、これは接客業でそこそこ目にしてきて、その後ネットでも見かけるのですが。
「痛い事苦いことを言われた時に、相手の態度言動目つきその他に対して因縁をつける」手法。結局の所「主観」な部分が多いので、「オレは不快だった」と言われると、それ以上の反論がしにくいっちゃぁしにくい所なので。
かくして「正論を言われる事をそもそも受け入れられない人」が、その原因を「相手の言い方にあるのであって、自分の狭量さにあるわけではない」って転嫁をすると「内容は正しいが、言い方を考えなさい」って話にもつながり得る(念のため。前述でつぶやいている人がそうだ、って意味では全くないので誤解のなきよう)。
んで、もう一方のBlogを軽くチェックしてみる。
http://blog.tatsuru.com/archives/001425.php
私の出す質問や脱線する無駄話の内容だけでなく、こちらの話し声のピッチやトーンや姿勢やテンションの変化といったシグナルを「どう読んだか」ということを見るのである。
なに屋さんになろうとしているか、にもよるかなぁ。
ただまぁ「話し声のピッチやトーンや姿勢やテンションの変化」。ん…テンションの変化は結局「話し声のピッチやトーン」と、後は「単語の選び方」「語尾」あたりに出るので。
その辺が「読める」人は、読めない人よりも有利ではあると思う。
…基本その辺は「苦労なく読める」ほうなので、読めない人がどれくらいの不利益を被ってるかは正直よくわからない。ごめんね。
コミュニケーション感度の向上を妨げる要因は、つねづね申し上げているように「こだわり・プライド・被害妄想」（＠春日武彦）であるので、「こだわらない・よく笑う・いじけない」という構えを私は高く評価する。
これは別に私の趣味でやっていることではなくて、この構えは生物の個体としての「生存能力の高さ」に相関するからである。
私は限りある教育的リソースを彼女たちに一定期間集中的に投じるわけである。
そのために要求する条件がだから、「どんな状況もなんとか生き延びることのできる能力」であることはハインラインの『宇宙の戦士』の新兵の選別条件と変わらない。
…これは色々微妙だなぁ。
このロジックを間違えると「圧迫面接」とか「威圧による教育もどき」を簡単に肯定できちゃうし。
違う角度で見ると「早めにへこたれて逃げたり悲鳴を上げたり倒れたり適合できなくなったり」したほうが、結果的に身を守れるケースもあるから(例：ブラック企業)。
とりあえず、ひとつだけわかっていることがある。
それはどんな場合でも、とりわけ危機的状況であればあるほど、「他者からの支援」をとりつける能力の有無が生き延びる可能性に深く関与するということである。
これも微妙。
明示的に「違う」って言い切れる内容ではないんだけど、同じくらいに「全面的に同意」出来る内容でもない…っていうか、同意するにはあまりにもあちこちに、脆さと落とし穴が想起されてしまうので「危ないなぁ」って思ってしまう。
他者からの支援をとりつけるための最良のアプローチは何か？
たぶん、ほとんどのひとは驚かれるだろうけれど、それは「ディセンシー」である。
んで、ここに行き着くんだなぁ、っと。
decency：礼儀正しいこと。また、礼儀作法。
念のため。
礼儀作法は「ある程度まで」は重要で。
ん…よくシャドウランとかVampire: The MasqueradeとかでPLに説明をするのですが。
礼儀作法ってのは「相手の領域に入るさい、ドアのノックの仕方を知っているか」だと思うのです。
ノックの仕方を知らないのはおおよそ致命的で。
門前払いを食らうか、或いは「大きなペナルティを背負った状態で」交渉を開始するので、とりあえず「絶対に避けておきたい」ところではあります。
ただ、所詮「ノックの仕方」であり、つまり交渉の「入り口」でしかないので。
そこから先を論じずに「美しいノックさえ出来れば交渉は上手くいったも同然」とか考えると、ひどい目に遭うっていうか食い物にされるのがオチだったりするわけで。
結論として。
「ある程度までの」礼儀作法と「ある程度までの」温厚な態度言動、ってのは大切なのだけれども。
あんまりそこに固執しても仕方がないし、相手によっては「クレームをつける対象」にそこを使ってきたりするので、そこで神経使いすぎてもつまらないので。
ある程度「まで」は意識、それでもなお五月蠅ければあとは「切り捨てる」くらいのバランス加減、でよいんじゃないかなぁ、と思う訳ですよ。
おいちゃんは。
コミュニケーション能力は「ある程度」ないと困る
難しい問題ではあると思うんだけど。
先に結論から書くと「特化するとほかがへたれるから避けた方がいいけど、ある程度までのコミュニケーション能力はスキルを伸ばすために必須」。
インスパイア元
http://dochikushow.blog3.fc2.com/blog-entry-1898.html
まず
人間の能力は、ゲームのポイント割り振り制に類似すると思う。（いやゲームの方が真似したんだけど。）
初期ボーナスポイントの大小はあれど、攻撃力にポイントを振れば防御が甘くなるし、魔法に振れば体力が無くなる。
金のある奴は夢が無いし、顔のいい奴は根性が無い。コミュニケーション能力にポイントを割り振ったら、他の何かが欠けている。
には全面的に同意。
以前に似たようなこと、書いてるし( http://d.hatena.ne.jp/gallu/20120122/p1 )。
ただ、とりあえず「IT系エンジニア」の場合、もう一つ別の切り口があって。
うちらの仕事って「お客様の望みを叶える」のが基本なので( http://d.hatena.ne.jp/gallu/20090808/p1 )。
目の前のお客様の望みにせよ、「割と望まれやすい方向」の模索にせよ。
「相手のニーズの根っこの隠された部分」がヒアリングできる、程度のコミュニケーション能力は、どうしても「不可欠」になるのですね。
もう一つ。
教える教わるは大事だと思ってるので。
「口開けてねだっておいて餌の味に文句つける」ような雛に何も与える気はない、にしても。
ある程度「適切な質問が出来る」とか「かみ砕いて教える事ができる」とか、それくらいのレベルのコミュニケーション能力は、職能の伝達って観点から、やはり「不可欠」になるので。
「高レベルのコミュニケーション能力」は要求しないし、下手にそこを要求すると「それ以外が手薄になる」から、割と、特に技術者とかにはお勧めしないんだけど。
ある程度まで円滑に会話ができる、とか、明文が書けるしゃべれる程度のコミュニケーション能力は、ないと「お仕事にならない」と思うのですよ。
なので。
あんまり「技術者だからコミュニケーション能力なくても大丈夫」とかって免罪符、おいちゃんは好まないかなぁ。
興味深いので：「完成」とは？「約束」とは？
元ネタは
「ソフトウェア開発」は「モノ作り」ではない
http://www.gcd.org/blog/2006/07/91/
の、コメントのほう。
あ、勿論「本文読んでる」前提で。
＆
夜半に勢いで執筆しているので、口調その他は気にしない事ｗ
7.
モノでも設計でもサービスでもなんでもいいけど、少なくとも頼んだモノは作って下さい。お金を決めて、それで作ると言ったモノは作って下さい。
作ると言ったものが作れない、いくらでできると言ったものができない。納期を守ると約束したのに約束が破られる。
詐欺ですか？
なんでもいいけど約束は守ろうよ。コメント by 通りすがり ? 2006年7月28日 @ 21:41
14.
ソフトウェア開発は設計である、という前提に一理あるかも知れません。その場合、クライアントが、そのように納得しているかどうか、が一番重要だと思います。
その上で、7.通りすがりさんの意見に賛成します。ボクの周囲にも、IT企業にソフトウェア開発を依頼して、追加追加で料金を請求され、SE業務自体に不信感を持ってる方が何人か居ます。ビジネスマンとしての仕事の進め方を知らないで、プログラムだけが書けても仕方がないと思います。コメント by sisen ? 2006年7月29日 @ 02:09
興味深いなぁ、と思ったコメントがこの辺。
まぁ正直、同じコメントの中で大体おいちゃんの見解と似たようなものは出ていて、それは
10.
約束は守りたくても、日本の商慣習は、実際のところ正式には約束したことにはならないんだよね。だって契約書作るのってしてないことも多いし。だからユーザは「頼んだもの」を明確にしないとだめですね。
最終的にソフトウェア開発の成否は「ユーザの意識」にあると思うんですね。最初にきちんと契約書作ることもしかり、ソフトウェア”だけ”があれば何とかなるという意識もしかり。コメント by yenxing ? 2006年7月29日 @ 00:04
30.
>頼んだモノが出来ない＝頼んだモノが設計されていない です。
いんや。ソフトウエア開発で、特に日本のソフトウエア開発で一番問題になるのは「頼んでいない」や「顧客自身が何が欲しいか分かっていない」です。美容院で「私の美しさを一番際だたせる髪型にしてちょうだい」で任せて、できた後で「私のイメージしていたのと違う！私はもっとキリッとしてふんわりとしてエレガントなのを期待してたのに！」と言って怒るようなもの。そんな曖昧な要求で期待したものが手に入るわけないでしょう？
頼んでもいないし、自分でも欲しいかどーかも良く分からん物を、作ってくれと言われて「ハイできます」と答える営業もどうかとは思うけど、そんな営業の口約束であっさり契約してしまう顧客企業の経営者もどうかしてる。コメント by とおりすがり ? 2006年7月30日 @ 01:35
このあたり。
7番さん14番さんがどうなのかは知らないのだけれども、おいちゃんが知っている多くのケースでは
・納期は決まってる
・予算も決まってる
・「何をしたいのか」がはっきりせず、納品直前とかで平気で追加と変更が入る
って状況。そりゃ仕上がらないよねぇ、っと。
悪意的にみると、7番さん14番さんとも「なんかいい感じのをよろ」で雑な発注かけて、変更だの追加だのを言った結果「遅延したり」「追加料金が発生したり」ってなったんだとすればそりゃ「自業自得だろう」としか言えない。
ちなみに、法曹の世界の人たちも「完成の定義は不明瞭だけどでも先方は完成を前提に納期と予算を提示しているんだから守るべき」っていう、割と謎理論を平気で言ってきたりするので色々と面倒です(この辺は後日腰据えてBlog書きます)。
んで…多分「完成の定義」は、実際問題クライアントとしても「非常に提示しにくい」と思われるので。
そこを考えると「アジャイルとかスパイラルとかでPDCAを短サイクルでぶん回しながら作成」がよいと思うのですが、これが(特に大手さんとの)「予算稟議」とかその辺とすこぶる相性が悪いときたもんだ。やれやれ。
こうやって考えても…うんやっぱり正直、素人さんが介入できる余地が少ないなぁ、とは思うのだけれども。
そこは「仕事だしある程度までは学んでください」としか言えない部分が結構あるよなぁ、ってのが本音。
質問してもらえればなんぼでも返答するけどさ。
「丸投げするからとにかくいい感じにやれ」って話であれば、時間給で青天井にするか、或いは受託ならゼロを２つ３つ増やすよ？ それでよければ、腰据えてつきあいますけどね。
あと。
21.
顧客が開発開始後に仕様変更や追加機能を要求してくる。
営業が無茶なスケジュールと予算で仕事を取ってくる。
などが無くなれば、ソフトウェアも予算内で期限内に完成すると思いますか？コメント by DIY ? 2006年7月29日 @ 12:13
これが面白い問いかけだなぁ、って思った。
とりあえず「妥当な予算とスケジュール」であれば、予算内には間違いなく完成すると思う(しなきゃ、それこそシステム開発会社の責任の元、身銭切ってでも完成させるだろうってかその義務があらぁな)。
期間は…微妙かなぁ。最大限の努力はするだろうから、よっぽどタコいところじゃなきゃ、間に合わないにしてもそんなに遅延はしないと思うけど。あとは「遅延したら１日あたり全体金額のｎ％の損害賠償を払え」的な契約ってのは、請負ならアリなんじゃねぇかなぁ、って思う。
この辺の議論は、とても興味深いし面白いし厄介なところ。
