技術者を襲う3年後の悲劇ってホントにおきるのかね - プロマネブログ
技術者を襲う3年後の悲劇：日経コンピュータDigital 毎度のことですけど、突っ込みどころについて、とりあえず書いときます。 業界全体で仕事量が増えればそりゃ人は足らなくなるよ これらの案件は“特需”のため、それに合わせて技術者を抱え込むのはリスクが高い。調査によると、従業員1001人以上の大手に限れば技術者不足とする割合は66.6％にすぎず、技術者不足を訴えるのは100人以下の中小に集中している。つまり、ユーザー企業から直接案件を請け負う大手は、自らの人員を膨らませることなく、IT業界の多重下請け構造を活用することで、この一時的需要をこなそうとしていることが見て取れる。 基本、システム構築プロジェクトは設計～開発～テスト～リリースという工程をこなした場合、大体の場合において開発～テストで人員のピークを迎えます。 この時、要件定義時点から比較すると、10～20倍程度増加することも当たり前
「アジャイルの神話」にしないためのプロマネ力 - プロマネブログ
ブルックスの法則とはなにか - 未来のいつか/hyoshiokの日記 後半の下り。ウォーターフォールでも、出荷前検収は当たり前だし、結合テストで中間検収やったりするので、ちょっと違うかな。基幹系だとフォーカス分割できない場合があるので、単純なアジャイル礼賛は危険だよ 以前*1似たような記事を書いたのですけど、アジャイル開発はウォーターフォール開発(以下WF)の欠点を克服していると言う様な言説は危険と思っているのでちょいとだけ書きます。 アジャイルが使いづらい案件 いろいろな開発を行っていると、アジャイルが有効に作用するプロジェクトと、WFが有効に作用するプロジェクトを見かけます。 アジャイルが有効に作用するプロジェクトは、フォーカス分割が可能でフォーカス制御が可能なプロジェクトです。 このフォーカス分割ですが、適応条件がかなり厳しいと感じることもしばしばです。 フォーカス分割づらい事例です
小学校でチャイムとトイレ掃除がなくなったとき - プロマネブログ
とある小学校の話。 チャイムの鳴らない小学校 最近、とある小学校で授業開始前後のチャイムが鳴らなくなったとのこと。 理由が「チャイムがうるさい」から。 小学校近くにマンションが建てられた際、その住人からの苦情によりチャイム停止となったそうです。 子供達への影響はって言うと、特に低学年の子だと授業開始に気づかないことも多く、また、騒音抗議もあるため、校庭で遊ばせないそうです。 運動会の時、昔は花火(信号雷)で合図を出してましたが、これもウルサイとの苦情で廃止になってしまったと聞きました。 まあ、こちらはメールか何かで連絡したほうが効率的かなとは思いますので、そんなには不便を感じませんけど。。。 トイレ掃除のない小学生 最近、とある小学校で子供たちが小学校のトイレ掃除をなくしたそうです。 理由が「子供にトイレ掃除させるなんてとんでもないという苦情」のため。 結果、清掃業者が入るようになったそう
海外配信消費税課税のフィジビリティは如何に - プロマネブログ
海外からの配信にも「消費税課税を」 NHKニュース 上記ニュースをみて、ホントウに実現可能なのだろうか、少し気になりました。 ちょっとフィジビリティを分析。 電子配信の業務フローをカンタンに書いてみる 最もよく使用されるであろう、クレジットカード決済での業務フローを、単純化すると上記の図のようになります。 ①電子配信の受信 指定した電子コンテンツのダウンロード契約を行います（商流）。このダウンロード契約と同時に、商品である電子コンテンツがユーザに配信されます（物流） ②クレジットカード決済 入手した電子コンテンツの費用が、コンテンツ配信会社よりクレジットカード会社へクレジットカード利用として計上されます（商流）。後日、請求日になりましたらユーザは請求金額の入金を行います（金流） ③利用料請求金入金 クレジットカード会社は、 ユーザから徴収した利用料をコンテンツ配信会社へ入金します。（商流・
システム分析アプローチを後輩と話した件 - プロマネブログ
後輩とシステム分析アプローチについて話す機会があったので、ちょっとだけ。 システム分析アプローチ システム開発を行う中で欠かせないのが、システムをどのように構築するのか分析するためのシステム分析アプローチです。 よく使うのは「POA」「DOA」「SOA」など。 それぞれのイメージを書くと以下のとおり。 POA（Program Oriented Approach：プログラム指向アプローチ） 業務フローなど、対象となるシステムモデルをベースに、事務手続きなどの「プロセス」をプログラムに落としこんでシステムを構築する技法。 小規模のバッチを中心としたシステムではわかりやすく作りやすい強力な設計技法。 でも、規模が大きくなるとスパゲッティなシステムとなってしまう。。。一個一個のアプリをどんなにきれいなプログラミングしても、システム全体がスパゲッティとなると破綻してしまう。。。アプリケーションの影響
消費税増税システム改修のトラブル報道から見る日本のシステム稼働率要求 - プロマネブログ
首都圏のスーパー 消費税トラブル相次ぐ NHKニュース オッサンは残念なことに今回の消費税増税に関するシステム改修のに直接関わっておりませんでした。世間的には4/1にリリースされたものの、障害が早速発生したようですね。 対応されるSEの方の苦労が忍ばれます。 ITpro編集長日記 - やはり免れなかった消費増税の鬼門：ITpro まあ、予定通りの「過去の教訓がない」批判ですね。 言いたくなる気持ちもわかりますが、１７年前よりも技術もシステムも進歩している現在、今回のトラブルが前回の消費税対応の教訓を活かせる事例なのかどうかもきちんと分析できてないのに、「教訓は十分生かせてない」なんて乱暴なことを言うのは些か閉口です。 消費税増税対応に伴うトラブル発生は、通常よりもむしろ少ない 日本には、2014年4月現在、3423の東証上場会社*1があります。 今回、ニュースになるような業務停止を伴うトラ
SIerとクラウドのエコシステムを描いてみる - プロマネブログ
クラウド自身が競争力としてのシステムインテグレータを必要としている － Publickey ふむ。もしかしてSIerとクラウドベンダってかなり密接な関係を持っているけど、意外と知られてないのかな、と思いました。 ちょっとSIerを取り巻くエコシステムについて、まとめてみようかと思います。 ※ココらへん会社などによってかなり方言がある場合があり、用語が異なるかもしれませんが、ご了承ください。 従来のSIエコシステム 大まかなSIerのエコシステムを図示すると、上記図のような関係があります。 ソリューションプロバイダー ユーザに対して「ソリューション」を提供します。 要は、業務改善のための業務フロー設計を行ったり、SOAなど考え方を用いて概要アーキテクトレベルの設計を行ったり、パッケージやハードウェアの選定を行ったりするなど、システム全体の設計を行います。プロジェクト取りまとめとしてマネジメン
単純な業務標準化礼賛は失敗のもと - プロマネブログ
記者の眼 - 「うちの社長はITが分からない」の欺瞞：ITpro この手の記事でERPを礼賛されているのを見ると、ちょっと違和感を感じるんですよね。。。 オッサンは受託だけでなく、Saasのサービス作ったり、パッケージ作ってたりもしてます。作る側の観点から違和感をちょっとまとめます。 国が違えば法・習慣も違う 業務の標準化が完了している欧米企業なら、買収対象の企業の業務プロセスもシステムも自分たちの仕組みに片寄せする。繰り返すが、どちらがベストプラクティスかよりも、標準化が重要だからだ。 パッケージでよく行われるカスタマイズとして 国カスタマイズ 業種カスタマイズ 個社カスタマイズ なんてのがあります。 一番問題となるのが「国カスタマイズ」。国によって言語はもちろん、法律、取引習慣等の慣習が違うことはよくあることです。パッケージは、往々にしてベースとなる業務スタイルを持ってますが、パッケー
新人プロジェクトリーダ向け。チームとプロジェクトを動かす１０のポイント - プロマネブログ
もうすぐ４月ですね。 ４月は人事異動の季節ということで、配置換えなど、仕事が変わることもあるかと思います。 オッサンの後輩なんかもこの時期チーム体制の変更などにより新たにプロジェクトリーダなどに抜擢される人もいるのですが、だいたい半年ぐらいは苦労する人も多い。 そんな若手に向けて、オッサンが過去行ってきたアドバイスをちょっとだけまとめてみます。 新人プロジェクトリーダ向け チームとプロジェクトを動かす１０のポイント １．チームメンバーが仕事ができないと思ってイライラしてはいけない リーダに抜擢される人は、設計やプログラミングなど仕事ができる人を抜擢するケースがよくあります。で、仕事ができる人がリーダになった場合、自分を基準につい仕事を割り振りがちだったりします。 「オレなら１日でプログラミングが終わるのになんで３日もかかるの？」とか、つい言いがちですけど、グッとこらえてください。 メンバー
「クラウド時代に自ら変革、日本のSIにパラダイムシフト」の雑感 - プロマネブログ
「2015年問題」がIT業界に迫る覚悟 - ［2015年問題4］クラウド時代に自ら変革、日本のSIにパラダイムシフト：ITpro ふ～む。上記記事を見ていて気になる記述がありましたので、ちょっと言及してみます。 クラウドで期間は短くなる？ ユーザー企業がパブリッククラウドを望めば、運用・保守やシステム基盤構築は不要になり、設計や要件定義にも従来とは異なるスキルを要求される。必要なソフト機能をネット経由で複数のクラウドから利用できるようにする、SaaSベースのSIが必須となる。 こうなると期間（工数）は短くなり競合も激しく薄利多売は避けられない。プライベートクラウドも、ほとんどの企業が自社センターからホスティングに変更する。 ちょっと問題となる記載がコレ。 「運用・保守やシステム基盤構築は不要」とありますが、パブリッククラウドになったから運用・保守が不要ってのはちょっと。。。 パブリッククラ
IT業界の「非モテ」とリケジョ比率 - プロマネブログ
データえっせい: 理系専攻率の国際比較 面白い記事を見ました。 元記事では、大学で理系専攻率の国際比較を行ってますが、日本は男女とも理系専攻率が低いとのこと。 それに対して韓国などでは女性の理系専攻率が高いとのことでした。 女性リーダーが活躍するオフショア 元記事を見てふと思い出したのは、オフショアです。 オフショア会社とは何社か付き合いがありますが、チームメンバーの大半が女性なんてのもザラ。過半数は女性リーダだったりしました。 それに対して、オッサンの会社は女性は１～２割程度。オッサンのチームに日本人女性はいません。全員男性です。 とまあ、改めて考えて見れば、中国なんかのオフショアでは女性が非常に活躍してます。日本では考えられないぐらいです。 聞いてみると、オフショアで活躍している女性に聞いたところ、ソフトウェア工学やコンピュータサイエンスを専攻してきたとのこと。 日本の職場では、大多数
詳細設計書も問題だけど、それ以上に成果物定義が問題 - プロマネブログ
詳細設計書という名のゴミ | Gm7add9 この手の話題が定期的に上がるわけですけど、毎度同じだよねで終わってしまっては人間進歩しないので、何が問題でどうすればよいのか少し考えてみたく。 詳細設計書は「プログラム説明書」として欲しい。 まあ、元記事も多分業務システムの受託の話の模様なのでSIをターゲットに。 往々にしてSI、特にウォーターフォール開発のプロジェクトの中では、設計書などのドキュメントを多数作成いたします。*1 V字モデル的には、設計から開発に至るまでの間 要件定義書 基本設計書・外部設計書 基本設計書・内部設計書 詳細設計書 プログラム みたいな成果物を作成いたします。 個別の詳細は別のサイトに任せるとして、それぞれ記載する内容を一言で表すと、要件定義書は「スタートとゴール」、外部設計書は「業務とサービスの仕様」、内部設計書は「サービスの構造と機能の分割」となります。 ※た
ITPro 「改正派遣法、施行されれば廃業」 の雑感 - プロマネブログ
変わる派遣法！IT業界に迫る地殻変動 - ［3］「改正派遣法、施行されれば廃業」：ITpro う～ん、微妙だった。。。 ユーザが再委託先を管理したら偽装請負 ユーザー企業では、IT業界で散見される多重下請け構造を避ける傾向が強くなりつつある。ITベンダーの管理が複雑になるからだ。元請けのITベンダーが、業務の一部を別のITベンダーに「再委託」することを禁止する条項を契約書に盛り込むこともある。元請けのITベンダーは再委託を避けつつ技術者を確保するため、従来の再委託先である中小ITベンダーに、派遣の形態を要求するわけだ（図1）。 再委託を禁止する「再委託禁止事項」や「再委託事前承諾事項」などの契約、見たことがないわけではないんですけど、これはちょっとおかしいですね。。。 「元請け」とあるように、一次請けが請負で契約を結んだ場合、「ユーザ企業にとってベンダ管理が複雑になる」ことを理由に、二次請
デスマーチの行進の仕方 - プロマネブログ
とりあえず、移行が1年延期が発表されたみずほ銀行のシステム統合の行方を占ってみる - プロマネブログ 前回、みずほ銀行のプロジェクトが炎上しているんじゃないかな、と書きましたので、そこからの派生。 システム開発などプロジェクトに関わり続ける限り、いつ遭遇してもおかしくないのがデスマーチ。 クマに遭遇した時にやり過ごすために死んだフリすることもありますが、デスマーチに出会った時にやり過ごすための主な方法についてちょっとまとめてみます。 基本はQCDの再調整 デスマが発生した場合、いろいろなやり過ごし方がありますが、基本はQ(quality：品質)C(cost：費用)D(delivery：期限)を見直すことが基本です。 現在対処が必要となるプロジェクトの要求がプロジェクトメンバーの処理能力の限界を超えた時、往々にしてデスマが発生します。つまり、プロジェクトメンバーの処理能力の範囲となるよう、Q
IT技術者の2014年年収予想を世界主要国と比較してみた - プロマネブログ
給与調査｜外資系・日系グローバル企業への転職ならロバート・ウォルターズ 調べ物していたら面白い資料を見つけました。 この資料は、各国の給与予測調査を行った結果ということで、日本を含めた数カ国の2014年予想年収、2013年の実勢年収を調査したものということです。 この資料にIT技術者の給与についても書いてありました。 ちょっと興味があったので、日本と主要国のPM、SE、PGの給与比較をしてみます。 主要国給与比較結果 ※フランスなど国によってはSEという職種がない場合がありますので、その場合はシステムアーキテクトやビジネスアーキテクトなどで代用してます ※プログラマは言語によって給料に差がある場合があります。比較しやすかったJavaプログラマを使ってます。 ※各国ピンきりの幅が広かったのですが、分布がわからないためピンきりの中間を取ってます。上海は最大値が非常に高かったため、ちょっとイレギ
『細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」 』の所感 - プロマネブログ
Developers Summit2014 リポート：ベンダーよ、シェルパの屍を越えていけ ～ 細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」 (1/2) - ＠IT 2月14日は仕事が忙しく聞きに行けませんでしたが、サマリレポートだけでも非常に楽しめたので、所感を。 バンバン出てくる実社名。。。大体予想できる会社でしょうけど、聞きたかったなあ。 出てきた内容からの所感を幾つか。 プロマネの仕事はやっぱり政治だ。。。 細川氏は、トラブルを防ぐためには「根回し」が大切だという。ベンダーは、ユーザーが「ちゃんと決めてくれる」かどうか、そして「誰が本当のキモなのか」を見極める眼力が必要だ。キーマンを見付けて、その顔色を見て、泥臭い根回しを続けなければならない。「開発は、きれいな身体ではできないものです」 これも典型的なあるあるですね。 正直、ステークホルダーを如何に上手く調整するか、
日本のIT業界の収益性の悪さは業界構造の悪さって本当？ - プロマネブログ
アナリスト・金谷敏尊が斬る！ 日本のIT業界に未来はあるのか：【第1回】ここが変だよ、日本のIT市場 (1/2) - ITmedia エンタープライズ う～ん、気になる記述があったので。 日米IT業界の利益率を比べるのはあまり意味が無い 北米では、大手SIベンダーであるIBM、Accenture、CSCの営業利益率はおおよそ15％前後であり、Oracle、SAPのような大手ソフトウェアベンダーでは35％前後の高利益率を維持している。これに対して、日本の名だたるITベンダーはどうだろう。NTTデータ（6.4％）、日立製作所（4.3％）、NEC（3.7％）、富士通（2.3％）と営業利益率は桁がひとつ異なるのが現状だ（総務省「平成25年版情報通信白書」に基づく）。 元記事では日本のIT業界と米国のIT業界を比較し、日本のIT業界は利益率が低く、それは日本のIT業界の構造的な問題が原因と分析してま
技術以外に設計に影響を与えるもの - プロマネブログ
論理削除と物理削除 ソフトウェア設計を行う際に、物理削除と論理削除ってのがあります。 物理削除というのは、データを削除したいとコマンドを発行したときに、データを即座に消す設計です。 これに対し、論理削除と言うのは、データを削除したいとコマンドを発行したときに、データを実際には消さずに利用者から見えなくする設計です。windows のゴミ箱をイメージすると分かりやすいかと思います。 この物理削除と論理削除、昔からどっちを設計上で採用するんだ、でもめることが多く、さながらキノコたけのこ論争みたいになったりすることがあります。 オッサンが若手の頃は、「とりあえず論理削除にしておけば後で問題が起きたときに復旧しやすいから安心」なんて教わったりしてました。 でも、最近は「積極的な要件がない限り、物理削除とするべき」という思想になってます。 そんな風に考えるようになったのは、以下の理由があります。 そ
「横浜銀カード偽造事件」の問題分析と雑感 - プロマネブログ
横浜銀、カード偽造事件 浮かぶＩＴ業界の「闇」 ：日本経済新聞 上記のカード偽造事件の感想を書こうと思ってすっかり忘れていたのですが、いまさら思い出したのでエントリ。 セキュリティ対策のためのよくある手段 よく、IT企業などの内部者によるセキュリティ関連の事件が発生すると、大体の場合はセキュリティ監査の強化などにより対策を行われるのが通例です。 大体の場合、「ログ取得による後追い検査」「作業承認制度の導入」などが行われる場合が多いです。 本番データを扱う端末室の入退出ログを取る。 指紋認証などを導入し、限られた承認メンバーのみ入室できるようにする 端末室入室を承認制にする 本番データを扱う端末自体のアクセスを承認制にする 端末ログを自動で記録するようにする とまあ、こんな感じです。 後追い検査は、要は問題が起きた場合に誰が問題を起こしたのか、をバックトラックできるようにするための措置です
プロジェクトリーダはコードの読み書きできれば良いか - プロマネブログ
「コーディング技術にこだわり過ぎると～」の反省会 - プロマネブログ コーディング技術にこだわり過ぎるとITエンジニアの地位は向上しない - プロマネブログ そいえば、上記記事のブコメ欄でいただいたコメントの中で考えてみたいなと思うコメントがあったので、記事でまとめてみようかと。 プロジェクトリーダに必要となる技術はコード読み書きできればOK? どっちにしてもコードが読み書きできない人はソフトウェア開発に関わっちゃいけませんので、その辺何卒よろしくお願いします。 考えてみたいのは上記コメント。異論はないのですけど、プロジェクトリーダ(以下、PL。プロジェクト進行の話が中心なので、広義のプロマネって言うと話がごっちゃになるので)はコードの読み書きできるぐらいでいいのかってのはあります。 知っている限りのPL連中は、往々ソースの読み書きできます。 もともと、プログラミングやったこと無いって人も
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
