オープンソースERP&CRMのCompiere-Japan(コンピエールジャパン)中小企業向けオープンソース ERP Compiereサポートサービスを提供しております。
Compiere-Japan(コンピエール)｜中小企業向けOSS ERP Compiere
オープンソースERP&CRMのCompiere-Japan(コンピエールジャパン)中小企業向けオープンソース ERP Compiereサポートサービスを提供しております。
ついに実稼働が始まったオープンソースERP
Compiereの日本商習慣対応版を公開しているアルマス 代表取締役 ジリムト氏。モンゴル出身で日本で起業した [画像のクリックで拡大表示] 「同業他社での事例の半額。非常に安くできた。オーダーカーテンは特殊な要件の多い複雑な業務だが，うまくカスタマイズできた」---日恵装飾 営業企画室長 山口健氏は，7月1日から実稼働を始めた，オープンソースERPの「Compiere（コンピエール）」を採用した新基幹システムをこう評価する。OSなどの基本ソフトからミドルウエア，アプリケーションと上位のレイヤーに拡大してきたオープンソースの波が，ついに業務アプリケーションの“最高峰”であるERPへと到達した。 JavaベースのオープンソースERP「Compiere」 日恵装飾は，オーダーカーテンや内装リフォームを手がける企業。日本だけでなくヨーロッパなど38カ国にカーテンを輸出しているほか，マルイが販売す
システムの要求仕様書を適切に作成するためのガイドライン，JUASが公開
「ユーザー企業が必要としているのはどのようなシステムか」を定義した要求仕様書を，いかに適切に作成するか――IT業界における長年の懸案事項である。日本情報システム・ユーザー協会（JUAS）は7月5日，この課題の解決を狙った「要求仕様定義ガイドライン」を発表した。システム開発に必要な情報を盛り込んだ要求定義書をどのように書けばよいかを具体的に示すことを意図したもので，「要求仕様書をいかに作るかという“how”に踏み込んだガイドラインは初めてではないか」と，JUASの細川泰秀専務理事は話す。まだ未完成の部分もあるが，ユーザー企業やベンダーの参考資料として役立ちそうだ。 要求仕様定義ガイドラインでは，要求仕様書の構成要素を，(1)（狭義の）要求仕様書，(2)概念データモデル，(3)入出力の定義，の三つとする。中核となるのは(1)。まず，システムに対する要求を「上位の要求」「下位の要求」という二つの
“限りなくパッケージに近い”SIサービスが登場、日本IBMが業種特化のSOA戦略を開始：ITpro
日本IBMが開始したSOAに基づくSIサービスの基盤となるのは、「WebSphere Business Services Fabric（WBSF）」と呼ぶミドルウエア。2006年8月に米IBMが買収した旧ウェビファイ・ソリューションズ製品を改名した。 WBSFが提供するのは、業務の流れ（ビジネス・プロセス）をXML形式で記述したひな型と、そのひな型に基づいて実行されるソフト部品群である「ビジネス・サービス」だ。これらを使って、アプリケーションを実現するために、業種別の用語モデルやメッセージ・モデルなども持つ（図）。 現時点で提供できるビジネス・サービスは、医療業界と保険業界を対象にした約300種。今後は顧客ごとにIBMが開発したり、サードパーティ製品を利用したりすることで、「製造・流通業向けに拡大していく」（日本IBMのSI部門でSOA事業推進を担当する高橋和子部長）計画だ。 WBSFを基
戦略マップとビジネスモデルの融合
企業業務システムの設計は、業務の在り方（ビジネスモデル）に依存し、業務の在り方・進め方は、経営戦略に依存する。今回は経営戦略を明示化する戦略マップの作り方とビジネスモデルへのマッピングについて解説する。 RUP（Rational Unified Process：IBM）ではビジネスゴールを導いて、それを達成するためにモデルを洗練することを推奨しています。そのビジネスゴールを導くためにSWOT分析などを行うようにガイドされていますが、詳細には規定されていません。 一方、バランスト・スコアカード（BSC）でもSWOT分析を行うような流れになっています。そこで筆者たちはその一部分だけを使うのではなく、戦略マップを使うことを思い付きました。最初は大発見のように感じたのですが、後に多くの人たちがビジネスモデリングの際にBSCを利用することを提案していますので、当然の結果だったのかもしれません。ただ、
要求は誰に聞くべきか - akon2.00βのよっぱらいの戯言
要求を出す、顧客が多様なこと。 #発注者として、まとめておいてほしいところだけども、 #これをまとめることも仕事のひとつらしい。 #whatをまとめて、経営者に説明し、納得させるのが #コンサルタントの正しい姿だと思っています。 思いつくままに顧客のステークフォルダを並べてみた。 1)経営戦略の立案者 2)経営戦略の実施者(IT化するひともいる場合がある) 3)購買 4)各部門の長 5)実際にPCを操作するとその上司 いずれの顧客も何をどのように要求したらよいかのか、実際に動くものをみないとわからない場合がある。 1)経営戦略の立案者 実現不可能な立案であったり、そもそもその会社の「現場」の実情にあっていない場合がある。 #経営者失格だが、大企業ではありがち #「システム導入する前に新しいPCを買ってくれれば助かります」 #なんて話には事欠かない。せめてメモリ増設してあげようよ 2)経営戦
システムコンサル育成でSI事業の構造転換を図れ：ITpro
SIが儲からないビジネスになった今、事業構造の転換が求められている。鍵を握るのが、顧客の経営者と直接会話してITニーズを引き出す「システムコンサルタント」の育成だ。普通のSEをシステムコンサルタントに鍛え上げ、真のコンサルティング営業を実現するための実践論を連載する。 ITサービス業では、SIビジネス構造の転換が喫緊の課題とされ、必要な施策の1つとして「システムコンサルタント」の育成が位置付けられている。 顧客の経営者と会話してシステムニーズをくみ取り、システム発想ができて、システム化計画を提言する。計画が推進される時には、SI受注を実現する。また、場合によってはSI受注したシステムについての著作権を確保し、それを基に新しいビジネスを創り出す―。単なる技術課題を解決するITコンサルタントではなく、ビジネスの創出ができるのがシステムコンサルタントである。では、システムコンサルタントはどのよう
わたしが知らないスゴ本は、きっとあなたが読んでいる: いきなりコンサルタントに抜擢されたSEが読むべき5冊
上長から「来週からコンサルタントとして○○社に入ってくれ」なんて言われたときに、あわてないための5冊。以下の条件全部にあてはまる人のための選書なので、関係ない方はスルーしてくだされ。シリーズ化しつつあるエントリ（ [その1]、[その2] ）だが、ここらでまとめ。 システム開発チームのメンバーまたはリーダー 顧客の御用聞きを「コンサルティング」だと思っている ←これ誤り McKinsey や accenture といった「ファーム」と一緒に、顧客の中に入って仕事しなければならなくなった これまで、即効性と実用性で4冊レビューしてきたが、このたび5冊目として扱いたいガイドを見つけた（4冊目）のでまとめてご紹介。 ■最初に結論 コンサル会社がやっている「コンサルティング」は、決まりきった手順や方法を粛々と実行しているに過ぎない。目標に対して泥臭いぐらい愚直に反応する。そうしたメソッドと沢山持って
ソフトウエア規模の単位は何にする？
今回は規模見積もりの単位の話をしましょう。「このプロジェクトは何人月」とか「何億円規模のプロジェクト」といったプロジェクトの規模ではありません。これから開発しようというソフトウエアのサイズの話題です。 皆さんが規模見積もりで最もお困りなのは，「規模の単位を何にするか」ではないでしょうか。規模の単位を選ぶのは簡単ではありません。なにせ相手は，形のない論理の集合であるソフトウエアだからです。 今まで，多くの単位が提唱されてきました。ステップ数（LOC：Lines Of Code）や画面/帳票数，ドキュメント・ページ数がその代表です。ファンクション・ポイント（FP）数，ユースケース・ポイント数といった論理的に考案されたものもあります。これら複数の単位を組み合わせて見積もる人もいるでしょう。それ自体はよいことですが，軸になる単位は一つに決めておくべきだと思います。見積もり精度を高めるには，実績値や
要求工学の概要（要求工学：第1回）
概 要 要求工学はソフトウェア開発における要求仕様化プロセスを工学的に定式化する技術として注目を集めている。今年は第12回の要求工学国際会議（International Conference on Requirements Engineering,ICRE）が日本の京都で９月６日から11日まで立命館大学の衣笠キャンパスで開催される[１]。本稿では、要求工学の概要と要求工学の本質的な要素を明らかにするとともに、要求工学の価値について述べる。最後に要求工学の課題を紹介する。 要求工学の必要性 要求工学（ Requirements Engineering）は新しい技術ではなく1970年代から議論されている。ソフトウェア危機が1960年代に認識されたときに、ソフトウェア開発プロジェクトが失敗する主要な原因が要求の欠陥にあると報告されている[２]。 開発したソフトウェアが納入され変更することなく使わ
「要求工学」のエッセンスを吸収する
読者の皆さんは，ソフトウエア工学（ソフトウエア・エンジニアリング）をご存じだろうか。これは，ソフトウエア開発に関する先人の知恵と研究者の研究結果，言い換えれば「ベストプラクティス」を体系的にまとめたものである。 「要求工学」注1）は，このソフトウエア工学を構成する重要な領域の1つだ。実際，ソフトウエア工学としてどんな領域があるのかを米IEEE Computer Societyがまとめた「SWEBOK」（Guide to the Software Engineering Body of Knowledge）注2）でも，序章に続く第2章で要求工学を取り上げている。 もっとも，要求工学はまだ発展途上であり，PMBOKなどのように全体がきれいに体系化されているわけではない。様々な研究者やエンジニアが日々新たな考えを示したり，良いプラクティスを紹介したりしている状態で，用語の統一もまだ不完全だ。つま
業務システムにおける要件定義からのデータ分析
要件定義におけるデータ設計は、一般的にその工程内のタスクとして存在することはありません。それは、データ分析の結果は論理テーブルのスキーマ定義だけではなく、「作るべきシステム」の基本設計のすべてに反映されることになるからです。したがって、データ設計だけを抽出してこのコラムで紹介していくのは、大変難しいため、今回は業務分析内で特にデータ分析が関わるポイントについて述べていきたいと思います。 また、当然ですがこのコラムの内容は、システムにリレーショナルデータベースが存在することが前提です。 ○ トップダウンアプローチとボトムアップアプローチ 業務分析でのデータ分析は、トップダウンアプローチで業務エンティティを抽出することから始まります。多くのシステムでは、要件定義の段階で属性項目が洗い出されていることはあまりないため、ボトムアップアプローチによる、関係(リレーション)の抽出からのテーブル定義につ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Technical documentation
NAIST 情報科学研究科 ソフトウェア工学講座 - 要求工学
要求工学:Requirements Engineering(月刊ビジネスコミュニケーション)