「制度上は6カ月を許容」でくすぶる不安、携帯4社のお試し利用で2年間タダの現実味 2024.09.18

当初の計画通りに作業が進んでいることを確認する見える化は大切だ。しかしそれだけでは、現場で問題が発生したことを早期にはつかめない。現場で起こっている問題を浮かび上がらせる工夫が必要になる。 数字による報告だけでは、プロジェクトの状況は見えてこない──。シーイーシーの栗原誠氏（第一システム事業本部 第二システム開発事業部 第三システム開発部 グループマネジャー）は、PM（プロジェクトマネジャー）として参画したあるプロジェクトで、こう痛感した。 それは、プログラミング/単体テスト工程の終盤でのことだった。栗原氏はそのプロジェクトで、「プログラム20本のうち10本のプログラミング作業が終わったので進捗率は50％。単体テストまで完了したのは5本なので進捗率25％」といった数字を基にした報告を、週次ミーティングでメンバーから受けるようにしていた。 報告を聞く限りプロジェクトは順調に進んでいるように見

「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします（編集部） プレゼンでも「巨人」の肩の上に立つ よく論文のことを紹介するときに「巨人の肩の上に立つ」という言葉が引用されます。これは、「現代の研究の成果の多くは、過去の多くの研究の蓄積によるもので、その研究自体は小さなものでも巨人の肩の上に乗っており、とても背が高く、高いところに到達できるのだ」ということです。 この言葉はプレゼンテーションの世界でも成り立つような気がしています。過去の素晴らしい発表や、自分自身の過去の発表を基に、より新しい充実したプレゼンテーションが可能になるのではないでしょうか？ プレゼンテーションにも、いろいろな場面といろいろな目的があります。研究発表や、製品やサービスの発表

夏休みスペシャル 2024 円安の中でも「頑張った」と思える、コスパが優れた2024年上半期のスマホ5選 2024.08.08

RedmineのVer0.8.4、0.8.6に入れたプラグインのうち、使っているものを公開してみる。 1年前に比べると、プラグインが充実していて楽しい。 結局10個以上も入れていた(^^;) 【コードレビュー】 r-labs - Code Review - Redmine Redmineのプラグインが充実している: プログラマの思索 リポジトリ画面からコードレビューのチケットを発行して、レビューをワークフロー管理できる。 お手軽にコードレビューできるのがいい。 レビューもチケットにするから、ワークフローのカスタマイズも可能。 【Hudson】 r-labs - Hudson - Redmine Redmineのプラグインが充実している: プログラマの思索 Hudsonと連携して、ビルド管理する。 SimpleCIプラグインよりもはるかに機能が充実している。 【Wiki拡張】 r-labs

前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考

これまでの連載では、ソフトウェア要求管理の基本を理解していただくことを目標にして、RUPにおける要求管理の成果物とワークフローを取り上げ、要求管理の基本を解説してきました。今回はいよいよ最終回です。本連載の締めくくりとして要求管理ツールについてお話ししたいと思います。 ［注］ 要求管理ツールを説明するに当たって、要求タイプ、要求属性、トレーサビリティといった用語が出てきますので、もしこれらの言葉がぴんと来ない場合は、まずは、過去の連載を読み返してから、今回の記事をお読みになられると分かりやすいと思います。 要求管理ツールとは？ 一般的に、要求管理（requirement management）ツールというと、開発チーム内で一元的に要求を登録、編集でき、その際に、変更履歴や変更理由を記録することができるツールを指しています。また、それらの基本的機能に加えて、要求ごとに、優先度・リスク・担当者

「すし屋の注文」とは訳が違う、要求仕様書の書き方：上を目指すエンジニアのための要求エンジニアリング入門（4）（1/3 ページ） 上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。 経済環境は依然として厳しい。換言すれば、供給量に見合った需要、つまり要求が限られている。「これは」という需要が欲しい。であれば、有効な需要につながる要求を生み出し、明確にしなければならない。 このような状況の中で、ソフトウェアビジネスに欠かせない要求仕様に取り組むことは極めて重要である。まさに、ビジネスに役立つ「真の要求」開発競争に突入しているといえよう。 要求仕様書は誰が書くべきか 第2回で、要求抽出のプロセスとして、顧客または社内からの不満

ソフトウェアエンジニアリング（注1）に関する理論や方法論、ノウハウ、そのほかの各種知識を体系的にまとめたもの。ソフトウェア専門職業人（ソフトウェアエンジニア）に要求される知識の集合体で、特にIEEE（米国電気電子技術者協会）とACM（米国計算機学会）が共同でまとめたSWEBOKガイドを指す。 ソフトウェアエンジニアリングの実践に必要となる知識は、過去のソフトウェアエンジニアリング活動における経験や研究などから抽出・蓄積されてきた。この知識が体系的構造を持つと見做したものがSWEBOK＝ソフトウェアエンジニアリング知識体系である。 SWEBOKを構成する個別具体的な知識は、過去に発表・出版されてきた文献や書籍の中にある。それら相互の関係は、経験あるエンジニアであれば頭の中で整理されていると推定されるが、未経験者や学習者にとっては体系的な存在であるとはいえない。未経験者や学習者が効率的にソフト

他の文書と同様、要件定義書はまず文書全体のアウトライン（骨格、構成）をしっかり作り上げてから内容を記述します。今回は、読みやすく分かりやすい要件定義書にするためのアウトライン作成方法を紹介します。 階層構造で読みやすい文書にする 要件定義書を作るためには、全体を大見出し＝中見出し＝小見出し（章＝節＝項）の階層構造にします。 「大見出し」「中見出し」「小見出し」の数を、それぞれ5から10程度にするのは、前回（第3回「分かりやすい提案書はアウトラインが美しい」）紹介した提案書と同様です。見出しの数が多すぎると、読み手が文書の全体像を把握できなくなります。また、1つの項目の記述量を1ページ内に収めるようにします。 要件定義書を構成する項目 要件定義書に必要な大見出しの項目としては、次のようなものが挙げられます。 システムの概要／システムの構想 機能要求 入力要求と出力要求 システム導入後の業務フ

「覚えやすくて，忘れないのが良いユーザー・インタフェース」（産業技術総合研究所 情報処理研究部門 情報流デザイングループ 主任研究員の増井俊之氏）。「忘れない」は「思い出しやすい」と言い換えてもいいだろう。一度覚えた操作方法をすぐに思い出せればいいのだ。使いやすさは，こうした記憶や理解，判断といった，人間の能力と密接に関係している。 初めて使う製品を目の前にしたとき，何をするだろうか。まずはそれらしく思える操作を試してみる人が多いのではないだろうか。それでうまくいけば，それがそのままその製品の使い方として記憶に残る。うまくいかなければ，いろいろと試行錯誤を重ねて，やがて正しい操作方法に行き着く。不幸にして，どうにもうまく操作できずに，せっかく買ったものを返品したり，部屋の隅でホコリをかぶらせてしまうこともある。 ユーザー・インタフェース――経験が新たな理解を生む（前編） ユーザー・インタフ

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

ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが