GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

【書評】C#実践開発手法 〜デザインパターンとSOLID原則によるアジャイルなコーディング〜

監訳者でおられる通りすがりのエバンジェリスト 長沢智治 (@tnagasawa) | Twitterから献本頂きました。

本書では「Adaptive Code」をテーマにしています。Adaptiveとは、コードを大幅に変更すること無く、新しい要求やシナリオに対処する適応力のこと、と定義されています。コードを大幅に変更すること無く変化に適用するためにはどうしたらいいんだっけ...っていう話を、デザインパターンやSOLID原則という概念を用いて解説する一冊になっています。

Adaptiveであるためには、とにもかくにも依存関係を整理しなければなりませんよね、という話から始まります。それをコードで表現したパターンを「Stairwayパターン」と表現しており、具象クラスの隠蔽を階段を登り降りするかのように表現しています。

依存関係をゼロにすることは出来ないけど、依存関係を疎結合にすることは出来ます。また、そうしないとダメな理由をこれでもかと言うぐらいサンプルコードを交えて説明しています。デザインパターンやTDDなども触れていますが、それらはあくまでも依存関係を整理することで、コードを変更すること無く変化に対応し、そのようなコードのテスタビリティが高い理由を説明する補足説明で使われています。

SOLIDの原則

この内容については本書をあたって頂くとして、面白かったのがSOLIDの「L」のパートで紹介されている、リスコフの置換原則というお話です。その中で「事前条件と事後条件」について語られており、それをコードベースで書くことが出来ます。事前条件は「入力となる対象全部の値が、そのメソッド正常に動作する条件を満たしているか」です。事後条件は「戻り値が有効な状態であるかどうか」です。

これを.NETの仕組みを使ってやるとこうなります。Beforeがif分岐コード、Afterが事前条件と事後条件をContractsを使ったものです。条件を満たせないとContractExceptionがスローされます。JavaでいうAssertみたいなもんですかね。

Before
public decimal CalulateCost(float kilograms,Size<float> inch) {
  if( kilograms < 0f ) {
   throw new Exception();
  }
  if(inch.X < 0f || inch.Y < 0f ) {  throw new Exception(); }
} 
After
using System.Diagnostics.Contracts;

public decimal CalulateCost(float kilograms,Size<float> inch) {

  Contract.Requires(kilograms > 0f);
  Contract.Requires(inch.X > 0f && inch.Y);

} 

C#erなら取り敢えず読んどけ

とにかく本書はしつこいです。しつこいぐらいコードを載せて「Adaptive」について400p近く語られています。本書でも「抽象化を行わなければ、無数の要求が大きな泥だんごと化し、責務はほとんど描写されず、結果としてユニットテストがなく保守も拡張も難しいのに、業務上不可欠なアプリケーションが出来上がります」と警鐘を鳴らしています。自分の明日の仕事をラクにするためにも、C#erは本書をあたる価値があるでしょう。

全然関係ないけど、個人的にはWPFのMVVMの決定的な入門書が欲しい。ピュアにC#で実現するパターンと、フレームワークを使うパターンで。しつこいぐらいそこを解説する本、なんか無いかな〜。

【書評】マリンITの出帆: 舟に乗り海に出た研究者のお話

地元の図書館にたまたま新着で入っていたので、読んでみた。とても面白い試みだったので、紹介します。

マリンITの出帆: 舟に乗り海に出た研究者のお話

マリンITの出帆: 舟に乗り海に出た研究者のお話

イカ釣りの機械のモーター制御からキャリアを開始

著者はカンブリア宮殿にも出演した東和電気製作所さんで、イカ釣りのモーター制御のプログラムを書くことからキャリアを開始。テグスがピンと張っている時は構造上イカが逃げることは出来ないが、船の揺れや海の状況によってテグスが緩みだすと、イカは逃げてしまう。

というわけで、漁船の揺れを検知してテグスが緩まないように、モーターの回転を制御するプログラムを書かれたそうです。C言語だよな、きっと。組み込み系の話は面白い。

ちなみに、簡単に言うとこういうロジックで算出されるそうです。計算の変換には積分を使うらしい。

  1. 加速度を検出し、速度に変換
  2. 速度を変位に変換し、モーターの回転速度に変換
  3. 補正する回転速度を出力

大人になると(特にITの仕事をすると)、数学が色んな現象をモデリングしていることに気づいて面白い。GPS三平方の定理を使って現在の位置を割り出すとか。学生の頃知りたかったですね。'`,、('∀`) '`,、

www.tbs.co.jp

ユビキタス・ブイ

「ホタテ養殖のために、海水温観測のブイを作って欲しい。10万で。」

環境省が導入するクラスのブイが、数千万円。漁業用で安価なものでも、数百万円。でも、ひとりの漁師が出せる予算は、10万円。水温観測をしたい理由は海水温を検知してホタテが大量死するのを未然に防ぐため。

・・・当初は10万円で出来るわけねーだろというお気持ちで試作品を作ったそうですが、漁業組合の青年会の方々の協力の下、地道なサンプルデータの収集を続けることで段々と実用化に向けた手応えを感じられ、「ノーマリーオフ」機能を組み込み実用化されたとのこと。素晴らしいですね。

その他にも色んなお話があり、iPadを使った漁業日誌アプリとか、漁船に無線LANを導入した話とか、現場に則した実践的なお話が多くて楽しく読めました。

制約なき開発は作業に過ぎない

本書の114p〜115pに書かれていて、これはと思いました。

新しいものを開発するときには、必ずチャレンジを含めるようにしている。つまり、少々厳しい制約を設けるのである。(中略) 何よりも、制約を設けないと工夫するために頭を働かせるチャンスを失ってしまうのである。実にもったいない。

最初からできる事が分かっている開発は単なる作業であり、そこに創造性はなく、次に活かせる技術も身につかない。その結果いいものはできず、達成感もないから愛着もわかない。

エンジニアの成長についてのほとんどすべてが書かれている文章ではないでしょうか。

マリンITの今後に期待します

今後のマリンITの目指す先はどこになるかわからないのですが、恐らくは方法論を確立して標準化を目指していくことになると思います。海水温のリアルタイム解析とか、海底の地図におけるGoogle Mapとか、やりたいことは色いろある中で、Python的な「間違えようのないやり方がひとつだけあるのが望ましい」という方法論を、産学連携して築いていけるといいなぁと思いました。

こういう話を聞いてると、ソフトのみでもたらすことが出来る革新的な物事って、そんなにないですよね。まずはハードを開発できないと新しい体験は生まれないだろうし、どんなにソフトをとっかえひっかえやっても、ハードそのものが変わらないとダメだなぁと。その意味で低レイヤーの技術とWeb技術の両方を会得するレイヤーフルスタックなエンジニアが、5年後には花型になってるかもしれませんね。

あわせてよみたい

news.mynavi.jp

システム内製か外注か、どちらを選択すべきか問題

atsuizoさん、ちーす。また飲みましょうー。

atsuizo.hatenadiary.jp

僕も強烈な内製回帰厨なので、本件については黙ってはおれませんでした。

内製がメリットを生む条件

何事も条件が揃わないとメリットは生まれません。僕は以下のとおりに考えています。

  • 事業の差別化要因が強化されることが期待できる。
  • 継続的に手を入れるだけの理由がある。
  • 外部サービスで代替出来ない理由が明確である。
  • デモテープを作ることが出来る人材がいる。

これら全てにYESと言えない場合、外注を検討したほうが良いでしょう。継続的に手を入れる理由がないなら、買ってくればいいんです。改善する理由が見つからないなら、リソースを割く意味が無い。リターンがないからです。重要なのはROI...というか、これだけ。内製することでROIを高めるためには、事業の魅力がアップしなければならない。よりお客さんが選んでくれる理由を濃くするか、増やさなければなりません。

ITで事業の魅力を高める手段は、色々あります。ネットショップの自作なのか、社内業務の高度化なのか、顧客向けサービス開発になるのかは、なんとも言えません。共通していることを大きく言えば、競争力の強化ですか。で、それはどうすれば実現されるかって話なんですけど、この2つしか無いんじゃないかと思ってます。

  • ビジネスモデルは今まで通りだけど、圧倒的にオペレーションが高度化される。
  • ビジネスモデルの再構築を行い、競争優位に立てる。

ITの話じゃなくなりましたね・・・。弊社の場合は前者の比率が大きかった。

ただ、経営判断をしたくても「出来上がったものを見せてよ」っていう話に絶対になります。口に入れてみないと判断できないので。その意味で「デモテープ」を作ることが出来る人材が必須で、極端に言えば「デモテープ作って下さい!」っていうオファーをクラウドソーシングでやってもいい。コード書かなくてもPaas(Kintone等)で作っても全然OKじゃないですかね。

デモテープ作ったら「やったぜ、これを公開して早速儲けよう」とするのが経営。しかし、どこかで「デモテープとレコーディングはレベルが違うんです」っていう話をしなくてはならず、それが出来る人材がユーザー企業に圧倒的に少ないというミスマッチを強く感じています。継続性に欠ける理由もここにありそうです。

内製化の人材確保問題

僕が何かしらの理由で一時的なり長期的なり永続的なり弊社を離れることになってしまったら、どうなるか。永続的に離れたらシステムダウンの時が弊社の終わりの時でしょうね。現場が崩壊します。零細企業なんてそんなもんで、そのリスクは受容するしか無い状態です。金もないし。

長期的(数年)離れても、別に問題無いです。仮に退職しても、僕個人にメンテ料を払ってもらえればちょいちょい手を入れるだけで済むぐらい、システムとして完成されたので。全てが僕の頭に入っているからできる事なんですけど。

僕の存在自体がメリットであり、リスクとなっています。死なないように鋭意努力します。

顧問プログラマ

人材確保のひとつの理想として、倉貫さんの「顧問プログラマ」っていう考え方を紹介します。IT技術は高度な専門職。会計士のように月額定額でサービスをして、IT経営を実現するためにコードを書いたり、要員の教育をしたり、外注とのやりとりをしたりする。そーゆー小回りの効くプログラマが圧倒的に足りないのは事実ですし、雇用するにはハードルが高過ぎるのも事実です。定額制でサービス化したいよね、と。人月最高だね。

kuranuki.sonicgarden.jp

世の中がソフトウエア化(ありとあらゆる情報がソフトウエアによって管理されること)する流れが進むわけですから、顧問プログラマにスポットが当たってもいいはずなんですけどねぇ... 特にユーザー企業さんに。本業がITではない所に。どうしたらいいんだろう。

作るだけじゃ意味が無いから、継続的にユーザー企業にIT支援を行えるような人材流通・流動の仕組みができるといいなぁという結論に、内製と外注を考えると落ち着いてしまう今日この頃です。

「これって、ドメイン駆動設計?」という資料を公開しました。

いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。

www.slideshare.net

ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。

ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。

  • その世界で現状行われていること
  • 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい)

上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが1つ。

で、ドメイン(特にいまやってる物事)を抽象化するには、「で、それってどういう情報をやりとりしてるんだっけ」「どんな意味があるんだっけ、その情報」って話になりますよね。それをモデルにして、モデルに対してプロパティとメソッドを与えていくのが、基本線なんじゃないでしょうか。オブジェクト指向やん、要は。

なので、ドメインっていうものをモデルに抽象化してオブジェクト指向の考え方を元に分割統治することで秩序を保ちながらドンドンできる事を進化させましょう、っていうのがもう少し実装に寄り添ったドメイン駆動設計で目指すことのように思いました。

未だによくわかりませんが、「ドメイン駆動設計は、みんなの心のなかにありまぁす!」っていう話は飽きたので、こんな感じでええんちゃうのという資料です。

ご興味のある方、ご自由にお使いくださいませ。

「みんなの転職」様に記事を寄稿しました

寄稿のご依頼を頂きまして、転職に関する記事を書きました。

www.tensyoku-hacker.com

能ある鷹は爪を隠すではダメで、能ある鷹は爪を出してアピールしないと何も始まらないぞ、という所を重点的に書いています。

よろしくお願い致します。

www.tensyoku-hacker.com

【書評】10年つかえるSEOの基本

献本御礼・・・ではなく、ウチの取引先の社長さんに「SEOってなんっすか?」って聞かれて上手く説明できなかったので本書を購入しました。

10年つかえるSEOの基本

10年つかえるSEOの基本

基本的な考え方が整理できて良かったです。もっと速く知りたかった。

SEOは広告ではない

本書の最後の方にチラッと書いてあるのですが、これって大事なんじゃないかなって思いました。

SEOって検索順位を上げることでサイトに来てくれる人を少しでも増やそうということで、要は上位に表示させることを言うんでしょ・・・っていうのは違う、と。もちろん上位に表示できなければ陽の目を浴びることはないんだけども、広告で成果を出すのとSEOで成果を出すのは、アプローチが異なると本書では書かれています。

広告の場合は販促がメインになるし、極端な話をすればリスティング広告を打てばすぐに上位に表示されるようになる。でも、SEOはあくまで検索エンジンの大まかな仕組みを知り、その上で検索する人が役立つコンテンツを作り情報が流通されていく中で上位表示を目指していくものなので、やるべきことが全然違ってくるし、長期的に見ると強いのは・・・? ってことですね。

ホワイトハットSEOとブラックハットSEO

という概念があって、上述したようにコンテンツの質をベースにリンクを介して情報を拡散していくことで検索する人に取って意味のあるコンテンツにするアプローチと、検索エンジンが抱える構造的な不備を利用して価値のあるコンテンツであると見せかけるアプローチがあるそうです。前者がホワイトハット、後者がブラックハット。へー。

ホワイトハットのやり方はとても地味で時間を伴うけど、後者なら上手いことやればすぐに上位表示が可能になる(そういう時期があった)そうです。ブラックハットの代表な手法が自作自演でリンクを貼ってリンクを稼いでいるように見せかけるものですって。でた!SEO業者ってやつだ!

そんな業者ははやく死ねばいいのに・・・と単純に言えない事情があります、と。そういった被リンクのあるサイトに対してペナルティを与えると、リンクを張るサイトが意図的にほかのサイトを順位を落とす(ネガティブSEOと言うそうです)ことになるので、バランスを取らざるを得ない状況になっている、と。

政治的なことがSEOの世界でもあるんですねぇ。

SEO is 地味

すごく地味。ホントに地味。プログラミングもそうだけど。

検索されうるキーワードを吟味して選定を行い、Googleさんがインデックス出来るようにマークアップして、検索してきてくれた人が最大限喜ぶコンテンツを頑張って作って、少しでもシェアしてくれる努力を続ける。参入障壁はゼロ。競合や後発はいくらでも出てくる。この状況で継続的に改善・努力をしていける会社さんは、そうそう多くないと思うわ。

逆に言えば、潜伏期間を耐え忍んで頑張ってきた人たちのみ、SEOの成果が享受できるのかもしれませんね。

検索にガンガンヒットする技術がSEO

・・・そんなことをちょっとでも思った方にこそ、本書を当たってほしい。「10年使えるSEOの基本」という主題の通り、本書は検索エンジンを取り巻く技術が変わっても影響を受けない普遍的なポイントに絞って、真っ当に検索エンジンと付き合う視座を提示してくれています。これを読んだあとには、「よし、SEO対策を行うべくSEO業者に見積をもらおう!」とはならないはずです。そんな死亡フラグを立たせないようにするのも、我々Web技術者の役目の一つだと思います。

Webサイトの保有コストは限りなくフリーに近づいている時代が来ているからこそ、地道にサイトを「経営」していくアプローチをしっかり固めて行きましょう!

【書評】ITシステムの罠31 システム導入・運用で絶対に失敗しないための本

実業之日本社、酒井様より献本御礼。

ITシステムの罠31 システム導入・運用で絶対に失敗しないための本

ITシステムの罠31 システム導入・運用で絶対に失敗しないための本

酒井様いわく、何故使い勝手の悪いシステムが生まれてしまうのだろう、という疑問が本書発刊のきっかけとなったそうです。

本書は外資系コンサルのATカーニー社にてハーバード大のMBAを卒業された超エリートが監修をされております。システム部門、ユーザー、経営の3者が共通言語を持てるようになるまでの「罠」を31点挙げられております。ERP導入したけど現場で使っているのはExcelや野良システムっていうのはあるある過ぎますね。パッケージのカスタマイズを前提にするならスクラッチで組んだ方が結果的に安いケースが多いとかね。あるよね。

正直なところ、本書を読んでだいぶ悲しくなりました。挙げられている失敗談の多くがITがブラックボックス化しすぎている。成功裏に導くほうが難しいぞ・・・っていう読後感。ATカーニーさんの事例が元になっているのでしょうから、フィクションではなく実際の現場で起こっていることなんでしょう。残念です。

本書で挙げられている罠の中で最も悲しい事例が、事業会社の部長さんが新規事業開発の為に取引先のITのベンチャーの技術者を引き抜いて内製部隊を作ったけど、仕様の策定権が内製部隊にないので全くスピードが出ない上に何を作っていいかも不明瞭で、当然のようにゴミのような成果しか出せず、このチームの処遇に困ったという話です。内製回帰の失敗事例、結構多いみたいだね...。

まずいと思ったらすぐに辞めよう

ITプロジェクトほど最初の1歩目から間違えたら後工程全てが駄目になるものはないな、と本書を読んで改めて痛感しました。1歩目は多くの場合要件定義の工程でしょう。

要件定義の工程は、食べ物のレシピを作るような工程です。「トマトソースパスタ」を作って皆で食べようと仮定します。でも、「トマトソースパスタ」のレシピって千差万別ですよね。トマトソースパスタの味の違いをレシピを見ても分かる人ってそうそういないよね。実際には口に入れないと(試食しないと)分かんないですよね。ユーザーはパスタを作る料理人じゃないし、プロが設計書を見てもそこからROIを判断するのは原則困難です。

上記のような状態が本書でもある「経営とITが共通言語を持てない」状態です。もう見飽きたぞ、この光景。なので、どの種のプロジェクトよりも、ITは撤退の決断が重要になります。間違いが発覚した所まで全てを巻き戻してやり直すしか無いので、間違ったことを頑張って推進しないで下さい。本書で挙げられている罠が複合的になって、役満クラスになっちゃいますよ。

XX化という言葉は使わないで

本書の残念な所はもう1個あります。全体的に論理展開が雑です。効率化・可視化・最適化・具体化・・・左記のような「XX化」という言葉がかなり多いので、尻切れトンボ。コンサルさんはこのXX化が大好きですね。XX化というのはビジネスにおける「通っぽい言葉」で、これほど費用対効果が不明瞭なものもない。でもそれなりに筋が通せるし、同時に銀の弾丸っぽい。僕にとってはNGワードです。

システム導入・運用で絶対に失敗しない方法を無償で教えます

最も残念なことは、この本を読んでもあなたがITシステムの導入に失敗する可能性は引き継き高いことです。失敗談を100個並べて穴が空くまで読んでも、失敗の兆候は経験でしかわからない。だけど、僕はシステム導入・運用で絶対に失敗しない方法を知ってます。タダで教えますね。自分で作って下さい。自分で作ったものを導入して運用して下さい。仕様を考える人と実際にプログラムを書く人を同一人物にして下さい。これだけです。

なんで失敗しないかと言うと、仕様の策定者と実装者が同一になれば、ユーザーと経営とIT部門で共通言語が持てるからです。本書の主題は、ITがと経営の間で共通言語が持てないままビジネスとITが分断されてしまうことがITプロジェクトの失敗の元凶にあるという警鐘です。共通言語が持てない理由、ひとつだけですよ。自分たちで改善できないからです。改善できない理由? 管理できないからです。管理できない理由?自分で手を入れていないからです。逆説的ですけど、失敗したくないなら失敗のリスクを取らないと絶対に失敗するんだよね〜。

僕が書いた絶対に失敗しない方法が極論すぎるとお考えの方も多いでしょう。是非、本書をあたって下さい。僕の言いたいことの輪郭が、より鮮明になること請け合いです。

ITシステムの罠31 システム導入・運用で絶対に失敗しないための本

ITシステムの罠31 システム導入・運用で絶対に失敗しないための本

あわせて読みたい

gothedistance.hatenadiary.jp

BPStudy#92で「エンジニアの経営学」の話をさせて頂きました

発表資料はこちらにございます。

www.slideshare.net

お金の流れについて知ったから良いエンジニア人生を築ける理由にはならないんですけど、会社組織と無関係では生きていけないので... 会社組織の論理ってものがあります、と。その上で仕事とお金の関係だけは精査して整理しておかないと色々不幸なすれ違いもあるんじゃないかなってことで、その辺をまずお話させて頂きました。現場に居続けるのもなかなか難しいチョイスになると思いますし。

この資料を作るにあたって本屋さんや図書館で経営学と書いてある本を結構読んだんですが、どの本でも組織運営について多くのことが書かれておりました。会計の話は触れていない本も多かった。ビジネスモデルの構築であったり経営戦略理論であったりというのは、時代が変わると再定義されてきている感が強く、結局何の話なのっていう尻切れトンボ感がね...

ただ、経営を語るにあたり全く色褪せない概念が「Do the right things.」と「Do the things right.」の2つ。これは車の両輪です。まずは自社にとってのrightを定義すること。これが最も重要です。なぜなら、間違ったことを正しく遂行することが起こりえるからです。ちなみに、「Do the wrong things right」は、最悪の状態です。

下記は英語で書いてありますけど、わかりやすく書いてあって勉強になります。

www.sitepoint.com

次に、正しいことを正しく行う。つまり組織設計を行っていく事が必要です。ひとりでは何も出来ませんし、自分ができても全く意味が無いので... 組織として強くあるためには、組織の設計が必要です。

当然ですが、人間には意思がありますし、誰も自分以外にはなれません。他人の思考を操って自分が望む結果を出すように強いることもできません。なので、直接動かすことが出来ない人をいかに動かすか(動いてもらうのか)が、一番重要なことだと思っています。組織運営の肝ってここだと思っていて、その際に僕が気をつけていることが後半部分のスライドです。

ホンマは下記の話で1時間引っ張りたいんですが、さすがに厳しかったです。懇親会で少々させて頂きました。

これで合計3回BPStudyに登壇しまして、なんと最多登板タイに踊り出ました。BP社さんということで、次は僕が最近お気に入りで使っているPythonのFlaskの話をして、ハーラー単独トップに躍り出たいと思っております。

それでは、また。

スクーさんでお話をした「エンジニアの経営学(前編)」が無料でご覧頂けます。

schoo.jp

録画放送の準備が整っております。どなたでも会員登録を頂ければ、無料でご覧頂けます。

前編の内容としてはこんな感じです。

  • 会社を経営する目的
  • 売上・コスト・利益の関係
  • 経営者と従業員が大きく違うこと
  • 経営者がいつも考えていること

この前編の内容は、僕が2010年頃に抱いていた問題意識が根本にあります。自分の働きは会社の経営に資するものでなければ、その仕事は意味がなくなってしまい会社運営の負担になってしまいます。それを「そんな仕事をアサインした経営陣無能」では終わらせるのではなく「この状況下で成果を出す為には何が必要で何をやめなくてはならないか」と考えてもらいたいな、と。チーム運営でも同じような状況になるでしょうから。

それでは、どうぞお楽しみ下さい。

schoo.jp

40,000ブックマーク到達御礼

はてなブックマークカウンタを見たら、ブログの累計ブックマーク数が40,000を超えました。みなさま、ありがとうございます!

2006年4月からはてなダイアリーを始めたので、今年で10年目ですか。我ながらよく10年もブログをやっていられるものです。30,000に到達したのが2011年10月なので、3年半ほどかかりました。更新頻度が激落ちしたので当然なんですが...

gothedistance.hatenadiary.jp
gothedistance.hatenadiary.jp

何度でも言いますが、このはてなブックマークという仕組みが無ければ、今の自分はありませんでした。勝手に感謝してます。はてなのユーザーであることが恐らく最大の貢献だろうと思っていますので、はてなから脱藩することはございません!栗栖社長!ご安心下さい!え!あんたはいらん?!

累計が20,000前後の頃はブックマークを頂くことが少なからずモチベーションになっていましたが、流石に4万となるとモチベーションにはなりません。ブクマされる為に書こうとは思わないですが、自分の面識のない誰かに伝わるのはリスクもやりがいもあるので、モチベーションの一因となって細々と続けることができています。通常はリスクが圧倒的に高いんですけど、なんとかバランス取ってます。リスクを取るのが好きな性分なんですね.... '`,、('∀`) '`,、

あと、自分は文章を書くのが何を差し置いても好きです! 言葉で何かを表現するのはいつだって面白いです。

これからも弊ブログが、いつも読んで下さる読者の方のお役に立てればと思います。

SQLを学習できるWebサービスを作りました。