非オブジェクト指向な「Javaプログラミング能力認定試験」 133
ストーリー by hylom
それならCOBOLでいいじゃん 部門より
それならCOBOLでいいじゃん 部門より
あるAnonymous Coward 曰く、
「SI業界(日本)のJavaプログラマーにはオブジェクト指向より忍耐力が求められている?」というブログ記事が話題になっている。
Java関連の認定試験の1つに「Javaプログラミング能力認定試験」というものがあるのだが、このWebサイトで公開されている試験サンプルがまるでCOBOLのプログラムのようで、オブジェクト指向的ではない設計になっているらしい。
これを受けて、ブログの筆者は
日本のSI業界でJava PGとして仕事をするためには、オブジェクト指向的にきれいなあるべき姿でコーディングできるスキルではなく、このようにオブジェクト指向をまったく理解していない上流のSEが作成した異常な設計書に忠実にしたがってコードを書き、また、その複雑なスパゲッティコードを長期にわたってメンテナンスする根性と忍耐が最重要のスキルとして試験で試されているということなのかと私は理解しました。
と述べている。
Javaの思想どおり (スコア:4, おもしろおかしい)
JavaのWORA思想をよく表している、良い問題ではないでしょうか。
Write Once, RunAway
ど腐れプログラムを直してこそ、上級者とか? (スコア:3, 興味深い)
2級とか3級とかがそういうのを作るから、1級なら直せるだろ?という前提でやっているのかもしれませんね。
でもって、下手な手入れよりまっさら作り直しがよかんべ、という話になるという、この業界でよくあることではなかろうか?
Re:ど腐れプログラムを直してこそ、上級者とか? (スコア:1)
でも現実にそういう傾向あるしなあ。
ド下手糞にスパゲッティプログラムを作らせて、トラブルが発生したら初心者に
継ぎ接ぎ修正させて、手遅れになったら上級者を担ぎ出す。
何か間違ってるだろと。
Re:ど腐れプログラムを直してこそ、上級者とか? (スコア:1, 荒らし)
>仕様書?あんなもんただの納品物です
納品物は完璧であった...ただ、動かないのが問題なだけだ...
いやぁ、よくある話ですね..orz
Re:ど腐れプログラムを直してこそ、上級者とか? (スコア:1, 荒らし)
>エスパー頼む
級レベルでは無理で、実は上に段位とかあるのかもしれない。
プロとか上級者が見分けにくい業界ですからね。
単体のプログラミングスキルもあるけど、旧来品に手を入れるとかね。
旧来品が、先祖を辿るとCOBOLで、それを力押しで移植とか、ありそう。
実はそういうスキルの方が好まれるのかもしれない。
Re:ど腐れプログラムを直してこそ、上級者とか? (スコア:1)
>残さざるを得ない苦悩とかありそう。
他のスレッドでも書いたけど、これがいったん動いたモノだと、
是正/改正へのブレーキは大きいですよね。
>「しがらみで真っ白にできない」「真っ白にすると責任も全てとらされる」「そんな時間ねえ」
某所でのお仕事で、プログラミングではないけど、そういった事に陥っていたプロジェクトがあります。
ある面、HWとかOSとかミドルゥエアといった部分なのですが、有り体に言えば、「設計していないで、OSやアプリのデフォルトでいいじゃん」という構築をしてしまった方々がいたりします。
当然、動かない部分が出てきますが、「ちゃんと設計した実装にしようよ、じゃないと延々と、あれが動かないこれがどうこうという作業に追いまくられる」という発言はおおむね無視されちゃってましたね。
「現在導入/設置しているサーバの手直しでやる。実際に動いている部分があるし、その検証の工数も費やしてしまっているので、今更設計から戻ってやる時間もないし、責任をだれもとれない、納期も近い」という無茶苦茶な指示がPMさんからあって、「こりゃダメだろ?」と...
>「しがらみで真っ白にできない」
全体WBSみて、詳細設計の期間がないのに、それで承認しちゃうのもすごいんですけどね。
なんで詳細設計なしなの?と聞いたら、リプレース前のシステムでは同じ様にOSやミドルの詳細設計はしていなかった、今回必要だとは言えないのでない...orz
で、基本設計で結構細かいところまでやっているかというと、「どの型のサーバにどのバージョンのOS/ミドルゥエアを入れる」程度しか記載がなかったりして、そもそもサーバとして動くための設計の形跡が全然ない。
それでも「一部だけでも動いた」「一部だけでも動いた検証と実績」が「動いた実績」で触らない様にしようという意識が働いている。
結果?仕様をちょっと直すたびに試験に追いまくられる開発の方々の工数の爆発があったりして、これがデスマなんだなぁ..とね。
どこまでが笑い話・都市伝説なのか… (スコア:1, 興味深い)
究極的には 「// でコメントアウトできる C」みたいな…
Re:どこまでが笑い話・都市伝説なのか… (スコア:2)
青い鳥を探すように、「オブジェクト指向」を実現する何かが存在すると信じて、
当所もなく、幻想を求めて旅を続けるのです。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
オブジェクト指向というか, 言語を含めたソフトウェア開発技術が役に立たないのは, 現実のボリュームゾーンのプログラマの能力を過剰に高く設定しているからじゃないかと思います. おそらくは
というのを, 現実のプログラマのレベルとして想定しておかなければならないのでしょう. FizzBuzz問題並みに低レベルだとは私も思うのですが, 最長不倒関数が作成される, ポインタの様なちょっとばかりイマジナリなデータにつまづく人が多い, クラスのメンバを全てpublicにしようとしたり, または個々のメンバ毎にアクセスメソッドを設けようとしたりする, ローカル変数を外部からアクセスできない不便な変数とみなす等々の傍証からすると, それほど間違っていないのではないかと.
このレベルを前提にしてオブジェクト指向とかを考えてみると, 役に立たないのも当然のような.
Re:どこまでが笑い話・都市伝説なのか… (スコア:2)
現実には3年もタダ飯食わすわけにはいかず、トレーニングに3ヶ月も割いてくれれば御の字。
そんな訓練不十分な奴らを使っていかに戦い抜くかを考えるとオブジェクト指向の適用はなかなか難しいですね。
# 3年というのはデザインパターン出現前の話なので今だともっと短縮できるでしょうが、結局デザインパターンをマスターするのが前提。
# はたしてデザインパターンをきっちり読破するような勉強熱心なのがどれほどいるやら・・・
あと、業務プログラムの場合、難しい部分はごく一部で大半はIDEが自動生成したClickイベントのテンプレートに処理を書き込んでいくだけで済むことが多くて、そういう簡単な部分ばかり任されてるとメソッド宣言を自分で書いたことのない奴とか普通にいる。
そいつらに「処理を分けろ」と言ってもメソッドを自分で宣言する行為の敷居が高いのでなかなか実践してくれないし、分けたとしても慣れてないやつは処理の切り出し方が下手なので再利用性が低く可読性も低いコード片をソース中にまき散らすことになり
「こんな読みにくくなるだけのことをするんならベタに書いたほうがずっとマシ」
という結論に落ち着いてしまう。
# そこで誰かが根気強くフォローする環境であればいいんだけどね
# 現実にはどこの職場でも有能なやつほど暇ではない
Re:どこまでが笑い話・都市伝説なのか… (スコア:2)
1クラス3000行のプログラムとか・・・JavaでもC++でも、都市伝説では聞いたことがある。
1クラス1000行のプログラムは、見たことがある。
上流や、マネージャ/チーフアーキテクトがオブジェクト指向、わかってないんだろうねぇ。
私は・・・わかっている範囲で使っています(こういう奴が、一番チーフアーキテクトになってはいけない)。
iPhoneアプリがらみでObjective-C勉強していますが・・・まだまだ修行の身ですね、オブジェクト指向。
-- gonta --
"May Macintosh be with you"
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
それ、どうやっても別クラスにできないんでしょうか…
一個30行の30個ぐらいには分割できそう。
まあ、それがどうやってもクラス固有で、他で再利用するメリットの無いプログラムならしかたありません。
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, 興味深い)
>それ、どうやっても別クラスにできないんでしょうか…
動いていたりすると、それが「動いているモノには触るな」
「触るにしても最小限」みたいな鉄則が出来ていたりしますね。
でもって、そういったソースがおかしいとか、コードレビューとか
ちゃんとやっていないと、終盤土壇場でみつかったりして、「終盤
まで動いていたから」みたいな言い訳が実績として前述の鉄則がでてきちゃったりする。
>それがどうやってもクラス固有で、他で再利用するメリットの無いプログラムならしかたありません。
再利用するためもあるけど、可読性のためにも、それが可能であれば、
そうするべきだと思います。が、前述の鉄則に阻まれることがあります。
また、運用系のエンジニアやPMクラスが阻むこともありますね。
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, おもしろおかしい)
>それ、どうやっても別クラスにできないんでしょうか…
いいから黙って言われた事だけやるんだ
Re:どこまでが笑い話・都市伝説なのか… (スコア:1, すばらしい洞察)
技術的にはできるでしょう。
やらない理由の大半は政治的理由ですよ。
Q1.コードが長いからクラス/メソッド分割しようよ
A1.クラス設計書/関数I/F仕様書が増えるからダメ
Q2.(C開発で)1つのファイルにコード全部書くと見づらいからファイル分割しようよ
A2.開発規約で「Cソース:ヘッダファイル:実行ファイル=1:1:1」と決まっているからダメ
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, 参考になる)
C99ならやってもいいのよ。
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, おもしろおかしい)
# {} は嫌い。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
(* 昔風にコメントアウトすればいいんじゃなイカ? *)
Re:どこまでが笑い話・都市伝説なのか… (スコア:1, 既出)
Re:どこまでが笑い話・都市伝説なのか… (スコア:3, 参考になる)
C++はC99の上位互換ではなく成っちゃうからなぁ
C++はほぼC89の上位互換でC99もC89の上位互換だけど
現在のC++とC99の互換性ってかなりなくなってるよね
struct foo {
int x;
int y;
} hoge = { .x = 0, .y = 1, };
なんてC++では不正な文法になるし
extern void foo( struct foo* p );
の関数に大して
foo( &((struct foo){ 0, 1 }) )
もC++的には不正だし
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
けど、いくらC99なら使えるっていっても、Cでmalloc/calloc使わずに可変長配列使えると言われると違和感あるけどなぁ。
1を聞いて0を知れ!
Re:どこまでが笑い話・都市伝説なのか… (スコア:3, 興味深い)
Cでmalloc/calloc使わずに可変長配列使えると言われると違和感あるけどなぁ。
試しに領域を確保して開放するだけの関数と、可変長配列を確保するだけの関数を作って一千万回まわすと
可変長配列: 0.210000(秒)
malloc: 76.670000(秒)
速度が要求されるんで最近は可変長配列ばっかり使ってるけどwindowsでは使えないらしい。
実際はmalloc一千万回する人なんて居ないか。
でもpowを数百万回まわす人は居たな。テーブルに置き換えたら恐ろしく早くなった。
#変数宣言の場所がめちゃくちゃになってきたらもう終わりだとおもう。orz
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
どちらかというと、可変長配列はallocaの代替ですから、なんでもかんでもmalloc/callocの代わりに可変長配列できるとは限りません。ある程度大きな領域の確保には依然としてmalloc/callocその他が必要です。
あと一応、Windowsで可変長配列が使えないのではなく、MSVCやBCCがC99対応していないだけなので、GCCならWindowsだろうがなんだろうが可変長配列使えます(Intelのはどうだったかな?)。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1)
> MSVCやBCCがC99対応していない
BCCの場合、デフォルトオフですけどC99に対応 [embarcadero.com]してますよ。以下、C++ Builder 2009 のコマンドラインヘルプ。
なお、C+ Builder 6(2002) では非対応でした。C++ Builder 2007 は未確認。
デフォルトでオフになってるのは、既存のコード(大半がC89レベル)との互換性の問題からでしょうか。
そういえば、かつてVisualC++のC++も、長らく変数のスコープが非標準(「for(int i = 0; i < n; i++){}」といった変数宣言がループ後も有効なまま)という問題があり [noppi.jp]、MFCなどのライブラリが非準拠な仕様に依存してるからこっちがデフォルトなままだという噂でしたけど、今では(2005=VC8以降)ちゃんと標準準拠 [microsoft.com]になってますね。
Re:どこまでが笑い話・都市伝説なのか… (スコア:2, すばらしい洞察)
例えば、関数プロトタイプは元々C++で導入された宣言方式で、それがC89でC言語に逆輸入されました。
それを、それこそ10年ぐらい前の時点でも、K&Rを想定して「関数プロトタイプを使ってるのはCではない」とか言っちゃったらもうダメでしょう。
同じように、そろそろもうC89を捨ててもいいんじゃないでしょうか。
Re:どこまでが笑い話・都市伝説なのか… (スコア:1, すばらしい洞察)
>> 同じように、そろそろもうC89を捨ててもいいんじゃないでしょうか。
そうやって「そろそろ~なんて古いものは捨てようぜ」で捨てられるなら,COBOLのコードなんてとっくに絶滅してるはずじゃないの?
言語は関係ない (スコア:1, すばらしい洞察)
能力的に問題のあるものが作れば、どんな言語を使ったって腐れたプログラムしかできない。
逆にまともな者が作れば、部門名にあるCOBOLだって、無駄な分岐やループのないシンプルで可読性の高いものを作る。
それだけの話。
Re:言語は関係ない (スコア:1)
まともな者は、いまさらCOBOLなんて腐れ言語は使わない。
良い技術者はどんな道具でもそれなりに使いこなすが、
同時に良い技術者ほど良い道具への拘りも人一倍強くなる。
Re:言語は関係ない (スコア:2, 興味深い)
匠は道具を選ばないというか、弘法筆を選ばずという面もあるからね。
>同時に良い技術者ほど良い道具への拘りも人一倍強くなる。
道具を選ぶというのは、職人レベルだという話もありますね。
職人でもよい職人は、きっちりと長年使った道具を手入れして、自家薬籠中のモノとします。
たとえば、よい職人であれば、使える道具で、その道具の最善を引き出しますね。
徒に拘るのは、職人ではなくて、単なる工具コレクターだという面もあります。
なので、
>いまさらCOBOLなんて腐れ言語は使わない。
は、道具のせいにした、単なる逃げ口上でしかないとも思えます。
COBOLをきっちり使い切った使い方をして精緻なものを組み上げるでしょうね。
それが出来ないので使わないということでしたら、それは単なる未熟さだと思いますよ。
しかし (スコア:1)
Re:しかし (スコア:1)
>しかし、どの道具を使うかで効率もストレスの度合いも違う
その道具に慣れた職人なら、その道具を使うことはそれほどストレスにもならないし、
効率もその道具で出せるモノを出すよね?
慣れていないといったことで、その道具を忌避する職人もいますよね。
たとえば、丸い溝が彫れるノミを持っていない期間が長い職人は、
角ノミでも丸い溝を彫れるし、丸ノミを調達してもそれを使いこなせる
様に時間をかけますよ。
もちろん、使い物にならない道具もあるでしょうが、道具として廃れるだけでしょうね。
たとえば、ノミなんかいらないよ、自動工具でなんでも出来るという人もいるでしょうね。
ノミ使いが自動工具を触っても、出来上がりの品質などについての目はあるので、その自動工具も改善したり、ノミとの併用をするでしょう。
Re:言語は関係ない (スコア:1, すばらしい洞察)
Re:言語は関係ない (スコア:2, すばらしい洞察)
まともな者(開発者)なら、そのような痴れ言は言わない。
> 良い技術者はどんな道具でもそれなりに使いこなすが、
> 同時に良い技術者ほど良い道具への拘りも人一倍強くなる。
開発言語としてのJavaは悪くないが、開発環境、いや、実行環境
としてはどうなんだろう?
普及するのも極めて早かったが、腐っていくのも早いような気がする。
10年後、20年後に実行環境生き残っているとしたら、Javaではなくて
COBOLのほうが生き残っているような気がしないでもない。
現在のCOBOL開発者は、もし10年後にタイムスリップしても同じように
すぐにプログラムを書けると思うが、Java開発者が10年後にタイムスリップ
したとしたら、使い物にならないと思う。
COBOLは10年前も今も10年後もあまり変わらないが、
Javaは10年前と今は違うし、10年後はさらに違うと思う。
10年後にJavaがまだ使われていればの話だが。
そんな不安定な環境が優れている道具となるとは、私ならば言えない。
優れた道具ほど、長い間使いこまれているというものだ。
Re:言語は関係ない (スコア:1, おもしろおかしい)
Java5,6あたりは無くなっていると思いますが、1.4.2なんかはなぜか官公庁で残っているきがしなくもないのは気のせいでしょうか・・・
あれおかしいな (スコア:1, おもしろおかしい)
デスマストーリなのに/.Jのアイドルの人がいない…(重連打撃音
一方、求人記事には (スコア:1)
その内のかなりの数が「何らかのフレームワーク経験者」ってのを期待・歓迎スキルにあげてるんだよね。
求人と実務が乖離してるって事なのだろうか?
それとも今酷いんで新しく採る人からはなんとかしよう、という意向なのか。
Re:一方、求人記事には (スコア:1)
典型的にはこんな感じかと思います。(ネタのつもりはないです)
派遣で他社に突っ込まれる。
フレームワーク使用において実装が必要となる最低限のクラスだけ作成が許されます。
各メソッドはCOBOL的に実装することが求められます。
共通処理はモジュール単位でユーティリティクラスを作成してそこに全部ぶち込みます。
もしどうしても新規クラスが必要な場合はプロパー社員で構成される社内エリート部隊に依頼します。
ただし依頼には事務的手続きが山ほど必要で、品質は担保されません。
バグ発生時は修正方法まで報告してもなぜか自分サイドモジュールの障害として計上されます。
意地でもクラスを作らせないのはオブジェクト指向を理解していない要員の知識にも還元できるからでしょうね。
結局それをすることにより上級者にも把握が難しくなっているだけだと思いますが。
このパターンは (スコア:1, 興味深い)
JAVAに書き換えただけの物では無いでしょうか、
私は指定の機能通りに動けば良いという場合が多かったので、
その都度最も早いであろう方法を取ってます。
細かい追加や仕様変更が後から増えれば増える程長くなりますので
当然スパゲッティに近くなります。
スパゲッティになるであろうコードならば先に判りますので、
対策はしますね。
再利用しなけりゃオブジェクト指向は不要 (スコア:1)
私感だけど、
オブジェクト指向というのは、再利用するライブラリを作成する場合は威力を発揮するのはよく分かる。
しかし、再利用しない場合は不要だし、多人数で開発する場合は他人とのインタフェース部分だけオブジェクト指向的にすれば十分だと思う。
他人に見せない内部まで生真面目にオブジェクト指向で作ったら、むしろコードサイズが大きくなり。処理が分散することで、かえって可読性が落ちる。
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:2, 参考になる)
他人に見せない内部まで生真面目にオブジェクト指向で作ったら、むしろコードサイズが大きくなり。処理が分散することで、かえって可読性が落ちる。
確かに必要なコーディング量は増える傾向にはあると感じますが、一時的なコーディング量の削減より恒久的な修正のしやすさを優先したほうがよいと思っています。
可読性に関しては、どういうコード設計になっているかというドキュメントをつけるだけでかなり向上しますよ。
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:1)
他人に見せる部分はしっかりとオブジェクト指向的に作らなければならないと思いますよ。だから、見せる必要のない変数はちゃんとprivateにして不正な操作から防止しなけりゃならなりません。
一方、他人に見せない部分というのは、逆に言うと、自分が把握できている部分です。この部分では、そこまで厳密に防御する必要は無いと思います。スコープの管理にしても、たとえばメソッド内の自動変数とクラス変数の使い分けでかなりの規模まで対処できると思いますが。
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:2, すばらしい洞察)
ここでいう「他人」は数ヶ月後(場合によっては数日後)の自分を含みますよね? ね?
Re:再利用しなけりゃオブジェクト指向は不要 (スコア:1)
>発揮しません。
レイヤが違います。たとえ、仕様がちゃんとしていても、クラス変数の操作がアクセサで防御されていなければ、ダメでしょう。オブジェクト指向ってライブラリの使用者に不正な操作をさせないための工夫が随所に盛り込まれています。
>書いているうちに共通部分が次第に見出せてくるので、そういうものをクラスに分離。
単に、共通部分を private メソッドに切り出すだけではダメですか?
また、細かい話ですが、このようなサブルーチン化はカプセル化とは違うものです。
>特にいらないのがアクセサ。
オブジェクト指向的には、格別な理由が無い限り、アクセサを使用すべきです。たとえ、もらった値をクラス変数に設定するだけのアクセサであってもです。さらに...
>多態性や動的束縛は爆弾を仕込むことになることもあるので、よく考えて使ったほうが吉。
だなんて、私と同じく、あなたもオブジェクト指向の濫用には反対だったりしませんか?
SI業界っていうのの範囲が微妙だけど (スコア:1)
via goo辞書 http://dictionary.goo.ne.jp/leaf/jn2/16749/m0u/%E3%82%A4%E3%83%B3%E3%8... [goo.ne.jp]
... 知識を集約できてなきゃ違うよな
# 細かい部分はわからないのはいいけど、その代わりキチンと意見を確認する(その権限があるようにする)じゃないと悲惨だよね
...
こっちの話も思い出した
http://el.jibun.atmarkit.co.jp/hidemi/2010/12/post-1eb2.html [atmarkit.co.jp]
http://el.jibun.atmarkit.co.jp/hidemi/2010/12/sepg-43e7.html [atmarkit.co.jp]
ここではSEの話だけど、
SE/PGで上下はないけど、PGであるならPGとしての価値がなきゃだめ...だねってのはあるよね
M-FalconSky (暑いか寒い)
Re:SI業界のプログラマ? (スコア:1, すばらしい洞察)
まあ,プロジェクトの最初の方はそうなんだけども,要件定義も仕様も丸投げで
いざ動かそうとした時には全然駄目で,その頃には下請け全員に逃げられてて,
どうにもならない場合に大量のPGを抱え込んで乗り切ろうとします。
そういった時に発揮されるPG能力の検定試験という事ではないでしょうか。
Re:SI業界のプログラマ? (スコア:1)
この場合特定の言語に特化する(出来る)ことはまずないですけどね。
開発を外注する場合は#1885943の通りで。
偏ってる気がしなくもないけどIDでいいや。
Re:Javaは現代のCOBOL (スコア:2, すばらしい洞察)
from もなか
Re:Javaは現代のCOBOL (スコア:1, 興味深い)
「自動車は現代における馬車」と言えるかも知れないけれど、
「時速50kmも出れば十分」とか「糞の始末をしても構わない」とは誰も言わない。
「XXは現代の○○」と言う比喩があっても、それは求められる機能や位置づけが同じ
というだけであって、生産性や性能が昔と同じということではない。
昔COBOLで書かれていた業務コードを今はJavaで書くのは事実だろう。
ただしCOBOLの数倍以上の機能を持ち、数倍以上の生産性で。
でなければ新しい言語やプラットフォームを使う意味など無い。
Re:日本のSI業界で必要なスキルは (スコア:1, 興味深い)
システム障害発生時の優先順位
1. 競馬、競輪、競艇などの公営競技
2. 金融機関の勘定系
3. 電力、ガスなどの社会インフラ
#パチンコ業界も品質に厳しいお客さまのひとつです。
Re:モデル化手法と技能の必要性 (スコア:1)
>そもそも、事務処理をコンピュータ化するための担当者に、オブジェクト指向なんていうモデル化手法が必要とされていたんだろうか。
>いまどきのコンピュータで、事務処理システムを作成するには、小難しいプログラムの理論など知らなくても、
>頭数を揃えて力ずくで書き上げれば、普通に動くようになるんじゃないか。
それは二流以下のSIです。事務処理も仕様変更・追加は発生するものだし、
そのときのシステム改修コストを考えると、かなりしっかり業務とデータ処理を抽象化し、
エレガントな設計にしておく必要があります。
また、そのようにきれいな設計にしておくことで、有用な新機能を提案し、費用を頂くが、
実は実装自体は非常に簡単、なんてこともおきます。