C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

掲示板トップ C# と VB.NET 入門 新規作成 利用方法 ツリー表示 トピック表示 ランキング 記事検索 過去ログ
ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

全過去ログを検索

<< 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 >>
■20112 　Re[1]: リソースファイル（.resx)について
□投稿者/ Azulean -(2008/06/05(Thu) 22:49:27)
    > リソースファイル(.resx）で例えば1234_HOGEHOGEという名前を登録すると、
    > 「リソース名 '1234_HOGEHOGE'は有効な識別子ではありません」
    > という警告が出ます。
    リソースの名前でResoucesクラスからプロパティが公開されることになります。
    しかし、数字で始まる文字列はプロパティ名として有効な識別子ではないため、この警告が出ます。
    実際、Resources.Designer.csを見て頂ければ分かると思いますが、_1234_HOGEHOGEにリネームされたプロパティが公開されます。

    > 「管理番号_任意」といったネーミングルールを崩さず、
    > 警告を消す方法があれば是非ご教示下さい。
    警告が意図する、望ましい形で解消することは無理です。
    それはネーミングルールとこの警告が相反するためです。
    警告を見ないフリをするか、ネーミングルールを曲げるかのどちらかぐらいしか今のところは思い当たりません。
記事No.20103 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20301 　Re[2]: リソースファイル（.resx)について
□投稿者/ 純＠ＷＡＳ -(2008/06/09(Mon) 14:22:20)
    Azulean様

    ご回答ありがとうございます。
    >実際、Resources.Designer.csを見て頂ければ分かると思いますが、_1234_HOGEHOGEにリネームされたプロパティが公開されます。
    ご指摘の通り、Designer.csにはリネームされたプロパティが公開されていました。

    >警告を見ないフリをするか、ネーミングルールを曲げるかのどちらかぐらいしか今のところは思い当たりません。
    ひとまず、お客様のご了承を頂くまでは勝手にルールは変えられないので、
    事情を説明した上で、見ないフリをして運用を開発を行おうと思います。

    本件解決です。
記事No.20103 のレス / END /過去ログ39より / 関連記事表示
削除チェック/

■20108 　デスマーチプロジェクトの立て直し・防止について
□投稿者/ やじゅ -(2008/06/05(Thu) 21:14:59)

    分類:[討論]　

    Seasar2の開発者のひが氏のBlogを読んでいて、デスマーチを立て直した旨の
    内容があり大変参考になりました。

    ひがやすを氏　ダイコン時代の設計手法-その2
    http://d.hatena.ne.jp/higayasuo/20040607/1086565824
    ・期間を短縮するために、画面チームと業務ロジックチームに分けた。
    ・データにアクセスするロジックとそうでないロジックを明確に分離する。
    ・ロジックは状態を持たない。
    ・1つのロジックで複数のことを行わない。
    ・同じロジックを複数に分散させない。
    ・データにアクセスするロジックも含めてすべてのロジックは、JUnitでテストする。

    これ以外にも、デスマーチプロジェクトを立て直す方法が幾つかあるのではないかと
    思います。

    そういった経験をなされた方の改善点、参考になるリンク先や書籍などあれば、
    教えてください。
    また、デスマーチになる前に防止する方法などもお願いしますm(_ _)m

    デスマーチの無い世の中にしたいものです･･･
親記事 /過去ログ39より / 関連記事表示
削除チェック/

■20109 　Re[1]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ 倉田　有大 -(2008/06/05(Thu) 21:28:09)
    > また、デスマーチになる前に防止する方法などもお願いしますm(_ _)m
    >
    > デスマーチの無い世の中にしたいものです･･･

    営業と意志の疎通!
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20114 　Re[2]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ 出水 -(2008/06/06(Fri) 01:47:56)
    劇的に立て直したわけではないですけど、
    タスクカードってのは有効だったように思えます

    自分や他の人がどれだけの仕事が残っているのかわかるし、
    優先順位や重要度を細かく把握できるのはいいです

    基本的にデスマってのは信号がなくて渋滞している状態だと思うので
    まずは前に進む気持ちを捨てて交通整理からはじめないとダメなんじゃないかなぁと思ってます

    #でも、これに当てはまらないデスマもあるかも
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20116 　Re[3]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ Jitta on the way -(2008/06/06(Fri) 07:41:52)
    仕様決定の過程を明確にすること
    たいてい、あとになって「なんでこんなことしたんだっけ？」とかなるんだよな。

    仕様と仕様の関連図を作る
    仕様を変更するとき、影響範囲、再テストが必要な範囲がわかりやすくなる。

    ブロックを長くしない
    読むの疲れた(-_-;)

    イライラしていると感じたら、帰る
    続けても、余計に参るだけ。気持ちを切り替えた方がいい。反対に気が乗ったら突っ走る。

    上司が連絡網に徹する
    上役がコード弄りはじめたら、かならず火を吹く。全体が見られるように、自分の手は開けておく。

    全力投球しない
    組織として、もしもに対応できる予備役をおんぞんしておく。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20117 　Re[4]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ ネタ好き -(2008/06/06(Fri) 07:50:02)
    学習期間を設ける事。
    余り慣れていない分野のプロジェクトをする時には、チームの学習時間を設けないとプロジェクトが火を噴きます。

    上司が口を出さない事。
    無知な上司が口を出すとプロジェクトの破綻は確定します。

    お客の我が儘を許さない事。
    お客の注文と我が儘を区別しないとプロジェクトは破綻します。

    上司の願望は聞かないこと。
    上司の願望・妄想の類も無視しないとプロジェクトは破綻します。

    止める決断する事。
    腐った企業は辞めるという意識をメンバーが持たないとプロジェクトは破綻します。


    私はブラック企業とデスマーチにしかあったこと無く（破綻していない楽園にいったことがない）、逆に破綻していなかった事を経験した事が無いのでまだまだ書ける気がしますが（因みに5・6年）、うんざりすると思いますので、これぐらいにしときます。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20118 　Re[1]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ よねＫＥＮ -(2008/06/06(Fri) 09:21:35)
    とある超絶デスマーチで見かけた素晴らしいリーダーを見て思ったこと。

    リーダーはあるべき姿を一貫して追いかける。変な妥協しない。

    スケジュールが押してくるとあるべき姿を捻じ曲げて手を抜いたり、諦めが入ったりしてしまいがちですが、
    「ＸＸＸは本当はＹＹＹでないといけない・・・と思うけれど、ＸＸＸが必ずしも悪いというわけでもないし、
    　ここでやり直すとスケジュールや工数があふれるから・・・」と間違った判断をすれば、
    そこでケチった工数が積もって爆発して後で10倍返しくらいの手戻り工数をくらうことがある。

    それに、リーダーが一貫してあるべき姿を追いかけてくれれば、継ぎはぎだらけの納得行かないプログラム修正など
    あるべき姿と乖離したような開発は極力さけられると思うので、開発者も変なストレスを貯めずに作業ができる。
    あるべき姿を普段から示しているので、メンバー間で何を問題と見るかという意識も共有できて、問題点の早期発見にも繋がる。

    チーム全体でのいろいろな判断をする際の基本となる指針は、リーダーにとってもメンバーにとっても
    とても大事だなと思いました。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20121 　Re[2]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ ネタ好き -(2008/06/06(Fri) 10:03:27)
    2008/06/06(Fri) 10:06:03 編集(投稿者)

    よねＫＥＮさんの意見に同感です。
    やっぱり私が経験した駄目なところは大概上司が無知でした。
    社長も「ITってなんか儲かるんやろ？」レベルですｗ
    日本にはマネージャーが不足しているんですよね。
    あと、他人は変えられないから、自分の研鑽が一番の解決法だと思います。
    もう馬鹿な他人に期待するよりも、自分が向上心をもった方が建設的だし、効率的だと思います。

    それはさておき、本当の解決策はその会社を辞める事かもしれませんね。
    そうすれば自然と馬鹿マネージャしか居ない会社がなくなってこの業界もましになるでしょう。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20123 　Re[3]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ PoohKid -(2008/06/06(Fri) 11:14:02)
    デスマは組織の機能不全と考えています。

    （上手く機能している組織ならば単に「忙しい」だけｗ）

    組織が機能するためのマネージャ論として、
    　・マネージャは現場が邪魔されないようにする
    　・俯瞰的視点で外的要因を事前に見つけ出す
    　・外的要因を排除するために奔走する

    のような話を読みました。

    　人材は「不良(ハミダシ)社員」からさがせ―画期的プロジェクト成功の奥義
    　天外 伺朗 (著)
    　http://www.amazon.co.jp/gp/product/4061327569/

    ソニーでNEWSを開発しが「ICKI（いっき）プロジェクト」をマネジメントしていた
    土井利忠氏の著書です（天外伺朗はペンネーム）。

    　http://itpro.nikkeibp.co.jp/article/COLUMN/20060912/247835/

    同じIT分野での成功プロジェクトの経験談を読めるのでオススメです。
    組織論を多分に含むので現代でも充分に通用します。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20125 　Re[4]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ こあら -(2008/06/06(Fri) 11:39:28)
    > デスマーチの無い世の中にしたいものです･･･

    私は幸いにもデースマーチ未経験です。
    勤務時間が200hを超えたことも片手で数えられる程しかありません。

    あ、４〜５回であって、３１回ではないです。

    素晴らしいマネージャ、素晴らしいメンバー、薔薇色の世界。という訳でもありませんでしたが。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20130 　Re[5]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ ネタ好き -(2008/06/06(Fri) 12:15:37)
    ■No20125 (こあら さん) に返信
    いいなぁー、私なんか5・6年デスマーチで、そうじゃないプロジェクトなんか参加した事がありません。
    上司は我が儘いいまくりでプロジェクトを破壊し続け（酔ってるの？）、
    同僚は「オブジェクト指向？それ食えんのか？あっなんか動かんぞ。」という感じｗ
    200hなんて当たり前。というかほとんど拉致監禁状態。帰りてぇー。
    しかも報酬をまともに貰った事が無い・・・
    そんな状態でした（笑）
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20128 　Re[5]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ 凪瀬 -(2008/06/06(Fri) 12:11:31)
>
    骨格となる部分の設計がヘボいとどうにも困りますね。
    設計が悪いと分かっていても動いているものは直さない、という指針を改めると効果的です。
    技術力があればどうにかなる。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20134 　Re[6]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ ネタ好き -(2008/06/06(Fri) 13:01:29)
    2008/06/06(Fri) 13:08:23 編集(投稿者)

    結局のところ、「君主危うきには近づかず」が正解なのかもしれません。
    説得を試みたことがあるのですが、上司や社長があれですと全然通じません。
    特に技術者をパソコンの部品か、開発ソフトのおまけと考えている人には交渉が成立しません。
    まぁ、私の会話能力の限界なのかもしれませんが、見切りをつける事が重要だと実体験から学びました。

    それはさておき、じゃあプロジェクトマネージャーには何が必要なのかと考えました。
    それはやっぱり情報処理技術全般を知っている事が前提になると思います。
    知らないものを管理できるはずがありません。
    それに加えて、交渉能力、社内で必要な権限、経営者の理解、全体を思い描く能力、柔軟さ、個々の技術者を把握する情報処理能力、ある程度の非情さ、バランス能力、などが必要だと思います。
    恐らく日本人そういった人が少ないのは「プログラムは下っ端がするもの」だという変な先入観が原因だと思います。
    常に学習できる人で無いと、全体のバランスを考えられるはずがありません。知識はすぐに陳腐化してしまいます。
    これら自分の書いた事を見て思ったのですが、一番足りないのは「経営者」なのかもしれませんね。

    追記
    じゃんぬさん、中さん、επιστημηさん、達なら良いプロジェクトマネージャーになりそうです。面識はありませんが、なんとなくそう思いました。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20136 　Re[7]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ ネタ好き -(2008/06/06(Fri) 14:07:01)
    しまった、立て直しについては何も書いていなかったｗ
    それはずばり、「プロジェクトマネージャを変える」事だと思います。
    マネージャが駄目ならば何人投入しても、どんなハッカーを投入しても恐らく駄目です。
    マネージャを変えて、おまけに余計な人も削り、画面・データ・機能・テストを分割するのはもちろんの事、「絶対に必要な要件」を洗い出して、そこへ信頼できるプログラマを投入するのが良いかと思います。
    あとは、新くて度胸と能力のあるマネージャに必要な権限を与えて、現在の状況の概要をキーとなる少数の人達とともにレビューして、プロジェクト進行度が誰の目にも明らかな状態にするのがよいと思います。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20141 　Re[8]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ じゅで -(2008/06/06(Fri) 15:47:45)
    ・要員の再配置
    ・残業すれば出来る事は出来ない事にする。
    ・PMやPLが注視しなければならないワークパッケージを明確にする。
    (他は多少おくれても問題ないのは悪い言い方をするとほっとく)
    ・コアな部分は、内部の出来る人に任せる。外だししない。
    ・新人などを、人数に数えて、工数と照らし合わせて作業分担をしない。
    ・お客さんの要望を吸い出す人間とクラスなどの詳細設計を行う人間は、
    必要なスキルが違うので、明確に分ける。
    ・上司は、実装部分に口を出さない。必要であれば、技術力のある人間をつれて
    客先につれていく。
    (お客さんにできない事は出来ないといえるような仕事をとるのが一番ですorz)

    まだまだ色々あるでしょうが、長くかいてたら送信できなかったので、
    短くしてみましたorz
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20166 　Re[9]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ やじゅ -(2008/06/06(Fri) 20:56:26)
    コメント頂いた方、貴重なご意見ありがとうございます。
    今日は忙しかったので返答が遅くなっております。
    後ほど、返答することにします。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20168 　Re[10]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ 出水 -(2008/06/06(Fri) 22:15:53)
    ここって、社長やらPMやらって立場の人もいるわけじゃないですか
    そういう場で会社辞めろとかマネージャーが無能だとかそんな仕事取るなとかってのは
    ちょっとあれでなになんじゃないかって思うわけです
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20170 　Re[11]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ 中博俊 ＠ -(2008/06/06(Fri) 22:38:41)
>
    まぁそれは杞憂。

    本題についてははっきり言って原因はこれっていうことがないので、オーダーメイドだなぁ。
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

■20263 　Re[12]: デスマーチプロジェクトの立て直し・防止について
□投稿者/ やじゅ -(2008/06/09(Mon) 02:07:59)
>
    >営業と意志の疎通!

    営業マンがお客さんのいいなりだと最悪になりますね。
    営業には意思を伝えて、それを防ぐのが営業の仕事でしょって突っぱねる

    >タスクカードってのは有効だったように思えます
    >自分や他の人がどれだけの仕事が残っているのかわかるし、
    >優先順位や重要度を細かく把握できるのはいいです

    作業の見える化は大事ですよね。
    他の人の遅れとか分かれば、手の空いた人が手伝えるし。

    >仕様決定の過程を明確にすること
    >　たいてい、あとになって「なんでこんなことしたんだっけ？」とかなるんだよな。
    >仕様と仕様の関連図を作る
    >　仕様を変更するとき、影響範囲、再テストが必要な範囲がわかりやすくなる。

    仕様書は決定事項だけ記さず、理由と意図も必要ですよね。

    >上司が連絡網に徹する
    >　上役がコード弄りはじめたら、かならず火を吹く。全体が見られるように、自分の手は開けておく。

    特に技術力がある人は、弄りたくなるんですよね。そうするとそれに夢中なってしまい
    他の事がおそろかになる。がまんが大切

    >お客の我が儘を許さない事。
    >　お客の注文と我が儘を区別しないとプロジェクトは破綻します。

    営業さんにがんばってほしいとこですね。
    お客さんにすぐに出来ないって言ってはならなくて、検討しますといったん持ち帰る
    要望は要望として受け入れる、あくまで余裕が出来たらですよね。(緊急時以外)


    >リーダーはあるべき姿を一貫して追いかける。変な妥協しない。

    リーダーがビジョンを示すというのが大事ですよね。

    >組織が機能するためのマネージャ論として、
    >　・マネージャは現場が邪魔されないようにする
    >　・俯瞰的視点で外的要因を事前に見つけ出す
    >　・外的要因を排除するために奔走する

    マネージャはあくまで調整役に徹することと、
    俯瞰的視点を得るために常に全体を把握するように情報収集せよ

    >骨格となる部分の設計がヘボいとどうにも困りますね。
    >設計が悪いと分かっていても動いているものは直さない、という指針を改めると効果的です。

    設計が駄目な場合でも、優秀なプログラマだとカバー出来るんですけど。
    リファクタリングしてもちゃんとテストすれば問題ないですし。

    >それはずばり、「プロジェクトマネージャを変える」事だと思います。

    プロマネを育てる意味では出来るだけ我慢なんですけど、その上の上司が指揮をとるように
    なりますね。

    >・要員の再配置
    >・コアな部分は、内部の出来る人に任せる。外だししない。
    >・新人などを、人数に数えて、工数と照らし合わせて作業分担をしない。

    最初は勉強の為とまかせていても、いざとなったらすぱっと切り上げて
    画面作成する人と業務ロジックを作成する人など作業を分担しないと
    工数が合わなくなりますよね。


    意見ありがとうございます、あいからずまとめが苦手です(^^;

    プロセス１４：プロジェクトマネジメントクリニック
    ケース１７：火消しに定石はあるか？
    http://pmstyle.jp/honpo/pmos-pro/browsing/200509.htm
記事No.20108 のレス /過去ログ39より / 関連記事表示
削除チェック/

＜前の20件 | 次の20件＞

<< 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 >>

ヒット件数が多いので過去ログ1〜76 までの検索結果 / 過去ログ77からさらに検索→
パスワード/

- Child Tree -