SIerはいまさら内製化できるのか？ - Sacrificed & Exploited
若い時にプログラムを書こう、必ず人生の豊かさにつながる | 日経 xTECH（クロステック）より 開発者はどこへ消えた ずっと気になっていたのだが、そもそもNTTデータの社員は開発をしているのか。 非常に危機感を持っていて、現状は何しろ内製率が低い。正直にお話すると全部合わせても3割とか3割5分ぐらい。残りは協力会社の方々に手伝ってもらっている。するとどういうことになるか。自分でコーディングしたり、ドキュメントを書いたりするより、コーディングする人たちを管理する仕事になってしまう。 いっぽう増田では、 日本のメーカー終了間近？ もう日本のメーカーのほとんどに、担当者は居ない。 製品のメイン開発者のほとんどが、社内に居ないのだ。 - 俺はプログラマー。 長年、とある組み込みマシンのメインプログラマーだった。詳細仕様、プログラムの細部、それらは全て資料化されているものの、膨大な量と難易度の為、
設計書の非常識1.設計書には詳細な実装方法を書く - Sacrificed & Exploited
SIerの常識：「誰が書いても同じソースコードになるように、詳細な実装方法の記述された設計書を書かなければならない」 プログラマの常識：「誰が書いても同じソースコードになるような設計書は書くだけ無駄、誰が書いても同じ振る舞いをするように、詳細に振る舞いを記述した設計書を書かなければならない。」 プログラムを作るうえで設計書や、仕様書の類は欠かすことができない だが、設計書や仕様書をちゃんと作っているプロジェクトでもよくデスマーチに陥っている。 なぜか？「設計書に記載するべき内容が間違っている」からだ。 （設計が間違っている場合も多々あるが。） 間違ったことをまじめにやっても良い結果は得られない。 「誰が書いても同じコード」は大事なことなのか - yvsu pron. yas 昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、そ
詳細設計書に何を書くべきか？ - Sacrificed & Exploited
詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと１対１に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容（内部の処理の実装方法）の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、
手順書の鉄則 - Sacrificed & Exploited
ビルド手順書だったり、モジュールの配備手順書だったり、そういった手順書を書くときに気をつけている事を勝手に列挙します。 はじめに 手順書を実施するうえで、最大の敵になるのがヒューマンエラーです。 ヒューマンエラーをなくすには、完全に自動化してしまえばいいんですが、そこまで出来ない場合でも最低限守った方がよい事をのべます。 よくあるパターンが コマンドの入力ミス 手順を飛ばした 配布先を間違えた などです。 1.手順書の実施順序は最初から最後まで一方向に読めるようにしておく たとえば、同じ手順を複数の箇所で実施させる場合、 ここでXXページの○○手順を実施する。 などといった前の手順に戻って実施させるような記述は避けましょう。 途中で手順をさかのぼって実施させると、いまどこの手順を実施しているのか分からなくなり、ある手順がスキップされてしまう確率が上がります。 めんどうですが、コピーペースト
前向きなヒューマンエラー対策をしよう。 - Sacrificed & Exploited
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチ
ステップ数の非常識2.ステップ数で進捗を管理する - Sacrificed & Exploited
SIerの常識：「毎日記述したステップ数を報告してください。」 こんな寝言を真っ昼間から堂々と言ってくれるSIerが多くて辟易します。 プログラムの実装がどれくらい進んだのかとステップ数には何の相関もありません。 プログラマの常識：「ステップ数なんかクソ食らえ、進捗は通過したテストの件数ではかるべき」 ダメな例その１ 「■週報でステップ数を報告するときの疑問」（1） Java Solution − ＠ITより 既存のコードを見直して書き直した結果、 クラスのステップ数が減った場合、 どのように成果を報告をすればよいのか悩んでいます。 下の場合、成果として報告できるステップ数は幾らになりますか？ 【先週】総ステップ数１０００ステップ 【今週】総ステップ数９００ステップ（先週比：マイナス１００ステップ） 上の【今週】ように上長へ成果報告をしたのですが、 結局何ステップ書いたのか分からないと注意
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ご冗談でしょうSIerさん その4 - Sacrificed & Exploited