タグ

ブックマーク / xtech.nikkei.com (103)

  • このベンダーに惚れた

    通り一遍の対応では顧客満足度(CS)は上がらない。それどころか目の肥えた顧客に腹を見透かされ、評価を下げることにもなりかねない――。 これが今回の「顧客満足度調査」の結論だ。13回目を迎えた誌恒例の調査は、新たに官公庁/地方自治体と大学を調査対象に加え、過去最高となる2213件の回答を得た。 ITベンダー各社の実力は急接近。21分野中9分野でランキング首位から最下位までが5ポイント以内にひしめいている。3年前に実施した第10回は22分野中4分野だった。システム開発・運用からハード/ソフト、ネットワークに至る全21分野の結果と合わせて報告する。 (市嶋 洋平、井上 英明) 記事は日経コンピュータ8月15日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。「特集1」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしていま

    このベンダーに惚れた
  • 惚れるベンダー,嫌いなベンダー--日経コンピュータ顧客満足度調査から

    日経コンピュータの2008年8月15日号で顧客満足度調査の特集記事を執筆した。第13回となる今回は従来からの企業に官公庁/地方自治体,大学を加え,全国から2213件という過去最大の回答数を得た。システム開発/運用といったサービスから,PCサーバーやERPパッケージといった製品のサポートを含めた満足度を算出している。 結果を集計し始めると,1つの傾向に気づいた。各ベンダーに対するユーザーの評価の差がグンと縮まっているのだ。具体的には,21分野中9分野でランキング首位から最下位までが5ポイント以内にひしめくという状況。3年前に実施した第10回では,首位から最下位まで5ポイント以内に収まったのは,22分野中4分野に過ぎなかったから,評価の差がいかに縮まったかが分かるだろう。各ベンダーの顧客満足度(CS)向上に向けた全社的な取り組みが一定の効果を上げた証左と言える。 しかし実際に2000枚の調査票

    惚れるベンダー,嫌いなベンダー--日経コンピュータ顧客満足度調査から
  • [MySQLウォッチ]第30回 MySQL 5.0のセキュリティ・ホールとInnoDBの設定

    前回からの短い間に,多くのバグフィックスとともに2つのセキュリティフィックスが含まれるMySQL 5.0.25がリリースされている。今回はこれらのセキュリティ・ホールについて解説する。また利用頻度が非常に多いInnoDBのファイル設定に関しても解説する。 MySQL 5.xのセキュリティ・ホール 権限のないユーザーが同名のデータベースを作成できる問題 Linuxなどファイルシステムが大文字と小文字をシビアに識別している環境で,来作成できないデータベースを作成できてしまうセキュリティ・ホールが発見された。 図1●権限のないユーザーが同様のデータベースを作成できるセキュリティ・ホールの症状(MySQL Bugs: #17647より) 1.$ mysql -u root -p 2.Enter password: 3.mysql> create database sample; 4.mysql>

    [MySQLウォッチ]第30回 MySQL 5.0のセキュリティ・ホールとInnoDBの設定
    mtbtaizo
    mtbtaizo 2010/01/13
    innodb_data_file_pathの設定方法
  • Android徹底解説---内部構造,移植,開発

    遂に日でもAndroid携帯が発売された。注目を集めているAndroidとは,一体何なのか,パソコンに移植するためにはどのような作業が必要なのか,アプリケーションを開発するにはどうするのか解説する。 目次 Androidの仕組みを知る(1)

    Android徹底解説---内部構造,移植,開発
  • グーグルのJavaScriptツール集大成「Google Closure Tools」

    2009年11月5日,Googleは自社サービス製品であるGmail,Google Maps,Google Docsなどの開発に使用しているJavaScriptアプリ開発ツール群「Google Closure Tools」を一般公開しました。 "Closure"は一般的に,閉鎖や閉店といった意味で使われます。ツールの命名としては少しネガティブなニュアンスを感じますが,Google Closure Toolsの場合は,終結といった意味で,開発プロジェクトにおける最終ステップの仕上げ用ツール。すなわち“栓”という意味で中身があふれ出さないようにキッチリ閉めておくものといった意味合いから命名されているようです。 Ultimate(究極)に近い意味でGoogleの自信の表れと受け取った方がいいかもしれません。Googleで新規公開になったプロジェクトとしては珍しく,ベータ版の表記もありません(Go

    グーグルのJavaScriptツール集大成「Google Closure Tools」
  • 上流工程-設計---目次

    新法で「アプリストアを競争状態に」の現実味、公取委はAppleGoogleと長期戦も 2024.05.16

    上流工程-設計---目次
  • 第3回 ●Xenのインストール方法(後編)

    今回は,米Red Hat社の新旧2つのLinuxディストリビューションRed Hat Enterprise Linux 4,同5と,Debian GNU/Linux 4.0でのXenのインストールに取り組んでみましょう。Xenに正式に対応したディストリビューションとそうでないものの違いがはっきり分かります。 前回は米Novell社のSUSE Linux Enterprise Server 10(以下,SLES 10)を例に採り,YaSTを使ったXenのインストール方法を紹介しました。今回は他のLinuxディストリビューションにおけるXenのインストール方法を紹介します。前半では米Red Hat社のRed Hat Enterprise Linux 4(以下,REHL4)を,後半では同RHEL5と,Debian GNU/Linux 4.0(以下,Debian)の例を紹介します*1。 これまでの

    第3回 ●Xenのインストール方法(後編)
  • Part5 基本設計におけるレビューの勘どころ

    Part5では,基設計フェーズにおける成果物の品質を向上させる施策について解説する。カギは,欠陥を除去するとともに欠陥を防止する仕組みを確立すること。重要な成果物については有識者を交えて「インスペクション」を実施することも大切だ。 「考慮していない外部システムとの連携が詳細設計で見つかった」,「仕様間の不整合が実装フェーズで発見された」――。どんなに基設計をしっかりやっても,その後のフェーズで「欠陥」が見つかれば意味がない。欠陥が発見されれば手戻りが発生し,進ちょく遅れや収益悪化といったプロジェクトの混乱を招く。 そこでPart5では,基設計フェーズにおける品質向上のプロセスや成果物のレビュー方法について解説しよう。 「欠陥防止」を徹底する 改めて言うまでもないが,基設計の成果物の品質を向上させるプロセスは,(1)設計作業を実施する,(2)成果物をレビューして欠陥を洗い出す,(3)

    Part5 基本設計におけるレビューの勘どころ
  • Part4 方式設計で利用できる「パターン」を知る

    高品質で変化に強いシステムは,アーキテクチャの良し悪しに依存する。だがアーキテクチャの設計は,外部システムとの連携や性能・信頼性の確保など考慮すべき点が多く,困難を極める。そこで利用したいのが,先人たちが生み出した方式設計のひな型である「パターン」だ。 ここ数年で,「パターン」という言葉がよく使われるようになった。読者も耳にしたことがあるだろう。 そもそも「パターン(Pattern)」とは,ある問題の解決策をテンプレート(ひな型)として記述したものである。問題を解決する手順や方法が記されているため,パターンを利用することで,迅速かつ確実に問題を解決できる。採用したパターン名をお互いに伝え合えば,メンバー間のコミュニケーション・ギャップも少なくなる。ただし,何でもパターンになるわけではない。再利用の価値があるものだけがパターンとなる。 パターンそのものの起源は古く,1970年代に米カリフォル

    Part4 方式設計で利用できる「パターン」を知る
  • Part3 オブジェクト指向の基本設計を理解する

    Part3では,オブジェクト指向に基づく基設計の方法論を,UP(Unified Process)をベースに解説する。下流工程で試行錯誤を繰り返さないためには,「実行可能なアーキテクチャ」を構築することと,アーキテクチャの利用方法を解説した「アーキテクチャ説明書」が極めて重要になる。 Part2では,主にウォーターフォール型開発プロセスとDOA(データ中心型アプローチ)に基づいた基設計の手順を示した。だが,最近はWebシステム開発を中心に,反復型開発プロセスやオブジェクト指向設計を採用するケースが増えている。 そこでPart3では,オブジェクト指向設計に基づく代表的な反復型開発プロセスであるUP(Unified Process)を例にとって,オブジェクト指向設計における基設計の勘どころを解説しよう。 動くアーキテクチャを作る UPでは「方向付け」,「推敲」,「作成」,「移行」という4つ

    Part3 オブジェクト指向の基本設計を理解する
  • Part2 設計手順の基本を身に付ける

    Part2では,多くのシステム開発で実績を持つ日IBMの「IBM-DOA」に基づく外部設計フェーズの手順を説明する。ここで紹介するDOAに基づく複合/構造化設計手法は,どんなプロジェクトにも応用できる基的なアプローチだ。基をしっかりと身に付けてほしい。 DOA(Data Oriented Approach:データ中心型アプローチ)は対象システムの「データの流れ」の把握に重点を置きながら,要件定義や設計を進めていくアプローチである。 DOAには様々なタイプがあるが,日IBM独自の「IBM-DOA」では,主に業務全体をデータの流れに着目して図で表現するDFD(Data Flow Diagram)を使って業務を分析・設計していく。Part2では,この「IBM-DOA」に基づく外部設計フェーズの進め方を説明しよう。「今さらDOAか」と思わないでほしい。最も基的で一般的なアプローチなので,

    Part2 設計手順の基本を身に付ける
  • Part1 今こそ「基本設計」のスキルを見直す

    システムの構造や実装方針を決定し,アプリケーションの機能,データ,画面などを定義する「基設計」。ITエンジニアの「コア中のコア」と言えるスキルだが,「最近弱体化している」と指摘する声が増えている。今こそすべてのITエンジニアが,ユーザーの高品質,短納期の要求に応えるために,「基設計」のスキルを改めて見直すべきだ。 「ベテランのエンジニアは基設計の一般的な手順は理解しているが,高度化・専門化した実装技術を駆使したアーキテクチャの設計でとまどう。一方,若手エンジニアは実装技術には詳しいものの,肝心の基設計の基礎的な方法論を理解していないことが多い」――。 こうした悩みは,多くの開発現場に共通する。これは,基設計そのものが難しくなっているからにほかならない(図1)。 メインフレーム時代は,ウォーターフォール型の開発プロセスと自社の製品の知識さえあれば基設計をこなせた。しかし,システム

    Part1 今こそ「基本設計」のスキルを見直す
  • 矢沢久雄の早わかりGoFデザインパターン 目次:ITpro

    VMware問題でIIJNTTコムなどが大幅値上げ、クラウド料金が2~3倍になる場合も 2024.06.14

    矢沢久雄の早わかりGoFデザインパターン 目次:ITpro
  • 第4回:テスト設計の流れを理解しよう

    テスト設計ではまず,テスト対象を分析して,いくつかの要素に分解することから始める(図1の(1))。ここでは,テストの目的やシステムの種類によって観点や粒度が変わってくる。日立製作所の石川氏は「単体テストではモジュール,結合テストでは個々の業務フローを示したユースケース・シナリオ,システムテストではシステム全体というテスト対象になる」と説明する。テスト対象の分解は,こうした粒度にテスト対象を分けていくことを指す。 図1●テスト項目の「設定」と「絞り込み」が山場 テスト設計では,テスト対象を分析・分解した上で,具体的なテスト内容とテスト結果の期待値を設定する(これを「テスト項目」と呼ぶ)。さらにテスト項目に優先度や重要度を付けて絞り込むほか,テストケースを作成してテスト項目に関連付ける [画像のクリックで拡大表示] テスト対象が決まったら,それを漏れなく網羅するテストの内容とテスト結果の期待値

    第4回:テスト設計の流れを理解しよう
  • 第3回:テスト項目の絞り込み:重み付けは必ず数値で表そう

    今回は,テスト項目を絞り込むテクニックを見ていく。 「テスト項目を絞り込む最も基的な方法は,優先度と重要度による重み付け。これを地道に評価し,それに基づいて絞り込むことが大事」。こう強調するのは,日IBMの水橋久人氏(テクニカル・ストラテジー&コンピテンシー 理事)だ。優先度とは,何を先にテストするのかを示したもの。これに対して重要度とは,影響の大きさと,バグが発生する確率を示したものだ。 水橋氏は「金額に関する処理や,法律に絡む処理については,重要度が極めて高くなる」と指摘。最近では品質リスクに関する点を特に重視すべきとも付け加える。品質リスクには,機能性や性能,信頼性/安定性,エラー処理/回復,運用/保守,他言語対応,互換性,セキュリティ,法令順守(コンプライアンス)――などがあるという。これらについて,求められる要求がどの程度のレベルなのか,またバグが発生する確率はどの程度なのか

    第3回:テスト項目の絞り込み:重み付けは必ず数値で表そう
  • 第2回:テスト項目の設定:設計カバレッジで漏れを確認しよう

    テスト項目の設定では,テスト対象におけるテスト項目の網羅性が重要となる。「テスト項目を漏れなく洗い出すには,設計カバレッジによるテスト項目の確認が必要」。こう話すのは,豆蔵の大西建児氏(ES事業部 シニアコンサルタント)だ。 設計カバレッジとは,設計すべきテスト項目を設計したかという網羅性を確認するもの。これに対して実行すべきテスト項目をどれだけ実行したかを示す「実行カバレッジ」もある。 通常,実行カバレッジによる網羅性の確認を取り入れないことはない。テスト項目の一覧を一つひとつ実施していけば,実行カバレッジを確認できる。 だが,設計カバレッジを確認している現場は意外に少ないようだ。その理由は,「設計カバレッジ」という考え方や具体的な確認方法が,開発現場に定着していないからである。 三つの方法で網羅性を確認 では,設計カバレッジをどのように確認するのか。豆蔵の大西氏は,具体的な方法として,

    第2回:テスト項目の設定:設計カバレッジで漏れを確認しよう
  • 第1回:テスト設計の必勝テクニック

    「必要なテスト項目が漏れてしまった」「時間切れとなり,必要なテスト項目を実施できなかった」――。こんな苦い経験を持つITエンジニアは多いだろう。テストでバグを取り逃がしてしまう“敗北”は,「有効打の不足」と「時間切れ」の二つが大きな原因だ。 有効打の不足には,実施すべきテスト項目が漏れてしまったという数の問題と,より効果的なテスト項目があるのに漏れてしまったという質の問題がある。一方の時間切れとは,限られた工数の中で必要なテスト項目を実施できなかったことを指す。 バグを効率よく狙い撃つ,これが「勝ちにいく! ソフトウエア・テスト」である。では,どうしたら勝てるのか。テスト技術の整備を推進する日立製作所の石川貞裕氏(生産技術部 担当部長)は,「テスト設計が決め手になる」と指摘する(図1)。「何をどのようにテストするのかを決めるテスト設計は,テストの成否に大きくかかわる。ところがテスト設計

    第1回:テスト設計の必勝テクニック
  • 【特選フリーソフト】3種類のパッケージを手軽に作成 checkinstall:ITpro

    checkinstallは,任意のソフトウエアのソース・アーカイブから,RPM形式やdeb形式,tgz形式のパッケージを作成するソフトである。パッケージ化するための詳しい知識がなくても,ソースからパッケージを手軽に生成できる。 最近の主なディストリビューションはソフトの管理を容易にするため,「パッケージ管理システム」を備えている。パッケージ管理システムとは,rpmやdpkgなどのパッケージ管理コマンドにより,ソフトの導入や削除を手軽にできるようにした仕組みである。Linuxシステムを構成するソフトはすべて,このパッケージ管理システムに対応するファイル形式である「パッケージ」として提供されている。 Linuxシステムを構成するソフト以外にもパッケージで提供されているソフトは数多いが,世の中にさまざまなソフトが存在する。中にはソース・コードだけでパッケージが用意されていないソフトも多数ある。こ

    【特選フリーソフト】3種類のパッケージを手軽に作成 checkinstall:ITpro
  • 不良ディスクからデータを回収するGNU ddrescue

    ソフト名:GNU ddrescue 開発者:Antonio Diaz氏 ライセンス:GNU GPL v3またはそれ以降 配布元:http://www.gnu.org/software/ddrescue/ddrescue.html GNU ddrescueは,読み出しエラーが多発するような壊れかけの記録媒体からデータを回収するツールです。読み出し可能なデータを先に回収する方式を採用しているので,一刻を争う事態でもより多くのデータを救出できます。 HDDに不良が生じた際,最も重要なのはデータをいち早く回収することです。不良の原因がコントローラか機械的なものかを問わず,多くの場合で時間経過と共に問題が大きくなってしまい,回収できないデータが増えるからです。 データ回収のポイントは「問題なく回収できるデータを優先して作業」することです。読み出しエラーが生じるデータにこだわってリトライを繰り返すと,

    不良ディスクからデータを回収するGNU ddrescue
  • 114. 比較演算子のパフォーマンス

    PHPでの比較を行う場合、大抵は「==」「!=」を使用すると思います。ただし、巨大なデータを処理する際のパフォーマンスが問題になる場合は、「===」「!==」を使用することをオススメします。今回は2種類の演算子でのパフォーマンスの違いを見てみます。 「===」と「==」の違いは型が同じかどうかをチェックするかどうかです。「===」では型のチェックを行うので「12 === '12'」はfalseとなります。同様に「12 !== '12'」はtrueとなります。 型のチェックを行うのだから、パフォーマンスは「===」の方が低くなると思うかもしれませんが、実際は高いのです。「==」では型の変換処理を内部で実行しようとするためで、型の変換をしないで比較を行う「===」の方が高速なのです。 まずは以下のスクリプトを見てください。 <?php $MAX = 10000000; $hoge = "abc

    114. 比較演算子のパフォーマンス