久しぶりの更新。一度ブログ書くの面倒になると、とことん書くのが面倒になるもんで。 【Web系最高って言うけど本当なの？】SIから転職したエンジニア達に聞いてみた - paiza開発日誌 まあ、いつものPaizaのWebアゲSIer Disの記事なわけなんですが。。。 最近、どうでもよくなって放置していたものの、いろいろ誤認している人が増えていそうなので、改めて問題点指摘しておきますか。ブコメ見るとSIer側の反論も欲しそうだし。 とはいえ、開発環境の話はわきに置いて、別の観点を中心とした内容となります。 イケてる環境のWEB系の労働生産性は、イケてないSIerのたった三割 http://www.soumu.go.jp/johotsusintokei/linkdata/ict_keizai_h28.pdf 上記は総務省が毎年公開している「ICT の経済分析に関する調査 」の資料です。 大体1

正月はずっと寝正月で惰眠にふけっていたのですが、いよいよ仕事始めを迎えるに当たり、今年の抱負も兼ねて業界展望の予想を行ってみようかと思います。 やっぱり2015年問題は起きない 改めて書くのもアレなんですが、一部のメディア*1で語られている2015年問題は発生しないと予想してます。 よく事例で引き出されるみずほ銀行プロジェクト。20万MMの壮大なプロジェクトとして語られてます。でも、そもそも20万MMは業界全体にインパクトを与えるほど巨大なのか、をきちんと考えるべきでしょう。 現時点、日本のIT技術者はベンダだけでも多よそ80万人。オフショア加えれば100万人程度の技術者が仕事しているわけで、年間の工数で考えれば1200万MMとなります。 みずほ銀行のプロジェクトも、単年で見れば10万MM程度でしかなく、業界全体の0.8％程度です。 上記の記事で紹介されている大型案件と呼ばれる案件を全て足

最初に、すいません。ただのグチです。 まあ、仕事をしていると嫌なこともあるわけで、腹の中でモヤモヤしているのも健康上良くないので、ここで整理してみようかと。 チームの開発生産性の比較にLOC生産性を使うな 結論はこれなんですけど、もうちょっとだけ。 保守開発なんてやっていると、他システム起因のプロジェクトにチームとして案件支援を行うことがあるのですが、それらを統括するPMO部隊の発言で、ひっくり返りそうになるのがコレ。 「今回は各チームとも生産性を○○KLOC/MM以上にして欲しい」 「オタクのチームは、見積生産性が☓☓KLOC/MMで生産性が悪いんじゃないか」 この手の発言聞くとやる気激減なわけですけど、仕事なので仕方が無い。。。 所謂クソコードが多いプロジェクトの方が生産性がよく見える そもそも、チームの開発生産性を比較するのに、LOC生産性を使うのは問題がおおすぎるのですよ。 保守開

タイトルのとおりですが、交通事故に遭遇しました。 ※今日ではないですけど。 概略 カンタンにまとめると以下のとおり 優先道路走行中に脇から入ってきた車と衝突 双方けがなしのため、物損として処理 警察には連絡済み 実は相手のある交通事故なんて人生で初めてなんですけど、初めて知ったことがありました。 物損事故では「無事故無違反」となる 何を言っているんだ、ということですが、物損事故は「無事故無違反」の事故・違反としてカウントしないとのことです。*1 カウント対象は、人身事故と建造物損壊事故のとき。 自動車同士の事故については対象外になるとのことでした。 要は、刑事事件としては関係なしなので、民事で勝手にやってくれということですね。 まあ、免許が減点にならないのと、罰金等取られないで済むのは助かります。 物損事故は自賠責は利用できない 物損事故の場合、損害賠償は自賠責は利用できません。*2 この

もうすぐ４月ですね。 ４月は人事異動の季節ということで、配置換えなど、仕事が変わることもあるかと思います。 オッサンの後輩なんかもこの時期チーム体制の変更などにより新たにプロジェクトリーダなどに抜擢される人もいるのですが、だいたい半年ぐらいは苦労する人も多い。 そんな若手に向けて、オッサンが過去行ってきたアドバイスをちょっとだけまとめてみます。 新人プロジェクトリーダ向け　チームとプロジェクトを動かす１０のポイント １．チームメンバーが仕事ができないと思ってイライラしてはいけない リーダに抜擢される人は、設計やプログラミングなど仕事ができる人を抜擢するケースがよくあります。で、仕事ができる人がリーダになった場合、自分を基準につい仕事を割り振りがちだったりします。 「オレなら１日でプログラミングが終わるのになんで３日もかかるの？」とか、つい言いがちですけど、グッとこらえてください。 メンバー

詳細設計書という名のゴミ | Gm7add9 この手の話題が定期的に上がるわけですけど、毎度同じだよねで終わってしまっては人間進歩しないので、何が問題でどうすればよいのか少し考えてみたく。 詳細設計書は「プログラム説明書」として欲しい。 まあ、元記事も多分業務システムの受託の話の模様なのでSIをターゲットに。 往々にしてSI、特にウォーターフォール開発のプロジェクトの中では、設計書などのドキュメントを多数作成いたします。*1 V字モデル的には、設計から開発に至るまでの間 要件定義書 基本設計書・外部設計書 基本設計書・内部設計書 詳細設計書 プログラム みたいな成果物を作成いたします。 個別の詳細は別のサイトに任せるとして、それぞれ記載する内容を一言で表すと、要件定義書は「スタートとゴール」、外部設計書は「業務とサービスの仕様」、内部設計書は「サービスの構造と機能の分割」となります。 ※た

Developers Summit2014 リポート：ベンダーよ、シェルパの屍を越えていけ ～　細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」 (1/2) - ＠IT 2月14日は仕事が忙しく聞きに行けませんでしたが、サマリレポートだけでも非常に楽しめたので、所感を。 バンバン出てくる実社名。。。大体予想できる会社でしょうけど、聞きたかったなあ。 出てきた内容からの所感を幾つか。 プロマネの仕事はやっぱり政治だ。。。 細川氏は、トラブルを防ぐためには「根回し」が大切だという。ベンダーは、ユーザーが「ちゃんと決めてくれる」かどうか、そして「誰が本当のキモなのか」を見極める眼力が必要だ。キーマンを見付けて、その顔色を見て、泥臭い根回しを続けなければならない。「開発は、きれいな身体ではできないものです」 これも典型的なあるあるですね。 正直、ステークホルダーを如何に上手く調整するか、

"地方エンジニア" という考え方はすでに終わっている なかなか興味深いスライドだったので、オッサンから幾つか所感を。 地方エンジニアと言う言葉の本当の意味は「地方企業向けに活躍できるエンジニアの不在」 先のプレゼン資料では、「地方エンジニア」を地方在住のエンジニアと定義されてましたが、元のITProの指す「地方エンジニア」は、地方企業向けに活躍できるエンジニアが不在で、首都圏や京阪圏などの都市圏のIT企業に対して技術提供を行えるエンジニアが集中してるってことなんです。 この問題の根が深いところは、都市圏の企業で着実に進められている業務のIT化に地方企業が追いつけ無いこと。 中小企業も多く業務のIT化を行う意欲が少ない、サプライチェーンがシステム化されておらず、一社だけのシステム導入が困難など、費用対効果の少なさから需要が少ない状況下で、IT関連の仕事が都市圏の大企業を中心に集中、結果エンジ

ウォーターフォール開発とアジャイルの本質 - プロマネブログ 以下、３部作の２本目です。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 前回と今回のシリーズはカテゴリ　プロジェクトマネジメント論にまとめてます。 単一の開発手法の限界からハイブリッド方式へ 前回、各開発手法は失敗プロジェクトの反省から、それぞれ本質となる改善要素を持つことを示しました。 ウォーターフォール開発（以下WF）であれば、形式知化。 アジャイル開発であれば、フォーカス分割。 これらは排反する概念ではなく、それぞれの利点を活かしてプロジェクト運営を行うことが、より効率的なプロジェクト運営につながると考えられます。 とはいえ、ハイブリ

以下、３部作の１本目です。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 度々話題なる開発手法、ウォーターフォール開発（以下WF）とアジャイル。 それぞれの違いってなんだろうと思い、ちょっと本質について普段考えていることをまとめてみました。 ウォーターフォール開発の本質とはなにか？ システム開発を行った方なら一度は耳にすることがあるWF。 各開発工程を順序良くこなしていく開発手法となります。 イメージにすると以下のとおり。 さて、WFのよく言われる特徴を以下眺めてみたいと思います。 最初に一括して要件定義を行うので、仕様変更に弱い No。一括して要件定義を行うこと自体は、要件定義のやり方の問題です。一括

裁量労働制で「長時間労働」指摘も　NHKニュース 多分嫌いな人が多いだろう裁量労働制で、「満足」または「やや満足」と回答した人が７０％を超える結果とだそうです。 多分、無作為な調査じゃあ無いんだろうなあ。。。オッサン勝手に分析します。 裁量労働制とは そもそも、裁量労働制とは、以下の特徴を持った労働制度です。*1 特定業種（証券アナリストやシステム開発、デザイナーなど）に限定 みなし労働時間分の給与を支払う代わりに、残業代は支払われない。法定残業時間を超過するおそれがある場合は、事前に36協定での労使合意が必要。 深夜残業、休日残業はいかなる場合でも支払対象。 要は、特定業種については割増賃金払う代わりに残業代がなくなるよって制度です。 IT業界などでは広く採用されている制度だったりします。 裁量労働制のメリットは「自身で時間をコントロールすれば自由な勤務が行えること」。デメリットは「仕事

「必要なこと」より「excelでやりたいこと」を優先するとシステム構築は失敗する - プロマネブログ 前回記事の反響があまりにもたくさんだったのでびっくり。前回書ききれなかった追記を書きます。 ブコメ欄で、いろいろな方から「Excelを直接利用したら」というアドバイスが有りました。 実はオッサンも同じことを最初考えたのですが。。。途中でやめました。 やめた理由ですけど、以下の通り。いずれもオッサンの独断と偏見です。 もともとの増田さんは、Excelでフィルタを使用するなど、そこそこExcelを使いこなしている模様でしたので、システムにガッチリと組み込むとかえって保守性が下がるかな、と考えました（id:airj12さんのコメントと同じ構想です。補足ありがとうございます） もともとの増田さんの文章から、システム構築にしてはずいぶん初期費用が安いので、おそらくパッケージかASP、SAASでの導入

久しぶりの更新。一度ブログ書くの面倒になると、とことん書くのが面倒になるもんで。 【Web系最高って言うけど本当なの？】SIから転職したエンジニア達に聞いてみた - paiza開発日誌 まあ、いつものPaizaのWebアゲSIer Disの記事なわけなんですが。。。 最近、どうでもよくなって放置していたものの、いろいろ誤認している人が増えていそうなので、改めて問題点指摘しておきますか。ブコメ見るとSIer側の反論も欲しそうだし。 とはいえ、開発環境の話はわきに置いて、別の観点を中心とした内容となります。 イケてる環境のWEB系の労働生産性は、イケてないSIerのたった三割 http://www.soumu.go.jp/johotsusintokei/linkdata/ict_keizai_h28.pdf 上記は総務省が毎年公開している「ICT の経済分析に関する調査 」の資料です。 大体1

「AともいえるがBともいえる」とか言う人の役立たなさ - Chikirinの日記 いろいろコメントをもらったのですが、はてブコメ欄みると文章がわかりづらいせいで読み違えているなってコメント幾つか見られたので、朱書きで補足追記してます。 普段から極論ばっかり行っているちきりん氏がついに自己弁護？ あまりにもしょうもなかったので、ツッコミをつい入れてしまいました。 さすが、議論の呼び水としての力健在ですな。 「Aだ」「Bだ」ためには問題設定の妥当性が必要 さて、この文章いろいろ突っ込みどころをはらんでますが、最大の問題としては問題設定の不具合を批判者に転嫁している点です。 往々にして議論を行う場合、「Yes」か「No」かの選択を行う場合が多いです。 ＜追記＞言い換えると「A」か「notA」か。 これは議論がスッキリしやすく、答えも出しやすいから。 ところが、「A」か「B」か、という選択の場合、