今のSI業界もリファクタリング可能だと思います - 達人プログラマーを目指して
SIという用語を聞いてイメージするもの 業界の現状を考えると理解できることではありますが、SI業界やSIerという言葉に対して、極端に悪いイメージを抱く人が多いようです。SEやPGなどの用語もそうですが、立場によって用語からイメージするものが大きく違っているみたいです。 用語 文字通りの意味 業界の常識 先端技術を追う人 プログラマー プログラムを書く人 PGと同義 新しい価値とサービスの創造者 PG プログラマーの省略語 コードを書き下す単純労働者 時代遅れの恥ずかしい言葉 SE システム化を行うエンジニア PGの上位職、御用聞き Excelとパワポの専門家 じゃまで不要なもの SIer 大規模な業務システムの開発・ 統合・保守を専門で行う会社 ITゼネコン構造の上位に位置するもの 人集め、中抜き、ブランド 軽蔑の対象、憎むべき敵 つぶされるべきもの 私はどちらかというと言葉の意味を文字
最近の開発現場はギャグとしか思えない - rabbit2goのブログ
知人とコソコソと世間話。最近の開発現場は面白いことが多過ぎるという点で意見が一致してしまう。その一例。 人の入れ替わりが激しくて技術やノウハウが蓄積しない。忙しくなるとスキルよりも経験よりも頭数を揃えることを主目的にやたらと人を集めるものの、プロジェクトが終わると直ぐさま関係を切ってしまうので継続的な蓄積が何も残らない。 コンプライアンスの掛け声の下、関係者以外にも情報が見えてしまうホワイトボードやRedmineによる情報共有はご法度。セキュリティ対策も厳しくなる一方なので、ソフトをダウンロードしてパソコンに入れるだけで、正義感の塊のような監視委員から直ぐさま電話がかかってくる。 行き当たりばったりの対策を取り続けているので、何か問題が有ってもブレーンストーミングで出てきたようなアイデア案ばかりが続く。根本原因を探ることをしないし、そもそもそんな追求を行うスキルすら無い。 人月単価に惹かれ
オブジェクトの広場
今月もオブジェクトの広場をどうぞお楽しみください。記事に対する感想は、ぜひ公式Facebookページのコメント欄までお願いいたします。（2023.12.20） 寝かせて使うソフトウェアコンテスト 本選レポート オージス総研主催のソフトウェアアイデアコンテストOGIS-RI Software Challenge Award 「寝かせて使うソフトウェアコンテスト」の本選と最終審査を2023年11月15日（水）に当社東京オフィスで開催しました。本レポートでは受賞作品と本選の様子をご紹介します。 はじめての自然言語処理 第30回 Elyza 日本語 Llama2 指示応答モデルのファインチューニングと vLLM での推論 今回は Elyza の日本語 Llama 2 指示応答モデルをファインチューニングし、vLLM にデプロイして高速に推論してみます。70 億パラメータモデルならギリギリ Tesl
“開発のよくある問題”を解決するCMMIの3大メリット－ ＠IT情報マネジメント
効率的に開発作業を行うために、どのような業界標準を使っていても、さらなる改善に組織を導いてくれるCMMI。今回はその3大メリットを紹介する。 （→記事要約<Page 2>へ） 前回、CMMIとは「開発から管理、組織運営、定量分析まで全てをカバーした“全部入りモデル”」であり、単一のプロジェクトだけではなく、複数のプロジェクトの成功を狙う「組織としてのビジネスの成功を目指したものである」と解説しました。 また、以下の図1はIT業界で使用されている開発の主な標準モデルと、そのカバー範囲をおおまかに示したものですが、このように、アジャイルとCMMIなど「一連の業界標準はお互いに排他的ではなく、重なる部分が多い」ことも紹介しました。すなわち、今現在スクラムを使って開発作業を行っている場合でも、作業を改善するためにCMMIを有効に使うことができるのです。 図1 IT業界で使用されている主要な業界標準
Joel on Software - 5つの世界
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/5/6 ある重要なことがプログラミングやソフトウェア開発についての文献でほとんど語られず、そのため私たちは互いに誤解する結果となっている。 あなたはソフトウェア開発者だ。私もそうだ。しかし私たちの目的や要求は異なっているかもしれない。実際、ソフトウェア開発にはいくつかの異なる世界があり、異なった世界ではルールも異なっている。 あなたがUMLモデリングの本を読んでも、それがデバイスドライバのプログラムを作るのには役立たないということはどこにも書かれていない。あるいは「(.NETに必要な)20MBのランタイムは問題ではない」というアーティクルを読んでも、それは当たり前のことに触れていない：あなたがROMが32KBの携帯電話のためのコードを書いているなら、それは十分に問題だ！ ソフトウェア開発には
「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
請負契約がソフトウェア開発者を苦しめている - プログラマの思索
IT業界で仕事していて、何故かデスマーチプロジェクトに数年に1回はぶち当たる。 デスマーチに陥る原因は技術力の不足やプロジェクト管理の能力不足などがあるけれども、IT業界で一般的な請負契約そのものに根本原因があるような気がしている。 請負契約が日本のソフトウェア開発者を苦しめているのではないかという仮説について考えたことをラフなメモ書き。 【元ネタ】 Twitter / @akipii: 日本のソフトウェア開発者を苦しめている根源に請負契約があるという仮設を考えてる。平鍋さんや倉貫さんが試しているアジャイルな契約は請負契約のアンチテーゼと考えると分かる気がする。 Twitter / @akipii: @mr_amichan 請負契約の制約条件は開発者の想像以上にソフトウェア開発者に厳しいのです。請負契約である限り本当のアジャイルな開発でないと体験してます。それをうまく説明したい。 Twit
ソフトウェア開発におけるプロジェクト運用の問題点 - レベルエンター山本大のブログ
以下転用。見事な風刺。 ・顧客が説明した要件 「他社に無い高性能なブランコを頼むよ」「能力三倍でガガっとこんな感じで」「システムよくわかんないんだよね」 ・プロジェクトリーダーの理解 「承知いたしました」「しかし３段なんて無理だと私だからこそ気付ける。１枚板こそ肝要」「ブランコって枝からぶら下げて…こんな感じだっけ」 「初めての分野で細かい仕様判らんからなあ」「精査はアナリストに任せよう。ブランコこがせたいのであとはヨロシク！」 ・アナリストのデザイン 「分析の結果、これでは漕げません。リーダーの目的仕様を満たすため邪魔な幹を除いて…」「ありゃ倒れるか？支柱を…」 「なんとしてでも今のままブランコが動けるように！」「ふぅ、作業要件定義の数も増えたしプロジェクトっぽくなってきたかな」 ・プログラマのコード 「なになに？ええと設計書によると… ブランコ板とロープが接続され、ロープが二本で木に接
こくちーずプロ - 無料で使えるイベント・セミナーの告知・集客サービス
個人から法人まで幅広い主催者の方にご活用いただいています。 イベント主催者7万人以上 チケット販売430万枚以上
ソフトウェア開発会社に入って学ぶべき最初の事 - やさしいデスマーチ
主に受託開発がメインのソフトウェア開発を行っている会社に入って学ぶべき最初の事です。よく、プログラミング言語を幾つか学べとか、技術的な部分が重要と言われています。しかし、個人的にはそれも大切かと思いますが、最近は開発プロセス・テスト技法・ドキュメンテーション能力などを学ぶ方が重要なのでは？と感じています。 技術的な部分を後にする理由 技術的な部分は業務を行っている中で、いくらでも学ぶ機会があります。少なくとも1年目や2年目では自分で新しい技術を持ってきて設計したりという事は少ないでしょう。すると、その会社で使われている技術を吸収するというフェイズでも良いという考え方もできるのです。勿論、自分で興味のある分野をどんどん伸ばすことは悪い事ではありません。 開発プロセスを学ぶワケ 別にアジャイルを学べ！みたいな事ではありません。しかし、ソフトウェア開発を進めていく中での作業の１つを取ったとき、そ
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
NTTデータのHadoop報告書がすごかった - 科学と非科学の迷宮
業界トップ のエンタープライズ Hadoop 企業 Cloudera に入社しました http://www.cloudera.co.jp/ 今年の6月に、「平成２１年度 産学連携ソフトウェア工学実践事業報告書」というドキュメント群が経産省から公表されました。 そのうちの一つに、NTTデータに委託されたHadoopに関する実証実験の報告書がありましたので、今更ながら読んでみることにしました。 Hadoop界隈の人はもうみんなとっくに読んでるのかもしれませんけど。 http://www.meti.go.jp/policy/mono_info_service/joho/downloadfiles/2010software_research/clou_dist_software.pdf 「高信頼クラウド実現用ソフトウェア開発（分散制御処理技術等に係るデータセンター高信頼化に向けた実証事業）」という
第1回 ITスペシャリスト：専門分野を複数持つ“山脈型モデル”が理想
「ITエンジニアは35歳が定年なんて言われているが、本当なのだろうか？」、「自分が勉強した技術が時代遅れになったらどうしよう？」――こうしたキャリアの不安を持つ若いエンジニアは多いのではないだろうか。 実際、IPA（情報処理推進機構）が毎年発行している「IT人材白書」の2009年版の調査では、IT関連の業種は、他の業種に比べ「将来の自分のキャリアが不安」と考える比率が高いことが明らかになっている（図1）。 ITエンジニアのキャリアの不安を解消するために実施されたのが、経済産業省の「IT人材職種別モデルキャリア開発計画策定事業」である。 この事業では、ITエンジニアの職種とスキルを体系化した「ITスキル標準」が定義する9職種について、トップレベルのエンジニア90人（1職種あたり10人）にインタビューを実施。インタビューに基づいて、職種ごとの標準的な「モデルキャリアパス」と、キャリアアップのた
RUP（らっぷ）
米国ラショナルソフトウェア社（現在はIBMの1部門）が、初期のオブジェクト指向（注1）をベースとしたソフトウェア開発に携ってきた企業・人々のさまざまな経験、専門知識、プラクティスを取り入れて、包括的な体系としてまとめたソフトウェア開発プロセス・フレームワーク、またはそれをサポートするプロセス製品。 RUPの特徴はユースケース（注2）を開発の基点とし（ユースケース駆動）、開発するソフトウェアの基本構造を早期に設定する（アーキテクチャ中心）が、ウォーターフォール（注3）のように始めから完全な形の完成品を想定するのではなく、重要な機能やリスクの大きな機能をユースケース単位にイテレーションを繰り返しながら構築する（反復型開発）ことなどである。また、RUPのプロセスは組織やプロジェクトごとにカスタマイズして利用する（カスタマイズ可能）ものとして構成されており、1つのプロセスではないので「プロセス・フ
日経SYSTEMS「設計ミスをなくそう」特集でのインタビューで思ったこと：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
日経SYSTEMS 3月号「設計ミスをなくそう」特集でインタビューいただいた。事前に大まかな話題をいただき、「俯瞰的な話」として回答差し上げた。ソフトウェアレビューを研究テーマの1つとして進めているので当然なのだが、普段細かい話や計測結果等を相当に近視眼的にみているので、視点を変えて考えるよい機会をいただけたと思う。 詳細は日経SYSTEMSをご覧いただきたいが、事前の話題をいただいた時点で考えたことは以下のとおり。 ここ10年くらいの文献の変化をみると「網羅的にとにかく全てのエラーを発見する」という考えから規模の増大に伴って「どこ（あるいは何）に注力してエラーを発見するか」という考え方に変わりつつある。（そのようなレビューが適しているソフトウェア、プロジェクトの割合が増えてきていることを反映したものだと思う。これにあてはまらないものもあるだろう） レビューの形骸化の主要な原因には、作業量
ソフトウェア工学とは何か
ソフトウェア設計とは何か？ （原文： What Is Software Design?） by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は，Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 本記事では，オブジェクト指向プログラミング言語の代表として C++ を挙げていますが，これは本記事が執筆された当時，一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java，Delphi，C# といったオブジェクト指向言語が利用可能となっていますが，そんな今でさえこの記事は古さを感じないものとなっており，ソフトウェア開発の本質，現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W. Reeves 氏に，
N AIST-IS-MT0451098 修 士論文 ソ フトウェア開発プロセスにおける 定 量的管理指標の導入支援 引地 一将 2 006 年 2 月 2 日 奈良先端科学技術大学院大学 情報科学研究科 情報システム学専攻
N AIST-IS-MT0451098 修 士論文 ソ フトウェア開発プロセスにおける 定 量的管理指標の導入支援 引地 一将 2 006 年 2 月 2 日 奈良先端科学技術大学院大学 情報科学研究科 情報システム学専攻 本 論文は奈良先端科学技術大学院大学情報科学研究科に 修士(工学) 授与の要件として提出した修士論文である。 引地 一将 審査委員： 松 本 健 一 西谷 紘一 飯田 元 門田 暁人 教授 教授 教授 助教授 （主指導教員） （副指導教員） （副指導教員） （副指導教員） ソ フトウェア開発プロセスにおける 定 量的管理指標の導入支援 * 引 地 一将 内 容梗概 ソ フトウェア開発プロセスの管理と改善の一手段として定量的管理がある． 定 量的管理とはプロセス中で定量的に測定されたデータから得られる管理指標に 基づいて開発プロセスを管理することであるが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://objectclub.jp/technicaldoc/testing/stack_tdd.pdf
http://www.sde.cs.titech.ac.jp/
組込みソフトウェア管理者・技術者育成研究会