パスワードを忘れた? アカウント作成
16897 story
プログラミング

自分のコードに誇りを持っていますか? 61

ストーリー by mhatta
人生相談 部門より

pinbou 曰く、

本家/.の記事より。ある悩めるプログラマからの問いのようだ。

私は自分のコードの品質のせいで、ひどく恥ずかしい思いをしています。私の書くコードはバギーで、遅くて、脆弱で、保守するのも一苦労です。同じような思いをしている方はいませんか? もしあなたもそうなら、何があなたの潜在能力の開花を阻んでいるのでしょうか? もっと大事なこととして、こうした状況を打破するために何かやろうとしていますか?
私は若いころからプログラミングを楽しんでいて(Apple IIe上のBASICで覚えました)、いろいろな言語やプラットフォームを使い、大小様々な企業で働いてきました。悲しいことに私のキャリアで一定していたのは、私が割り当てられるプロジェクトは、プロジェクトの開始からお客さんの資金が無くなるまで、あてどなく漂流してしまうということです。ここ/.に集う開発者で、自分の企業を説得して「カウボーイ風コーディング」を止めさせるか縮小させるかし、ベストプラクティスを導入させるのに成功した人はいませんか? 誰か自分の上司に、お客がいつも正しいわけではないこと、たまにはノーと言うのが一番のこともあるんだよと説得できた人はいませんか?
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by okky (2487) on 2007年12月19日 11時46分 (#1268118) ホームページ 日記
    私の書くコードはバギーで、遅くて、脆弱で、保守するのも一苦労です。

    なのに
    ここ/.に集う開発者で、自分の企業を説得して「カウボーイ風コーディング」を止めさせるか縮小させるかし、ベストプラクティスを導入させるのに成功した人はいませんか?

    というのは何か間違っている。

    この人の場合、2つの異なる障害があって、それが複合的にプロジェクトの息の根を止めていると思われる。会社を直すのはより時間が掛かるので、まずは自分を治すことからはじめるべきだろう。

    プログラムが『バギーで、遅くて、脆弱で、保守するのも一苦労』な状態になるのは、

    ・熟慮されたアルゴリズムを用いず(バギー、遅い)
    ・計算量を事前に予測せず(遅い)
    ・例外が多く(バギー、脆弱、保守が大変)
    ・目の前の問題を直せばよい、と修正を最小化使用としすぎるから(保守が大変、脆弱)

    である事が多い。これを直すのは一筋縄ではいかないが、

    1) まずはアルゴリズムの勉強をする
    2) 特に「計算量」の勉強をする
    3) アルゴリズムの勉強には「マクロ」レベルからビット操作などの「ミクロ」レベルまであるが、その全てを勉強する事で「例外」を減らす
    4) 常に「問題の本質」について考え続ける(症状消しをしない)
    5) socket プログラミング、multi thread など、マニュアルを見ただけでは判らない事が続発する領域に関しては、本を読みまくる。他人のコードは「本を読んだ後」の方が良い。腐ったコードの方が世の中には多いので、間違ったコードを覚えてしまう確率が異様に高いからだ。
    6) コンパイラ…特にオプティマイザについて勉強する。すると、最近のコンパイラは「わかりやすい記述」をしたほうが最適化が進むことがわかる。すると、「半端に凝った記述」をしなくなる(保守性向上)

    というプログラミングの勉強と、

    7) コードを書く前に、そのコードが何をするものなのか、文章で書いてみる。で、その通りに本番コードとは異なるプログラミング言語で書いてみる。すると曖昧な部分が判るので、文章を直す。それから本番コードを書く。するとなぜかバグが減る(曖昧な部分が減るため)
    8) 明文を書く練習をする

    という、実はプログラミング以外でも鍛えられる属性を鍛える訓練を続ける。

    結局、知識が圧倒的に不足し、その知識を全てロードしようとすると脳がパンクする所に問題があるのだ。脳の容量を拡張し、マニュアルを見れば判るような知識は捨て、もっと本質的なことを覚えると良い。

    二言で言い換えると、「努力不足」「プログラミングを舐めるな」になるんだと思う。
    --
    fjの教祖様
    • >目の前の問題を直せばよい、と修正を最小化しようとしすぎるから(保守が大変、脆弱)

      必要なときに、壊して一から書き直す手間を省くからそういうことになる。
      カウボーイだかエクストリームだか知らないけれど、とりあえず書いて動かすなんて手抜きが許されるのは必要があればいつでも捨てて書き直すという約束が守られる間だけだ。
      最初はプレハブや掘っ立て小屋でも構わない。何が建つかも分からないうちから丈夫な基礎を作っても無駄だ。でもそれを大きくしたいなら、基礎から造り直さなきゃ丈夫なビルは建たないってこと。
      • by oldwave (20436) on 2007年12月19日 15時27分 (#1268402) ホームページ 日記

        この前、レビューを頼まれたソースコードはひどかったですね。読んでいて「このコードを書いた人は、この関数がどのように動作すると正しい動作と言えるのか、厳密なイメージが描けていないな」ということが、ありありとわかるのです。おそらく、仮組みしたコードを動かしてみながら、例外的なパターンを後から発見し、アドホックに完成に近付けていったものに違いないのです。

        僕自身は探索的プログラミングの信奉者で、コーディング前に綿密な設計が必要だとはあまり思わないのだけれど、こういう事例を見てしまうと「コーディングにはその前提となる設計が必要だ」ということをもっと強調した方が良いのかも知れないと思ってしまいます(もちろん探索的プログラミングは、コーディングを通じて「より良い設計」を追求するのであり、設計が不要だという主張はまったく持っていないのですが)。

        やはり、ソフトウェア開発における「生産」はコンパイルであり、コーディングは「設計」なのだということをもっと多くの人が知るべきなのでしょうね。プログラマーは誰でも設計者になる意識を持たないとダメですよ。

        親コメント
      • まぁ、そのプレハブでも流用しやすいように、壊す規模は最小限で済むように組むって
        努力は怠ってほしくないけど

        だれだこの...2KLもある関数作った奴は...

        ってのは良く聞く話
        親コメント
        • 壊す規模は最小限で済むように組む

          うーん、これはどうなんだろう。私はあまり気にしない。

          これが可能になるためには、プログラムを「フレームワーク(骨組み)」と「肉付け」に分離する、といったことを意識してコーディングする必要がある。

          しかし、ちょろっと書く程度のプログラムで、これらを意識するのは、それ自体重たい作業。エクストリームなどでこれを最初から意識するのは辛かろうし、そもそも「ちょちょいと書いてみる」という方針には合わない。

          なので、そんなことは意識せずに書き、『ゴッソリと捨てる』事を勧める。
          大事なのは『ゴッソリと捨てる』前に、「なぜ捨てる必要があったのか」「何が悪いのか」をきちんと記録すること(文章の形で)。他の人に見せる必要は無く、「意識するべきポイント」をはっきりさせるために、これをやっておくと良い。
          # 大抵の場合、全部捨てて書き直すことになるけれど。

          あと、「書き直す」時には「使えるフレームワークが世の中にはすでに無いか」調べること。書き直すのだから、フレームワークにどういう機能があると良いか、イメージはできているはず。それを探してみる。見つかる可能性はあまり高くないけれど、見つかった場合は「世のほかの人達とバグを共有できる」のでbug fix が楽になる。

          だれだこの...2KLもある関数作った奴は...

          大丈夫。全部捨てることになるに決まってるから (^o^)。

          # 商用ソフトの場合書いた行数より削った行数の方が多い気がする…。
          # 三項演算子を if/else に直す等、書く場合は行数が増えているはずなのに…
          --
          fjの教祖様
          親コメント
          • その手の2KLの関数とかって、作った本人はそれで良かれと思って
            その後になって発覚しませんか?

            作り直すのにお金がもらえるなら良いんですが、ボランティアじゃ困りますよね
            無論作った当人がやるならそれでも良いんですが...大抵消えてたり...

            一人で作ってたり使い捨てとわかっているソースなら良いとは思いますけど
            それは客先に納品する製品では出来ないのでは?
            今後一生修正しないソースってのもありえないだろうし
            親コメント
  • by Tak.M (6722) on 2007年12月19日 11時53分 (#1268127)
    > 私は自分のコードの品質のせいで、ひどく恥ずかしい思いをしています。

    こう思ってくれる人なら、今は悪くてもそのうち良くなるよね。
    自戒しない人は、何度指摘しても、次から次へとゴミを増産してくれる。

    • いやでもApple IIeの頃からコーディングしてて、今もこれだというのは
      ちょっとどうなんでしょぅね。反省だけなら猿でもできるというか、
      実践の伴わない反省には価値がないわけで。

      #自分も今までの人生で反省だけはたくさんしてきたので自戒をこめてID
      親コメント
      • ここにつけるのは不適当かもしれないし、議論に水を差したら申し訳ないけど。

        私は「ひどく恥ずかしい思いをしています」ってのは釣りというか、他の人に発言させやすくするためのリップサービスだと思います。「Apple IIe上のBASICで覚えました」ってことならキャリアは普通に考えれば15年以上。「あてどなく漂流してしまう」仕事ばっかり、それだけの間続けられると思います?その間には成功体験がどこかであるはず。しかもこの人、曲がりなりにも「いろいろな言語やプラットフォームを使」えるくらいの柔軟性があって、「大小様々な企業」の人事担当者なりが「この人だったら採用したい/任せてみたい」と思わせるような人なんです。自然に考えると成功体験もそこそこあるんじゃないでしょうか。

        # 最初大手で、失敗続きで訳あり小企業しか雇ってくれなくなったってパターンかもしれませんが。

        「バギー」ってのは最初の内部コンパイルが通った後は0.1件/KLOC。「遅くて」っていうのが「同じ仕様のSTL実装に負けました」ってレベルで「恥ずかしい」んだったら、私も自分の実力には大変恥ずかしい思いをすることになるでしょう。

        もちろん、何年経っても腕が上がらない人はいるでしょうけど、そんな人がこんな問題提起をするかな。本当は、身近にいる「数年やっているんだけどなかなか腕が上がらない人へのよきアドバイス」を求めているような気がします。

        # 深読みしすぎ?

        とはいえ、そういう人を想定してアドバイスなり意見なりを/.jpの住人が述べることには文句はありません。むしろ、各々の発言は興味深く読ませていただいてます。

        --
        vyama 「バグ取れワンワン」
        親コメント
    • 自戒するだけの人はそこから前進しません。
      えてして嘆く人間は自分では前に進もうとしません。
  • よくあること (スコア:5, おもしろおかしい)

    by icecream (33977) on 2007年12月19日 12時01分 (#1268135) ホームページ
    今朝目覚めたら、自分のベッドに知らないコードが寝ているんです。
    しかもコメントとかつけてないんです。全裸です。

    昨日飲んだ所までは覚えているんですけど・・・
    • Re:よくあること (スコア:5, おもしろおかしい)

      by Anonymous Coward on 2007年12月19日 13時19分 (#1268249)
      そのときは一夜限りのテストと割り切って
      二度と使わないつもりだったんですけど
      結局、関係はずるずると続いてしまって…

      まったく個人的な付き合いのつもりが
      いつの間にか同僚や上司にバレてしまい、
      「責任取れよ」と清書まで求められる始末です
      親コメント
  • by gonta (11642) on 2007年12月19日 11時50分 (#1268122) 日記
    自分の過去に書いたコードは、目を覆いたいものばかりです。先輩やオープンソースのコードを眺めて、ある程度「見られる(可能)」品質にあげたいなぁ。上記2例は、かなりいいお手本です。

    お客さんとのやり取りであったのは、自分が仕切るときは徹底的にやります。間に1社入ったときは「いわれたことだけ」に切り替えます。

    とても安く買い叩かれていたサーバ構築の案件だったんですが、単純・費用を安く・止まらない(=ありえないでしょう)構成を求めてきたので、散々うだつのあがらない会話をして、
    「これ管理するとしたら、月いくらで管理しますか?」ときたので、
    「管理しません!」
    とはっきり断りました。地雷は埋まっているかもしれないから怖い。地雷が埋まっているとわかっている道は、歩かない。

    ちょっとプログラミングからは話がそれましたが、内容的にも金額的にも納得しない仕事は、作業量・品質もスルーして「やりっぱなし」にしたほうがいいとおもいますよ。PHPを安く受けている連中の話聞くと、担当者がもういなくなった、当時のやっつけ仕事(=品質管理なんかあるわけが無い)が、近々大更新(PHP4->5もあるし)するようです。人材確保できてんのかなぁ。
    --
    -- gonta --
    "May Macintosh be with you"
  • by AcDcPwr (32146) on 2007年12月19日 12時31分 (#1268178)
    設計や物作りに携わっている人達の共通の悩みかと思いますけどね。

    私も自分で設計した物や作った物を、後から見て恥ずかしくなることは良くあります。

    自分で設計して図面も引いた案件で、実際竣工して現場を見てみたら、自分の浅はかさに気がついた・・・とか
    運用してみたら現場の保全要員からだめだし食らった・・・とか

    法律や卓上、技術的には問題なくても、設備全体(運営や保全も含めて)として優秀かどうかというとそうではないですからね。

    まぁ、自分で恥ずかしいと思えるってことは、改善の必要があることに気がついてるんだから気が付かないよりはましですね。
    技術屋は日々勉強して、自分のスキルを磨くのも仕事(それとも趣味か?)のうちでしょう。

    いつかはどこに出しても恥ずかしくないものを作ってみたい物ですけどね。
    好きなだけ予算使わせてくれれば・・・って野暮な突っ込みは無しにしてください(笑)
    限られた予算で最良の物に仕上げるのも技量のうちでしょうから
  • 何層離れているか (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2007年12月19日 11時16分 (#1268100)
    クライアントとの間に中間層が無いシンプル(小規模)なプロジェクトであれば、
    クライアントの真のニーズを引き出し、期間・コスト上の現実的な解を示しつつ、
    クライアントと共により良い解を模索し、認識を一致させる事は可能です。

    中間に営業担当等が一人入る辺りまでは、
    自身のコミュニケーション能力・マネジメント能力のみで何とか...。

    間に一社、複数の担当者が入ると、もう運の要素が多くなりますよね。

    二社以上入った日にゃ
    「言われた通りにやればいい」的な意味で
    責任意識が薄れるので、逆の意味で平気(をい)
  • by Anonymous Coward on 2007年12月19日 11時46分 (#1268119)
    個人的には「論理的に考えられていないコードであること」だと思います。
    全ての兆候は、小さなTYPOや意味不明なコメント。
    首をかしげるのは、統一されていないネーミングや実装方針。
    確信を得るのは、他人が読めなくなるような妙なテクニックの乱用や、名称と内容の不一致。
    結論は、構造からして全てが論理的に正しくない。

    しかも、そういう人に限って「こんなに色々な言語使えます」=構文しってても構造化すらできない
    「ループの数減らして速度あげました」=無関係な処理をひとつにまとめるなボケ
    「デザインパターン適用しました、シングルトンです」=どう見てもグローバル変数
    と小手先の技や見ためばかり学ぼうとしてコケている気が。努力の方向性が間違っているのでは?
    # 誇り?昨日書いた自分のコードには不満があります。成長してますから:-P
    • by TarZ (28055) on 2007年12月19日 11時53分 (#1268128) 日記
      # 実体験に基づくものだとは思いますが、例が悪すぎるというか、極端すぎるような気も…。
      ## コードは非の打ちどころがないけど仕様を満たしていない、なんてケースもありますし。

      # 誇り?昨日書いた自分のコードには不満があります。成長してますから:-P
      昨日書いた自分のコードが読めないのですが、これは進化なのでしょうか、退化なのでしょうか。
      親コメント
      • by Anonymous Coward on 2007年12月19日 12時28分 (#1268173)
        キャプテンPG 主題歌
        「君はコーディングができる」

        若い日はみな デスマで疲れ
        書いたソース 自分もわからないよ
        夢でデバッグしよう
        とても 追いきれないよ
        納期よりもっと 大事なことは
        バグを出して 自分を試すことだ
        君はコードが書ける
        誰もコードが書ける
        RFP 燃やせばそれで
        心も体もさわやかだ 僕らは
        若い日はみな 徹夜で逝けよ
        ( ゚д゚ )
        こっちみるなw 白目を向いて逝くなw
        それがデバッグなんだ
        それがデバッグなんだ

        泣ける日もある そんな時には
        バグだろうが 仕様と突き放せよ
        君が仕様をだした
        僕も仕様をだした
        この胸が今 すがすがしいよ
        きのうよりも
        ソースが大きくなった
        これでエンバグ増えた
        これでエンバグ増えた
        体脂肪 増えるにつれて
        心も体もやさぐれた
        二次元に 萌えればそれで
        心も体もさわやかだ
        僕たちは
        親コメント
  • 通信販売?(オフトピ-1 (スコア:2, おもしろおかしい)

    by Lurch (10536) on 2007年12月19日 11時48分 (#1268120)
    >私の書くコードはバギーで、遅くて、脆弱で、保守するのも一苦労です。
    そんなあなたに、怪しげな商品を紹介する記事かと思ったのは内緒です。
    --

    ------------
    惑星ケイロンまであと何マイル?
  • by Anonymous Coward on 2007年12月19日 11時48分 (#1268121)
    - 能力のない人に能力を上回ることをさせない
    - 正確な伝達ができない者をあいだに挟まない。
    - 裏づける判断力もないのに空約束する者をあいだにはさまない。
    - 受注だけでは成果にせず、納入までを責任範囲とする。

    # 次どうぞ。

    • > 能力のない人に能力を上回ることをさせない

      それだと成長しないので、能力をやや上回るくらいのことをさせるのが良いと思います。もちろんバッファは用意しておいた方がいい。

      その場限りの(プロジェクト|人)ならそれでもいいけど。
      親コメント
      • 論旨には賛成です。
        その論旨とは外れたところで恐縮ですが、

        もちろんバッファは用意しておいた方がいい。

        個人的に、この「バッファ」という言葉の使い方にいつも違和感を感じるのです。この言い回しを使う人、沢山いるのですが。
        この場合「マージン」が正しいと思っているのですが、私がおかしいのでしょうか。

        いや、つまらん話で誠に申し訳ない。難癖つけるつもりはありません。
        親コメント
  • by alcus (32114) on 2007年12月19日 12時14分 (#1268149)
    「そんな特殊な例は考えなくっていいよ」って言われた、
    その特殊だったはずの例が将来「不具合だ!」って騒がれることに。

    ある意味、死亡フラグ?
  • by Hatris (33732) on 2007年12月19日 12時16分 (#1268153) 日記
    >お客がいつも正しいわけではないこと、たまにはノーと言うのが一番のこともあるんだよと説得できた人はいませんか?

    というのは、システム設計上の問題に関係する部分だと思うんだけどなぁ。
    コードにいちいち文句をいうお客に対して困っているのであれば、私の巨大な勘違いですが、とりあえずシステム設計に対しての問題点であると仮定してみる。

    本人が一番気にしている筈の部分は、文頭の

    >私は自分のコードの品質のせいで、ひどく恥ずかしい思いをしています。

    って部分。
    そんな悪い品質のコードを書いちゃう原因ってのは、そもそも物事の考え方に問題があるからじゃあないかと思う。
    原文を読んでいるわけではないので、誤訳やニュアンスの違いがある可能性もあるのだけれど、
    その辺一切は棚に上げておきます。

    良い品質のコードを書くには、
    ・求められている役割(仕様)を正しく理解する
    ・仕様に足りないもの(穴となるであろう部分)を見つけ出す
    ・必要以上に複雑にせず、見やすいコードを書くように努める
    そして、
    ・コードが仕様通りに機能し、不具合が発生しないことを検証する

    なんてことは/.でわざわざ言う話じゃないか。
    (むしろ元ネタを離れてツっこまれそうで・・・)

    トピ趣旨からは外れますが、ありがちだけどなかなかできない事に、
    「金に見合う仕事をする」
    ってのがあると思うんですよ。

    夢を見すぎた仕様だけど、お金はこんだけー な感じで、
    それをスタート時に夢から覚めぬまま始めちゃうと、
    途中でお金無くなって、全てが中途半端なままになっちゃうと。
  • なるべく単純に、無駄が無く、重複が無いように心がけてます。
    単純にするために、アルゴリズムを目で追えるように要点だけをまとめたものを上位におくようにしています。
    無駄を無くするために、不必要な変数をなくしたり、意味の無い処理を削ったりします。
    重複を無くするために、同じ処理を複数箇所に書かないこと、同じ条件は一箇所にまとめることを心がけてます。

    自分の過去のコードの反省と、メンテ要員の質が悪すぎでとんでもないことになってたソースを眺めた経験からこうするようにしました。
    心がけなんで、実際のコードはまだまだ直すべきところが多いんですが。
  • by Anonymous Coward on 2007年12月19日 11時25分 (#1268103)
    もっと大事なこととして、こうした状況を打破するために何かやろうとしていますか?

    PCの前に座らず、
    ソースを書かないでいる時間を増やすこと、ですかね。

    助さんが刀を抜くのは、番組後半。

    • by rascal (33552) on 2007年12月19日 15時19分 (#1268390)
      >助さんが刀を抜くのは、番組後半。

      最後は印籠で無理やり治めるので、あまり本気で刀を振るう必要もないのであった。
      親コメント
      • Re:さらに言えば (スコア:1, おもしろおかしい)

        by Anonymous Coward on 2007年12月19日 19時11分 (#1268590)
        しかし印籠を持ち出すのは、何故か悪代官クライアント側なのであった。
        親コメント
        • 『入らん。』
          「そこをなんとか入りませんかね。」
          『これじゃ検収無理だね』
          「今月形だけでも検収いただかないとこちらも回らなくなりますのでなんとか。」
          『とはいってもこっちも首かかってるしねぇ』
          「3ヶ月間常駐して無償で対応しますから。」
          『半年だねぇ。』

          # この作品はフィクションのはずであり、実在の人物団体等は一切関係ないと思われます。
          ## まぁ微妙にリアリティ無いけどな。
          親コメント
  • by NOBAX (21937) on 2007年12月19日 11時38分 (#1268112)
    という定義が必要でしょうね。
    メモリ容量がなかった時代は簡潔で短いコードが良しとされました。
    今はメンテナンスが容易なコードでしょうか。
    時代と共に品質の示すものも変わるでしょう。
    • by Anonymous Coward on 2007年12月19日 13時14分 (#1268242)
      高い凝集度、低い結合度、高いテスタビリティ。 良いコードと呼ばれるためには、これらが必要条件である。
      親コメント
    • メンテナンスが容易 というのにもイロイロな定義・解釈がありうると思うのだが、
      たいていの場合、短くて簡潔に書かれたコードはメンテが容易だと思うよ。

      変数名を1文字だけにするとか、スペースや改行を置かずに詰めて書くとかの
      ムリヤリな短縮化はしない方がいいけどな。

      しかし、元記事のヒトはApple IIeなんて時代からプログラム書いてるのに、
      短く簡潔に書こう!みたいなクセが付かなかったんだろうか。
      オレ、NECのパピコンあたりからプログラム書いてるけど、いつも
      もっと短く、速く走るようにできないだろうかって、ある意味偏執的なぐらい
      自分のコードを推敲するよ。
      なので、わりと人に見せても恥ずかしくないコード(まー極上とはいわないが、
      少なくとも中の上程度)が書けてる自信はある。

      • 昔は短いロジックでこなせる一種アクロバティックなコードを書いていた時期もありました。
        今は迂遠でもわかりやすいコードを書くことに注力しています。
        場合によってはわざとダラダラ長く書いたりもしてますよ。
        • >今は迂遠でもわかりやすいコードを書くことに注力しています。
          私もそうしてますね。
          自分の手を離れた後、どの程度のスキルを持った人がコードを読むかわからないので、
          極力初心者でも理解できる&コメントいっぱいのコードを書いてます。
          ---------------
          昔やった作業で、私から作業を引き継いだ人が本当のPG初心者で非常に困った事があり、
          その時の経験からこの考えに変わりました。
      • ソースが短ければ速度が上がるということにならないよ。
  • 自分の*行動*に誇りをもちたい、と思う年末進行中。
    --

    -supercalifragilisticexpialidocious-

  • by Anonymous Coward on 2007年12月19日 12時04分 (#1268137)
    尊敬できる確かな技術を持った先輩、要は間違ってたら丁寧に教えてくれる人が身近にいないとなかなか上達しないと思う。
  • 自分のコードに誇りを持っていますか?

    誇りを持たないことが誇りです。
    誇ってしまうと成長が止まってしまいがちになるからです。
    ...って、啓発系のお話ではないようですねw

    誰か自分の上司に、お客がいつも正しいわけではないこと、たまにはノーと言うのが一番のこともあるんだよと説得できた人はいませんか?

    このシナリオに出くわしたことがないですね。
    上司はお客さんについてある程度正しく認知しているパターンが多く、とりあえず自分と同じ理由で悩んでいることが多いです。
    お客さんを説得する前に 'システム開発がわかっていない' 上司を説得しなくてはいけないということですね。
    普段からコミュニケーションをとって聞く耳を持ってもらった上で、根気良くわかってくれるまで説明するしかないでしょうね。(専門用語抜きで)

    難しいことは理解しようと思えない人が多いですから、聞く耳を持たせるのは重要です。
    聞く耳を持たせるために仲良くなるのも結構重要です。でも正直なところ臨機応変でしょうね。

  • だとするとまずプロジェクトの開始前に顧客の「本当の望み」を聞き出せてない事が問題。「仕事と私、どっちが大事なの?」と詰め寄られたときの模範解答が「寂しい思いをさせてごめん」だったりするようなもん。顧客は仕様の話をしようとするだろうけど顧客はソフトウェアの仕様に関しては素人なので、まず前の段階へ話を戻す必要がある。この要素に関しては営業サイドの責任の方が重い。

    技術的には「昨日のコードはクソ」だなぁ...。自分のコードを誇っていられるのはそれを吐いてる時だけだよ。
  • コードに限らず、
    自分が手がけた仕事の成果に誇りと「責任」を持つ必要がある。
    この二つは不可分。
    「誇り」だけでは独善的になり、まともな仕事は来なくなる。
    「責任」だけでは便利屋と見なされ、こき使われて潰される。

    態度は偉そうだけど成果はヤリ逃げ&責任転嫁、な連中に
    さんざん煮え湯を飲まされた挙句の、
    さしあたっての結論。
    --
    ----------科学は思考の柔軟剤
  • by yoshimo (15798) on 2007年12月19日 22時53分 (#1268691)
    とりあえずプログラム上の格言を一つ
    「他人の仕事は自分でしない」

  • by the.ACount (31144) on 2007年12月20日 13時08分 (#1269098)
    プログラム自体はコメントから書き始めます。(その前にアルゴリズム説明書を書くけど、プログラム作ったら、実際の作動状況/テスト結果も説明書に入れる)
    自分の作るプログラムは、アルゴリズム・デバッグだけ自分でやり、それを実用化のために修正するのは他人ですから、分かり易く、直し易くないと始まらない。
    コメント (文章) から書くと、機能分割も言葉で表現し易くなり、「コメントで分かる」以上の効果があります。(当然、説明とプログラムが食い違うなどありえない)
    かなり、特殊なプログラミング状況だけどね。(プログラムじゃなく、アルゴリズムを作ってる)
    --
    the.ACount
  • by Anonymous Coward on 2007年12月19日 11時07分 (#1268097)
    >誰か自分の上司に、お客がいつも正しいわけではないこと、
    >たまにはノーと言うのが一番のこともあるんだよと説得できた
    >人はいませんか?

    仕事してれば、そんなの日常茶飯事だと思うけど?

    # 日常茶飯事じゃないほうが理想ではあるけどね
    • Re:ほえ? (スコア:3, 興味深い)

      by Ryo.F (3896) on 2007年12月19日 11時26分 (#1268104) 日記
      そんなの日常茶飯事
      しかし、担当者が上司に上げた「ノー」は、顧客に届かないのが常であった。

      日常茶飯事じゃないほうが理想
      どうせ届かない「ノー」なら、言うだけ労力の無駄と悟った結果であった。

      とか?
      親コメント
  • by Anonymous Coward on 2007年12月19日 12時23分 (#1268166)
    現在12時20分。私は昼休みに弁当食べながら読んでいる所ですが、11時台
    の書き込みが多くてびっくり。
typodupeerror

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

読み込み中...