伝言ゲームって怖いよね。
何とは言わず。
（以下、ありがちなパターンを想像）
- 開発者「確かにちょっと問題あったんですけど。当時要件に性能が挙がってなかったので。」
- 開発者「無償で改修くらい入れてもいいんじゃないですかね。」
- 営業「改修ってどのくらいかかるの、コード修正、テスト、配置含めて？」
- 営業「結構かかるね。じゃあ、いいよ。当時要件になかったんだからそれは仕様の範囲だし。」
↓
- 営業「不具合ではありません。当時の背景を考えると仕様の範囲内です。」
- 施主「じゃあ、不正なアクセスになるんですかねぇ。」
- 営業「まあ、想定外なアクセスにはなると思います。」
↓
- マスコミ「不具合はなかったという。」
↓
- 読者「そりゃねーよ」
読者からは結果しか見えないですしねぇ。
「よくよく聞いてみたらそんなに悪くないじゃない」、「各人の立場考えたらどこにも嘘はない」とかだから済むという話でもなく。世の中起きてる大問題ってだいたいこの手の伝言ゲームの結果なわけで。1か所でも校正が働いてれば問題起きなかったかもしれないけど、ことごとくかみ合わなくて、とか。どこか1点だけを見て犯人捜ししても何も問題解決せず、どうやってこの手のコミュニケーションロスをなくすか考えなきゃいけないんですよね、きっと。
プログラミングの学習は IDE 前提だろ、常識的に考えて
タイトルは釣りっぽくしてますけども、そこそこ真面目に。この話題、プログラミング以前の問題な気がしてきたのでブログ書いてみる。
↓学び始めは IDE VS コマンドライン のどちらがいいかという話。
常々↓こんなの書いてる身としては、Java な方面にもこういうこと言ってくれる人がいて一安心。
ふと思ったのは、これって「1歩ずつ着実に進まなきゃいけない」というのがそもそもの勘違いなんじゃないかっていう気がしてきました。
とにかく先に進んでから見下ろす
プログラミングに限らず、どんな学問に関してもそうなんですけども、「ある章を完全に理解するまで次には行かない」みたいな人が結構いるじゃないですか。
あれって実のところ、学習の仕方としてはダメな部類にはいるんですよね。実際のところはもう、最初に1度、理解の度合は置いといて、全部に目を通した方が効率がよかったり。
よくある例えとしては、学習を登山に例えるのがあるんですけども、下から見上げるとあまりよく見えないけども、とりあえず上に登ってしまってから下を見渡すとよく見えるっていう。
理論はメッシュ状
というのも、理論って一本道じゃないんですよね。
三角関数の加法定理とか、それ単体で覚えたら大変ですけども、数学できる人は以下のように、他のいろんな事象と結び付けて覚えています。
- exp(ix) = cos x + i sin x
- 微分すると sin → cos → -sin → -cos。
- {cos x + i sin x}^n = cos nx + i sin nx
数学苦手な人には一見関係なさそうに見えますが、全部つながっています。数学の得意な人はその「つながり」で覚えています。教科書を真面目に前から順になんて読んでたらこういう覚え方できないんですよねぇ。もう、教科書もらった日に全部一通り目を通しちゃうくらいが正解。てか、上の学年の教科書も最初から配れと言いたいくらい。
他にも、ありとあらゆる場所で、いろんな理論が他のいろんなものとつながっていて、単体で覚えるよりも包括的に覚える方がはるかに簡単で、はるかに強固に記憶されます。
人の記憶はメッシュ状
理論が一本道じゃないなら、覚え方もメッシュ状にした方が効率がいいんですよね。だって人間の記憶ってのものは単体で物事を暗記するようにはできていないから。メッシュ状に、いろんなものの関連性をいろんな方向からつないで記憶しているわけで。
何か1個ちゃんと覚えないと次に進めないと思ってる人は、ぐずぐずと次に進めず停滞していることが多いように思います。
スーツ
25〜28日の3日感はtech・edに参加していたわけですが。
今回は登壇者バッジで入場する手前、一応スーツで参加したり。1年に1度見れるかどうかの超レア姿。コスプレもいいところでした。
※服装は自由ですが、短パン・Tシャツなどはお断りします
自由ってなんなんでしょうね。
別にかっちりスーツな必要なかったんですけどもね。なんとなく、ビジネス カジュアルな感じで OK。でも、ジーンズ以外のボトムスを持っておらず、結局スーツに。で、どうせならたまのスーツだしかっちりしようと、ネクタイと背広まで装備。
でも、もうビジネス カジュアルみたいな中途半端な規約要らないと思うんですけどもねぇ。というか、ビジネス カジュアルなんて定義なくて、何も規約定めてないに等しく。
- 「俺がビジネスだ！」（タンクトップにジーパン姿で）
- 「襟付きシャツにメンパン履けばいいのよね？ラメ入りパイソン柄でも。」
とか言ってみたい衝動に狩られ続ける日々（実際口に出して言ってますけど）。
スーツだからと言って
「普段の姿をチンピラとするなら、完全にマフィアですよね？」
ええ、正解です！道とか電車の扉ふさいでる高校生くらいなら、ひとにらみでどきます！（実話）
あと、「どちら方面のビジネスですか？歌舞伎町？」などというご質問もあながち間違ってはいないと思われます。ええ、スーツもちょっとアレです。すみません。
クールビズ
でも、久々にネクタイしめるに至ったはいいものの、街の様子を見てみれば、ここ数年でノータイが増えましたよねぇ。8割方はもうノーネクタイ。
環境がどうとかいう名目があれば、これだけノータイ文化普及するんですよねぇ。もういっそ、このままの勢いでスーツ自体滅びればいいのに。
久々にスーツ着てみてつくづく思ったんですけども、電車とかの冷房設定、いまだに完全にスーツ前提の温度設定ですもんねぇ。そりゃ女性客は寒い寒いといいますよ。
コスプレ
某 K 都にある K 大とか、卒業式がコスプレ パーティじゃないですか。コスプレってフォーマルなかっこなんじゃね？もうビジネスもコスプレでいいんじゃね？
とか言おうとしたところで、普段から「スーツはコスプレ」「日本全国コスプレ会場」とか言い放ってることを思い出しました。何も間違ってなかったですね、ビジネスもコスプレ。
自分人件費は使わない
僕は結構「自分人件費は使いたくない」みたいな表現するんですけども、これの言いたいところは、
- 個人で、無償で開発しない
ということです。
実際、自分がプログラム書くのは仕事か、あるいは記事とセットのサンプルコード。
追記： ちなみに、この話のキモというか、自分の行動ポリシーは「個人スキルへの依存は避けたい」です。なので、公/私・個人/チーム問わず、だいたい以下のような方針：
- 自分が投げ出したらそこで終わる仕事はしない
- もしそうなら、最初からやらない
- いつ何時自分がいなくなっても仕事が回る程度に資料等残す
- 常に情報は共有する
- ドキュメントやコメントは整備する
- 可能な限り、人を育てる仕事をする
あと、普段から「工場生産、マニュアル接客最高」とか言ってる理由もここから来てます。「データのオープン化 - ++C++; // 管理人の日記」で書いた「データを人質に取るな」と通じますけど、ノウハウを人質に取った仕事はしたくない。
個人開発はくじけて消える
個人が作ってるフリーウェアは、作者がくじけた時点で消えてなくなっちゃうんですよねぇ。
例えば、IE がまだ 6 の頃、Opera みたいな独自レンダリングエンジン持ってるブラウザーももちろんありましたが、IE コンポーネントを使ったタブブラウザーも結構流行ってました。たくさん出るのはいいんですけど、流行り廃りも激しく、多くのタブブラウザーが出ては、多くのものが消えていき・・・
すたれちゃったからしょうがなく別のタブブラウザーに移り、そのたび、操作性の微妙な差に苦労し・・・。最終的に行きついた境地は、もう IE でいいや。
個人開発はくじける
もっとも、IE 7 が出てくれたおかげで、公式にタブブラザーが使えるようになりましたが。
となると、今度は、フリーウェアのタブブラウザーの存在意義がなくなるんですよね。公式であるから。
てか、需要があるならいずれは大手がやる。大手がやらないものは需要がない。なので、やるとするなら、
- 普及し始めを狙って、大手が需要に気付く前にやる
- ニッチ狙い
のどちらかしかないわけで。前者は「期間限定」になりがちだし、後者は広い普及望めないしで、それでモチベーション保てるのか、という。
そりゃ個人開発はくじける
しかも、そこそこ流行ってしまうと色々言ってくる人増えますしねぇ。
「ここまで普及すると、もうこのアプリはあなただけのものではありません。ユーザーの要求を聞いてください。」
「広告うぜー。拝金主義うぜー。てか、スパイウェアなんじゃねぇの。」
プロだと、客層絞る（上客にだけ丁寧な対応して、その他は「ほどほど」に対処）とかやるコツを知ってるもんなんですけど、個人開発だとその辺りの勘所わからずくじけちゃったりとかも。
心なし程度の募金依頼/広告はほとんど儲からない
最初からガッツリ儲け見込んでやるならともかく、趣味開発で、心なし程度に募金募ったり、広告載せたりしても、大して儲からないんですよねぇ。
というか、儲け狙ってやっても、素人だとそうそう儲けられるものでもなく。iPhone アプリみたに、初期から食いついたアーリーアダプターの一部は儲かることもあるんですけど、大体この手の「素人市場」はすぐに供給過多なレッドオーシャンになっちゃうし。
その割に、日本だと「金儲けはよくないこと」みたいな空気がひどいんで。
趣味開発は面倒なところが完成しない
趣味開発やると、ほぼ確実に「作るのが面倒なところ」だけが未完成で残ります。これは個人でなくてもそうで、オープンソース開発ではよくあるそうです。作ってて楽しいところだけはみんな作りたがるんだけど・・・って。
8割がた完成させるところまでは楽なんですよねぇ。残りの2割は、やっぱ商用でないと完成しない。
その点、Apple とか Google が主導でやりつつ、オープンソース開発者も抱え込んでるようなプロジェクトは理想的らしいですけども。「必要なんだけど誰もやりたがらない部分」を、商用でやってる会社が埋めてくれるとか。
主導者がくじけたら消える
主導者がくじけても、一度はやってしまえば、他の誰かが引き継いでアプリは残る・・・そんな風に思っていた時期が僕にも・・・いや、最初からなかったかも(笑)
なかなかねぇ、やっぱり主導している人がくじけたら開発止まっちゃいますねぇ。
なので、個人で趣味開発はしない
自分がくじけたときに、色々と無に帰すことはやりたくないんですよねぇ。
だから、自分がプログラム書くのは仕事か、あるいは記事とセットのサンプルコード。
前者は必要に迫られてやってるんだから当然として、後者に関しては、入門記事とかなら、自分がくじけて更新やめても、記事を見て勉強した人が引き続き何かを生み出してくれるはずなので。
データのオープン化
Cloud! Cloud! Cloud!
思いっきり「クラウド」って言葉がバズってる昨今、皆様いかがお過ごしでしょうか。
とりあえず、大きなくくりでクラウドって言ってしまうと色々と胡散臭いですが、そのクラウドの背景にある潮流は確固たるものだと思います。いろんな視点から、いろんな「クラウド」があるかと思いますが、例えば：
- インフラ
- 仮想化・自動プロビジョニングによる管理手間の低減
- クラウド プラットフォーム
- SaaS
- 出来合いのサービスの提供を受けることでそもそも開発自体しない
- マルチテナントにサービス提供することで、規模効果によるコスト削減
などがその潮流にあたるかと思います。
そんなこのご時世に、僕が今ここで言いたいことは「データをオープン化しようよ」ということです。
データをオープンにして欲しい
要はね、システムのデータベース情報、プログラム的にとれる口を開けといてくれと。
もう、B2C、B2B 問わず、ありとあらゆるシステムはデータ用の API 用意しろと。
「オープンな技術を使っているのでベンダーロックされませんｷﾘｯ」とかいう前に、お前のとこのシステムをオープンな作りにしろよ！と。ベンダーロックと以上に、SIer ロックもされたくないです。
身代金
最近、SI 屋さん相手にこのようなやり取りいたしました：
- 自分「このシステム、帳票出力周りは WinForms でできてるみたいですけど、サーバーとのデータのやり取りどうしてます？何か API 的なところは標準的なプロトコルでやってます？」
- SI 屋「いやー、『作りこみ』でやってまして、標準的な何かというのではないんですよ」
- 自分「じゃあ、何か API の提供お願いします。流行りの OData 的なもので」
というのも、追加の要件ができたときに、SI 屋さんに追加発注するまでもないような小さない改修とかあるじゃないですか。そんなもん、自社で作るよ、と。
あと、保守契約でもめたときに、いつでも解約の通告出せるようにしておきたいという意図もあったりします。最悪、喧嘩別れすること想定した場合に「あなたのところクビにしたいのでデータベースの移管お願いします」とかお願いするのも切なく、なら最初からデータを自由にとれる状態にして置きたい、と。
いずれにせよ、プログラム的にデータ取れるようにしとけと。
（もちろん、データベースのアクセス権限もらって直接データベース触るとかもありなのかもしれないけど、ビジネス ロジック層通らないのはちょっと・・・）
（あと、API 公開してもらわなくても、ウェブの画面を HTML スクレイピングして情報とったりもできるけど、それをやらされる方の身にもなって・・・）
それがないのって、ある意味、SI 屋さんにデータを人質にとられてるようなものなんじゃないかとか思うわけです。
保守費用の中に、幾分か身代金が含まれている状態。
サービス指向
クラウド的な潮流の1つに、サービス指向ってのもありますよね。（正確には、クラウド以前からあるというか、クラウドのきっかけとなった潮流という感じですが。）
小さな機能単位でサブシステムを区切って、それぞれがプログラム的にやり取りしながらシステム全体をなす、という（機能単位 ＝ サービス。サービス連携でシステム構築）。それに、1つで完結したシステムであっても、対人間向けの UI だけじゃなくて、対プログラム向けの API を公開（サービス提供）。
システム内の一部分だけを置き換えるとか、他のシステムと連携して新しい事業起こすとかできるように。
これ、「人質解放」の意味もあると思うんですよねぇ。
ちょっとした UI であればいつでも自前で用意できる。
SI 屋ともし喧嘩別れすることになったとしても、引き継ぎ先を見つけるまでの間くらいは自前で保守できる。
データ サービス
さらに突き詰めていくと、そもそもデータだけ提供してもらえれば十分なところも多くない？とかも思ったり。
BI 的な処理なんて、システム内でやっていただかなくても、トランザクション データだけオープンにしておいてもらえれば Excel PowerPivot ででも読み込んで自前で解析するから！とか。
システム納品してお金もらうとかじゃなくて、データだけの切り売りとかもありですよねぇ。
MS が Azure の一環としてやってる Dallas なんかがまさにそれですけども。
物理的な商品でも、システムやアプリケーションでもなくて、データのマーケットプレース。
Ruby チップ・・・だと・・・
http://itpro.nikkeibp.co.jp/article/NEWS/20100628/349693/
これはいくらなんでもちょっとひどいなぁ（「Ruby チップ」の方）。問題は2点。
注： Ruby だからダメってわけじゃなくて、Ruby の部分を Python とか .NET に置き換えたとしてもまるでダメ。
ハードウェア記述書いただけ
ハードウェア系の研究室にありがちな話なんですけども、単にハードウェア記述化しただけで「研究」と称する人が多いんですよね。（やってる本人は百も承知でやってる。こんなのを研究と呼んでいいのかわからないけど、それでとりあえず卒業できるから。）
研究っていうと、本来、何らかの問題に対して「私の知恵で問題を解決します」と言えなきゃいけないわけですが。この手のハードウェア記述しただけの研究は、
- 問題： ハードウェア記述言語はクソなのが多いので記述が大変です
- 解決： 根性出して書きました！
になりがち。特に、(ガベコレ部分だけとはいえ) Ruby プロセッサを作るのに、「記述が大変」以上の困難があるとはとても思えない。
というのも、昔そういう試みは「Java プロセッサ」で通った道なわけです。10年以上前に、Java のハードウェアアクセラレーターを作ろうみたいな研究山ほどありました。が、今、それが役に立っている形跡はまるでなく。
要するに、10年は前の研究、しかも芽が出ているとも思えないものを Ruby で置き換えて再発名してるだけ。もちろん、「Java だとこういう点が問題だったけども、Ruby ならその問題を乗り越えられます」と言えれば研究にもなりますが、それが示されている節もまるでなく。
地域ガラパゴス化
もう1つの問題は、「なぜ Ruby なのか」という問いに対する答えが「地域発の技術だから」でしかないんですよね。ほんとうは新規性なんてまるでないんだけど、既存研究の一部分を地域発の技術で差し替えることを指して「地域イノベーション」とか言われても。
まして、今回の場合は Java でダメなことがわかってることを真似てるわけで。なのに、「Ruby」を冠してるだけで地域振興的な意味合いのお金が出てる。それは Ruby を盛り上げることにはならず、むしろ貶めることになるのでは。あるいは、せっかく世界的に認められた Ruby というものを、再び地域ローカルなガラパゴス技術化させてしまうだけ。
ってことで、なんかもう、このニュースには「ハードウェアがらみの研究」と「地域イノベーション」ってものの問題が凝縮されてる予感が・・・
