SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
法務・知財
情報サービス取引 同業者間取引 知的財産権法 経営資源管理 サイバーセキュリティ 法務・知的財産関連政策 法務研修テキスト 報告書 JISAブックレッツ14「デジタル時代のIT法務と契約実務」2022年11月1日新発売！ 今日必要とされる法務・契約上の知識を多角的視点から編纂しています。 ◆内閣官房・公正取引委員会 「労務費の適切な転嫁のための価格交渉に関する指針」の公表について ～労務費の転嫁に係る価格交渉について、発注者及び受注者がそれぞれ採るべき行動/求められる行動を「12の行動指針」としてまとめたものです。 ◆公正取引委員会 「労務費の適切な転嫁のための価格交渉に関する指針」と「取引適正化・価格転嫁促進に向けた取組」についての説明動画 ～YouTubeで配信中です。 情報サービス取引 システム開発・運用取引 JISA報告書「JISAソフトウェア開発委託基本モデル契約書2020」 報
NTTデータが新開発手法、“見た目重視”で工期3割削減：ITpro
NTTデータは2008年10月15日、顧客の要求を使いやすさも含めて的確に定義するシステム開発手法を策定したと発表した。特徴は、要件定義時に画面レイアウトを含めたシステム全体の使いやすさについて顧客と合意を取ること。 米アクシュア・ソフトウエア・ソリューションズ製の画面プロトタイプ作成ソフト「Axure RP（アクシュア・アールピー）」を利用することで実現した。この手法に変更することで、要件抽出における品質向上と約30%の工期短縮を実現できるという。同社はこの手法を拡大し、2009年に50件の適応を目指す。 新手法では企画工程で業務の全体像を定め、それをもとに画面レイアウトのプロトタイプを「Axure RP」で作成する（図）。Axure RPはVisual Studioなどの開発ツールよりも簡単な操作で画面レイアウトを作成でき、Visioなどの作画ツールよりもリアルに本番環境でのシステムの
きたみりゅうじ&ウェブキャリア SEフトシ君の知っておきたい「転ばぬ先の商慣習」第11回 - ウェブキャリア
第11回 営業日は何曜日？「基本的には」と落とし穴。 第10回 「電気料金の案分」と言われて計算してみたがどうしましょの罠 第9回 売上日と出荷日は同じか否か？商売という行為の意味を聞く。 第8回 予算策定システムは、「ボトムアップ」か「トップダウン」か。 第7回 「クビになるかも」と、見積もり有効期限の恐ろしさを知る 第6回 商社向け会計システムで知る、「会計」という言葉の幅 第5回 「年次処理」でぶち当たった、まさかまさかの落とし穴 第4回 「売上がのってない!!」…言われて直してまた怒られて 第3回 「請け書には印紙をよろしく」言われて待ってた落とし穴 第2回 設計終了で受けた指摘に「消しゴム？」と固まる私 第1回 とある受発注システムで「締め日」の意味に脂汗 フトシくんは、IT専門学校を卒業後、中規模SIerにて働くコーディング大好きな若手SE。 プログラミングならなんでもござれ！
Revision 502: /akm2000/plugins/trunk/selectable_attr
Revision 502: /akm2000/plugins/trunk/selectable_attr
［OSC島根］「RubyでCOBOL技術者は復活する」---松江市の基幹システム開発で得られた実感
「COBOLとRuby on Railsのアプリケーション構造は似ており，ベテランSEのノウハウが生かせる。RubyでCOBOL技術者は復活する」---テクノプロジェクト 専務取締役 吉岡宏氏は2008年9月12日から13日にかけて開催されたオープンソースカンファレンス2008 Shimaneの講演で，松江市の高額医療費合算システムをRubyで開発した経験で得られた感想をこう語った。 テクノプロジェクトは，IPAの自治体へのオープンソースソフトウェア導入実証事業として，松江市の高額医療費合算システムをRuby on Railsで開発した。この実証の目的は，Rubyが自治体の基幹システムに耐えうることを実証することおよび，COBOL技術者がRubyでシステム開発するためのノウハウやライブラリの整備である。開発されたプログラムはオープンソース・ソフトウエアとして公開されており，また得られたノウ
「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えよう - kなんとかの日記
はっきり言おう。大規模プロジェクトは存在自体が悪。 続けて同氏は、ケーパース・ジョーンズ氏の著書「Patterns of Software System Failure and Success」から調査結果を引用し、大規模プロジェクトになればばるほど、当初の見積もりとは大きくかい離したものになり、かつ失敗する可能性が高いことを示した。「（一般的なプロジェクトも含めた調査結果でさえこれなのだから）デスマーチについては推して知るべし」とヨードン氏。 エドワード・ヨードン、デスマーチを成功に導く対症療法を説く - ITmedia エンタープライズ (強調は筆者による) うむ。言っていることはごくあたりまえのことではあるが、ヨードン氏が言うと説得力がある。 調査結果の抜粋。FP（ファンクションポイント）はジョーンズ氏が定義している単位で、1FPが100行程度のコードであるという。1FPであればほぼ
COBOL屋の呪縛 - masayang's diary
今回の日本出張ではいくつかのプロジェクトの状況をみてきた。で、思ったこと。 「COBOL時代のデータ構造を引きずることで、生産性や保守性が落ちている」 フラグだらけのマスター 本物のコードをだすわけにはいかないので、すごく簡略化した例で説明したい。あるシステムを利用できるユーザのマスターテーブルがあるのだけど、そいつには「なんちゃらサービス利用可否フラグ」みたいなのがたくさんついているのね。 この方式の問題は以下の通り。 テスト負荷 フラグがあるということはそれをチェックするif文があるということ。 if文があればテスト件数は最低２件は増える。 入れ子になれば、４件、８件...と増えていく。andやorでも同じ。 コードの冗長性 「あるユーザがサービスAを使えるか」を調べる処理と「あるユーザがサービスBを使えるか」を調べる処理はほぼ同様になることは明らか。 「サービスAを使えるユーザ」を調
あるＳＥのつぶやき: プロジェクト管理メモ
プロジェクト管理はオンラインの情報だけで学べるものではないとは思いますが、情報がなくならないようにメモしておきます。 ■プロジェクト管理 プロジェクトマネジメント入門：ITpro プロジェクトマネジメント連載記事インデックス プロジェクトマネジメントの理論と実践：ITpro 計画部分を重視したプロジェクトマネジメント連載記事インデックス プロマネ最強マニュアル---目次：ITpro プロジェクトの火消し方法解説記事インデックス プロジェクト・マネージャの「やってはいけない」---目次：ITpro プロジェクトマネジメントアンチパターン解説記事インデックス なぜプロジェクトは失敗するのか インデックス － ＠IT自分戦略研究所 プロジェクト失敗理由の連載記事インデックス EnterpriseZine：コーナー：実務で役立つプロジェクトレビューの心得 リスク管理などのプロジェクト管理解説記事イ
画面遷移の作り方のパターン - urekatのスカンク日記３
actionの分け方のセオリーってあるの？とずっと思っていたので整理してみる。 前提条件 確認画面があるかもしれない 完了画面もあるかもしれない Ajaxはつかえない そうです携帯用です 入力画面とDB書き込みを１つのactionにまとめるパターン(Railsレシピ33のpostbackみたいやつ) GETできたら入力フォームを出す。action先は同じaction==自分自身。 POSTがきたら(if request.post?)書き込み処理をする。 成功したらredirectで次の画面へ(GET). 失敗したら再度(GET時と同じように)入力フォームを出すと同時にerror_messages_forでエラー箇所を表示。 いいところ 入力フォームの生成用のaction/view,書き込み実行のactionが１つにまとまっているのでソースがきれい。 1画面と1actionを対応させやすい。
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
Microsoft Office ホームページ
すべての Microsoft 製品 Global Microsoft 365 Teams Copilot Windows Surface Xbox セール 法人向け サポート ソフトウェア Windows アプリ AI OneDrive Outlook Skype OneNote Microsoft Teams PC とデバイス Xbox を購入する アクセサリ VR & 複合現実 エンタメ Xbox Game Pass Ultimate Xbox Live Gold Xbox とゲーム PC ゲーム Windows ゲーム 映画とテレビ番組 法人向け Microsoft Cloud Microsoft Security Azure Dynamics 365 一般法人向け Microsoft 365 Microsoft Industry Microsoft Power Platform W
MS-Project の使い方 | ins13の日記 | スラド
今更ながら、ちょっとだけマジメに help を読んだので、メモしておく。 ほぼチュートリアルの要約だけど...。 なんといっても最初が肝心！この手順とルールを知っておかないと あとがすごくメンドウになる。 # というか、やっぱりマニュアルは読むべきだな。 1. 新規プロジェクトを作成 開始日を決めて OK とする(他は決めなくても OK)。 ひとまず保存して「ガントチャート」画面を開く。 2. タスクを積み上げる。 このとき、開始日・リソースは気にしないで、タスクと期間のみを淡々と入力する。 ※小技その１： 期間の欄で、数値の後に次の省略文字を付けると、月、週、日、時、分を簡単に入力できる。 ・ 月 = mo ・ 週 = w ・ 日 = d ・ 時 = h ・ 分 = m 単位は「日」か、もしくは「時間」で揃えるとラクかも。 ※小技その２： 期間の欄に ０日(0d)を入力すると、そのタスク
［見積もり編］FPを過信してはいけない
見積もりを作成する際に，定量的な見積もり技法を用いることがある。特に最近ではファンクションポイント法（FP法）が定着しつつあり，現場で用いられる機会も増えている。FP法はシステムの工数規模が定量的な数値となって表現されるため，発注側と受注側の双方の共通の物差しとして用いられる。また1人月当たりの生産性指標として用いられることもある。 しかし，FP法で計測された値を過信すると大きな失敗を犯す。実際の現場でも，FP法の数値だけが一人歩きしてしまい大変な結果となったケースがある。 FP法は「ユーザーが識別しない機能」を数えない Dさんは，中規模SIベンダーV社の中堅社員である。数年前にFP法（IFPUG法）について外部研修を受け，見積もりの根拠として必ずFP値を提出していた。 今回，V社は大手携帯電話会社U社から，販売店に対するリベートを支払うシステムの再構築を受注した。契約の形態としては，要件
ネトゲと仕事～明け暮れる毎日 - Sapiensの生産性
一番聞かれる事が多いのは、やっぱりこれ、「生産性」だね～＾＾ 「ファンクションポイント法」という、システム規模の見積技法をご存知でしょうか？ 「Ｃシステム」は、前にやった「Ａシステム」の、およそ倍くらいの規模だねぇ＾＾ Ａシステムの開発経験者であれば、およその見当でこんな事が言えますが、これってとっても主観が入りやすいと思いませんか？ｗ そこで、システム規模を比較しやすい客観的な数字として表そうとしたのが、ファンクションポイント法（以下、ＦP法）です。 FP法は、だいたい以下の様な手順で算出します。厳密には異なるかもですが、そこはかんべんですｗ システムの画面にある入力・出力ボックスの数を数える。またその画面で使用されるファイル（テーブル）の数を数える。 ボックスの数と、ファイルの数を使用して、FP法で決められた算出式に当てはめ、FP値を求める。 １～３を、そのシステムが持つ画面数分、
ファンクションポイント法入門
ファンクションポイント法とは、ソフトウェアの規模（大きさ）をそのソフトウェアが持っている機能を元に測るための手法です。ソフトウェアという目に見えないものの大きさを測るのは難しい事ですが、現在ISOでも検討が進められており、このファンクションポイント法をベースとした「機能的規模計測」として標準化される見込みです。 ファンクションポイント法の概要については、こちらをご覧下さい→ファンクションポイント法
ＩＦＰＵＧ法でのＦＰ算出 - Xupper技術サポート部のページ
あっ！肝心のＩＦＰＵＧ法でのＦＰ見積りについて紹介するのを忘れていました・・・ これまで、ＩＦＰＵＧが規定しているＦＰ見積りの手順が既知のものであるという前提で、各種見積り方法を紹介してきましたが、ツールでのＦＰ算出の方法を紹介する前に、ここで、ＩＦＰＵＧで規定されている手順について解説（復習）しておきたいと思います。 ＩＦＰＵＧ法での見積り手順は以下のとおりです。 1.ＦＰ計測種別の決定 2.アプリケーション境界の決定 3.データファンクションのＦＰ算出 3.1 データファンクションの識別（ＩＬＦとＥＩＦの識別） 3.2 データファンクションの複雑度の判定 3.2.1 データファンクションのDET数識別 3.2.2 データファンクションのRET数識別 3.2.3 データファンクションの複雑度判定 3.3 データファンクションのＦＰ判定 4.トランザクションファンクションのＦＰ算出 4.1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
not found
POST 後の振る舞い - まちゅダイアリー (2006-02-23)
MS Projectのマニュアルとテンプレート (.NETの覚え書き)