kなんとかの日記 このページをアンテナに追加

2010-06-07

形式的な仕様記述がすごいらしい

| 05:28 |  形式的な仕様記述がすごいらしい - kなんとかの日記 を含むブックマーク

 早速,メルコ・パワー・システムズの開発部門が原因究明に乗り出す。しかし,いくらデバッグしてみても不具合の原因が分からない。それどころか,現象が非常にまれにしか起きないため,不具合の再現すらおぼつかない状況だった。

 開発作業に暗雲が立ち始めたちょうどその時,社内でモデル検査技術の試験適用を進めていた早水公二氏が現れる。新技術の調査・導入を担当する技術統括部 ビジネスチーム2に所属するモデル検査の専門家だ。既に何件かのプロジェクトでモデル検査の効果に手応えを感じ始めていた同氏は,この不具合の原因究明にもモデル検査技術が使えないかと思い立ち,作業に取り掛かる。そして,モデルの作成やツールによる探索作業などを経た13時間後,見事,不具合の原因を見つけ出したのだった(図2,図3,図4)。

no title

形式的手法を用いることで、再現性が非常に低いバグの原因をわずか13時間で見つけたとな。すごすぎる。

 今回の不具合の要因は結局,境界値に起因する条件判断文の単純な実装ミスだった(図3)。バグというのは,大概が思いも寄らない部分に潜むからこそ,発見できずに不具合となる。レビューやテストの観点を増やせば検出できるという正論だけでは限界がある。「コンピュータルーチンワークとしてプログラム中を探索するモデル検査は,人力に頼るテストの限界を別の観点から補足してくれるもの」(星野氏)といえる。

no title

形式的な仕様記述は、プログラミング言語とは独立して利用できるのかな。だとしたら、動的な言語においてテストを補完するものになるのだろうか。

 自然言語の仕様であれば,人により解釈は千差万別。一度きりの片方向のやりとりであれば,目立たない仕様解釈の誤差も,仕様精査や実装のサイクルが回る中で蓄積され増幅されてしまうのだった。サイクルを経ても,解釈の誤差が入り込まないような方法論,それが形式的手法だったのだ。「10万行もの仕様をVDMで書いたと言うと,『ほとんど実装に近いですね』などと言われるが,仕様策定者が実装を書いて何が悪いのか。そのくらいの詳細度が本当に必要な立場であれば,実装並みに厳密な仕様でも,ためらいなく書くべきだ」(同社の栗田氏)。

 栗田氏によると,形式的手法による仕様記述を経験すると,仕様を厳密に書く発想が根付くため「今は日本語に戻っても十分厳密に仕様を書く自信がある。形式的仕様記述言語がソフトウエア技術者の共通言語になれば望ましいのでは」とする。

no title

かっこえー!

英語の勉強やめて、仕様記述言語を勉強しようかな。

2010-01-30

Javaは『end of life』なのか?

| 23:26 |  Javaは『end of life』なのか? - kなんとかの日記 を含むブックマーク

一方で、バージョン管理ツールSubversionが後退し、それと入れ替わるように分散バージョン管理(Distributed version control)が前進しています。ホワイトペーパーでも「GitMercurialといった分散バージョン管理はこの数年で大きな注目を集め始めており、地域的に分散した環境でのバージョン管理を求めるエンタープライズ市場での推進役となっている」と書いています。

no title

"エンタープライズ" ではまだSubversionじゃないかなあ。GitMercurialも、リポジトリの一部だけをcheckoutしたり、ディレクトリ別にアクセス制御ができたりしないよね?孫請けの末端開発者には担当部分のコードだけアクセスできるようにしておかないとだめなんじゃないだろうか。開発者ならだれでもソースコードをまるごとダウンロードできる状態は、みんな大好き "エンタープライズ" ではまずいと思うんだけど、どうでしょう?

もう1つ急速に内側に向かって前進しているのが次世代テストツール(Next-gen test tools)。ホワイトペーパーでは特にRubyコミュニティから登場したrspecとCucumberの名前を挙げています。そのほか、多言語開発環境(Polyglot dev environment)、Google Waveなども急速に内側に向かっています。

RSpecRubyの柔軟な言語仕様に大きく依存しているから、同じようなのを他の言語で書こうとすると難しい (書けそうなのはList/SchemeSmalltalkぐらいじゃないかなあ)。実際、自分でRSpecを他言語に移植してみようとすればわかるけど、Rubyのブロックってさりげなく偉大だと思う。

JavaScriptがほとんど外宇宙から第一級のプログラミングへとまっしぐらに進んでくるのがこの分野でもっとも注目すべきトレンドであることは間違いなさそうです。

正直いうと、世間で言われるほどJavaScriptがいい言語とは思えないんだよね(今どきforeach文や引数デフォルト値がない言語を使うのはつらい)。でもGoogle AppEngineでserver side JavaScriptがサポートされちゃったりすると、一気に盛り上がるんだろうなあ。

もう1つ中心に向かっているのがJavaの寿命です。まだAssessの段階ではありますが、「Javaの進化は緩慢になっています。新しいバージョンの登場にはほとんど3年近く待たされています」とホワイトペーパでは書いていますが、一方でJava VMの上で動作する新しい言語、GroovyJRubyScalaClojureなどが新しいイノベーションとなりそうだとも記しています。

Javaが『end of life』になっているんだけど、それはちょっと違うんじゃね?進化が遅いことと、寿命が来たかどうかは別の話だよね。たしかにJavaはIT業界での主役の座からは落ちたし、Sunがなくなっちゃうなどいい状況とはいえないけど、『end of life』は言い過ぎ。せめて次のJava7が出てから判断しようよ。

参考:

もしJava7がクロージャをサポートして2010年中にリリースされたら、Javaが『end of life』というのは間違いだったと言っていいだろう。そうでなければ・・・


元記事の元記事であるInfoQの記事より:

C# は、ラムダ式、拡張メソッド、オブジェクトイニシャライザと自動プロパティセッタとゲッタのような新しい言語機能の導入を続けています。 その全ては 3.5 リリースの言語で利用可能です。C# の 4.0 リリースで、動的キーワードと名前付やオプションパラメータの導入を見ることができるでしょう。それらは C# をより Ruby のような言語に近づけ、より Java 言語の前方へ運び続けるでしょう。

最近のテクノロジにおけるトレンドは?

Javaと違って、C#は着実に進化しているみたい。ThoughtWorksによる評価も高い。

でもなあ、Martin FowlerはMSから多額のお金をもらっているらしいから (元Sunの人がそう言ってた)、そのへんは割り引いて聞いておくことにする。

トレモロトレモロ 2010/01/31 13:35 ウチなんてまだCVSだよ(涙)。。。

2009-02-26

ソフトウェア工学は知識や技術を体系化するけど属人性の排除はできてない

| 02:14 |  ソフトウェア工学は知識や技術を体系化するけど属人性の排除はできてない - kなんとかの日記 を含むブックマーク

ソフトウェア工学は、知識や技術を体系化することには成功している。だけど、属人性の排除はまるっきりできてない。

たとえばオブジェクト指向を考えてみるとよい。オブジェクト指向という考え方は、プログラミング言語においても設計方法論においても大きな影響を与えたし、ソフトウェア開発においても大いに役立っている。またデザインパターンなどは、まさに知識を体系化したものの例としてふさわしい。

しかしオブジェクト指向が広まることで属人性が排除されただろうか? 誰もがよいクラス設計を行なえるようになっただろうか? 現実は逆だろう。一握りのできる人たちは美しいまでのクラス設計を行なうが、多くの人は汚くて複雑なクラス設計しかできていない。つまりオブジェクト指向が広まるにつれ能力差と属人性は拡大していった*1

これには 2 つ理由があると思う。

ひとつは、オブジェクト指向を理解している人としてない人との格差により属人性が広がったこと。オブジェクト指向を理解している人は高い生産性を上げ、そうでない人は生産性を上げるどころか下げてしまうことも珍しくない。新しい技術が登場するほどこういった格差は広がるばかりであり、できる人間への属人性は高まっていく。

もうひとつは、利用可能な選択肢が多いに増えたことで、それをどう適用するかで人による違いが大きくなったこと。これはオブジェクト指向を十分理解している人どうしの間でも違いが大きいことに注意したい。たとえばクラス設計をするうえで、継承を使うのか委譲を使うのかクロージャを使うのか、どんなデザインパターンを使うのか、住所を顧客クラスの属性にするのか独立したクラスにするのか、などなど。利用可能な技術が増えるほど人による違いは大きくなり、結果として属人性は高まってしまう。


どうも少なくない数の人が『ソフトウェア工学は、工学である以上、属人性の排除が求められる』と考えているようだ。しかし工学は知識を体系化して生産性を高めることができればそれでよく、属人性の排除なんて別に必要ないと思うのだが、いかがだろうか。

「工学」は「工業」に通じるので、全体としての生産性を上げたい、というのが目標。何故そうなるかを解明できているかどうかなんて、ときには二の次、三の次にされる。

だから、属人性を排除したい、ということは工学として当たり前のこと。

ソフトウェア工学 - それって食えるのか?

属人性を排除したからといって生産性が上がるわけではないし、属人性を排除しなくても生産性を上げる方法はあるだろう。他の分野での工学は属人性を排除する事で生産性を上げたかもしれないけど、それがすべての分野でも成り立つとは限らない。

少なくとも、属人性を排除しようとして今までの何十年と失敗を繰り返してきたのだから、いいかげん『属人性を排除すれば生産性が高まる』ということに疑問を持つべきではないか。

*1:そもそも「オブジェクト指向」という言葉の定義からして、人によって大きく異なる。まるで属人性を排除できていない。

お幸お幸 2009/02/27 14:12 かねがね同意します。
「工学」的には結果の一致(属人性の排除)が大事
「工業」的には品質(一部に生産性)が大事
ですね。
ちなみに、オブジェクト指向のクラスと数学の集合のマッピングができるますが、「オブジェクト指向」は、科学や工学を基礎においていないと思います。

サスケットサスケット 2009/02/27 18:16 >属人性を排除したからといって生産性が上がるわけではないし

工学の何たるかなんて知ったこっちゃ無いけど属人性を排除したら生産性があがることもありますよ。
生産性を挙げる目的で属人性を排除し、それができたなら。

一番効果がわかりやすいところを簡単に言うと「人に依存する」ということは「能力・スキルに依存する」ということ。
基本的にスキルを有しない人とスキルを有する人では後者のほうが金がかかるんだから、うまいこと「属人性を排除できた」という条件下では、たとえば単純に給料辺りでの生産性はあがっているわけ。

スキルが無いとできない仕事をスキルが無くても(高価な人間に任せなくても)できるようにするという目的で属人性を排除できたなら、原則コストあたりの生産性はあがってないとおかしい。原則。上がってないならそれは人員調達だか給与水準だか何かをミスってるんだと思う。
そりゃ、【○○さんの一日の生産性】という見方をしたら下がるほうが多いだろうけど……まさかそんな見方をしているのではなかろうか。


>少なくとも、属人性を排除しようとして今までの何十年と失敗を繰り返してきたのだから、いいかげん『属人性を排除すれば生産性が高まる』ということに疑問を持つべきではないか。

それは別の問題だと思うけど。
属人性を排除することで生産性があがる所を狙ってやら無いとあがるはずが無い。
属人性の排除に失敗したのか、属人性の排除の適用箇所を誤ったのか知らないけど、『属人性を排除すること』は基本的に(生産性に限らず)メリットなんだから疑問視するのは、『何を目的にどこに適用するか?』なんじゃなかろうか。

自動化することも属人性の排除でしょ。
自動化するところあると認めてるんでしょ?
自動化によって(個人のではなく総合的な)生産性があがる局面は無いわけではなく、これは成功例の一つでは?
何十年も失敗し続けてなんてどこを見ていっているのか知らないけど、成功例もそんなレアなものではないでしょう。

属人性を排除するには困難なところでやっちゃって失敗したのを見て『属人性を排除しなくても生産性を上げる方法はある』とか『疑問を持つべき』とか短絡的杉。
【あらゆる局面で属人性の排除に効果があるわけではない】といいたいなら誰だってわかってること。

オブジェクト指向使った。
自動化ツールを買った。
ただこれだけで属人性の排除につながるだとか生産性向上するだとかなんて短絡的な思考している奴だったらそれは失敗するに決まってる。

オブジェクト指向の言葉の定義ができてない?人によって違う?
何でそんな状態で満足できるのか?
理解してないなら理解させる。定義が違うなら合わせる。「言葉の定義からして、人によって大きく異なる」イコール人に依存しているんじゃないか。「人に依存しないようにしたけど駄目だった」とかではなく、最初から人に依存した前提条件を敷いておいて【属人性は拡大していった】とかどういう印象操作かと。

「ツールを使って属人性を排除します」という局面で、「ツールのこと理解してません。正しい使い方がわかりません。人によって使い方が違います」で属人性排除に成功するほうがおかしい。そしたらまずはツールの使い方etc込みで「属人性の排除」でしょ。確かにそれすらわかってなくて失敗した例はいっぱいあるだろうけど、そんなものを見つめて判断材料にしてもしょうもない。



>しかし工学は知識を体系化して生産性を高めることができればそれでよく、属人性の排除なんて別に必要ないと思うのだが、いかがだろうか。

工学の何たるかなんて知ったこっちゃないけど、生産性があがろうが下がろうがどちらにせよ属人性の排除は必須課題だからなあ。
属人性の排除をしたけど生産性があんまりあがらなかった?いいじゃない。多少(許容できるレベル)のコストならば逆に払っても属人性の排除ができるところはしておきたい。そういう局面もある。

ていうかソフトウェア工学ってそんなに生産性生産性な短絡的な発想なんだっけ?生産性以外のものも見てたと思ったんだけども。
工学であるから属人性の排除をするわけでも
生産性があがるから属人性の排除をするわけでもなく
品質、コストetc、ソフトウェア開発のどこかの局面で効果があるから、その局面に属人性の排除を取り入れるんでしょう?

jimsiejimsie 2009/02/28 01:33 > どうも少なくない数の人が『ソフトウェア工学は、工学である以上、属人性の排除が求められる』と考えているようだ。

それは、そう書いている人が「ソフトウェア工学」ではなく「工学」について書いてるからだと思う。

「属人性の排除」が生産性を上げるための唯一の手段ではないし。

ソフトウェア以外の分野でも、職人を排除できたからハッピーかと言うとそういうわけじゃない。
ある程度、属人化を排除できたからこそ、職人が職人でなければできないことに活かされるのだろうし。

たかだか数十年しかやってない分野なので、結果を出すのはこれからなのだ >ソフトウェア工学

cafebabecafebabe 2009/02/28 12:51 配送の仕事をするのに車を導入した → 自動車免許が必要になった → 免許持ってる人しか仕事できない! → 属人性が高くなった

という間違いをする人はいないでしょうが

システム開発にオブジェクト指向を導入した → 仕事にオブジェクト指向の知識が必要になった → オブジェクト指向の知識があるひとがいない! → 属人性が高くなった

という誤った主張をする人は絶えませんね。

特定の人にしか仕事の仕方を知らない、替えが効かない状態を属人性が高いと言いますね。
特定の人しかスキルを持っていないことを属人性が高いとは言いません。
そんなことを言ったら医者にしろ弁護士にしろ属人性が高いことになってしまいますね。

ソフトウェア工学は属人性の排除を手助けしてきました。ただし、仕事をするために必要なスキルは向上してしまいましたが。

2009-02-25

HTMLコーダーやWebデザイナーをバカにしているプログラマーは全員腹切って死ね

| 02:33 |  HTMLコーダーやWebデザイナーをバカにしているプログラマーは全員腹切って死ね - kなんとかの日記 を含むブックマーク

デザイナーとプログラマーの間に優劣なんかない。あるのは役割の違いだけ。なのになんでHTMLコーダーとかデザイナーとかをバカにするプログラマーが多いのかサッパリわからない。

HTMLコーダーやWebデザイナーをバカにしているプログラマーは全員腹切って死ね。


web業界にも様々な職種があり、最近では分業化も進んでるみたいだが、

だからって「自分はHTMLコーダーですから、プログラミングには興味ありません」は通用しない。

HTMLコーダーやデザイナーも、プログラミングは勿論サーバーやネットワークの知識を持つべき。

まぁデザイナーは別業界でもある程度潰しがきくかもしれない。

プログラミング知らないHTMLコーダーがダメな理由

なんでやねん。なんのために仕事が分かれていると思ってんねん。デザイナーがサーバやネットワークを知らないといけないような状況って、プログラマーがクソなだけだろ。

そんないうんやったらプログラマーだって経営も営業もユーザサポートも全部やれや。電話でアポとって、客前でプレゼンして、見積書作って、契約書にハンコもらって、売上金を回収して、トラブルがあれば頭下げて、それ全部プログラマーでやってみろや。やらないにしても、それらの知識をおまえは全部持ってるのか? 他人に偉そうに要求できるほどおまえは他の分野の知識を持ってるんか?


一番危ういのはHTMLコーダー。

HTMLコーダーって、HTMLしか書けない人が多い。

プログラミングは分からない、とか、勉強する気はない、とか言っちゃう人もいる。

HTMLなんて所詮静的なものだから、webっていう分野の中で見たときその重要度は最底辺である。

webは動的でこそ意味があるからね。

HTMLの重要度が最底辺である理由が、静的なものだからだって。

なんでそれが理由になるんだよ、バカじゃねーの? 静的だから重要じゃないとか訳わからんことほざいているおまえこそ、論理的な思考ができてない最底辺の技術者だよ。


HTMLコーダーという職業が未だ成立しているのは、単にプログラマがHTML書くのが面倒くさいから。

そもそもHTMLなんて素人が一ヶ月本気で勉強すれば仕事になるレベル。

後はハックw ひたすらハックw そして複数のブラウザでチェックチェックチェック。

まさにIT土方。力仕事なのである。

なあ、ここでいうHTMLコーダーって、当然CSSも含まれるよな? 今どきCSS抜きでWebページ作るわけないもんな?

それで、おまえはそのHTMLコーダーよりましなHTMLとCSSが書けるの? 複数のブラウザでデザインが同一のページが書けるの? IEでだけ表示が崩れた時に、それを直せるだけの知識がおまえにあるの? IE とほかのブラウザとでマージン計算がどう違うか把握してるの?

「単にプログラマがHTML書くのが面倒くさいから」とか言ってんじゃねーよ、ほんとは自分じゃまともなHTMLとCSSが書けないだけだろ。おまえのいってることは、「プログラミングなんて素人が一ヶ月本気で勉強すれば仕事になるレベル」と思ってる自称上流コンサルと一緒じゃねーか、ボケが!


なにもHTMLコーダーからプログラマにステップアップしなくても、普段の仕事で活用出来る。

プログラミングがちょっとわかれば、人間が手作業でやる仕事をコンピュータに丸投げできる。

HTMLコーダーはそれをしない。

なんか、自分の手でやることが粋だとか、古い職人みたいなこと言いやがる。

HTMLは手打ちに限るね、なんて、うどん屋かっつーの。

HTMLエディタを使わない、もしくは使っていてもメモ帳と同じレベルでしか使ってないのは、

ソフトを使いこなせない、逆にソフト(コンピュータ)に使われている状態。

自分の理解レベルをちょっとでも超えると、あもうこりゃ手でやったほうが早い、ってなっちゃう。

だから成長しない。

もしおまえのいうHTMLコーダーがほんとにメモ帳程度のものしか使ってないなら、それは確かにそのHTMLコーダーはまずい。できる人ほど自分の道具にこだわるべきであり、Dreamweaverを使えない(買えない)としても、せめて閉じタグを自動で入力補完できるようなエディタを使うべき。


HTMLコーダーは一人ではなにも生み出せない。

なにか便利なwebサービスを思いついてもそのプロトタイプすら作れない。

webの一番美味しい部分を捨ててる。

なにが『webの一番美味しい部分』なの? なぜそれが『一番美味しい』の? それはおまえがプログラマー視点しか持ってないからそこが『一番美味しい』と思い込んでるだけじゃないの?


HTMLコーダーはなぜかプライドだけはいっちょまえ。

プライドだけがいっちょまえなのは、HTMLコーダーより自分のほうが上だと思っているおまえのほう。


俺の書いたコードを勝手に変えるな、とか、俺のCSSに手を出すな、て具合。

そんなことプログラミング覚えてから言え。

デザイナーが書いたCSSに手を出すほうが悪い (せめて事前に一言ことわるべき)。おまえだって、自分が書いたプログラムをデザイナーがいじったら怒るだろ? それと同じだということがなぜ分からない?


世の中そんなキレイごとだけでは回らない。

動くモノを作り出すために妥協せざるを得ないこともある。

動くモノを作り出すためにCSSを勝手に変更したの? 意味わかんねー。


ここのマークアップ変えるだけでサーバ負荷が減るんならそうすべき。

サーバ負荷が変わるようなマークアップって何? ちょっと思いつかないな。具体的な例を見せてもらわんとコメントできない。


さぁHTMLコーダー諸君、今日からプログラミングのお勉強始めましょう。

おまえこそHTMLコーダーよりきれいなHMTLとCSSが書けるよう勉強しろや。HTMLなんて素人が一ヶ月でマスターできるんだろ? ちゃちゃっと勉強してHTMLコーダーを排除してみろ。

だいたい、Webデザイナーが苦労しているのは、互換性の低いブラウザをプログラマーが作ったせいじゃねーか。そのせいで世の中のみんながどんだけ迷惑してるのかわかってんのか? Webデザイナーに迷惑をかけてるのはブラウザの互換性の低さ。そしてその原因はプログラマーにある。なのになんでデザイナーに対してえらそうな態度をとるプログラマーが多いの?


HTMLコーダーやWebデザイナーをバカにしているプログラマーは全員腹切って死ね。バカにされても仕方ないのはレベルの低いHTMLコーダーやWebデザイナーだけ。それはレベルの低いプログラマーがバカにされても仕方ないのと同じ。少なくとも『静的だから重要度は最底辺』とかぬかしているアホは脳ミソのレベルが低いのは間違いない。おまえのようなやつから真っ先に死ねや、クソが。

その辺その辺 2009/02/26 16:58 安易に「死ね」とか言う人って哀れに見えますよ。

jspいらなくね?jspいらなくね? 2009/02/27 02:31 >ここのマークアップ変えるだけでサーバ負荷が減るんならそうすべき。
この程度で減らせるサーバの負荷ってどんだけw
まともなエンジニアなら他のボトルネックを潰すべき

ごもっともごもっとも 2009/02/27 10:27 そしてWebプログラマもまたバカにされる存在という。

お幸お幸 2009/02/27 14:27 個人的には、ユーザに近いもの(価値)を作っている人が偉いと思っているので、プログラムコーダーよりはHTMLコーダーが偉いかと。
互換性の問題はプログラマーよりは、経営者の問題だと思います。

プログラマプログラマ 2009/02/27 19:00 プログラマです。おしゃるとおり。
私も普段Webデザイナーと組んで仕事をすることがあります。少なくとも顧客がシステムに見た目を気にする場合はWebデザイナーに画面作成を依頼します。彼らは優秀であり、私では到底できないきれいな、そしてユーザビリティー・ユニバーサリティーに優れた成果物を作成します。ここに彼らの価値があると考えています。別にWebデザイナにHTMLやCSSを求めようとはしません。安く、早く、よいものを作ってもらえれば、場合によってはHTMLを書く人やCSSを書く人はこちらで用意して書きます。
ただし、仕事をする前に注意すべきことは伝えます。「回線細いから、あまり容量が大きくならないようにしてください。」「画面がころころ変わるので、あんまり複雑なつくりにしないでください。」「スピード命の業務なので、できるだけ少ない手順で動く画面にしてください。」この意味を理解してもらうためには、多少なりともサーバの知識、言語の知識が必要です。(もちろん、サーバ構築や実装ができる必要はありません。)ソフトウェア業界の仕事を理解してもらい、何を求めていて、その後我々が何をしていくか理解してもらうことで、よりよい仕事ができると信じています。
なので、「インフラ、言語は俺の仕事ではないので、知る必要はない」という発言はあまりうれしい意見ではありません。
最後に、ほとんどのプログラマ(少なくともWEB系)は、CSSの知識も、HTMLの知識もあります。そして、幾人かはユーザビリティーの学習もしています。お互いの仕事をなるべく理解しあい、優良なコミュニケーションのもと、いい仕事がしたいですね。

tamakiiitamakiii 2009/02/28 01:19 何がまずいって自分の守備範囲より外のことに手を出そうとしないような自己中心的な言動をすることと、それをする人がHTMLコーダーやWebデザイナーに多いということなんじゃないかなと、個人的には思います。知識を得ようとする、周りにもっとコミットしようとする姿勢すらないのは、ともに仕事をする人間としてどうなんでしょう。

プログラマーも営業を云々の所は極論ですね。そんなのができる訳ありません。ただ、もっと周りとうまくやっていくために、両者とも必要な知識や経験を得ようとする姿勢は持つべきではないでしょうか。

hogehoge 2009/02/28 10:24 これはひどいwww

designerdesigner 2009/02/28 14:49 >ほとんどのプログラマ(少なくともWEB系)は、CSSの知識も、HTMLの知識もあります。

そんなことありません。自分は何社かWebデザイナーをしていますが、ほとんどのプログラマーはCSSの知識はありませんでした。

safasafa 2009/02/28 17:07 いいね。おもしろかったよ。

picosukepicosuke 2009/02/28 23:15 エキサイトしてしまう気持ち、非常にわかる。
わかりすぎて泣けてきた。
個々人のレベルの問題なのはわかりつつも・・・どうしても・・ね。

kekekunkekekun 2009/03/03 13:55 経営者です。

各人が各人の専門に全力をつくせるようにすべきで
プログラマの専門領域のプログラムを
デザイナーに勉強さえるのは
頑張ってもらうべきところが違うと思う。
デザイナーはデザインに注力すべき。

もちろん、建築やるのに建築の基礎知識がなくちゃ
建たないものを描いちゃうように
関わる人はそれにたいする
基礎知識はもっててもらわなくちゃこまるけどね。

その上でね、専門に注力してほしい。


プログラマがデザイナーに
プログラムの知識を強要するのは
職務放棄に近いかなと思うよ。


デザインとプログラムを結合させるという
プログラマーの役割なのか
デザイナーの役割なのか
グレーなところがあって
その業種はプログラマともデザイナーとも別職種だと思う。

フロント弄ってる奴フロント弄ってる奴 2009/03/07 02:39 最後の最後で特大の的外れな極論を太字で書いちゃってるよ。だから馬鹿にされるんだね、納得する。

それはそれとして、指示者の下にぶら下がってる連中なら、味噌もクソも同じだね。結局、取替え可能な人材なんだし。

まあ、でも、フロント弄ってるプログラマなら、HTML,CSSは普通に弄れるよ。

そうすると、HTMLコーダーって職業は、JavaScriptも弄れるんだよね? そうでないと、存在意義は、互換性調整のテスターって感じになってしまうんだが・・。

コーダー一年生コーダー一年生 2009/03/30 15:29 ちょうどこの記事を読んで悲しい気持ちになっていたところだったので
すごく共感が持ててうれしかったです。

プログラムのことがわかった方が、自分でできることが広がるので
勉強はとても大事だと思います。
難しいことはわからなくても、PHPの表示面とかはなんとなくちょっとだけいじれるようにはなりました。
コピペコピペで恥ずかしい限りではあるのですが…。

そうやって、きっとみんな私のように勉強している人もいっぱいいるのでしょうが、
ぜんぜん知らない人に「テメェらそんなんだからだめなんだ」みたいなことを言われてしまうと、
とても悲しくなるのは事実です…。

がんばっても覚えられない、頑張りたい、のにそうやって「やってない」って言われちゃうと寂しいんですよね…。

うちのプログラマたちはcssがすごく下手なので
そういうときに私は「なんで勉強しないんだよ…」とは思わないんですよね。
プログラマのみんなが思ってたらどうしよう、って怖くなっちゃうんですね

よしおよしお 2009/08/24 15:15 同様にHTMLしかやろうとしないコーダーも役立たず。はっきり言って、HTMLは簡単。たいしたことない。webプログラマに求められる知識の方がよっぽど高度で、広い。
javascriptくらい書けないようになってないと、そいつは向上心がないってこと。もちろんdreamweberのspryを使うようじゃ、だめ。デメリットを理解して使うなら別だが。
てゆーか、自分の業務範囲以外を理解しようとしない奴らはうざい。ぬくぬくと温室で育ってるだけ。

よしこよしこ 2009/09/16 22:37 Dreamweaverのスペルもミスるようなプログラマはたいしたことないですね。

みまみま 2009/09/27 03:17 xhtmlもCSSもflashもactionscriptsもjavascriptsもphpもjavaもperlもネットワーク・サーバセッティングもデザインも、もうWEBサイト制作に纏わる技術代替網羅してるけど。

こうなってくると逆に会社の中では「ウザいやつ」になってしまう。

何故なら、サイト1個作るときに他の人間を必要としないから。

結局自分のできる事を人にやらせようとして、自分よりできない姿を鑑賞して優越感に浸りたいだけ。

実際やられるとイライラしだす。

プログラマプログラマ 2010/11/05 15:59 プログラマは処理の構造を考えるのが仕事
全くやっていることが違うのになんで怒るの?
少なくともあなた方の言っているような
レベルの人たちはプログラマとは言えません。

原 2011/01/20 03:43 わかるぜっ!

でもコーダーはいらんとかデザイナーはだめとか有能は人はそんなこと言わないぜ!

引用されてるプログラマーはオ○ニー野郎だ。

プログラマーが悪いんじゃなくてこのオ○ニー野郎がオ○二ーのしすぎでかわいそうになってしまったんだ!

デザイナーデザイナー 2011/04/15 02:26 よくわかります。プログラマーにとどまらずウェブデザイナーをバカにしてる人は多いと思います。数が多いから使い捨てとか、知識が浅い、みたいな。
デザインもWEBで商売をするにあたって必要なものであることを知らしめてやりたいですね。
何でこんなにデザイナーの地位が低いのだろうか…

プログラマプログラマ 2013/01/22 18:28 え、デザイナーなんていらないでしょ
どんだけ狭い範囲の仕事なんだよ
ってか10分の1でしょ、デザイナーなんて

プログラマプログラマ 2013/12/15 10:58 確かにどちらが偉い、凄いなんて考えてる時点で相手の程度が分かりすね。
>だいたい、Webデザイナーが苦労しているのは、互換性の低いブラウザをプログラマーが作ったせいじゃねーか。
それを一般のプログラマに対して思っているなら貴方の頭はおかしいです。

プログラマーもどきプログラマーもどき 2014/01/12 12:45 役割分担は大事だと思うがこの記事は酷い。

まぁまぁまぁまぁ 2014/03/18 15:16 構造ガン無視のコーディングが蔓延りすぎたんじゃないかな。
滅茶苦茶だとプログラム側から非常に操作し辛かったり、静的コードに手を加えなきゃならない時もある。
分業の重要性を分かっているなら裏側で苦労してるプロラマーが居るかもって配慮と、そうならない為の歩みよ寄りはあっても良いと思う。
もちろんプログラマーも同様。

webデザインから『web』外せばwebデザインから『web』外せば 2014/03/24 00:52 Webの基礎は知るべきじゃないか?
jQueryペタッと張ったけど応用が利かないとかは勘弁してね。
まさか理解してないモノに依存するデザイン設計はしてないよね。
君のような人に相談されても、僕は協力する気に慣れないかな。
ネットを通じてモニタ画面に表示されるデザインを作ってるんだよね?でも仕組みには興味が無い、またら理解するつもりも 無いって印象を受けるんだけど。
もしそうなら君はwebは語るべきではないし、恐らく語れないだろうから、肩書から『web』を取るといいよ。それで砂場でお絵描きでもすればいいんじゃないかな?

デザインからPGまでやる人の意見デザインからPGまでやる人の意見 2014/07/28 14:33 レベルが低いコーダー、デザイナーが多いから、引用元の記事みたいな意見が生まれるんだと思う。

実際、HTMLCSSに比べて、PGは知らないといけない部分多い。PGに比べてWEBの知識少ないコーダー、デザイナーが多すぎる。

デザイナーの意見デザイナーの意見 2015/05/11 12:19 言語の違いはおいといて、プログラマ=htmlコーダはIT土方という面では同じ。
若い時の下積みでやるには絶対必要不可欠な工程だと思う。

最終的に、他人が設計した仕様に沿ってコーディングするだけでは高い価値にならない。
もちろんスキルの引き出しは多いほうがいいが、
職人に徹したら年取った時に詰む。

コーディング要員は、吸収が早くて、安く使えて、体力のある若い人を取りたがるからだ。
そしてやれる人は山ほどいる。

全体設計にかかわるシステムエンジニア、ウェブディレクターなどの
客との折衝、問題解決、お金、人の管理ができる人はなかなかいないので、
企業は高い価値と認める。

だから、客に対して価値のある提案ができるかどうかの方が大事。
これは年取ればとるほど経験値で価値が上がっていく

デザインでもそう、フォトショ、イラレができるから偉いわけではない。
デザインでどれほど客の売上に貢献できるかがデザイナーの価値。

エンジニア寄りPMエンジニア寄りPM 2015/08/17 19:36 HTMLコーダーやWebデザイナーという職種をバカにしているというより、経験則によってバカな人が多いと感じているだけなんだと思うよ。

PHP同様にHTMLは非常に簡単である故に中途半端なスキルの人たちが多くなりがちなのは感じるところだし、
今どきのWebデザインは動きありきなUI・UXは当たり前なのに、仕様が滅茶苦茶な上、漏れ放題ということも少なくない。結果としてプログラマ、あるいはエンジニアに尻拭いをしてもらう始末

当然そうじゃない例外もいるが大半がそんなじゃねぇ、、、

コーダー、デザイナーがプログラマの尻拭いが出来れば、持ちつ持たれつで良い関係が築けると思うけど、その前にツールの発達によってコーダーが不要になり、Webデザイナーはエンジニア化していくのではないかな

ごむべえごむべえ 2016/06/14 00:39 htmlの人!おれもわかるぜw
キミの文章はhtmlはできてcssはちょっとだけ解るよ♪って人が書いた文章に見えたw(実際htmlとcssごときにちょっともクソもないがw)
確かにこの人のレベルだと、こういう発言をしちゃうのは仕方がないと思うw
通常webプログラマはhtmlとcssはできて当たり前で、万が一解らない場合でもググれば解決できるレベルw(できるとか表現しちゃうとhtmlしかできない人とかAdobeの緑ぃやつしか使えない人に怒られちゃうのかな?w)

おっと!それよりもhtmlコーダー様はどうだろう?
仮に難易度がかなり低いと噂のphpが使われてるファイルに何やらエラーがあるようだ(もちろんキミが扱って起きたエラーだw)!解決できるかな?w
無理でしょ??w試しにトライしてみてほしいwww
つまりそういうことwヒントが『ほにゃららline21』とかあっても21行目見に行ったり、その前の英文読まないでしょ?www

大体英語読めないでしょ?w
翻訳サイトも使ってなさそうwww
別にいーと思うよhtmlとcssくらいなら英語とか必要ないレベルだしw
だからキミは幸せだと思う。きっと技術もなく独立しちゃった革命家か向上心の欠片もないクズだろ?w

もしキミがクズだった場合、
変数aがaho、
そうでない場合、
変数aが、baka。

例えがキミだから非常に分かり難いが、webの業界でも頻繁に使われる単純かつ基本的な条件分岐(htmlの人のためにふりがな打っておくね!『じょうけんぶんき』後でググってね!)、この程度もできないのに腹をどうにかってw
いいね!w

あ 2016/09/13 17:22 これは酷い
論理破綻(というより飛躍)のオンパレード
そりゃこんな記事書くような奴は馬鹿にされて然るべきだわ
実際webデザイナーなんて高卒とか専門卒がほとんどだしね
稀に存在する大卒もFラン卒か経歴に傷しかない人生失敗君くらいしかいない

い 2017/08/06 09:57 この人頭悪そう。

SI屋SI屋 2017/08/09 19:52 僕は底辺SIer でサーバーサイド(SQL,Java.VB.c#)やっててたまにJavaScript (typescript )触ります。
IT土方代表の下請け会社ですがさすがに、HTML と CSS わからない人はいませんが、、、
ていうかわからなかったらどうやって画面作るんだろう、、、

最近のフロントエンド開発現場ははMVC やらMVVM フレームワークがもっぱらでHTML はただの入れ物で動的にDOM を操作することのほうが多いと思います。
CSS も直書きするよりSASSやLESS をコンパイルする方が多いような、、

つまり何が言いたいかっていうとフロントエンドはHTML とCSS だけでやってくことは非常似厳しいです。
レスポンシブWebデザインもbootstrap を使えば実現できますし最近のエディタやIDE はパッケージダウンロードするだけで使えます。

フロントエンドでモダンな開発しているところはHTML CSS使えて当たり前、フレームワークやライブラリー使う時代ですからプログラミングも少し勉強すれば活躍の幅が広がると思います。
あなだがHTML CSS のみで勝負するなら、フロントエンドのエンジニアは最近はそれらを理解して使いこなせる人も多いですから、デザインで勝負すると言うと思います

名無し名無し 2017/11/07 22:09 こんなクソ記事消した方がいいですよ
検索妨害になります

通りすがりのプログラマ通りすがりのプログラマ 2018/01/15 19:29 体感的にコーダーさんに不勉強な人が多いと思う。
たとえばSassやCSSフレームワークが理解できて、jQueryのコピペじゃなくreactやvueなんかを書けるコーダーさんなんて見たことが無い。
なぜなら、そのレベルに達した人はフロントエンドエンジニアにクラスチェンジするから。

2009-02-24

Re: ソフトウェア工学とスーパープログラマは両輪

| 01:51 |  Re: ソフトウェア工学とスーパープログラマは両輪 - kなんとかの日記 を含むブックマーク

ようやく本気を出してくれたようなんだけど、論理的な思考をすることに本気を出してほしい。想像力を働かせることに本気を出されても困る。


ようはあなたが望む体制はスーパープログラマーに選ばれないってことじゃないの?

文章の意味がわかりません。ワシの頭でもわかるように書いてください

これは...(省略)...

dankogaiが言いたいのはこうではないか。

  • 生産性は定数ではないから、常に生産性が高いかどうかわからないことのために体制なんか変えるかボケ
  • 生産性は何を生産するかで変わるから、以下同文
  • そんなスタッフつけたところで、スーパープログラマーは仕事が気に入らなきゃいなくなるよ

ということだろうね。

つまり、この最後のところが、僕のコメントなわけだ。すたっふーがどんなにいようが仕事が気に入らなきゃ選ばれない。逆に、どんなに劣悪な環境でも仕事が気に入ったらやるんじゃないの、dankogai的スーパープログラマは。dankogaiも当該エントリではそれがプログラマの習性だと述べている。

ソフトウェア工学とスーパープログラマは両輪 - novtan別館

『あなたが望む(ような)体制をスーパープログラマーは選ばない』ことと、彼らが仕事を気に入るかどうかは関係ない話なんじゃない? 体制を選ぶことと仕事を選ぶことをごっちゃにされてもね。

あと優秀な人にスタッフをつけてあげれば、気に入らない仕事をスタッフにまかせて、気に入る仕事に集中してもらうことができるよね? Dan氏も書いているように、彼ら(スーパープログラマー)は延々と自分が好きな仕事を見つけてはそれに没頭しちゃうんだから、気に入る仕事がない状況を心配する必要はあまりない。それより気に入らない仕事をしなきゃいけない状況を心配するべきで、そのためにサポートスタッフをつけてあげればいい。

ようは、『あなたが望む体制はスーパープログラマーに選ばれないってこと』は理由になってないってこと。


それは、スーパープログラマ以外の人も含めて、業界全体の生産性を高めようとするソフトウェア工学が間違っていると言ったからだよ。スーパープログラマで需要が満たされるのであれば、ソフトウェア工学はいらない、ということだからその前提はおかしい、と言っているわけだ。もし、そういう前提じゃないんであれば、そもそもこの話は成り立たないわけだから。

意味わかんねー。

単に生産性の高い人の能力を引き出すというだけの話が、なんで『スーパープログラマで需要が満たされる』とかになるわけ? だれかがスーパープログラマーだけで需要は満たす事が可能だと言ったの? また脳内で補完してるのかい? 想像力が豊かだね。


それはある意味正しくて、ある意味間違っている。能力差による違いが顕著になる物量と、能力によらず一定時間を消費する物量が存在する。そして、ソフトウェア開発において、前者の物量も、後者の物量も、どちらも存在する。プログラム書く一つをとっても、10000行を書くのに費やす時間がそれほど大きな差になるかどうか。効率の悪い開発者でもタイピングだけは早かったりする。

なあ、キミはコードを書いた事があるのか? 『10000行を書くのに費やす時間がそれほど大きな差になるかどうか』ってマジデスカ?! キミにとってはコードを描く作業が『能力によらず一定時間を消費する物量』なのか?!

あれか、Java の getter と setter を IDE でチマチマ生成する作業のことを言っているのか? それとも import 文が 10000 万行でもあるのか? もしそうだとしたら、Java は行数を水増ししてくれる便利な言語という地位をさらに確固たるものにしてくれるだろう。


もちろん、10000行を8000行で済ますことができる場合もあるし、設計しだいでは1000行になるかもしれない。こういう部分では確かに差が出るんだけど。

10000行が1000行になる意味が分かってますか? コードを書く作業が減るだけじゃないんだよ、仕様書やドキュメントを書くコストが下がるし、いちばん大事なのは保守性が高まってメンテナンスコストが大幅に下がることなんだよ? 今までの発言を見ていると、10000行が1000行になってもコーディング作業のコストが下がるぐらいにしか思ってないんじゃね?


そして、設計書作成やテストにおいて、その差の出なさ加減は顕著だ。でもって、標準化やテスト技法の進化によって、差が出る部分の度合いを埋める努力は日々行われている。

もう、ここで意見が決定的に違うよね。設計書作成やテストで能力の差がでないわけがない。『その差の出なさ加減は顕著だ』って、本気で言っているのか? なんで設計書作成やテストで能力差がでないのか、その根拠が知りたい。


ほら、プログラマーの話になっているじゃん。

は? なんで『プログラマーの話』に限定しちゃうわけ? 物量を削減するのはプログラマーしかできないとでも思ってるの? プログラマーの話にしたがってるのはそっちじゃん。


あと、ここで言っている物量は、成果物の物量ではなくて、作業の量の話だよね。大規模プロジェクトにおいて、成果の管理をどう行うかもソフトウェア工学の重要な視点だと思う。

『物量』って言葉を使ったのはそちらなんで、同じ言葉を使っただけ。別に作業量の話に限定した覚えはない。

なんかさ、話を勝手に限定しないでくれる? キミは想像力が豊かすぎるよ。


だから、それはたとえが悪いんだって。世界の頂点に立つ限界ぎりぎりの戦いだから「簡単に出ないものを無理に出す」わけじゃない。そういうニュアンスを無視して考えるならわざわざオリンピック選手なんて極端な話にする必要ない。体調管理とか、タスク管理とか、そんな程度のことも自分で出来ないからスタッフをつけるってわけじゃないでしょ。

たとえが悪い? チーム北島の話だけじゃなくて漫画家とアシスタントの話も例として出しているのに? ほかの人は普通に理解できていることを、キミの豊かな想像力が「スーパープログラマー」と「オリンピック」を結びつけてしまったために誤読を引き起こしているだけじゃないの?

それに『搾り出す』と「絞り出す」の違いがわかんないのは、たとえとは関係ないよね。キミの国語力の問題。

#違いが理解できました?


そうじゃないプロジェクトを減らすためにソフトウェア工学を否定する必要があるわけ?むしろ、そういうプロジェクト管理手法をきちっと適用してもらうことでプログラマーが楽に働ける環境になるんじゃないの?

なんかもう話がずれまくってるわ。『優秀な人の能力を引き出す』『属人性の排除は間違い』というだけのことが、なんでこんな話になるんだよ。


という話だから、需要における現実性とコストの面から言うと、折り合わないというのが僕の主張。だから、ソフトウェア工学は有用。出せる金と、求める信頼性において「安くていいもの」「高くていいもの」「安くてそこそこのもの」が提供できるのがよい。「高くてダメなもの」をどう排除していくか。これも一つのテーマだと思う。

で、そのソフトウェア工学様が属人性をなくしてくれたおかげで、安くていいものが提供できるようになったわけ? プロジェクトの失敗はなくなって、お客も開発者もみんな幸せになったわけ?

なってねーからみんな文句いってるわけじゃないの? 属人性を排除したらプロジェクトが成功するなら、みんな喜んで排除するよ。


30倍からだいぶ縮まりましたな。

そりゃそうだ、「月70万と140万」の場合の話なんだから。月70万と140万なら、4〜5倍がせいぜいじゃない? 金額を指定しなければ、できる人とできない人で30倍の開きぐらいあるでしょ。

30倍がどのくらい現実的なのかイマイチわからなかったんだよね。倍で4〜5倍なら、月210万くらいなら30倍のパフォーマンスなのかなあ。

自分の読解力がなかっただけだろが。どのくらい現実的かどうかなんて関係なく解釈できる文章を、キミは正しく解釈できなかっただけのこと。それを『30倍がどのくらい現実的なのかイマイチわからなかった』なんて、ごまかしてんじゃねーよ!


単純に値段が高いことが能力の差に現れないことが多いですね。SIerにおける人材というのは、

  • プログラムができる
  • 設計ができる
  • 全体設計のビジョンが作れる
  • いろいろ客に説明できる
  • 業務要件分析してシステム設計できる
  • X人のチームを監督できる
  • 特殊な技術領域に精通

等のさまざまなスキルによって値段がある程度決まってくる。そこに生産性という指標はなかなか入ってこないんだよね。だから、生産性という点で140万の人が70万の2倍の生産性がでるかというと、そういうわけでもない。

『生産性という指標はなかなか入ってこない』んじゃなくて、キミ(またはキミのプロジェクト)がそれを入れてないだけじゃ? あとスキルと生産性を切って話すのはなぜなの? たとえば『業務要件分析してシステム設計できる』スキルがあれば、その分野では明らかに他の人より生産性が高いといえるよね? まさか「業務要件分析してシステム設計できる人でも特殊な技術領域に精通しているとは限らない」とか言い出すんじゃないだろうな。


それは、生産性という言葉が当てはまらないからかな。

なんでやねん!?


生産性に差が出ることが、属人性を排除することが誤りである理由であるならば、それが間違っているといいたいから。

確認するけど『それが間違っている』というのは「生産性に差が出るということが間違っている」という理解でOK? (キミの文章はわかりにくいから、設計書を書くのは勘弁してくれな、開発者がみんな困る)

で、もしそうだとしたら、個人間に能力差があるにも関わらず「生産性に差が出るということが間違っている」という根拠は何?


仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。

従来のソフトウェア工学が決定的に間違っている点 - kなんとかの日記

これは、上で述べたスキルをもった人材、ということだと思うんだけど、この文章自体は大いに同感なわけです。ただ、ソフトウェア工学の要不要とは結びつかない。

『属人性は排除できないし、人材の替えはきかない』ということには同意してるということ? もうなんか主張がコロコロしてわかんねーよ。

じゃあこれでどう?

  • 従来のソフトウェア工学は、属人性を排除しようとしている点において、決定的に間違っている

これならキミでも同意できるんじゃない? 先の文章に同意しているのであれば。


繰り返しになるけど、ソフトウェア工学の属人性排除が個人の生産性の差を理由に否定されるのであれば、生産性に差がつく場所の話をしなければ意味がないでしょう。コーディングだけじゃなくて、テストもそうだと思う。そして、差がつかないところも沢山あるんだよ、というのが僕の主張。

『生産性に差がつく場所』は、どこでも。『差がつかないところ』は沢山もない。その根拠は、差がつかないようなところはたいがい自動化できてしまうから (最初から書いているけどね)。本来なら、差がつかないようなところが残っていること自体を問題にすべき。

つーか、『設計書作成やテストにおいて、その差の出なさ加減は顕著だ』なんて言ってる人間が存在すること自体が意味分からん。あまりにも斬新すぎる考え方なので、その根拠をほんと教えてほしい。


ソニーが「新型ゲーム機」評価スタッフを募集中

| 23:43 |  ソニーが「新型ゲーム機」評価スタッフを募集中 - kなんとかの日記 を含むブックマーク

ソニーが「新型ゲーム機」評価スタッフを募集中 (ITmedia)

これって単にデバッグ要員を募集しているってだけだよね? なにが『評価スタッフ』だよ。

でも『新型ゲーム』じゃなくて『新型ゲーム機』なんだよね。ほんとかな。

ワシの予想: PS2 のサポートを復活させた PS3 が登場

NeoCatNeoCat 2009/02/25 10:31 Mac OSではメモリ使用情報を収集するのに時間がかかるらしく、これを top -RFX とオプション指定で抑制あげると負荷が下がります。あと、ソート順がCPU順でないので -u オプションもつけると良いと思います。

サスケットサスケット 2009/02/26 12:36 >つーか、『設計書作成やテストにおいて、その差の出なさ加減は顕著だ』なんて言ってる人間が存在すること自体が意味分からん。あまりにも斬新すぎる考え方なので、その根拠をほんと教えてほしい。

斬新どころか、属人性を排除しているんだから普通に差は付かないでしょ。

テスト項目なんて、属人性排除を排除して、「こうしてこうなったらOK」ってテスト計画書に書いてあるんだから、延々こなすだけ。
スーパープログラマー様はエンターキーを押す速度がそんなに速いのかと。

設計書(特に詳細な部分)も属人性排除してルールができている局面では差が付かない。
画面設計書で、画面に項目並べるのにそんなに差が出るのかと。


要するに、「属人性を排除する意味が無い」という前提で考えるからそうなる。
エントリのような思考で入るっているあなたは、意味が無いと思っているからきちんと人に依存する部分を普段から排除しようとしていないんだよ。前提が違うわけ。
で、あなたは排除できてないから「差が付く」と思ってしまう。


『設計書作成やテストにおいて、その差の出なさ加減は顕著だ』というよりは、『設計書作成やテストにおいて、属人性を排除しやすい(ので差の出なくなり加減が顕著だ)』
と読めばいいんじゃないか。

前提を誤ってはいけない。あなたが反論を述べている相手は属人性を排除することをメリットと取って実践しているんだ。
差をなくしている人、無くそうとしている人に何言ってんの。

「そのプロセスで属人性の排除はできない」という反論ならともかく、「差がでない(属人性の排除ができる)なんてありえない」なんて反論意味不明に過ぎる。




そもそもさ。
あなた自身「差がつかないようなところはたいがい自動化できてしまうから (最初から書いているけどね)。」と書いている以上、属人性を排除して機械的に誰がやっても同じ処理をこなすことにメリットを得ているんじゃないか。

あなたの論理なら自動化なんて定型処理しかできないバカ機械に任せないで、スーパープログラマー様が有り余る能力で5倍30倍で処理してくれるほうがいいんじゃないの?何であなたの論理下で自動化させているの?矛盾してるじゃん。

みーみー 2009/02/27 02:12 >>サスケット

>テスト項目なんて、属人性排除を排除して、「こうしてこうなったらOK」ってテスト計画書に書いてあるんだから、延々こなすだけ。
>スーパープログラマー様はエンターキーを押す速度がそんなに速いのかと。
テストってのはテスト仕様を作る(and 記述する)作業の事だ。テストの実行は自動テストしろよ。

>『設計書作成やテストにおいて、属人性を排除しやすい(ので差の出なくなり加減が顕著だ)』
と読めばいいんじゃないか。
設計とかどう考えても一番属人牲が残る所だろ。違うというなら、要求定義から設計を機械的にせいせいしてみろよ! というか、その方法を教えてくれマジで。

>そもそもさ。
>あなた自身「差がつかないようなところはたいがい自動化できてしまうから (最初から書いているけどね)。」と書いている以上、属人性を排除して機械的に誰がやっても同じ処理をこなすことにメリットを得ているんじゃないか
お前の国語力は0か? 主張してることは「属人せいが排除できるようなことは自動化できるのだから、残った人手でやる部分は属人性が強く出る所だから、人によって生産性の開きがでかい」という意味だろ?

批判するにしても、もうちょっとまともな論理で批判してやれよ。

サスケットサスケット 2009/02/27 08:54 はい、アウト。


>テストってのはテスト仕様を作る(and 記述する)作業の事だ。テストの実行は自動テストしろよ。

テスト計画は人に依存する。それはOK。
テストの実行は自動化可能=属人性を排除している

属人性を排除している

もう一度いいます。

自動化=属人性を排除している。


>設計とかどう考えても一番属人牲が残る所だろ。違うというなら、要求定義から設計を機械的にせいせいしてみろよ! というか、その方法を教えてくれマジで。

レベルの問題をわかってない。
属人性を排除=全部機械化、全部何も考えなくていいというわけじゃない。

△人に依存する場所をゼロ
△人に依存する場所を減少

でも属人性を排除している。
具体的にいえば、ルール化できることはするわけだ。設計書作成の規約を作ることで規約にのっとる部分が『属人性の排除』となる。ということは書いたてるだろちゃんと。→ルールができている局面では
国語能力の前に注意力を鍛えなさい。あるいは、あなたが単に『属人性の排除』をするためにどうするかという経験が無いだけ。『属人性の排除』=機械的とか短絡的杉。




>お前の国語力は0か? 主張してることは「属人せいが排除できるようなことは自動化できるのだから、残った人手でやる部分は属人性が強く出る所だから、人によって生産性の開きがでかい」という意味だろ?


ワーイ、自動化するんだ?自動化するんだ?自動化するんだ?
なんだやっぱり「属人性を排除している」んじゃないか。
私は(残ったところを人がやるのは当然だけど)『属人性の排除が必要』と言ってるんだから、それでいいんだよ。

きみ、これ読んでないんじゃないの?

>『優秀な人の能力を引き出す』『属人性の排除は間違い』というだけのことが

>じゃあこれでどう?
>従来のソフトウェア工学は、属人性を排除しようとしている点において、決定的に間違っている
>これならキミでも同意できるんじゃない? 先の文章に同意しているのであれば。

この人は『属人性の排除は間違い』と言ってるんだよ。
私はそれを否定してるんだよ。

「属人せいが排除できるようなことは自動化できる」とか・・・排除できたら駄目だろこの人的に。
この人は『属人性の排除は間違い』と『明記』しているんだから。明記している。もう一度言うけど、『属人性の排除は間違い』と書いてある。国語能力の前に注意力を鍛えなさい。擁護とみせかけて首絞めてやるなよ。やっぱり『属人性の排除は必要』なんだよねー。


もう一度言うけど『属人性の排除は必要』

故にアウト。

サスケットサスケット 2009/02/27 08:56 ごめんなさい、こうだね。

△人に依存する場所をゼロ
○人に依存する場所を減少

鴨澤眞夫鴨澤眞夫 2009/02/27 13:18 topはそもそも「負荷が高くて自分が一番上に来ちゃうからtopと名付けた」と聞いたことがありますが…それはさておき。
ウチでは
top -ocpu -s5
をtopのaliasにしています。-ocpuでCPU時間によるソート、-s5で5秒後とのサンプリングです。

これでもやはりCPUコアごとの負荷は出ませんが、1個のCPUに対する負荷として出てくるので、たいがいは間に合っています。