スタッフ ページ 4 ｜Webシステム開発の株式会社フラッツ

はじめに

こんにちは。そして、はじめまして。4月にFLATzにCTOとして入社した天方と申します。
今後、FLATzの技術について統括していく立場として、そして一技術者として、技術のイノベーションを担っていきたいと思います。

今回は、自己紹介をしたいと思います。
まずはベーシックなアトリビュートについて示します。

• 名前 天方貴久
• 出身 東京（中野生まれの新宿育ち）
• 趣味 読書 ハードSF（グレッグ・イーガン、J.P.ホーガン、他）、プログラミング、お絵描き

都会の真ん中で生まれた、もやしっ子です。その割に「新宿育ちっぽくない」とよく言われます。

自分がどんな性格なのかについて自己分析をすると、

• 他の人があまりやっていないようなことに興味を魅かれる。
• 行動を起こす前に熟考して、一気に行動する。
• 複雑な物事は、分割して、単純化してからとりかかる。
• いろんな現象をアナロジーで考えることが多い。

という特徴があります（と思っています）。

SFと私、そしてコンピュータについて

例えば、私の特徴を、趣味のハードSFで説明してみます。
ハードSFというのは、「リアルな科学的背景に裏打ちされた世界・物語を構築するSFのジャンル」のことです。
皆さん、ハードSFについてご存じですか？あまり知らない人が多いかもしれません（笑）。

私としては、ハードSFは

• 「もしも、○○だったら」を深く考えることで、既成の価値観を再構築できる。
• 最先端の科学技術と深くかかわりあっていたり、新たなセンスや情報が手に入る。

が面白くて、月に２～３冊くらいは読んでいたりします。
特に、ジャンルを知っている人が少ないということは、得られる情報の価値も上がりますので、一石二鳥です。

私が好きなハードSFのひとつにJ.P.ホーガンの「星を継ぐもの」という小説があります。
この話は、主人公の科学者が、月に１万年前に人がいたされる証拠となる遺物について調査を依頼されます。
主人公は調査団のリーダーに任命され、大量の科学者・技術者の情報を収集・整理し、巧妙に関連付けることで調査を進展させます。

一人の視点では見過ごされてしまうような情報を、複数の情報を知りえる人が巧妙につなげていく演出に、当時、感銘を受けたのを覚えています。
今、考えてみると、現代の科学者や技術者は、インターネットを通じて、全員がこの主人公と同じことをしています。

その点だけなら、SFよりも現在の方が進んでいるといえると思いますが、このSFにはもう一つアイデアが仕込まれていました。
それは、情報をつなげる役目をコンピュータの知性に行わせるというアイデアです。
人は同時に何人もの人と話すことはできませんが、コンピュータであれば、それが可能です。
そのコンピュータが同時に何人もの人の知識の交通整理を行えれば強力なツールになるというものです。

人と人との間で、知識の流れをインテリジェンスにコントロールする仕組みは、私には非常に魅力的なものに見えました。
今、この業界にいるのもその時の強い思いがあるからと言ってもいいかもしれません。
今はまだ、このアイデアは直接実現していませんが、検索技術やナレッジの仕組みについては、SF以上に進んでいるといってもよいと思っています。
そういった意味で、このアイデアを自分で実現するチャンスも十分にあると日々精進しています。

さて、話が趣味の話なのか、コンピュータへの話なのかわからなくなってきてしまいましたが、自己紹介についてはこれくらいにしたいと思います。

皆様、改めまして、よろしくお願いいたします。

次回

次回は、今回お話しできなかった、今まで私がかかわってきた技術についてと、今、興味を持っているプレファクタリングについて話していきたいと思います。

こんにちは。藤原です。
今回も引き続き、将棋の局面DB+Wikiについてお話したいと思います。
前回のエントリで書いたように、このシステムをPHP+MySQLで現在開発中ですが、まだお見せできる段階までは出来ていませんので、今回は現在の開発状況と今後の開発について、お話したいと思います。

前回のおさらい。

まず始めに、前回のエントリの内容を簡単にまとめてみます。

• 1.　棋譜データベースには解説などが載せにくく、直接参考になる情報が手に入らない。
• 2.　局面をデータベース化すると、同一局面を一括して扱える為、解説などがつけ易い。
• 3.　解説をwiki方式で自由に編集できるようにすることで、情報の質、量が向上する。

以上が、前回の内容です。ポイントは、局面は全ての棋譜にまたがってユニークなので、解説をつけるなら局面につけたほうが更新が簡単、と言うことです。

開発状況

このシステムを使うときのユーザ側から見た手順は以下のようなものを考えています。

• 1.　ユーザが興味のある局面の全体図か部分図を入力する。
• 2.　検索結果が表示されるので、見たい局面を選択。
• 3.　局面、解説、現在の形勢判断投票結果が表示される。
• 4.　解説を編集、形勢判断に投票。

現在はこの流れの、1,2の部分で使う、局面図の入力UIと全体図検索が完成しています。後は部分図を使った検索が出来るようになればこのシステムの肝の部分が完成します。

部分局面検索

さて、その部分局面からの検索ですが、なかなか一筋縄ではいきません。というのも、現在、データベースに保存する際、局面を40個の駒の位置情報と、その駒情報を結合してmd5を通したハッシュ値として保存しているからです。全体図検索の時は、検索したい局面のハッシュ値を同様に作り、ハッシュ値の合致するものを検索しているのですが、当然部分局面検索ではこの方法は使えません。

と言うわけで、部分局面検索を実現するためにデータベースに保存するデータを40個の駒情報ではなく81枡の盤面にどの駒があるかと言う情報にしようと、現在構成を変更中です。これなら、どの枡にはどの駒、と言うように条件をつければ部分局面の検索が可能です。

それなら最初から、盤情報を保存するようにしておけばよかったのですが、開発当初にデータベースの構成を考えたときは、駒の位置情報を保存したほうがデータ量が少なくなる(盤情報81×2byteに対して駒情報だと40×2byte)ため、そちらを採用していました。先見の不明です。

今後の開発

今後は、まず部分局面検索を完成させた後、先ほど書いた手順が一通り動作するプロトタイプを作ってみようと考えています。部分図局面さえ出来れば、解説、形勢判断部分にはそれほど時間がかからないはずなので、次回のエントリまでには完成させて、次回はそのプロトタイプをご紹介したいと思います。