ソフトウェア工学をつつく7ープロセスモデル。ちゃんと作業を区切ろう。

ソフトウェア工学がもたらした成果の中で、一番重要かもしれない概念が プロセスモデルピヨ♪今回はそのプロセスモデルをつつくピヨ♪
プロセスモデルを簡単に言うと、システム開発とシステム運用の工程を細かく区切って定義したものピヨ。これは工学でお馴染みの考えピヨね♪みんな、工場見学もしくはTVとかで工場内の様子を見たこと事ある？見たことがあるのならば、箱だけを作る工程、箱に入れるものだけを作る工程・・・などが明確に区切られて、機械で大量生産されているのを知っていると思う。このように、明確に作業を定義する事により作業の自動化や生産性の向上を期待できるんだ。そのソフトウェアバージョンがプロセスモデルと思えばいいピヨ♪
その中で一番古く単純なのがウォーターフォールモデルピヨ♪これはソフトウェア開発を6個の工程で区切るプロセスモデルなんだ。その工程を列挙するから見てね♪


【ウォーターフォールモデルの手順】

• 基本計画・・・既存のシステムがある場合、その問題点を調査し、システム分析を行い、システム用件、問題点の解決法を考えるピヨ。そして新規の場合も再構築の場合も、システムのユーザーの要求、システム導入会社の要求等を正しくまとめて要求定義書にするピヨ♪
• 外部設計・・・要求定義書に基づいて、ユーザインタフェース（画面、印刷物のレイアウト等）、コード設計などをおこうなうピヨ。この工程で定めた事は、外部設計書に書くんだ。
• 内部設計・・・外部設計書に基づき、オブジェクトのデザインやモジュールの設計をするピヨ。この工程で定めた事は内部設計書にするんだ。
• プログラム設計・・・内部設計書に基づきコーディングをするピヨォ♪
• テスト・・・出来上がったプログラムをテストするピヨ。
• 運用・・・ここまで来たらソフトウェアシステムは完成だから実際に運用して、今後の為に問題点などを書いておくピヨ。

上記の一覧を見たら分かると思うけど、ウォーターフォールモデルの特徴は、 各工程を滝が流れるように順番に進めていく所にあるピヨ♪ ってこれぐらいならば、どの教科書にも書いてあるからつついているとは言わないよね。皆も現実を知りたいだろうから、中の人（このブログの作者）の実体験を踏まえながらもっと詳しくつついていくピヨ♪じゃあ行くぞ！鳥やー
※先に断っておくけど、これは中の人の体験に基づくものだから、情報産業全体のことではないピヨ。


バサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサ



【基本計画の現実】
中の人の仕事はフリーな何でも屋エンジニアだから全工程を担当することが多いんだ。だかも勿論この工程も経験済み♪その時の事を踏まえて基本計画をつつくいていくピヨ♪
教科書では大層な事を書いているけど、現実はそんなにたいしたものではないピヨね。日本では良くある事で、契約書での壮絶な心理合戦、責任範囲の不毛な擦り付け合い、美麗字句の言い合い、名刺交換、無意味な会議・・・などで費やされるピヨ♪とてもじゃなけど、巷で考えられているような華麗な工程ではないピヨね。実際は、泥臭い人間模様としか言いようがないそうだよ。勿論、情報産業は広いからもっと優雅な所もあるんだろうけど、残念ながら中の人は体験した事が無いピヨね。
先ほど書いたように、この工程は今後の全てを定める重要な工程なんだけど、実際は後の工程に押し付けられる事が多いピヨ。だってぇ、ココの工程で出てくる人の大半は情報処理技術を知らない人だもんね。そんな人達が、ソフトウェア工学に基づいてシステムを定める事を期待できるでしょうか（笑） その結果生まれるのが意味のない要求仕様書ピヨね・・・


【外部設計】
本来はしっかりとした完璧な要求定義書が必要なんだけど、現実はえてして意味のない要求定義書しかないからこの工程では、システムを使う顧客の要望を推理する事から始まるピヨ♪中の人の場合は仕方が無いから、無意味な会議中に勇気を振り絞って、情報の断片を聞き出して、この工程で推理をするそうだッピヨ。でも当然のことながら開発者はエスパーじゃないから、ウォーターフォールモデルでは禁止されている後戻りが何度も発生するピヨ。それでも完全な要望を顧客から聞きだすのは不可能に近い事ピヨ。だって、お客様も要望が定まっていない場合が多いからね。それは無理もない事だよ。お客様にしたら異文化以外の何ものでもないし、本来一番詳しくあるべきプロジェクトの責任者が情報処理技術を知らないもんだから上手くいくはずがないピヨ。 こんな調子だからやはり、ここで仕上がる外部設計書は不完全なものピヨ・・・もうだめぇ


【内部設計】
不完全な外部設計書と格闘しつつ、技術者が職人魂を発揮してデスマーチの下にソフトウェアの全体像を考えるピヨ。この工程はえてして、プログラム設計と同時進行されるピヨ。その様は地獄としか言いようが無いピヨね。今までツテがここに押し込まれているという事だね。本来ならば内部設計書を作るべきなんだけど、デスマーチではちゃんとしたものは作られない傾向があるピヨ。


【プログラム設計】
本来ならば内部設計書を見て行うこの肯定だけど、先述の通り内部設計と同時に行われる事が多いピヨ。もう世間の優雅なイメージとは逆で、阿鼻叫喚絵図だピヨ。ここで多くの人間ドラマが発生するピヨ。もちろん、悪い意味でね。デスマーチ中に職場恋愛なんて生まれない。生まれるのは負の感情だけさ。


【テスト】
ウォーターフォールモデル型開発では、実際は殆ど行われていないピヨ。これで本当に大丈夫ぅ？


【運用】
テストがろくにされていないものだから、当然お客様からのクレームが来るピヨ。当たり前だよね。無計画かつ、お客様の要望をろくに聞かないで成功するはずが無い。日本では責任者は責任を取らず、デスマーチの被害者である技術者達にに責任を押し付ける場合が多いんだ。それでも職人魂に燃える技術者達には「今こそ本当のシステム開発の始まりだ。お客様の声がやっと聞こえるぞー。」という強者が多いピヨね・・・・


どうかな？これで強烈にウォーターフォールモデルの弱点が分かったと思う。それはソフトウェア開発は完璧に進められないという事ピヨ。ウォーターフォールモデルでは、全工程が正しい事を前提としていけるけど、現実はそんなに甘くないピヨ。仮に要求定義を完璧にしたとしても、時が経てばシステムに対する要求が変化するからね。そんな現実を無視したプロセスモデルは通用しないピヨって事だね。だけど、このモデルは非常に重要ピヨ。このプロセスモデルを反面教師として、多くの犠牲を払いながら開発プロセスの研究がさらに進んだんだ。この先が気になると思うけど、長くなるからここで一旦おしまい。

ネタつつき4－狭くなる個人の世界

最近ブログが硬くなり始めていると感じましたので、雰囲気を和らげる為、久しぶりにネタ記事を書きます。昨今は人一人の世界が狭くなった事をよく感じます。それは色々な場面で感じます。リーマンの破綻と石油について、事故米、モンスタークレーマー、情報産業の３K構造・・・それらに共通することは視野の狭さです。これらの中から私が一番な情報産業の３K構造について採り上げ、それを元に狭き世界について書きます。
情報業界はもう３Kと呼ばれて久しく、それを心のそこから完全否定出来る人は少ないと思います。この構造の原因は色々ありますが、私がまず思いつくことは「知識が狭くなっている」事です。プログラマの人はよく「上司がプログラミングを知らなさ過ぎる」と言います。そして、上司は「部下は管理職の事を分かってくれない」といいます。どちらが正しいのでしょうか？私は両方だと思います。それらの意見は事実無根ではなく、現実に存在する問題なのです。では、何がそのデッドロック状態を生んでいるのでしょうか？それはこの業界の構造そのものだと思います。上司が悪意を持って部下の仕事に対して無知でいるのではないし、部下が上司が嫌いで逆らっているのではないのです（ここでは悪意を持った個人はマクロ問題なので無視します）だとしたら、何がこの構造を生んでいるのでしょうか？それは、人の心だと私は思います。論拠は、人間社会は自然現象ではなく、人間の行動によって成り立っているものだからです。無論エントロピー的な要素もあるでしょうが、大半は人が行動した結果の積み重ねなのです。
今の段階では話しが抽象的なのでさらに具象化していきます。システム構築は、上流工程だけでは机上の空論ですし、下流工程だけでは唯の自己満足です。全工程が必要なのは大半の人が同意していただけると思います。ここで３Kを生んでいるのは机上の空論です。情報システムは魔法ではありません。ちゃんと理論や技術が存在しそれに基づいて構築されるものです。その知識が0でまともな設計が出来る筈がありません。勿論これは逆も真也で設計的に間違っている実装はお客様の要望を満たしません。話しを簡単にするために簡単な方程式で表現するとこうなると思います。 品質　＝　設計能力　＊　実装能力
ここでこの業界が３Kに陥っているわけはこんな人が大量に居るからです。 0 = 10(どっちか) * 0。 こうなってしまえば、誰かが無理にカバーするしかありません。それが３Kを生んでいると思われます。この例では作る側に視点を置きましたが実際はもっと悲惨です。こんな会社が大量にあります。 経営者の能力 = ( 経営能力 10 ) * ( 知識 0 ) ※逆の場合もあり
勿論この経営者の能力不足は社員が尻拭いせねばなりません。これで3Kが発生しない方が不思議です。それに加えて悪名高き多重下請け構造で情報産業が成り立っています。もうこれは末期癌状態だといえるでしょう。
この解決方法は極めて簡単です。0ではなくせめて1にすればいいのです。そして、他方の人を認めれば・・・100 = 10 * 10となるのです。しかし、多くの人がそれを行うとはしません。何故ならば、評価する側も狭い世界で物事を判断しているので「評価基準が偏っている」のです。そうなれば、人は利益を求め、その評価基準だけを追い求めます。当然の結果といえるでしょう。
ここで一度今まで事を振り返って考えてみてください。偏った世界に生きていると自分が10だと思っていても実質は0（ 0 ＊ 10 ）なのです。何も残りません。
纏めに入ります。我々が一人で社会構造を変えるのは不可能です。ですから、まずやるべき事は、私たち一人々が広い視野を持つよう心がける事です。単純な結論だと思うでしょうが、全ての物事はバイナリ（些細な事）で構築されているのです。巨視的な設計でバイナリを組み立てる。我々情報処理技術者らしい考えだとは思いませんか？

中の人の徒然草97

本日はまだ極度の肩こりの影響が残っていて体調が優れませんでした。肩こりは万病の元って本当なんですね。もちろん、風邪や疲労などの他の病気の影響もあるのでしょうが、肩こり恐るべし！です。皆様も気を付けましょう。
今日Ｒｕｂｙの記事を書いていてふっと思ったのですが、私の本業はプログラマ（コーダーといった方がいいかな）ではなくて、システム設計から実装まで請け負うフリーエンジニア（自分でも職業名が分かりません）であるのに、ブログにプログラミング以外の事を書いていません。最初は書こうと思ってカテゴリを登録したのに、気がつけばデータベース・ネットワークについての記事を書いていませんでした。これは不覚です。これでは【無差別】とはいえませんし、ネタ能力が半分以下しか発揮できません。なので少しずつ、システム設計・ネットワーク・データベースの事を書いていきます。あと、エンジニアにとって重要な知識である簿記に関する記事も書こうと思っています。
ここまで読んで、「ええー今までの連載は？」と思った人も居ると思いますが、それについては心配後無用です。ちゃんと書いていきます。英語翻訳・ＳＴＬ実装・仮想ＣＰＵ実装などの記事も忘れていません。ただ、体調が悪かったので書いていなかっただけなのです。このブログの方針は無差別と気紛れなので、「今日はどの連載が書いてあるかなー」と毎日このブログを見てください。最近はＲｕｂｙの記事ばかりでしたが、一気にシリーズを書き終えてしまうと楽しくありませんから、私は直ぐに完結させません。
あと、今まで書き忘れていた事がありました。それはＲｕｂｙをつつくシリーズのＸ表記です。これは、記事を読む順番をまだ決定していないという意味です。順番を定めて書くには、10回ぐらい先まで考えて書かなければいけないので負担が大きいからひとまず書いて後で順番を決定する方式にしました。勿論順番を決定した際には、前後をあわすために記事を少し書き換えるかもしれません。
本日のブログは以上です。また明日会いましょう。

RubyをつつくXーヒアドキュメント1。スパゲティに注意。

今回はお待ちかね。ヒアドキュメントの便利な使い方をつつくピヨッピヨッ♪先ず見てもらった方が早いと思うから、コードをつっつくピヨね♪


printf(<<EOS, 1.9) これでも 正常に 機能する だよね Ruby%.1f どんだけー EOS

初めてこのプログラムを見た人は意味が分からないと思うピヨ。だから何も考えずに実行してみて。そうすると某携帯小説風文字列が表示されるピヨね♪このようにヒアドキュメントは 開始記号（<<EOF）～終端記号(EOS)のある行で区切られるという特徴があるピヨ。つまり、開始記号の位置は重要でないピヨね。ちょっと分かりにくいから、さっきのプログラムをＲｕｂｙはどう解釈したか書くピヨね。

printf("これでも\n正常に\n機能する\nだよね\nRuby%.1f\nどんだけー\n", 1.3)

どう？これで分かったかな？イメージ的に言うと開始記号の位置で文字列が生成されるという感じピヨ。現時点で、ヒア・ドキュメントってぇなんか凄くなくなくない？って思ったらまだ甘いぃぃピヨョョョ！ヒアドキュメントにはまだ隠された能力があるピヨ♪それについては・・・またサンプルをつつこう♪


name = 'インドリ' puts <<"EOS" ボクは #{name} サル じゃないピヨ 鳥 だピヨ 歳は 人間で いうところの 30 今年で 30 好きな ものは 情報処理技術 それ以外 ないって 感じ ピヨ ピヨ EOS

これを実行してみよう。そうすると、ボクはの次の行でちゃんと「インドリ」って表示されているピヨね。これは式展開という機能だピヨ。ちなみに、式展開については違う記事で紹介するピヨ♪でも、普通は・・・ <<EOSって書くピヨ 何故かと言うと・・・ <<"EOS"と<<EOSは同じピヨ これはまだ普通の機能なんだけど、ヒアドキュメントの機能はまだあるピヨ♪
次のプログラムは驚くよー


printf <<`EOS` DIR > dir.txt EOS

このプログラムを実行してごらん？あれ？何も表示されないや。でもruby.exeがあるディレクトリを見て御覧。ディレクトリの内容がdir.txtファイルへ出力されているピヨね♪凄いよね。
つまり・・・ <<`EOF`でコマンドが実行できるって事ピヨね。`記号は気をつけてね、日本語入力OFFの状態でアットマーク(@)+Shiftを押せば入力できるピヨ。これでヒアドキュメントの機能の説明は終わり。やろうと思えば、まだ細かい事をつつけるけど、つつくシリーズは初心者向けだから止めておくピヨ♪おしまい♪

中の人の徒然草96

今日一番印象に残ったのは某携帯小説の事です。元々このネタは、先日じゃぬさんの記事で知ったものだったのですが、どうもあの文体を見て、じゃんぬさんが紹介している内容を読むと、読む気力さえ出ませんでした。というののも私の目には、小説というよりも、未知なるスタックベース言語の命令文の羅列か、括弧無しS式の羅列、もしくはPrologの一種のように見えたからです。
ところが、本日るーごんさんがあの小説を最後まで読んで感動した事をブログで書いていました。これには正直言って驚きました。感動した事については、人の好みの問題なので気にならなかったのですが、【最後まで読んだ】という所が驚き意外の何物でもありませんでした。それで私も決心して読んでみたのですが・・・3章までと7・8章を何とか速読するのが限界でした。その小説は、私の完成と根本的に相容れない主人公設定でした。それに、オチも面白くないし・・・仕方が無いので、二つ名メーカーネタをるーごんさんのブログのコメントに書きました。
この一連の出来事の中でふと思ったのですが、携帯という媒体とPCという媒体で受ける印象が大きく違うのかもしれません。小説という情報自体は変わらない筈ですが、媒体を通じて情報を人間が受信することにより、情報の処理結果が変わってしまうようです。うーん実に面白い。
なにはともあれ、本日のブログを終えます。また明日会いましょう。

RubyをつつくXーヒアドキュメント。表現は人それぞれ。

今回はヒアドキュメント（here-document）をつつくピヨ♪ヒアドキュメントというのは、一言で言うと文字列の表現方法の一種ピヨ♪ とはいえ、こんな事を言われても誰もわからないからプログラムにしてつつくピヨッ♪ピヨッ♪


puts <<EOS これ ヒアドキュメント ピヨ♪ 変わっている よね EOS

このプログラムを実行してみて♪みて♪某携帯小説みたいな形式のメッセージが出るピヨね♪ つまり、ヒアドキュメントは、開始記号<<EOSから終端記号EOSまでの文字を文字列にする機能なんだ。キーワードEOSは小文字（eof）だと構文エラーになるから注意してね♪ これでおしまい。と、言いたいところだけど、そこはRubyだから、ヒアドキュメントも例に漏れず、色々な注意事項や使い方があるんだ。
先ずは注意事項を囀るピヨ。終端記号EOSのインデントが柔軟に出来ないんだ。これは間違えやすいから注意してね。これは実例をみなきゃ分からないよね？問い言うことでこのコードをつついてみよう。


puts <<EOS ヒアドキュメントって 頑固で 柔軟性が ない よね EOS

このプログラムをコンパイルしてごらん。構文エラーになったピヨね。厳密に言うと終端記号は行頭でなくてはならず、他の文字は一切かいてはならないんだ。厳ピィー。でも、インデントだけは<<-EOSと開始記号を書けばどうにかなるんだ。


puts <<-EOS これで インデント 出来るしー でも まだ かたいよねー EOS

このようにヒアドキュメントの終端記号（EOS）は硬いルールがあるけど、それだけだとヒアドキュメントは使いにくいだけだよね。でも、当然まつもと氏はそんな事をしない。面白い使い方があるんだ・・・それはねぇ・・・
おっと、記事が長くなりすぎるから、ここでおしまいピヨ♪次回お楽しみに♪ではまた

バサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサバサケーキ食べたいなー

中の人の徒然草95

本日は見ての通り書籍レビューに燃えた一日でした。何度かこの徒然草で触れていますが、私は秋の夜長に読書をしています。そうすると、どうしても自分が好きな物を他者へ紹介したい衝動に駆られるのです。今日はその衝動が爆発したので沢山書きました。とはいえ私の蔵書は200冊ぐらい（まだまだ増加中）なのでまだまだ書き足りません。また機会があればレビューを書きます。このレビューが誰かのお役に立てれば嬉しいです。
本日はこれにてブログを終えます。また明日会いましょう。

書籍をつつく31－C++言語のカラクリ 誕生の秘密と舞台裏。楽習に役立つ本♪

さっきC++の設計と進化（通称D&E）を紹介したら、この本を紹介しない理由が無いピヨ♪
C++言語のカラクリ 誕生の秘密と舞台裏
D&Eの監修者であるεπιστημηさんが書いた楽しい本ピヨ♪
じゃあ、まずは目次を・・・


【目次】

第1章 C++誕生秘話
第2章 C++コンパイラを作った手順
第3章 main関数・リンカの謎
第4章 仮想関数テーブルのありか
第5章 テンプレートの登場
わんくま同盟座談会

この本の内容はご本人に聞いたところC++の設計と進化（D&E）を補完する本との事。だからボクはD&Eと関連付けて書いているピヨね♪D&Eを読んだ人は分かると思うけど、当たり前の事だけど日本のC++の歴史が書かれていないピヨね。だからこそこの本なわけ。
この本は珍しい分類の本ピヨ♪というのも、堅苦しいプログラミングの本でもないし、何らかの技術思想本でもない、そして勿論わんくま同盟の布教本でもない。あと、目次から感じる印象はコンパイラ本だと思うけど、別にコンパイラの話しに終始している訳でもないピヨ♪だから、「C++コンパイラはちょっと・・・」と敬遠している人にも気楽にお勧めするピヨ♪
じゃあ何の本なのかというと、ボクが思うにC++を楽しむ為の本だと思うピヨ♪C++を業務で使って居る人の中にはもしかしたらC++に対する悪いイメージを持っている人が居るかもしれないし、C++を難しくて嫌なものだと捉えて初めからC++を触らない人が居るかもしれない。だけど、実際はそんな事は無くて、C++プログラミングは楽しいものだピヨッ♪♪この本はそれを感じさせてくれるピヨ♪
これは余談なんだけど、この本をわんくま同盟勉強会へ持っていくとサインが貰えるピヨ♪これは勿論、επιστημηさんがその場に居て、マナーをわきまえたらの話しだけどね♪わんくま同盟勉強会へいく時はこの本を持参していこう♪そして、礼儀正しくサインをねだろう♪

書籍をつつく30－C++の設計と進化。必読書。

巷でよく言われる御三家本以外にも、ボクが必読書だと思う本があるんだ。それがこの本ピヨ♪
C++の設計と進化
先ずは目次を見てみよう。


【目次】

薹ー1章　2005年のC++
第0章　読者のための注記
第1部
第1章　C++の前史
第2章　C with Classes
第3章　C++の誕生
第4章　C++言語の設計ルール
第5章　1985~1993年のできごと
第6章　標準化
第7章　C++への関心と利用
第8章　ライブラリ
第9章　そしてこれから

第2部
第10章　メモリ管理
第11章　オーバーロード
第12章　多重継承
第13章　クラス概念の高度化
第14章　キャスト
第15章　テンプレート
第16章　例外処理
第17章　ネームスペース
第18章　Cのプリプロセッサ

この書籍は何かというとC++の歴史と設計の本ピヨ。C++プログラミングをある程度していれば、「何でこうなるの！」と思った事が一度はあるだろう。その【何で？】に答えるのがC++の設計者Bjarne Stroustrup氏が書いたこの本というわけさ。この紹介を読んだ人の中には、堅苦しいイメージが湧いて、購買意欲が無くなった人が居ると思う。だけど、この本は意外とそんな堅苦しいものではないピヨ。この本を堅苦しいと呼ぶのならば、プログラミングの本は全部そうだといっていい。
ボクはこのブログで何度も情報処理技術は【楽習】するべきだと唱えてきた。好きなものじゃないと、長時間学びたくなくなるし、人間は嫌な事を忘れるように出来ているからね。多分鳥も同じピヨ。この本はその助けになると思うピヨね。それに、ソフトウェアというものは、設計理由を知る事が深い知識を生むからね。皆も自分が設計＆実装したソフトウェアについては、誰よりも詳しいと思うよね？だから設計理由を知れば自ずと実力はUPするピヨね♪


【総評】 楽しみながら学習し、設計理由とその背景を知る事が上達への早道。この本はそれを助けるから、C++使いは絶対に読もう！！！

各言語にこんな本があってもいいと思うんだけど、何で無いんだろうね？不思議ピヨね。

書籍をつつく29ーModern C++ Design。魔道書。

先ほど紹介したC++必読書以外に挙げるとすればこれ、
Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート活用術 (C++ In‐Depth Series)
これはもうボクのハートのど真ん中に矢を放つ本だね。内容を囀る前には定番の目次をご覧あれ。


【目次】

第1部　テクニック
第1章　ポリシーを基にしたクラス・デザイン
第2章　テクニック
第3章　タイプリスト
第4章　小規模オブジェクトの割り当て

第2部　コンポーネント
第5章　汎用のファンクタ
第6章　Singletonの実装
第7章　スマート・ポインタ
第8章　オブジェクト・ファクトリ
第9章　Abstract Factory
第10章　Visitor
第11章　マルチメソッド

付録A　最小限のマルチスレッド・ライブラリ
参考文献
索引

この本を一言で言うのならば魔道書ピヨ♪というのも、STLの超絶技巧を書いた本だから魔術としか思えないない出来なんだ。正直言って、今ボクはこの本の全てを理解していないピヨ。きっとSTLを実装する能力を身につけた時、この本の全てが分かると思うピヨね。 こんな事書いたら皆引くと思うけど、まあ続きを聞いてね♪
この本を読むと、脳の血行が良くなり、パニックになる。それでもボクはこの本をお勧めしたい。この魔道書を読むことによりC++を学習してよかったと感じる事間違いなしピヨッ！！STLはC++にしかない宝物（最近はDもあるけど）なんだから、C++をどうせ使うのならば全てを極めたくなるのが技術者魂というものだろう。
Amazonのレビューを読むと、「職場で使えないテクニック」と書かれている。それは真実だけど、そんなに会社や怠惰な同僚のレベルにあわす必要があるのだろうか？プロならば誰に言われなくとも自分の技をひたすら磨くもんじゃない？この魔道書のレベルの高さを考えて、購入を躊躇している人も居るだろうけど職人になりたければ読むべきだと思うピヨォッ！！！
それに、Boostを実装した人達は皆この本を読んでいるだろうし、実際ボクはコンセプトはこの魔道書を見て思いついたのに違いないと感じたピヨ。だからこの魔道書を理解する事によりBoostの実装を知る助けになると思うピヨ。Boostを極めたい人も絶対読もう！！！