カテゴリ: 雑記 【ソフトウェア】

エンジニアとのミーティングでFacebookのBSD+PATENTSライセンスについての当社の対応方針を質問されたのですが、その時点ではこの騒動を全く認識しておらず、「えっ、初耳です」的な、法務としてはなんとも情けないリアクションをしてしまうことになったので、ちょっと調べてみました。

という書き出しでことの概要をまとめようと思ったのですが、マンサバにきっちりまとめられていたので概要はそちらを参照していただくとして、ここではこのライセンスとどう向き合うべきかを書いてみたいと思います。

【OSSと特許の関係】
ライセンス条件に従っているにも関わらずOSSの利用が第三者の権利侵害を構成するというという状況にしっくりこない方もいらっしゃるかもしれませんが、仮にOSSが提供している機能について当該OSSと全く無関係の第三者が特許権を保有していた場合、当該OSSの利用は特許権侵害となる可能性が高いはずです。
もし特許権者に悪意があったら、協力者の顔をして開発中のOSSに自分の特許権を持つ技術を組み込んでしまい、広く普及したところで特許権に基づく主張を始めるという戦術も理論上は取ることが可能ですらあります。(Apache License2.0ではContributorによる特許ライセンスが明記されていますが、第三者を通じて特許権侵害コードを組み込むことで容易に回避できるので、悪意のある特許権者に対してはあまり有効な対抗策にはならないと思っています。)

【BSD+PATENTSライセンスの意味】
BSDLでソースコード及びバイナリコードの利用がざっくり許諾されていますが、同時にPATENTSで特許権のライセンスが特に記載されていることからすると、BSD+PATENTSライセンスのBSDでは特許権はライセンスされていないと考えるのが自然だと思います。
逆に言えば、当該OSSに特許権を有していない場合は、BSD+PATENTSライセンスとBSDLに違いはないということでもあります。
だとすると、BSD+PATENTSライセンスを敢えて選択し、多くの変更要請を受けながらもこれを維持したFacebookは、何らかの特許権を当該OSS(の機能)に関して保有しているのだろうということが推測できます。
そして、もしFacebookが当該OSSに関して特許権を保有している場合は、そっくり同じ機能を持つ別のソフトウェアを当該OSSに依拠せずに制作すると、当該別のソフトウェアはFacebookの特許権を侵害している可能性が高い、ということになります。

【BSD+PATENTSライセンスを採用したOSSを利用するのは危険なのか】
BSD+PATENTSライセンスを採用しているOSS、例えばReact.jsを利用している場合、PATENTSの条件により、自社や自社の関連会社(subsidiaries/affiliates)や代理店(agents)がFacebookに対して特許権に基づく主張をすると自動的にReact.jsの特許権ライセンスが終了するということになります。
これを受けて「Facebookの競合他社やFacebookに特許権の主張をする可能性がある会社はReact.jsの使用を差し止めるべき」という指摘がなされているようですが、React.jsについてFacebookがどのような特許権を保有しているのかを把握していない段階でこのような対応をするのはやり過ぎではないかと思います。(使っても使わなくても開発に影響がないライブラリであるなら別ですが、React.jsはそういった種類のものではないと理解しています。)
というのも、もしReact.jsの利用を差し控えて、例えば自社で必要な機能を開発したり、他のライブラリから必要な機能を調達したとしても、それがFacebookのReact.js関連特許に抵触している場合は、結局特許権侵害になってしまうことには代わりはないからです(React.jsを使う限りはPATENTSに基づいてライセンスを受けられますが、そうでない場合はライセンスのない実施にしかならない)。
そもそも、PATENTSに基づくライセンスはFacebookに特許権の主張をするまで終了しないので、もしFacebookに対して特許権の主張ができそうな状態になったら、そのタイミングで初めてReact.jsの利用停止を検討すれば良いだけのことです。
さらに言えば、もしFacebookがReact.jsに関する特許権を一切保有していなかったとしたら、特許権ライセンスが終了しても、当然のことながらReact.jsの利用は妨げられません(そりゃそうだ)
このような前提に鑑みると、BSD+PATENTSライセンスへの強い反発は、損得勘定というより、優越的地位を振りかざして非合理的な主張を押し付けるFacebookへの抗議という側面が強く、その利用は別段危険なものではない、というのが現時点における私の感触です。

【まとめとお願い】
BSD+PATENTSライセンスの存在をしったのもつい先日のことで、リサーチもウェブ上の資料を当たっただけなので、僕自身の特許に対する知見の欠如も相まって上記の内容に重大な誤りや勘違いが含まれている可能性があります。
にも関わらずこうして記事に書いたのは、偏に「間違いがあれば早めに気づきたい」という一心によるものなので、ぜひ間違っている(ようにみえる)ところがあれば、コメントやTwitter等でご指摘頂けるとうれしいです。

ではでは
このエントリーをはてなブックマークに追加

ござ先輩のエントリーを読んで、久しぶりに法務ブログっぽいエントリーを書こうと思い立ちました。
題材は、永和システムマネジメントの例のスキームです。

このスキームを目にした方が最も印象的に感じるのは「初期費用を無料にして、運用費だけで回収する」「しかも、途中解約に制限・ペナルティはない」という回収モデルの部分だと思います。
永和システムマネジメントは、どのようにしてプロジェクトが赤字に終わってしまうリスクを回避しているのでしょうか。

1.対価の発生時期を早める
永和システムマネジメントの例のスキーム(永和スキーム)は、ウォーターフォール(最初から完成品を作る)モデルでも、対価の回収方法を変えれば実現自体は可能です。
つまり、実のところ、永和システムマネジメントがアピールしているアジャイル(ちっちゃく作った後完成品目指して追加開発していく)は、永和スキームの必要的要素ではないのです。
ただ、アジャイルはウォーターフォールに比べると最初のリリースまでの時間が圧倒的に早いため、結果として、リリース後に発生することになっている対価の発生時期を早めることが可能になります。
永和システムマネジメントは、アジャイルの特性の「ちっちゃく作って…」を、こんな面からも活用しているんですね。

2.リリース前のコストを圧縮する
アジャイルで開発する以上、最初のリリースまでに必要な工数はウォーターフォールよりもずっと低くなります。
また、純粋な開発工数以外にも、成果物の仕様が限定されているため、仕様変更に振り回される危険も低くなります。(仕様追加に至っては、「リリース後にやりましょう」と切り捨てることが可能)
さらに、著作権を譲渡しないこと、着手時点でリスクを取っているのは主に永和システムマネジメント側であることから、通常の受託開発よりもユーザーの無茶な要求に振り回されにくいという面もあるかもしれず、そうであればコスト圧縮に大きく寄与すると考えられます。
対価発生前のコストが圧縮できれば、当然立ち上げ時の赤字幅も小さくなりますよね。

3.リリース後もコストをかけない
永和スキームの紹介ページを見ると、トライアル開始されるプランSSにおいて、月次で委託できる工数は1チケット。
”1チケットで1日程度の保守・サポート対応が可能です。”とのことですので、これが1人日という意味なのであれば、アジャイルの継続開発というより、どちらかと言うと保守・サポートに近い印象を受けます。
最初のリリースから次のバージョンのリリースに1人月必要だとすると、ユーザーがチケットを買い増さない限り、1年近くかけて開発することになります。(本当の意味での保守が発生する可能性を考慮すると、1年を超過する可能性も多いにあります)
このように、リリース後にかかる工数を限定することで、黒字化までの期間を短縮できるってわけです。

なお、永和スキームの紹介ページを見ると、プランSSの料金は15万円なので、1人日15万円という前提で単純に人月単価に換算すると300万円(4年目以降は半額になるそうなので、150万円)ということになりますね…
ただ、買い増しチケットの単価は15万円よりも安いかもしれません。

4.成果物を転用する
永和スキームでは、著作権は永和システムマネジメントに留保されますので、特段の事情が無い限りコードの転用は永和システムマネジメント側で自由に行えます。
ワークフローの様な汎用性の高い案件を受注できた場合には、これを転用することで次の案件のコストをぐぐっと圧縮できる可能性があります。
ものによっては、パッケージ化してライセンスで収益を上げることだって可能になるかもしれません。

5.成長を見せることで期待感を持たせる
システム変更時には、ユーザーとしても教育や運用の変更などの対応をせざるを得ないため、たとえ開発費/構築費が0であってもそう簡単に新しいシステムの利用をやめる訳には行きません。
これに加え、アジャイル開発の下では、リリースされたシステムに要望していた機能が追加され、(運が良ければ)使い勝手も向上していくのを目の当たりにしたユーザーが「来月・来年はもっと良くなっているかもしれない」と期待することにより、さらにその効果が高まるんじゃないかと思います。想像ですけど。
当然ながら、リリース後は単月では黒字になるように値決めしているはずなので、継続期間が長期化はそのまま黒字幅になるわけですね。



このように見て行くと、目先のキャッシュだけ工面できれば、通常の受託開発と比較しても、それほど危ない橋を渡っていないように思えてきませんか?
ぜひ技術力に自信のある他社さんも、丸パクリではなく、「ご紹介キャンペーン(顧客を紹介してくれたら1年間収益分配する、とか)」「余ったチケットをコンサルティングetcに流用できる仕組み」「ボーナスチケット(汎用性のあるシステムについてはチケットを上積みしてあげる)」のような工夫を追加して新しい契約スキームを盛り上げて頂ければと思います。

ではでは〜
このエントリーをはてなブックマークに追加

法と規則や会社法と計算規則など、二つの条文を行ったり来たりするのって煩わしいですよね。
パーフェクト六法HDは、iPadの大画面を生かしてそんな悩みを解消することができます。
(一瞬、もう一つの新機能、未施行法令一覧も登場しますよ!)



なお、上記のムービーはiPodTouch4GenとiMovieを使って"10分くらい"で作成しました。
すごい。
HDムービーをこんなに手軽に編集できる時代が来てたとは、未だにPHSユーザーの僕には信じがたいおはなしです・・・

申請には既にまわしているので、審査に引っかからなければ、来週にはお手元にお届けできると思います。

おたのしみに〜

※パーフェクト六法HDをご利用いただいている皆様へ
 お手すきの際で結構ですので、AppStoreにてパーフェクト六法HDのレビューをお寄せいただけるととても嬉しいです。
 また、ご意見、ご要望につきましては、twitterの@kataxまたはアプリ内のフィードバックボタンからお送りいただけると、早めにご対応できますのでご利用下さい。
このエントリーをはてなブックマークに追加

昨日リリースしたiPad向け六法アプリ「パーフェクト六法HD」について、購入表明をして頂いた方の人数に応じてリリース特価を設定するキャンペーンを実施しました(詳しくは、こちら)。
その結果、定価1,200円のところ、7/10までは700円(42%off)で販売することになりました。(このエントリーをアップした時点はセールの真っ最中です。ぜひご利用ください!)

僕自身、アプリの販売方法を工夫したのは今回が初めてだったので、その背景や意図を書き残しておきたいと思います。
少しでも開発者のみなさんのご参考になれば幸いです。


・ベースは共同購入モデル
アメリカのGrouponというベンチャーが、大して儲からないと思われていた共同購入ビジネスで大成功しつつあるというニュースは、多くの方が目にされたことがあると思います。(ご参考
今回の仕組みは、この共同購入モデルをベースにしています。

もっとも、「買うよ」で値下げ方式は、「買うと言った人が買ってくれる保証がどこにもない。」という点で、通常の共同購入と決定的に異なっています。
通常の共同購入モデルは注文することで購入の意思を表示することになるのですが、このような方法はAppStoreでは実現できないため、こればっかりはどうしようもありません。
ただ、この点は物販であれば在庫リスクを抱える恐れがある以上致命的な問題となりますが、もともと在庫ゼロのソフトウェアダウンロード販売においては別段問題はありません。
もちろん、実際には購入しない人の「買うよ」コールで販売価格が下がることはありますが、「パーフェクト六法HDを買う」という意思を公に表明して頂くことはそれ自体が非常に効果の高い宣伝となり、大きな価値をもたらしてくれますので、購入表明をした人がアプリを実際に買ってくれたかはあまり問題ではない(むしろ、買う気もないのに宣伝にご協力いただいたことについて、感謝した方がいいかもしれない)のです。
(Twitterでは悪意のある振る舞いをする人の割合が少ないので、そもそも杞憂なのかもしれませんが。)


・「RTした人にプレゼント」方式とは違うよ
また、「買うよ」コールで値下げ幅を大きくします、という方式は、最近、TL上で目にすることが多くなってきた「このポストをRTしてくれた方の中から●名様にプレゼント」という企画とも似ています。
ただ、「RTした人にプレゼント」企画には、各twittererの自発的な意思が含まれていいないという点で、「買うよ」で値下げ方式とは大きく異なります。
なお、「RTした人にプレゼント」企画はTL上に広告看板を捻じ込むことであり、Twitterらしくなくて好きじゃないという方は多いと思うのですが、どうなんでしょう。
少なくとも僕はあまり好きじゃないですし、紹介されている製品やサービスに興味を抱くこともあまりありません。(景品に興味を抱くことはあります 笑)


・その他にもある「買うよ」で値下げ方式のいいところ
  • 購入(予定)者との接点を得られる
    →ご要望・ご指摘を頂きやすくなります。

  • 盛り上がりや勢いを可視化できる。
    →目の前で盛り上がってるお祭りには参加したくなるのが人情ってもんです。

  • 「買うよ」と言ってもらえると純粋に嬉しい!
    →iTunesConnectで「●個売れた」というレポートを見るより、顔が見える分嬉しさも倍増です。

  • 「みんなで大幅値下げを獲得しよう」という一体感が心地いい
    →値下げするんですから、せっかくならたのしくやりたいじゃないですか。

・今回のキャンペーンの反省点
  • 購入表明を募集する期間が短すぎた
    →正味1日だけになってしまいました・・・

  • Twitter検索がへぼいせいでハッシュタグを付けて頂いているのに拾えなかったtweetがあったかも
    →Googleのアップデート検索で補ったものの、こちらも100%拾えてるわけではないので。

  • 中途半端な値下げになってしまった
    →半額以上値下げしたかったのですが、期間の短さも相まって値下げ幅は中途半端な42%offに。

  • 根回ししなさすぎた
    →事前に購入される意思を伺っていた方には、前もってご協力のお願いをしておくべきでした。

  • 購入表明の例文を挙げたせいで、購入表明が画一的になってしまった。
    →画一的な購入表明が並んでいるのを傍から見ると、いかにも「宣伝キャンペーン!」という臭いが・・・




今後も機会があったらプラットフォームの特性に合わせた、開発者にとってもご購入者にとってもメリットがある販売促進方法を考えてみたいと思います。

そんじゃ、午後もがんばりましょ〜
このエントリーをはてなブックマークに追加

ザ、梅雨。

さて、ながーいながーい「レビュー待ち」期間がようやく終わり、今日になってやっとパーフェクト六法HDのレビューが始まりました。

過去の経験からすると、問題がなければ数日でレビューが終わってリリースされることになります。

パーフェクト六法HDは、ベータテストにご協力いただいた皆様から多岐に渡るアドバイスを頂けたおかげで、当初想定していたものよりもずっと使いやすく仕上がったと自負しています。
お忙しい中未完成のアプリをご利用いただき、また様々なアドバイスをいただき、本当にありがとうございました。
スクリーンショットはこちらにまとめてあります。


さて、肝心の価格ですが、少なくともリリース直後の数日程度は割引価格でご提供したいと考えています。
ただ、今までリリース割引という行為をしたことがないため、実際のところ、いくら割り引くのが適切なのかの観覚がさっぱりわかりません。

そこで、パーフェクト六法のご購入予定者の人数に応じて「えいや」で設定してしまうことにしました。

料金テーブルは以下のような感じです。
  • 定価
    1,200円

  • 購入予定者:0〜10人
    1,000円

  • 購入予定者:11〜20人
    900円

  • 購入予定者:21〜50人
    800円

  • 購入予定者:51〜100人
    700円

  • 購入予定者:101人〜
    600円


市場のニッチさからするとあんまりないとは思いますが、もし101人を大きく超えるようなことがあれば、さらに割引します。

ご購入予定者の人数は、twitterで”#llhd”が含まれる「パーフェクト六法HDを買うよ」という意思がわかるようなつぶやきでカウントします。
(わかる方向けにより簡単にご説明すると、要はハッシュタグをつけて購入の意思があることを教えてくださいということです。)
なお、”#llhd”の前には半角でスペースを空けないと検索に引っかからないという話を聞いたことがありますのでご注意ください。

とりあえず、
「パーフェクト六法HD買うよ。 http://bit.ly/pcllhd #llhd」
とtweetしていただければカウントされますので、なんかめんどくさいなと感じた方はこちらをご利用ください。途中のURLは、このエントリーの短縮URLです。

そんじゃ、今日も一日頑張りましょー
このエントリーをはてなブックマークに追加

朝のニュースはiPad一色といったおもむきで、一瞬テレビに映ったサラリーマン風の男性が会社の偉い人の目に留まって営業さぼって行列に並んでるのがばれてクビになったらいいのにと呪詛の言葉をそこかしこに吐き散らしているみなさんこんにちは。僕は元気です。

さて、先日すったんもんだのあげくようやくSnowLeopardにアップデートしてiPadアプリの開発ができるようになったので(Windowsユーザの間隔では驚きですが、新しいバージョンの開発環境は、早くもLeopardを対象OSから外しているのです!)、早速始めてみました。

起動直後
56)


法令検索
11)


一から作り直すのでいったいいつリリースできるのかは全く不透明ですが、おおむね当初ほしがっていた人にiPadが行き渡った頃には完成させたいな〜と思っている所存です。

そんじゃ、まったね〜。
このエントリーをはてなブックマークに追加

ここ数ヶ月、もはや何がテーマのブログだったのかさっぱりわからなくなっている気がしなくもありません。
忘れている方がいるかもしれないので再確認しておきますが、このブログは、企業法務がテーマですよ!(鏡に向かって)


さて、と。

昨日Twtterでもお伝えしましたが、ITエンジニアのための契約入門で利用しているエンジン部分のソースをgithubにアップしました
URLは、http://bit.ly/easypubです。
決して高機能なものではありませんが、簡単に電子書籍を公開できるよう心がけています。
ライセンスは(正確にはライセンスじゃないけれども)CC0です。

このエントリーでは、オープンソースにした理由を書いてみたいと思います。

1.やってみたかったから
一番大きな理由です。
なんかほら、「オープンソースにしました」って、ちょっといい感じゃないですか。

2.ダメ出ししてもらいたいから
いままでちゃんとプログラミングについて学んだことがないので、まず間違いなく僕の中には不正確な理解が数多くあるはずです。
今回ソースをさらすことで、自分の間違った理解を少しでも正すことができればいいな、と思っています。
ぜひ、ツッコミをお願いします。

3.たくさんの電子書籍を読んでみたいから
本好きの一人として、一日も早く電子書籍という選択肢が身近なものになればいいなと思っています。
そして、思っているだけより何か行動した方がその実現に近づくのは間違いないので、微力かもしれませんが自分のできることをしようと考えました。

4.販促になるから
350円で販売中のITエンジニアのための契約入門で実際に利用しているエンジンです。
と書けば、少しは販促になるかもしれないと思いました。後付けですけど。

5.惜しくないから
いやらしい話ですが、がっぽがっぽ儲かるソフトウェアやコストをかけて作ったソフトウェアをOSSにすることに抵抗を感じるのは自然な感情だと思います。(OSSにしたから自由に使える訳ではないという話はさておき)
その点、電子書籍はエンジンで儲けるものではなく、そもそもこのエンジンは工数もほとんどかかっていないので、さっぱり惜しくありません。
だからこそのCC0です。

--------------------

今後、暇を見てより電子書籍っぽい要素(理解度テストのようなインタラクティブな機能など)を追加したいと思っていますが、「俺がやっちゃる」という方がいらっしゃったら手を加えていただければとてもうれしいです。

そんじゃ、今日も一日がんばりましょう。
このエントリーをはてなブックマークに追加

今朝、ITエンジニアのための契約入門が無事リリースされました。
iTunesのページはこちらから
 ↑ iTunesがインストールされていない場合はブラウザで閲覧可能です。

エンジニアの方はもちろん、プロが関与しない電子書籍のクオリティはどんなもんか気になる方も、ぜひお手に取っていただければ幸いです。

--------------

さて、電子書籍後の世界について、です。
今朝リリースされたITエンジニアのための契約入門のアプリを作りながら、ふと「電子書籍が普及した後、どんな変化が起こるんだろう」なんてことを考えたりしていました。

普通の書籍が店頭に並ぶまでには、編集、装丁、印刷、流通などのコストが発生することは避けられません。
そのため、今までは、これらのコストを賄える売り上げが見込める書籍しか店頭に並ぶことはありませんでした。

ですが、電子書籍は、工夫と努力次第でストアに並ぶまでに必要なコストをほとんどゼロにまで下げることができます。
つまり、どれだけ売れるかを気にすることなく、それこそ自分が書きたいことを書いただけの本だって世界に向けて気軽に販売することが可能になるのです。

ノウハウの蓄積や技術の進歩によって電子書籍を出版する手間は今後加速度的に小さくなることは明らかなので、上記の「自分が書いた本を誰でも世界に向けて販売することができる」という事実を理解する人が多くなるにつれ、普通の書籍が存在しない電子書籍は次第に増えていくはずだと思います。

今の時点では電子書籍の品ぞろえは普通の書籍の足元にも及ばないけれど、今後も「普通の書籍を電子化したもの」ではない、生まれつきの電子書籍が増え続ければ、そう遠くない将来にこの関係が逆転するのは、ほぼ間違いないんじゃないでしょうか。
そうなれば、両者の関係は、選択肢は豊富だけど玉石混淆な電子書籍と、数は少ないけれど出版社によって品質が保証された普通の書籍といったところになるんだろうと思うのです。

そして、さらに時代が進んで電子書籍がより一般的になれば(それこそ、”普通の書籍”と言えば、それが電子書籍を指すくらいになれば)出版社は原則として紙媒体の書籍を販売しなくなり、品質を保証する機能だけを持つようになるかもしれません。
もしそうなったら、もう「出版社」という呼び名と実際の機能が食い違うことになってしまいます。

今の時点では自分でも荒唐無稽な空想のように感じるけど、こんな時代は案外すぐそこまで来ているのんじゃないかな、なんてことを考えたりしたのでした。

そんじゃ、またね〜
このエントリーをはてなブックマークに追加

T/O
で終わらせてもいいんじゃないかとも思えるほどに長く、そしていつも通りのタイトルをつけてみましたがみなさんいかがお過ごしでしょうか僕は元気です。


さて、電子書籍の話です。
kindleの普及のせいなのか、iPad発売の影響なのか僕にはよくわかってないのですが、とにかく最近、いろんなところで「これからは電子書籍/電子出版がアツい」という言説を耳にするようになりました。
とかく何事にも影響されやすい僕のことですから、ブログや本を読んでいるうちに電子書籍にも興味を抱いてしまうのはごく自然な成り行きです。
「そうか、アツいのか。んじゃやってみよう。」という感じで、ほんとに実現可能なのかもよくわからない状態で動き出しました。
2月のことです。
そして昨日、紆余曲折を経て、なんとかAppStoreへの申請まで無事たどり着くことができました。

今回のシリーズでは、この2ヶ月半の軌跡をメールのログをたどりながら振り返ってみたいと思います。

--------

2月8日
電子書籍の時代がくる(というか、もう来てる)という弾さんのエントリーを読んで、そんじゃ自分でもやってみるかと思い立ちました。
とはいえ、自分だけで売り物として成り立つコンテンツを作り上げる自信は全くないので、日頃交流させていただいている法務ブロガー3人(dtkさんhiroさんtacさん)に「やってみませんか?」と、メールをしてみました。
すると、その日のうちに3人から「よしやろう」という返事が返ってきました。

2月9日
一日で企画が通ってしまったのはいいのですが、みんな仕事を抱えているサラリーマンなので、そうそう集まることもできません。
というわけで、原稿はGoogleDocsで書き進めることになりました。
そうと決まれば、ということで、GoogleDocsに共有フォルダを作成し、Googleグループにこの企画のグループを作りました。

2月10日・11日
10日に「こんな企画でどうでしょう」という企画案をグループに投げました。
で、翌日には、3月末リリース目標という無謀アグレッシブな工程表というおまけ付きで、企画が固まっていました。
なお、この時点で、「エンジニア向けの契約入門」というテーマが設定されました。

2月12日〜14日
コンテンツの骨子をアップし、全員で叩いたうえで、各自の担当部分を立候補形式で割り振りました。
いよいよ執筆の開始です。

2月15日〜
各自、GoogleDocsで原稿を書き進めました。

2月20日〜3月14日
徐々に「ここが書けたよ」という報告があがり始めてきたため、各自、各々の担当部分の執筆と並行してGoogleDocs上で他のメンバーの原稿に修正をかけ始めました。
ただ、この段階ではどこを修正したのかを明確にしながら手を加えていったので、どうしても修正は限定的になりがちでした。
その結果、修正を繰り返しても、担当者間の文章のトーンがバラバラだったり、問題意識が別の方向を向いてしまっている点を修正しきれませんでした。

3月15日
原稿が出そろい、メンバー内でのレビューも何度か回せたことを確認し、想定読者であるエンジニアの方に原稿をレビューしていただくための準備に入りました。
僕は、KatokichiSoftさんgothedistanceさんatsuizoさんあきみちさんに打診し、レビューについてご協力頂けることになりました。

3月18日〜
各自、レビューにご協力頂けるエンジニアの方に、原稿を送りました。
当時の原稿の完成度の低さは冷や汗もので、レビュワーのみなさんには大変ご苦労をおかけしてしまいました。


後半へ続く
このエントリーをはてなブックマークに追加

突然ですが、僕は高校時代、囲碁将棋部というあらゆる部活の中でもトップクラスにもてなさそうな(というか実際トップクラスにもてない)部に所属していました。

そして、囲碁将棋部の部室には、今まで目にしたことのない時計がいくつもおいてありました。
時計が二つ横に並んでいるのです。

chessclock


この奇妙な時計こそ、囲碁、将棋、チェスなどをする方には必須の、そして、しない方には一生無縁なグッズ「対局時計」なのです。


この対局時計を使うと、各プレイヤーの持ち時間を別々に計測できるため、対局がスリリング、スピーディかつメリハリの利いたものとなります。

ただこの対局時計、少なくとも日本では、ものすごく高い。
安いものでも数千円、高いものでは1万円以上するのです。

ストップウォッチを横に並べてちょいとオプションをつけただけの機器が1万円。
正気の沙汰とは思えません。

そこで、今では将棋を嗜まなくなってしまった僕も、金儲けのために義憤にかられて立ち上がらざるを得ませんでした。
そして登場したのがこのアプリ、対局時計 Proです。

チェスでおなじみのフィッシャーディレイ、将棋でおなじみの秒読みには当然対応。
手数も記録され、対局途中でアプリを終了しても、再起同時にはもちろんレジュームされます。

さらに、ブリッツ、10秒将棋などのお遊び対局を気軽に楽しむために、セーブスロットを5個つけておきました。
いつでもキワモノ設定を簡単に呼び出すことが可能です。

これだけそろって価格はたったの350円。
めいじんせ・・・じゃなかった、1万円以上する対局時計を買おうか買うまいか迷っていたあなたは、道具屋さんの前にAppStoreを覗いてみることをお勧めします。


ダウンロードはこちらから
55
このエントリーをはてなブックマークに追加

↑このページのトップヘ