コードが美しくないために起きる問題を考える（前編）―重複のあるコード／誤読問題
(ヘアメイク：浦杉美和子） 「美しいコードと安定するコードは相反するものではない」（小野） 小野：過去の記事のフィードバックで、知人で某とあるSIerの営業の経験が長い方がですね、Facebookで記事を引用して「SIerの営業としては、美しいコードかどうかじゃなくて、美しいコードよりもバグがないコードが、お客さんに納得してもらえるんだ」というようなことを書いてて。まるで美しいコードとバグがない安定したコードが相反するみたいな感覚でいて、「美しいコードだから安定してるんだ。両者は対立しませんよ？」みたいなことを返信しました。でもたぶんそれが出てきちゃうってことは、SIの営業、しかもかなり有名で、SIerの営業はかくあるべしっていうお手本みたいな人が、そういう発言を普通にしちゃうってことは……。 編集部：ちょっと軽い眩暈を覚えるくらい、共有されてないってことですよね、美しいコードについて。
スコープマネジメントとは【プロジェクトマネジメント講座 第8章】
スコープマネジメント スコープマネジメントとは、プロジェクトの作業範囲や成果物を決めることです。プロジェクト失敗の原因の1つにスコープが不明確だったということがあります。ユーザーサイドと開発サイドで「何をするか」、「何を作るか」を明確に定義しておかないと、プロジェクトの終了間際になって「あれが漏れてる」「これも作ってもらわないと」というトラブルになりかねません。 そのため、PMBOKではプロジェクトの計画プロセスで作業範囲を取り決めることをスコープマネジメントとして定義しています。 ウォーターフォールの場合は、一般に見積時に概略スコープを提示し、要件定義工程で詳細なスコープを定義します。 作業スコープと成果物スコープ PMBOKのスコープ管理では下記２種類のスコープが定義されています。 ・プロジェクトスコープ…規定された特性や機能を持つ、プロダクト、サービス、所産などを生み出すために実行し
SI系企業で社内独自のフレームワークを作りたくなる理由について
tl;dr社内フレームワークは開発生産性を高めるためと言われることが多いが、実際はシステムを守るために産まれる（ことがある）すべては複雑怪奇な業務をシステム化する人が、システムアーキテクチャや非機能面まで全て見れないことに起因する画期的なハックはなく、業務にもシステムにも詳しい人を増やしていきましょうはじめにSI系の大規模な業務システム開発に参加すると、社内独自の重厚なフレームワークに遭遇することがあると思います。ここでいう社内フレームワークとは以下の条件に一致するものを指すことにします。 クローズドソースであるその社内でゼロベースで開発されたり、既存のフレームワークを拡張・ラップしているなど、独自の背景・思想により開発されているそのため、フレームワーク独自のお作法や制約がある開発生産性の向上や、非機能的な要件を満たすことを目的とする社内フレームワークに思いを馳せる自分が経験があるのはJa
情報システム部はどうであると得するのか？ - 急がば回れ、選ぶなら近道
いまさらの感もあるのですが、特にいろいろと日本全国を飛び回るようになって、いろいろなお客さんにお世話になっています。ということで、その辺りで感じたことで、特にエンドユーザーの情報システム部はどうあると、「有利」なのか、ということを書いてみます。 対象は、お金を湯水のように使えないエンドユーザーさんです。とにかくリスクヘッジのためなら何百億円使おうと問題ではない、というユーザーさんはフルリスクを取れという要求以外であれば、SI屋さんの方から「無理なので、ご遠慮します」ということはありません。そのようなユーザーさんは、例外だとは思いますので、ちょっと対象外です。（なんか最近そうでもない説はありますが） 以下、あくまで自分の経験なので、不快な気分の方は、完全スルーでご容赦をお願いします。ベンダー風情が生意気な事を書きやがって、という方もいらっしゃると思いますので、そういう方には事前に、謝罪してお
社内政争が盛んな紛争地帯にいるけどもう戦死しそう
異動で4月からいる部署が社内政治の舞台になっててもう死にそう… 今まではお客さんが見える部署にいた。 お客さんは喜ばせる相手であり、また無理難題をふっかける敵であり、それは大変だったけれど 今思えば単純な世界だった。 いろんな考えの人が居たけれど、それはやり方の違いだけであって目的はお客さんからお金を貰うということに付きていた。 何の因果か直接お客が見えない部署に異動になった。 社内交流とかスキルを撹拌させるとかそういう意図があるのかもしれない。 この事業部、A派 B派 C派 みたいな派閥がある。 外から見た分だとあまり分からなかった。 はじめこそは半沢直樹みたいとかちょっとワクワクしたところもあるし、狭い世界でよくやるなとちょっと引いて見ていたが ここにいる限りこの戦いとは無縁になれないと知ってお腹が痛い。 なんだよここ本当になんでこんな細かいことで対立しているんだよ。あまり詳しくは書け
アスペルガーのヒトリゴト みずほ銀行次期システム開発が順調に破綻中らしい
以下は、『みずほ銀行次期システム開発が順調に破綻中らしい』へのリンク。 http://blog.livedoor.jp/majisonictokyo/archives/13157934.html 以下、面白いと思ったコメントを書いてみる。結構変えている。 コメントＡ： A「ハァ・・・」 B「どうしたんだい？」 A「プロジェクトが間に合わないからって、人員が2倍になったんだ」 B「それは良いじゃないか！」 A「会議に10倍時間が掛かるんだ・・・」 コメントＢ： 銀行業務ってそんな要件がコロコロ変わるような物なの？ 唯の金貸しじゃないの？ ⇒細かい所で仕様をコロコロ変える。 担当によって全く違う事を言う。 開発側で相手を丸め込んで要件を纏められる人がいない ⇒間違えてクリアボタン押して客の残高が消えたら困るだろ。 まぁ・・・本当の勘定系ってのは少し前にあったみたいな 「振込処理がたくさん来たか
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第3回：消された案件とチームの事件 (2/4)