パターンウィーバーの韓国語版
韓国語版を開発しました。
５月ぐらいには、配布できるようになると思います。
画面ショットは、こんな感じです。
2008年04月18日
2007年03月04日
未知への適応法
暫くご無沙汰しておりました、岡部です。まだ1年は経たないと思いますが、年月が過ぎるのは早いですね。
今回は、最近ふと思ったことを少しだけ、たまには「モデリング」カテゴリでも書いてみたいと思います。 前回の私の記事（科学と魔法）にも通じるところがあります。
私にはもうすぐ幼稚園に入る子供が居るのですが、子供の成長には目を見張るものがあります。 大人になってもこのくらい成長できたら、すごいだろうなとは、どの親も思うことでしょうか。
子供と接し、その成長を見守りながら、刺激を与えたり、たまには誘導したりしていると、 子供がどのように物事を理解し、本人にとっての世界観を構築していくか、その過程が見えてきます。
子供にとっては、世界は初めてみるものです。 （稀に特殊な才能を当初からもっている子供も居るかもしれませんが。） 初めてみる世界の構造や成り立ち・ルール・仕組み・因果・自分の行為の影響、 そういったことを一般的には試行錯誤しながら会得していくように見えます。
実際、ある程度成長するまでは、子供は試行錯誤し、 学習はその試行錯誤結果に影響を受けているように見えます。 例えば、それが実際には正しくなくても、ある一度の試行の結果でさえ次回に活かします。 勿論、試行回数が増えれば増えるほど、その次に正しい行動を取れる精度も向上します。
余談ですが、ですから親は、この時期にはある程度結果を導くなどして、 子供の成長する方向を誘導することが出来ます。悪用はいけませんよ！ でも、それは通常「しつけ」に利用されます。 （「しつけ」とは、現社会のルールを教え、適用させ、生き抜く術を与える務めなり。）
しかし、ある程度試行錯誤によって成長すると、今度は「組み立て」を始めます。 試行錯誤で得られる知識は断片的なので、これを繋ぎ合わせて、体系付け始めるわけです。 そうすると「概念」が必要になってきます。 つまり、単なる事実の積み重ねではなく、それらを抽象化することが必要になります。
「数」、「時間」、そのもの自体とは別途に付与される「役割」とその名前など。 やたら数え始めたり、昼と夜の区別、「もうすぐ」「あとで」、時計、「ごっこ遊び」などが代表的でしょうか。
「科学と魔法」で言えば、数打ちゃ当たる魔法を連打したのち、その結果を科学的に分析し始めるのです。 科学とは「記号」と「帰納」と「演繹」であると、私は書きました。そしてそれは、「モデリング」です。
最初に結論を述べずにグダグダ言うのは私の悪い癖ですが、 最初に述べた「最近ふと思った」と述べたのは、そんな子供の「考え方」の変化と動きを見ていて、 『子供は常にリモデリングを繰り返しながら生きている』こと気付いたということです。
なんということでしょう！（ビフォーアフター風に！）
子供の驚異的な成長は、未知に適応する為の究極のアジャイルモデリングに支えられているのではないでしょか。
今回は、ここで終わりです。何か示唆が得られれば幸いです。
2007年02月26日
UML2.1.1
UMLのマイナーバージョンアップが行われました。
http://www.omg.org/technology/documents/formal/uml.htm
長瀬
2007年01月29日
モデリング上達のコツ
「モデリング」とは、ある対象（例：業務やシステム）
を整理して、分かりやすく表現することです。
つまり、より正確かつ容易に、内容を伝えられるモデル
＝「優れたモデル」といえるのではないでしょうか。
でもこのようなモデルを作成するのは容易ではありません。
しかも、モデルは明確な「正解」があるわけでないので、
数学のようにひたすら問題集を解いていくだけでは
効率的に学習することができません。
私が推薦する効率的な学習法は、ただモデルを作るだけでなく、
作ったモデルを他人に説明する、ということです。
他人にスムーズに内容の説明ができないモデルは
どこかまだ整理が十分でない箇所があるか、
表現法がマッチしていない可能性が高いのです。
作成した本人が眺めているだけでは気が付かないような
モデルの問題も、他人に説明してみることで、
はじめて気が付くことが多いんですよね。
ちなみにモデルの表現法として、形や大きさ、
配置、配色なども実は重要なファクターです。
多少整理が十分でないモデルでも見栄えがよいと
いいモデルのように見えてしまうことがありますから。
このあたりもモデラーは「センス」を磨く必要がありそうです。
テクニカルデプト 橋本 大輔
2006年12月27日
ソフトウェアプロダクトラインモデリング
PLUSS（Product Line Use case modeling for Systems and Software engineering）の記事が、Communications of THE ACM１２月号に載っていました。ユースケースモデリング方法論の評価一覧があって（Jacobson、Gomaaなど）、そこでCross-cuttingの欄がよいのがPLUSSになります。「Use cases can be parameterized」となっています。ということは、アスペクト指向分析にはPLUSSが最適なのかもしれません。
実際の例（スウェーデン防衛産業）も少し書いてあって、フィーチャーツリーを書いて、フィーチャーがユースケース、シナリオ、ステップに対応しています。図がないと、なんともわかりづらいのですが。
対応しているCASEツールは、テレロジックのDOORSとROSEとなっているので、ちょっと古いのかなという気もします。単にシナリオのスッテプに表が書けるというだけかもしれません。
UMLモデリングだけでも、そんなに簡単ではないのに、プロダクトライン、フィチャーモデリング、アスペクトとなってくると、壁は高そうです。
長瀬
2006年09月27日
パターンウィーバー Ver2.2
ここ最近忙しく、ブログが更新できずにいました。
忙しかった理由の１つがパターンウィーバーのリリース準備だったんですが、
苦労のかいあって（？）パターンウィーバーVer2.2がそろそろ提供できそうです。
今回は一応マイナーバージョンアップにあたるものですが、
メジャーバージョンアップ並の強化が行われています。
一番の目玉は多国語によるモデルの開発ですね。
１つのモデルを複数の言語（日本語＋英語＋中国語など）で編集できるため
オフショア開発でもUMLが活用できると思います。
オフショア開発では仕様書に書かれた日本語のあいまいさなどで
オフショア先とうまくコミュニケーションが取れないことがありますが、
こんなときこそコミュニケーションツールとしてUMLが本領発揮できると思います。
ちなみに多国語のプロジェクトはStandard版でのみ新規に作成できますが、
Lite版でもStandard版で作成された多国語のモデルを編集することは可能です。
これ以外にも、ソースコード連携がかなり改善されていたり、
書きやすさの面でもかなり向上していたりしますので
ぜひ一度お試しいただければと思います。
ちなみに、ビジネスモデラーなどEclipseを意識せずにモデルを
作成したいユーザ向けにRCP（Rich Client Platform）版のリリースも行う予定です。
テクニカルデプト 橋本 大輔
2006年08月11日
ビジネスプロセスモデリング
ビジネスプロセスのモデリングは一見簡単そうに見えて
最も難しいモデリング作業だと私は思っています。
ビジネスエキスパート（顧客・ユーザ）にヒアリングを行い、
業務内容を引き出すことはもちろんのこと、
収集した内容を整理し、モデルとして表現した上で
その結果をビジネスエキスパートに確認してもらわなければなりません。
ビジネスエキスパートは情報システムのプロでない場合も多く、
「誰が見ても理解できるモデル」として表現できなければなりません。
このためには、用語の標準化、１つ１つのアクションの粒度を合わせる
といったさまざまなコツやテクニックが必要になりますが、
これらは知識ではなくモデリングを経験して身に付いていくものです。
経験で身についていくさまざまなコツやテクニックは
いいお手本のモデルを見ることで早く吸収していくことができますが
一般的なモデリングの書籍に掲載されたモデルは実開発のモデルに比べると
かなり簡略化されており、それほど参考にはなりませんし、
かといって機密保持の関係上、実開発で作成されたモデルは
公開できないことがほとんどですので、プロジェクトに参加しないと、
なかなか本格的な内容のモデルを見ることはできません。
そこでご紹介したいのが書籍「電子カルテと業務革新
～医療情報システム構築における業務フローモデルの活用～」です。
この書籍は2003年・2004年度の厚生労働科学研究（医療技術評価総合研究事業）
「電子カルテ導入における標準的業務フローモデルに関する研究」の成果がまとめられたもので、
弊社はモデラーの立場でこのプロジェクトに参加しています。
内容は、ある中規模病院でヒアリングを行い、ビジネスプロセスを整理したもので、
数十個のビジネスプロセスが掲載されているだけでなく、
AsIsモデルからToBeモデルを導き出す方法論の解説もしています。
ビジネスプロセスモデリングのお手本として活用できると思いますので
ぜひ参考にされてはいかがでしょうか？
ちなみにちょっと値段は高めですが、UMLツール（パターンウィーバー）が
付属していますのでお得感はあると思います。
http://www.tech-arts.co.jp/recommendation.html
テクニカルデプト 橋本 大輔
2006年07月21日
UML仕様書の読み方
皆さんはUMLの仕様書を読んだことがありますでしょうか？
OMGがUMLの認定試験（Ocup）を始めたこともあって、
以前よりはUMLの仕様書を読んだことがある技術者は
増えてきたのではないかと思います。
（以前はツールベンダーや一部コンサルタントしか読んでいなかった）
UMLの仕様書はもちろん英語ですし、ページ数も多いので
ちょっと読むのに躊躇するかもしれませんが、
コツさえつかめば簡単だったりします。
（UML2.0になってUML1.X時代よりはるかに読みやすくなりましたし）
UMLの仕様書はあらかじめその構成を知っておくと読みやすくなりますので
今回はちょっとだけ解説したいと思います。
（ちなみにUMLの仕様書はここからダウンロードできます）
UMLの仕様書は大きく構造（Structure）に関する要素（クラスやコンポーネント等）と
振る舞い（Behavior）に関する要素（アクションや相互作用等）の2つのPartに分けられて解説されています。
さらにその中は章ごとに分けられ（だいたいダイアグラム単位と考えればよいでしょう）
UMLの各要素（クラス、コンポーネント、ユースケース等）が解説されています。
以下にUML仕様書の構成を俯瞰してみました（要素「クラス」の場合）。
UML Specification（UMLの仕様）
└Structure（構造に関する要素）
└Classes（クラス図関連要素のパッケージ）
├Overview（パッケージの概要説明）
├Abstract Syntax(メタモデル）
├Class Description（所属要素群）
│ └Class（要素）
│ ├Generalizations（継承元の要素）
│ ├Description（概要説明）
│ ├Attributes（保持する属性）
│ ├Associations（関連する要素）
│ ├Constraints（制約）
│ ├Additional Operations（オプション）
│ ├Semantics（要素の意味）
│ ├Notation（表記法）
│ ├Presentation Options（表記上のオプション）
│ ├Style Guidelines（表記上のガイドライン）
│ └Examples（表記例）
│
└Diagrams（所属要素群の表記例一覧）
私がいつもUML仕様書を読んで各要素の調査を行う際には、
以下のような手順を踏んでいることが多いですね。
１）調査対象となる要素のAbstract Syntax(メタモデル）を確認
２）その要素のClass Description（要素説明）を確認
Abstract SyntaxはMOFで表現されたUMLのメタモデルのことで、
各要素がどんな概念なのかをモデルとして表現しています。
文章からはつかみにくいことも、モデルを見れば理解できることが多いですね。
テクニカルデプト 橋本 大輔
2006年07月04日
UML Profileとは？
UML ProfileとはUMLを特定のビジネスドメイン（業務分野）や
プラットフォーム（実装技術）向けに拡張するための
ステレオタイプがセットされた仕様のことです。
UMLを拡張するためには、UMLで定義されている
「ユースケース」や「クラス」などの要素に対して
ステレオタイプを付けて意味を加えます。
例えば、UML Profile for EDOCに定義されたステレオタイプ
《ProcessComponent》は、UMLの要素Classifier（分類子）を拡張しています。
このステレオタイプには、タグ（Property）としてprimitiveSpec、
primitiveKind、isPersistent、granularityなどが用意されており、
通常のClassifierでは用意されていない内容をこの要素に定義することができます。
UML Profileを利用したモデリングはMDAでも重要です。
MDAにおけるモデル変換定義を行う際に、多くの場合は
PIMとPSMで使用するUML Profileに定義されたステレオタイプ間の
マッピング（対応付け）を行うからです。
パターンウィーバー向けにも様々なUML Profileデータが提供されています。
サンプルモデルも用意されていますので、UML Profileを使用したモデリングをお試しください。
http://pw.tech-arts.co.jp/download/uml_Profile.html
テクニカルデプト 橋本 大輔
2006年06月27日
今注目されるコンポーネントベースモデリング
1990年代後半から2000年代前半は、インターネットの普及とともに
Javaによるオブジェクト指向開発が本格的に広まりだしたころでした。
当時、UMLを使ったオブジェクト指向開発方法論といえば
RUPが代表的でそれ以外の選択肢はあまりなかったように思います。
（特に日本では情報も限られていたので）
日本では広く普及しませんでしたが、アメリカでは1990年代後半に
Desmond Francis D'Souzaと Alan Cameron Willsがカタリシスという
UMLを利用したコンポーネントベース開発の方法論を発表しています。
最近は、SOAが流行しだしたことで、やっと分析・設計フェースにおいても
コンポーネントベースモデリングが注目されてきていますが、
弊社は当時からカタリシスに注目し、カタリシスベースの
コンポーネントベース開発手法を考案して、試行錯誤を重ねながら
ノウハウを蓄積してきました。
SOX法やEAなどでモデリングが注目されてきているのもそうですが、
コンポーネントベース開発についても、やっと今まで蓄積してきた
ノウハウが活かせる環境がそろってきたなとうれしく思っているところです。
カタリシスはMDAやUML2.0、MicrosoftのSoftwareFactoryにも
大きな影響を与えています。書籍として発売されていますので、
ご興味のある方は一読されてはいかがでしょうか？
http://www.amazon.co.jp/exec/obidos/ASIN/0201310120/qid=1151408370/sr=1-3/ref=sr_1_10_3/249-7758931-3063524
テクニカルデプト 橋本 大輔
2006年06月13日
UMLの技術者認定制度について
近年UMLが普及するとともにUML技術者への需要が高まり、
UML技術者のスキルを体系化して認定する動きが出てきています。
日本におけるUML関連の技術者認定制度としては、
UMTP（UMLモデリング推進協議会）の「UMLモデリング技能認定試験」と
UTI（UML研究所）の「OMG認定UML技術者資格プログラム」の２つが存在します。
この２つともUMLを看板に掲げてはいるものの、試験の内容は大きく異なります。
UMTPの「UMLモデリング技能認定試験」は、UMLを使った「モデリング」のスキルを
認定する資格であるのに対し、OCUPはUMLの仕様で規定された「表記法」と「意味」に
関する知識を認定する資格です。
実際、業務でUMLを使ったモデリングをするためには、
表記法とモデリングの両方のスキルが必要であり、
この２つの認定制度はうまく住み分けが出来ているのではないかと思っています。
両方の資格試験とも対策本が出版されていますので、
問題の雰囲気をつかみ、腕試ししてみてはいかがでしょうか。
テクニカルデプト 橋本 大輔
2006年05月30日
オフショア開発とモデリング
先日、中国でオフショア開発の現場を視察する機会がありました。
視察した会社の売り上げの多くは日本から受注するシステム開発であり、
会社の中では当たり前のように日本語が多く飛び交っていました。
（使っているマシンのOSも日本語ですし、メールのやり取りも日本語でした）
中国でのオフショア開発はかなり盛んで
今のところ中国の売り手市場ではありますが、
中国国内ではどんどん新しい会社が起業しており、
開発会社間での競争は非常に激しいようです。
視察した会社は、納期や品質へ非常に強いこだわりを持っており、
こういった部分で他社と競争していくと言っていました。
中国国内での競争が激しくなっていくと、
当然成果物の品質は上がっていきますので、
ますます日本の開発案件が中国に流れていきそうです。
一般的なオフショア開発における日本側の役割は
仕様をしっかり整理して中国側に伝えることです。
しかし、従来の文章中心の設計書では、あいまいな日本語の記述が
多くなってしまい、中国側にうまく意図が伝わらないことが多いようです。
このため、オフショア開発でもUMLを用いたモデリングが注目されています。
UMLで明確な設計書を記述し、しっかりとプロジェクトをコントロールできれば
成功するオフショア開発が見えてくるのではないかと思います。
テクニカルデプト 橋本 大輔
2006年05月17日
ますます注目される「モデリング」
ここ最近さまざまな分野で「モデリング」が注目されているように思います。
例えば、SOX法（サーベンス・オクスリー法）では業務の可視化が必要不可欠ですし、
SOA（サービス指向アーキテクチャ）によるシステム開発でも、
ビジネスプロセスモデリングが非常に（一番？）重要なポイントとなっています。
（モデリング無しのSOAなんて絶対絶対ありえません）
各ドメインの標準仕様でもモデリングがキーワードになっているようです。
例えば、医療分野における標準仕様であるHL7（Health Level7）では、
最新版（Ver3）のコアとなる仕様にRIM（Reference Information Model）という
参照モデルが用意されていますが、これはUMLのクラス図です。
また、診療情報交換用のメッセージ設計にはHDF（HL7 Development Framework）という
RUPベースの方法論が規定されています。
EDIの標準であるebXMLでも、UMM（UN/CEFACTモデリング方法論）で作成された
BRS（業務要求仕様）なしでは、「標準」のプロセスやデータとして認められません。
（モデルによる裏づけがないと「標準」として認められないということ）
以前から、UMLやモデリングは、一部で（特にJavaなどOOベースのシステム開発で）
注目されてはいましたが、必須の技術としてまでは認識されていなかったので、
ここ最近の動きは１モデラーとして非常にうれしいですね。
テクニカルデプト 橋本 大輔
2006年04月28日
最近のMDA関連の動き
OMGによってMDA（Model Driven Architecture）が発表されて数年が経過しました。
現状、MDAはどこまで実現されているのでしょうか？
これまでMDA対応をウリにしたツールはたくさんリリースされましたが、
それらの多くは単にコード生成機能を備えたUMLツールであり
「MDA＝モデルからのソースコード生成」という誤解を生んでしまいました。
MDAベースのソフトウェア開発では、まず実装技術に依存しないモデル（PIM）を開発し、
そこから実装技術に依存したモデル（PSM）に変換して、ソースコードを生成します。
このように本来MDAが目指していたのは、モデルを実装に依存しない視点と
実装に依存する視点に切り分けることで、変更に強くすることだったはずです。
（MDAの概要はOMGのMDA guideを参照してください）
これを実現するため、MDAツールにはMOF（Meta Object Facility）
を基盤としたモデルの変換機能が必要になります。
これまでもモデル変換機能を備えたMDAツールもありましたが、
ベンダー独自の仕様で開発されており、標準仕様は存在していませんでした。
OMGでは、MDAを実現するために数年かけてモデル変換に関連した
標準仕様の策定を進めており、ほぼ完成に近いところまできています。
仕様策定に加わっているベンダーは、ツールの開発も同時に進めているでしょうから、
OMG標準ベースのMDAツールがリリースされる日も近いのではないでしょうか。
なお、OMGにおけるMDAのPIM開発関連仕様には、
ビジネスシステム用のUML Profile for EDOC、
組み込みシステム用のExecutable UMLなどがあります。
EDOCはOMGで標準化され、すでに公開されていますが、
UML1.4がベースになっているため、UML2.0対応が待たれるところです。
また、Executable UMLはこれまで各ベンダーの独自仕様でしたが、
現在OMGでスティーブ・メラーを中心に標準仕様の策定が進められています。
テクニカルデプト 橋本 大輔
2006年04月24日
日本版EA対応UML Profile
テクノロジックアートの橋本です。
今回はEA（Enterprise Architecture）について取り上げたいと思います。
数年前に一時流行ったEAですが、最近は日本版SOX法などの動きもあり、
本格的に導入しようとする企業が増えてきました（SOX法についても今度取り上げたいと思います）。
しかし、EA自体はざっくりとした枠組みが決まっているだけですので
各企業ごとに具体的なモデルの表記法や開発手法、管理手法等を定めなければなりません。
日本政府でも情報システムの調達制度を見直し、EAの導入を進めるため、
これらの統一的な手法を示すガイドラインを定めました（業務・システム最適化計画策定指針）
このガイドラインでは、各EAの体系ごとに作成すべきモデルが表記法も含めて規定され、
モデルの専門家でない人にも分かりやすい一方、様々な種類の表記法を採用しているために
対応できるツールがない（または限定されてしまう）という問題がありました。
（DMM、DFD、WFA、ERなどの表記が規定されている）
この問題を解決するための１つの手段は、ガイドラインで規定されたモデルを
すべてUMLで表現できるようにしてしまうことです。
UMLには特定の対象をモデリングするために、UML自体を拡張するメカニズムがあります。
これがUML Profileと呼ばれるものです。
弊社が委員として参加しているINTAP（情報処理相互運用技術協会）の
オープンシステムモデリング技術委員会では、上記のガイドラインで規定されたモデルを
UMLベースで表現するための議論を進めてきましたが、
その成果が「日本版EA対応UML Profileに関する研究報告書」として公開されました。
この報告書には、上記ガイドラインの各成果物を、
UML2.0ベースで表現するためのUML Profileが定義されています。
このUML Profileデータとサンプルモデル（パターンウィーバー用）は、
以下のURLからダウンロードできますので、一度お試しいただければと思います。
（パターンウィーバーの評価版でもお試しいただけます）
http://www.intap.or.jp/
http://net.intap.or.jp/INTAP/information/report/17-rm_odp-report.pdf
http://www.intap.or.jp/odp/index.html
テクニカルデプト 橋本 大輔
2006年04月19日
パターンウィーバー Ver2.1
テクノロジックアートの橋本です。
ちょっと宣伝になってしまいますが、今回はツールの話題を取り上げます。
弊社で扱っているUMLツールパターンウィーバーが2月末に
マイナーバージョンアップされました。
マイナーといっておいて実は内部的には大きく変わっており
ほとんどメジャーバージョンアップ並みの変更が行われています。
今回のバージョンアップの目玉はなんといっても名前空間のサポートです。
これにより、しっかりとしたモデル管理が行われるようになったため
かなり本格的なモデリングにも耐えられるようになったと思います。
従来からの画像出力やPDF出力、ソースコードのフォワードがついて
￥7,800ですから、ますますお得感の増したUMLツールになったのではないでしょうか。
なお、2.1の発売と同時にプラグイン開発キットもリリースされました。
これはパターンウィーバーの追加機能を独自に作成するためのキットで、
C++ソースコード出力プラグインなどもこのキットで作成されています。
名前空間のサポートとプラグイン開発キットのりリースにより
いろいろなツールとの連携なども容易になったのでこれからが楽しみです。
ちなみに評価版は以下よりダウンロードできます。
http://pw.tech-arts.co.jp/download/community_edition.html
テクニカルデプト 橋本 大輔
2006年04月14日
UMLを活用するために
テクノロジックアートの橋本です。
私は普段の業務でUML・モデリング関連のコンサルティングを担当しています。
このブログでもこれに関連した話題を中心に情報発信していきたいと思います。
１回目の投稿ということで、UMLを活用するためのポイントについてとりあげたいと思います。
現状UMLはJavaなどオブジェクト指向ベースの開発が一般的になったこともあって
設計の道具として、かなり浸透してきたのではないかと思います（使われ方のレベルは様々ですが）
技術者の中でUMLという言葉を知らない人はほとんどいなくなりましたし、
設計書の中では、クラス図やシーケンス図が当たり前のように登場しています。
モデリングツールも安価なものから高価なものまでいろいろ販売されていますね。
ただ、UML本来のメリットを引き出して活用するというレベルまでには
なかなかたどりつけていないのではないかと思います。
UMLを活用するために必要な知識は、表記法だけでなく、
オブジェクト指向の基礎知識はもちろんのこと、開発プロセス、
アプリケーションアーキテクチャなど多岐にわたります。
また、モデリングのポイントである粒度、上流～下流までのシームレス性などは、
知識よりも経験によって身についていくものです。
プロジェクトに合わせてUMLの中から使用するダイアグラムを選択して
サブセット化する能力も重要です。
これらは簡単に身に付くものではなく、
モデリングを何度もおこなって経験を積んでいくことが大切です。
特に一番確実で効率よくスキルが向上する学習法は、
小さい範囲でいいので、上流～下流までをなるべくシームレスにつなげて
プログラムまで落としてみることかと思います。
プログラミングすることでその上流のモデルに問題点が見つかり、
それをモデルに反映していくことで、精度の高いモデルが完成します（イテレーティブですね！）
この学習法で身に付く重要なスキルは後工程を考えたモデリングができるようになることです。
（例えば、どの粒度でユースケースを書くと、クラス図にどう影響するか？
どうシーケンス図を書くと、プログラミングにどう影響するか？など）
このスキルを鍛えることで、上記の粒度やシームレス性などが意識された
品質の高いモデルが書けるようになっていきます。
最初の投稿ということで張り切って長くなりましたが、
今後はもっと細かい内容の投稿もしていく予定ですのでよろしくお願いいたします(^^;
テクニカルデプト 橋本 大輔