サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
labo.mamezou.com
はじめに 豆蔵社内でSysMLの勉強会が始まりました。SysMLって何だろう、と興味を持っている方も多いと思います。そこで、初心者の私が勉強会で感じたこと、ポイントだと思ったことを、そのままの目線でレポートしていきます。講師は、お客様へのSysML導入経験がある、弊社ES事業部の井上さんです。勉強会は全3回の予定です。 SysMLとは 勉強会は、SysMLが広まった背景から始まりました。現在、システム開発は、大規模化かつ複雑化の道を辿っています。それに伴って、システム開発に関わるステークスホルダー(利害関係者)も増加しています。このため、ステークスホルダー間でコミュニケーションできるツールが必要になってきました。メカ・エレキ・ソフトを包括し、システム全体をカバーする言葉(言語)です。そこで登場したのが、「SysML」です。SysMLは「Systems Modeling Language」の
業務アプリ開発者・情シス部員のためのBI入門 第2回:OLAPによる販売データ分析 ~Excelのピボットで~ 印刷 株式会社豆蔵 BS事業部 シニアコンサルタント 近藤 正裕 2009/12/03 [ITと経営] はじめに 皆さんこんにちは。第1回から非常に間が空いてしまい申し訳ありません。前回は、Google AnalyticsをひきあいにしてBIの活動全体を俯瞰してみました。BIプロジェクトでは、See/Plan/Doのサイクルで活動を進めていくこと、Seeにおいては対象領域のデータを分析し傾向を把握することなどを説明しました。前回の次回予告では、「分析のためのデータ構造・データ品質について説明する」と述べましたが、その話は次回以降に回して、今回は、Seeのフェーズにおいて重要となるOLAP分析について説明していきます。 分析対象の販売データ OLAP分析のイメージを掴んでいただく
プロトタイプエンジニアとは プロトタイプエンジニアという言葉を最近聞くようになっています。定義というのは特にないと思いますが、いわゆるゼネラリストタイプのエンジニアで、特定分野のエキスパートというより技術を広くカバーでき、まだ存在しない未完成のプロダクトを新たに創りだせるエンジニアです。AppleやASUSなどではプロトタイプエンジニアの採用枠があるとも言われ、製品へのフィードバックを重視しています。 生活スタイルの変化とユーザ体験・モノのインターネット iPhoneやAndroidなどのスマートフォンが出てきたことによって、私たちの生活スタイルが大きく変化しようとしています。生活スタイルが「どのように変化するか?」というユーザ体験を提供できないと、製品そのものが売れない。そんな時代になっています。 今までの製品企画では「付加価値」という既存の物に対して機能を「付加」するというのが製品開発
前回ご紹介した通り、「システム開発地図」はシステム要件定義の成果物を中心として業務分析および設計・実装における成果物をどのようにつなぐのかを俯瞰した地図です。実際の地図のように、ゴールに至るまでの道筋を大まかに俯瞰することや、注意すべきポイントを一貫した実例で詳しく見たりすることができるものでした。(図 1)。 詳細を閲覧し、地図のナビゲーション機能を提供するSilverlight Deep Zoom版はhttp://labo.mamezou.com/special/sp_015/sysdevmap/sysdevmap.htmlをご覧ください。操作方法については、前回記事(第1回:エコな開発を)をご参照ください。 業務システム開発のための役割・責任範囲 業務システムは、妥当な期間とコストで開発され、長期間運用・保守されていくべき企業の資産です。システムを業務変化に適合させ効果的に経営をサポ
要件開発入門~要求を要件に仕上げるコツと真髄~ 第1回:イントロダクション - 要件開発とは何か 印刷 工藤 浩志 2008/11/19 [要求開発] ソフトウェア開発は、システムの分析や設計、実装、そしてテストに重きが置かれるきらいがあります。 しかし、手戻りがなく良質なソフトウェアを開発するうえで、質の良い要件が整っていることが前提になります。総論ではこの活動に異議を唱える方は少ないと思いますが、現状のソフトウェア開発の現場ではまだまだ十分に認識されていないようです。しかも、この活動に時間と労力が割けられていないことが現状です。 この要件開発に限らず、「正しいことが正しいとわかっただけ」ではなかなか行動を起こすことができません。実際に行動が起こせるためには、その活動の「価値」と、「わたしでもできるんだ」といった「見通し」が必要です。 本連載では、この「要件開発」活動の「価値」とその活
誤解しがちなモデリングの技 第6回:初心者にありがちな間違い 印刷 株式会社豆蔵 ES事業部 皆川 誠 2009/10/02 [モデリング] 今回のテーマは「初級者にありがちな間違い」ということで、ここまでとは少し趣向を変えて、オブジェクト指向とUMLを習得しつつある人がしばらくの期間描きがちになる間違った例をいくつか紹介していきたいと思います。 その1:汎化関係に多重度 まずは、汎化(継承)の概念をいまひとつ理解しきれていない人が描くクラス図にたまに出てくる間違った例です(図1)。 この図はある図書館の貸出/返却処理や蔵書管理を行うシステムの分析モデルの一部と考えてください。UMLのクラス図を見慣れている人は、これを見てすぐに表記法上の間違いを指摘することができるでしょう。そう、汎化関係の両端に多重度が表記されているのがすごく変ですよね。このように描かれたクラス図を他の人から受け取った
「問題は解決ではなく、解消せよ」~混迷のIT業界を生き抜くためのマネジメントツール SSM 第5回:KJ法 四つの誤解 今回はちょっと SSM を離れて、KJ法の話をしてみたいと思います。(昨年EM-ZERO) vol. 4.2 に書いた「今だから、KJ法」の加筆修正版です) 2010/06/03 「問題は解決ではなく、解消せよ」~混迷のIT業界を生き抜くためのマネジメントツール SSM 第4回:客観と主観 これまでのビジネスの世界では、「客観的」な考え方が正しく、そうでないもの(主観的なもの)は正しくない、という風潮が強く、なるべく主観的なもの、客観的に判断できないものは排除される傾向にありました。特にIT業界の場合はその傾向が強く、科学実証主義的に 再現可能がどうかが重要視されています。 2009/10/02 「問題は解決ではなく、解消せよ」~混迷のIT業界を生き抜くためのマネジメント
システム開発地図 第2回: 関係者の役割分担をマッピング 前回は、業務システム開発に携わる関係者全員が、成果物やプロセスの全体を地図のように俯瞰できる「システム開発地図」をご紹介しました。 前回の予告では、今回はモデリングツールやプロジェクト管理ツールに焦点をあて、ツール活用ポイントや、システム開発地図におけるツールのカバー範囲などを見ていくとしていました。しかし、筆者らの参画したプロジェクトを思い返していくと、開発時の効率化で削減できる無駄よりも、責任者がはっきりしないことによる無駄の方が大きいということに気がつきました。 そこで今回は、システム開発における関係者の役割分担について見ていきます。システム開発地図上に、関係者の役割分担をマッピングして見てみましょう。 2010/11/11 組込み開発のためのモデリングワンポイントレッスン 第8回:状態遷移 今回も前回に引き続き動的構造を取り
第2回:REST導入における勘所 ~誤った導入をしないために~ 前回の記事では、REST の原理原則についてお話させて頂きましたが、ざっと RESTの概要をご理解頂けましたでしょうか。続編となる本記事では、もう少し踏み込んだ形で、REST アーキテクチャの種類と、導入における勘所をお話させて頂きます。 2009/12/03 この記事を読む 第1回:RESTのコンセプトと特徴 ~REST を知ると考え方が変わる~ 現在、一般的になりつつある REST (REpresentational State Transfer) ですが、いざ実践しようとするためには、正しい理解と実装指針が必要です。前編となる本記事では、REST の概念をご紹介し、後編となる次記事では、一般的に言われている勘所と、私が実プロジェクトで実践した勘所についてご紹介します。 2009/10/02 この記事を読む
誤解しがちなモデリングの技 第8回:モデルの意味的な誤り(II) 印刷 株式会社豆蔵 ES事業部 皆川 誠 2010/10/15 [モデリング] 今回も前回の記事に引き続いて、「表記法としては間違っていないけれども、表現している内容(モデルの意味)に{おかしな|あやしい}ところがある」というケースをいくつか見ていきたいと思います。ここではモデルの意味的な部分/解釈に関わってくることになるので、「明らかに間違っている」とは言えない(見方によっては十分に正しい)ケースも出てきます。そのため、この記事の内容が「どんなときも絶対的に正しい」などとは思わず、あくまでも参考程度に読んでみてください。 今回の記事では、以下のようなヘルスメーター(体重・体脂肪率計)の概念モデルを考えてみます。 「株式会社 豆蔵ヘルスケア」では、新型ヘルスメーターMZ-HM01(図 1)を開発しようとしている。このヘルス
関数型プログラミングの楽しみ方(Scala編) 第1回:Scalaって楽しい? 印刷 株式会社豆蔵 BS事業部 コンサルタント 小林 健一 2010/06/03 [プログラミング] はじめに 本特集記事では、新しいプログラミングの可能性を信じて努力する方のために、 ちょっと変わった、しかし強力で実用性のあるプログラミング言語、 Scalaを紹介します。 ここ最近、業務で使っている言語以外でプログラミングしていない方、 「言語はC、Java、VB、COBOLだけおさえておけばOK」という方はぜひ、 この機会にScalaに触れてください。新しい発見が山ほどありますよ。 今回は、まずScalaの概要を紹介します。 言語なんてJava,C,VB,COBOLだけおさえておけばOKでしょ? 現在、プログラミング言語の中で大きな比率を占めているものとしてJava、C、VB、COBOL、あとはPHP、R
「問題は解決ではなく、解消せよ」 ~混迷のIT業界を生き抜くためのマネジメントツール SSM 第5回:KJ法 四つの誤解 印刷 株式会社豆蔵 BS事業部 岡村 敦彦 2010/06/03 [要求開発] 前回(第4回「客観と主観」)」の最後の部分で、KJ法(注1)について「「KJ法はデータ(情報)の分類手法である」というのは大きな間違い」と書いたところ、多数の方から「え?違うの?」という反応を頂きました。そこで今回はちょっと SSM を離れて、KJ法の話をしてみたいと思います。(昨年EM-ZERO (注2) vol. 4.2 に書いた「今だから、KJ法」の加筆修正版です) (注1) 「KJ法」は、川喜田研究所の登録商標です (注2) エンジニア向けのフリーペーパー(http://www.manaslink.com/) 1.はじめに 「KJ法は分類手法ではありません。」 少し前になりますが、
システム開発地図 第1回:エコな開発を 印刷 株式会社豆蔵 BS事業部 近藤 正裕 今田 忠博 菅野 裕 2010/06/03 [ITと経営] [モデリング] はじめに 業務システムの開発・保守において、発注側と受注側が互いの立場を超えた共通認識を持てないことは大きな障害となります。伝言ゲームによる間違いや認識のずれによる手戻りは、開発の遅延や経営的な損失を招きます。 本記事では、このような課題に対する指針となる「システム開発地図」をご紹介します。この地図を使って、業務分析から要件定義、設計・実装に至るまで、発注者と受注者が共通の認識を持ち、成果物のトレーサビリティーを確保してエコな開発を行うための考え方・視点を提案します。 エコじゃない開発 業務システムを再開発するときに、現行システムのドキュメントが存在しない、存在したとしてもメンテナンスされていないということがよくあります。システム
誤解しがちなモデリングの技 第5回:ユースケース図にまつわるアレコレ 印刷 株式会社豆蔵 ES事業部 皆川 誠 2009/07/07 [モデリング] 連載第5回のテーマは「ユースケース図」です。ユースケース図を描く際に誤って使われることが多い表記や、{あまり嬉しくない|誤った}ユースケース図の描き方/使い方などをいくつか紹介していきたいと思います。ただし、ユースケース図を描く際にもっとも典型的な失敗である「ユースケース図上で細かく機能分割してしまう」や「《include》と《extend》の使用方法を間違ってしまう」といった例については既に他の記事やホームページなどで多く解説されているので、是非それらの記事をご覧ください。本記事では、その他の少し気付きにくい誤用/誤解の例を紹介します。 その1:アクター⇔ユースケース間の関連線の矢尻 最近はそれほど見かけなくなってきましたが、少し古い本
誤解しがちなモデリングの技 第1回:コンポジションにまつわるアレコレ 印刷 株式会社豆蔵 ES事業部 皆川 誠 2008/11/17 [モデリング] この連載では、コンサルティングでのモデル・レビューの場、教育講座実施中、各種の勉強会などの際に良く観察される、UML表記法やモデリングに関する典型的な誤解/勘違いをとりあげて解説を加えていきます。これによって、より正確なモデルの読み書き、効果的なモデル作成など、モデリング・スキルの向上を狙います。また、必要に応じて「あまり広く知られていないが、知っていると便利」なモデル要素や表記法についても随時紹介していこうと思います。 連載第1回のテーマは「コンポジション(Composition)」です。 コンポジションはクラス図でのクラス・アイコン間に引かれる関連線の一種で、インスタンス間の強い集約関係(全体-部分関係)を表現します(図1)。ここでは、
第2回:OLAPによる販売データ分析 ~Excelのピボットで~ 前回は、Google AnalyticsをひきあいにしてBIの活動全体を俯瞰してみました。BIプロジェクトでは、See/Plan/Doのサイクルで活動を進めていくこと、Seeにおいては対象領域のデータを分析し傾向を把握することなどを説明しました。今回は、Seeのフェーズにおいて重要となるOLAP分析について説明していきます。 2009/12/03 この記事を読む 第1回:BI概説~Google Analyticsを例にして~ IT業界に携わっている皆さんは、「ビジネス・インテリジェンス(Business Intelligence : BI)」という言葉を耳にしたり、製品や技術に触れたりした方も多いのではないでしょうか。BIとはおおざっぱに表現すると、<業務システムに蓄積されたデータを分析することで、業務上の意志決定や業務その
RESTful Web Services より良いWebインタフェースの構築と分散型システム連携 第2回:REST導入における勘所 ~誤った導入をしないために~ 印刷 株式会社豆蔵 BS事業部 コンサルタント 五味 和人 2009/12/03 [アーキテクチャ] 前回の記事では、REST の原理原則についてお話させて頂きましたが、ざっと RESTの概要をご理解頂けましたでしょうか。続編となる本記事では、もう少し踏み込んだ形で、REST アーキテクチャの種類と、導入における勘所をお話させて頂きます。 1. RESTfulとREST-RPC、そしてハイブリッド 一般的にRESTスタイルのアーキテクチャには以下の3つがあります。 外観的にも内観的にも、アーキテクチャがRESTの思想に準拠しているものを指します。 どこまで完全準拠するかといった点では、アーキテクトの主観が介入するところではありま
組込み開発のためのモデリングワンポイントレッスン 第1回:対象を明確に 印刷 株式会社豆蔵 ES事業部 井上 樹 2008/11/17 [モデリング] はじめに 大規模複雑化する組込みソフトウエアに対応するために、モデルを開発に導入している企業が増えてきています。実際、コンサルティングの現場でも以前よりも多くの業界からモデリングに関する問い合わせがきています。 そうしたモデリングですが、モデルを書きさえすればソフトウエアの生産性や品質が向上するというものでもなく、UMLを導入したけど、現場が混乱しただけで効果が出なかったなんて話も多いのではないでしょうか。 この連載では、そうした組込みソフトウエアの開発の現場でモデルの効果をうまく出すためのポイントを伝えていければと考えています。この連載を通して、皆さんのモデルの効果が高まっていったとしたら幸いです。 モデリングから見た組込みの特徴 まず
電気通信大学:西 康晴 先生インタビュー 第2回:日本のテストの現場への提言 印刷 株式会社豆蔵 取締役 プロフェッショナルフェロー 豆蔵ソフト工学ラボ所長 羽生田 栄一 2009/12/03 [テスト・品質改善] 日本のテスト業界の立役者である電気通信大学の西康晴先生へのインタビュー、第2回は日本のソフトウェア開発におけるテストや品質確保の取り組みに対しての所感と提言です。 大学での研究の在り方から、産業構造の問題点まで、率直なご意見の裏側に日本のテスト技術の向上に対する熱い思いを感じる内容です。 日本は欧米に比べてソフトウェアテストや品質が専門の研究者が少ないような気がしますが、この傾向は今後変わるでしょうか。 西: まず、どこの国でも開発系の研究者が圧倒的に多いということが前提ですが、特に日本でテストの研究者が少ない背景には技術の系譜の問題があると思います。 ソフトウェアという領域
この「保温器」は「温度センサー」から取得した「現在温度」が設定された「上限温度」と「下限温度」の範囲に入るように「ヒーター」のON/OFFを制御するものとします。この「保温器」のステートマシン図(状態遷移図)を考えてみましょう。 図2 はガード条件の使い方を誤ってしまっている典型的な例です。この状態遷移図に従って実装された「保温器」は、おそらく「現在温度」が「上限温度」を超えても「ヒーター」がOFFにならず、どこまでも加熱し続けてしまいます(場合によってはペットの熱帯魚が全滅してしまったり、火災が発生してしまったりします)。 このステートマシン図でまずいのは「加熱中」状態と「非加熱中」状態の間の遷移にかけられているガード条件の部分です。おそらく、このようなステートマシン図を描く人は『これらのガード条件はいつでも常にチェックされていて、その条件が満たされたら遷移が起こる』という間違った解釈を
ご挨拶 ソフト工学ラボ 編集前記~2月号~ 印刷 株式会社豆蔵 取締役 プロフェッショナルフェロー 豆蔵ソフト工学ラボ所長 羽生田 栄一 2009/02/24 [業界への提言] みなさん,こんにちは。 豆蔵ソフト工学研究所の所長の羽生田栄一(はにゅうだ えいいち)です。 早いもので,豆蔵ソフト工学ラボ(愛称:豆蔵コラボ)における情報発信も3回目を迎えました。その間,米国経済に単を発した世界同時不況は日本にも大きな影響をじわじわと及ぼしていますが,日本政府は自民党の求心力の低下と相俟ってしっかりとしたメッセージを国民に対して世界に対して発信することができないでいるようです。言葉に対する信頼が失われています。 ソフトウェア工学における最大の関心事は,『意味のあるコミュニケーション』と『複雑さの管理』です。前者のために様々な「見える化」のためのモデリング技術(含む文書化技術)があり,後者のため
SOA実践の最前線 第5回:クラウド時代のトランザクション 印刷 株式会社豆蔵 BS事業部 岩崎 浩文 2009/07/07 [アーキテクチャ] こんにちは、新緑と雨の季節、休日は趣味の写真撮影で大忙しの岩崎です。今回は、サービス指向の一環として、クラウドコンピューティング(以下クラウド)などでトランザクションの形態が果たして変わるのだろうか? という話をひとつ致します。 本領域は、客観的な評価や共通認識の乏しい箇所です。様々なご意見や認識があることは間違いありません。技術変革(という名の変更)も頻繁に行われています。本稿も最前線のそうした認識過程のひとつとして、あくまで2009年中頃におけるひとつの参考情報としてお読み頂ければ幸いです。 サービス指向とクラウドコンピューティング 最近クラウドという単語を良く聞きます。それ自身にさほど明確な定義は無く、初期のSOA製品と同じくマーケティン
誤解しがちなモデリングの技 第4回:ステートマシン図 (II) 印刷 株式会社豆蔵 ES事業部 皆川 誠 2009/04/22 [モデリング] 連載第4回のテーマは「ステートマシン図(II)」です。前回の記事に引き続き、ステートマシン図を描く際に誤って使われることが多いモデル要素や、{あまり嬉しくない|誤った}ステートマシン図の描き方/使い方などをいくつか紹介していきます。 その1: ChoiceとJunctionの違い いくつかの遷移をまとめたり、逆にガード条件によって何本かの遷移に振り分けて表記したりできるように、UMLのステートマシン図にはChoice擬似状態とJunction擬似状態という二種類の擬似状態が用意されています。ところが、ChoiceとJunctionの振る舞い/意味付けの違いを明確に意識せずに適当に使ってしまっているステートマシン図を見かけることがあります。 あるデ
RESTful Web Services より良いWebインタフェースの構築と分散型システム連携 第1回:RESTのコンセプトと特徴 ~REST を知ると考え方が変わる~ 印刷 株式会社豆蔵 BS事業部 コンサルタント 五味 和人 2009/10/02 [アーキテクチャ] 現在、一般的になりつつある REST (REpresentational State Transfer) ですが、いざ実践しようとするためには、正しい理解と実装指針が必要です。前編となる本記事では、REST の概念をご紹介し、後編となる次記事では、一般的に言われている勘所と、私が実プロジェクトで実践した勘所についてご紹介します。 1. SaaS/PaaSとREST SaaS(Software as a Service)やPaaS(Platform as a Service)、クラウドといった言葉をよく耳にします。 We
電気通信大学:西 康晴 先生インタビュー 第1回:プロフェッショナルなテスト技術者になる方法 印刷 株式会社豆蔵 取締役 プロフェッショナルフェロー 豆蔵ソフト工学ラボ所長 羽生田 栄一 2009/10/02 [テスト・品質改善] 日本のテスト業界の立役者である電気通信大学の西康晴先生にお話しを伺ってきました。 これから3回に分けてお送りしていきます。 西先生は、電気通信大でテスト技法やソフトウェア工学を中心に研究・教育活動を行うとともに、産業界におけるテストや品質の問題にも積極的に関わり、日本のソフトウェア開発をよくするためにテストという切り口で果敢に挑戦されています。ソフトウェアテストシンポジウム(JaSST) など様々なテスト関係者コミュニティの立ち上げや世話役も引き受けられ、若手エンジニアの悩み相談を受け持つ頼もしいお兄さんという側面ももっています。 今回のインタビューでは、西先
業務アプリ開発者・情シス部員のためのBI入門 第1回:BI概説~Google Analyticsを例にして~ 印刷 株式会社豆蔵 BS事業部 シニアコンサルタント 近藤 正裕 2009/04/22 [ITと経営] はじめに IT業界に携わっている皆さんは、「ビジネス・インテリジェンス(Business Intelligence : BI)」という言葉を耳にしたり、製品や技術に触れたりした方も多いのではないでしょうか。 BIとはおおざっぱに表現すると、 業務システムに蓄積されたデータを分析することで、業務上の意志決定や業務そのものの改善に必要な知見を得ること ということができます。業務システムには業務を遂行した結果としてのデータが日々記録されていきます。このデータを将来のために活用しようというのがBIの基本的な考えです(※1) 。 BIというと、システム開発とは無関係のものというイメージを
クリエイティブなエンジニアスタイル5カ条 第1条: 納得感のある開発手法を身につけるべし 印刷 株式会社豆蔵 プロフェッショナルフェロー 萩本 順三 2008/11/17 [業界への提言] 最近のエンジニアはエンジニアリングを楽しむことをしていないように思う。なんとなくの感覚であるが、狭い鳥かごに入れられて周りを見ずに開発をやっているようにも思えるのである。 これでは、ビジネス価値を高めるソフトウェア開発などできない。もちろん、優秀なエンジニアは、そのような表現には値しないだろう。しかし、多くのエンジニア達がそのような鳥かごに入っているように思えてしまうのだ。 これを解消するためには、ソフトウェアエンジニアのクリエイティブ力を高められるようなエンジニアスタイルを確立すべきだ。 そのようなクリエイティブなエンジニアスタイルとはどうあるべきなのか、ここでそのイメージについてみなさんと共有する
この連載では、コンサルティングでのモデル・レビューの場、教育講座実施中、各種の勉強会などの際に良く観察される、UML表記法やモデリングに関する典型的な誤解/勘違いをとりあげて解説を加えていきます。これによって、より正確なモデルの読み書き、効果的なモデル作成など、モデリング・スキルの向上を狙います。また、必要に応じて「あまり広く知られていないが、知っていると便利」なモデル要素や表記法についても随時紹介していこうと思います。 第8回:モデルの意味的な誤り(II) 今回も前回の記事に引き続いて、「表記法としては間違っていないけれども、表現している内容(モデルの意味)に{おかしな|あやしい}ところがある」というケースをいくつか見ていきたいと思います。ここではモデルの意味的な部分/解釈に関わってくることになるので、「明らかに間違っている」とは言えない(見方によっては十分に正しい)ケースも出てきます。
豆蔵社員のオススメ プロジェクト管理ツール"Trac"入門 印刷 株式会社豆蔵 BS事業部 菅野 裕 今田 忠博 近藤正裕 2009/01/13 [プロジェクトマネジメント] はじめに システム開発プロジェクトに携わっておられる皆さん。はじめまして。 私たちは普段、様々な企業のお客様の元、主にシステム開発プロジェクトで、要件定義や開発の標準化、フレームワークの設計・開発などを行っています。他にも、プロジェクトマネジメント支援や、開発者に対する技術支援を行うこともあります。 こうした業務を通して、これまで様々なプロジェクト管理にツールを使ってきました。中でもTracはシンプルな操作性・画面でありながら機能は強力で、とても使いやすいと感じていました。ちょうどそんなときに、縁あってTracの入門・活用本を執筆する機会を得て、「Trac入門」を共同執筆しました。おかげさまで、売れ行き好調のようで
次のページ
このページを最初にブックマークしてみませんか?
『豆蔵ソフト工学ラボ-身近な改善から明日のソフトウェアまで:ITエンジニアリング技...』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く