CalcがExcelより優れている点を見つけた

表題がすごい煽った表現ですが、
実際は大した事はありません。



自分用の勤務表入力シートでも作ろうかとしていた時のことです。

出勤と退勤の時間は毎回入力するとしても、
休憩時間をどうするかについて困っていました。

ほとんどの日は固定値と変わらないのに、
たまに入力が必要となってしまうタイプのデータなのです。

しかも休憩時間は、
数値1個の入力では済まないのです。

深夜に休憩したとした場合、
深夜労働の時間から控除する必要が発生します。

深夜だけならまだいいんです。

休憩は複数回あるわけですから、
通常の休憩と深夜の休憩が混在してしまうことが普通なのです。

これをわざわざ入力者に計算させますか？

いえ、自分ならさせません。

いつからいつまで休憩したかだけ入力すれば、
後は勝手に計算してくれるのが理想です。

だって*表計算*ですし。

ということで、
休憩時間は最大3回分の開始時刻と終了時刻を入力できる設計にしました。

ただそうすると、
休憩時間の入力のためだけに6行奪われることになります。

普段は出勤と退勤の2行しか使わないのに、
滅多に使わない機能へ6行使うのは犯罪的です。

ならばとグループ化を使って普段は隠してしまうことにしました。

これで必要なときだけ休憩時間の入力欄を表示させることができます。

後はシートの保護をして計算しているセルを守ってやれば…あぁ！！

シートの保護をしているとグループ化の操作が引っかかる！

しかも突破するにはマクロを使わないといけないらしいです。

せっかく非マクロでここまで来たのに、
グループ化とシートの保護の両立のためだけにマクロを使うことはやりたくありません。

うう～ん、
休憩時間の入力のときだけシートの保護を外させる？

いやいや、
それならシートの保護をしない方がましでしょう。

なら、なら…



これがExcelの限界だっていうのなら、
Calcはその限界を超えてやる！

ってことがあるのではないかと思い、
LibreOfficeのCalcで同じことを試してみました。

…できてしまいました。

同じことをやりたかったら、
ExcelよりCalcを使った方がよさそうです。

以上、終わり！

何が学者に似ていて、何が画家に似ているのか

プログラマー談義をしていたときのことです。

プログラマーは学者の性質と画家の性質を持っているという話題が出ました。

そのときは「うんうん、そうですね」で済ませてしまいましたが、
具体的にはどのあたりが当てはまるのでしょうか？

まあ挙げればたくさんあるでしょうけど、
一番大きそうなのをそれぞれひとつずつ挙げてみることにします。



まずは学者です。

これは"言葉を厳密に定義している"が一番大きいと思っています。

さすがに概念的な用語に関しては意見が割れたままだったりしますが、
一度決まった用語に関してはかなり厳しいです。

一般の方の知識であれをやりたいこれをやりたいと言われると、
その理解の食い違いでひどい目に合うことが多々あります。

実際はADSLでインターネットに接続したいという要望なのに、
「LANを構築したい」なんて説明された例があるとか。
(まあこれはネットワーク話ですが、プログラマーなら特に苦戦しないですしおすし。)

プログラマーはチューリング機械とお話する関係上、
学者並の言葉の厳密さが発生してしまいがちです。

日常レベルに食い込んでいる学者、
それがプログラマーなのかもしれません。

やっぱり、*ソフトウェア工学*だってことです。



では画家はどうでしょう。

こっちは思いあたる節が多すぎて絞りにくいのですが、
あえて挙げるなら"作り上げたものに美を見出す"でしょうか。

これは別に画家に限ったことではないですけど、
画家というメタファーを使うときはクリエイター全般としての扱いが多かったもので。

…経営者と対峙しやすい部分とも言えるかもしれません。

ソースコードの美しさを理解するには相当の技量を要求します。

そして、美しさの価値は美しさが分かるものにしか意味がないのです。

画家に対して美しさはどうでも良いから大量生産しろと言う人は少なそうですが、
プログラマーに対しては美しさはどうでも良いから大量生産しろと言う人はたくさんいます。

画家に言うそれと同じくらいの侮辱の言葉なんですがねぇ。

もしそれが鬱陶しいを思うのであれば、
ソースコードに美を見出すプログラマーを全員クビにしてみてください。

プロジェクトが技術面で炎上するのが確定すると思いますけどね。

プログラマーのレベルが高いということは、
それだけソースコードに美を見出していることと等価なんじゃないでしょうか。

このあたりのお話は、
「ビューティフルコード」でも読んで、どうぞ。



…書けば書くほど理解してもらえなさそうな現実に絶望してしまいそうです。

ピザトースト

ひさびさに料理ネタで記事を書いてみました。

今回はスタンダードなピザトーストです。

具はベーコンに玉ねぎにピーマン…
ちょっと寂しいでしょうか？

それなりにこだわったのはピザソースです。

一応手作りのソースで、
ケチャップをベースにウスターソースやコショウ、
それに少しだけガラムマサラを加えています。

お好みで隠し味に醤油を加えると香ばしさが増すかも…と思いました。

簡単な料理ですし、
各家庭の微妙な違いを楽しむのもおもしろそうです。

さあみなさんも、いざぁ！

管理者が管理するほど生産性が下がる

Excel方眼紙で作られた各種文書(!?)を眺めてみると、
なんでこんな些細なことまで管理したがるのか疑問に思えてきます。

文書からは相当な神経質さが伺えるのに、
これらの資料を入力する時間については無頓着という不思議。

ただ自分が管理している気分を味わいたいがために、
何十、何百、何千万の金額をドブに捨てているようにさえ思えます。

彼らは何を管理したいんでしょうか？



まずソフトウェア開発における管理者の役割は、
*生産性の最大化*に尽きるのではないでしょうか。

そして管理者は、
生産性を向上させるのに必要な環境を整え、
生産性を低下させる要因を排除することが求められます。

ピープルウェアなんかを読めば出てくる話だったかな？

それを忘れて必要以上に管理者が干渉を行うと、
生産性の低下を招きかねません。

生産性が最大化する管理の度合いを考えるのも、
管理者の仕事ではないでしょうか。

多重派遣を無くす方法を考えてみた

ちょっと前の仕事の話ですが、
開発体制がお客様から自分の会社に到達するまで長いこと長いこと。

もう何段階あったのかすら覚えられませんでした。

途中が破線で省略されていましたし。

そして案の定、
お客様に対して顔を合わせることがあれば、
その中のどれかの社名を使わなければなりません。

嘘を極力避けたい自分としては、
これが一番の苦痛です。

これって詐称かなにかで罪にならないんでしょうか？



いや、罪にするべきという方が正確なのかもしれません。

派遣であったとしても、
自分の所属している派遣会社を名乗らなければいけないことにしてしまうのです。

こうすることで、
どれだけの人員が間接的な雇われ方をしているのか実感させることができます。

多重派遣は色々と問題が指摘されていますが、
一番の問題は政府から依頼された仕事でも堂々と行われる事です。

そんな人達に現実を教える方法として、
社名を偽らないというのは有効ではないでしょうか。

…抜け道探される方が早いかな？

おまじないとカーゴカルトプログラミング

よく初心者へプログラミングを教えるときは、
"おまじない"として決まり事のように教えることがあります。

"おまじない"として"#include <stdio.h>"をタイプしろと、
一体どれだけの人が説明したことでしょう。



一方で、
"カーゴカルトプログラミング"というアンチパターンが存在します。

これを簡単に言ってしまえば、
意味も分からず"おまじない"を盲目的に使っていると、
関係ない部分や余計な部分に記述してしまって問題となることを指します。

言っている意味としては、
"おまじない"≒"カードカルトプログラミング"でだいたい合っています。



つまりプログラミング初心者に対して、
私たちは最初からアンチパターンを教えていたことになるのです。

しかし"おまじない"を避けて説明しようとするなら、
初心者は誰もついてこれないことでしょう。

最初に習ったことは無意識に引っ張られやすいものですし、
できることなら間違ったことを教える内容から極力除外したいものです。

本当にプログラミングを上達して貰いたいのであれば、
この"おまじない"は避けるべきではないでしょうか。



さいわいなことに、
最近のプログラミング言語は"おまじない"が昔よりずっと少なくなりました。

アンチパターンを教えないという方針に則るのであれば、
Rubyなんかを使って教えた方が良いでしょう。

まあ"簡単過ぎる"という欠点もあるのですが、
アンチパターンを踏むよりかはマシだと判断しました。

もし本物のプログラマーを求めるのであれば、
SICPでふるい分けでもすれば良いのですから。

見えなくても、百聞は一見にしかず

よく、分かりやすく説明できない方が悪いという風潮があります。

(被害妄想ですけど)特にプログラマーが技術について話すときは顕著で、
難しい事を長々と話されても訳が分からないと言われます。



まあその指摘は一理あります。

プログラマーという人種そのものが説明ベタの傾向がある気がしないでもありません。
(というより、学者全般かもしれませんけどね。)

簡単なものなら図式を使えば何とかなるかもしれませんが、
抽象化のレイヤーが上の方になると図解ですらややこしくなります。

「百聞は一見にしかず」とは言いますが、
ソフトウェア工学はその一見を見せる方法を見出していないようです。



でもプログラマーには、
確かに見せられなくても見えているものが確かにあるのです。

それは*境地*なのかもしれません。

私達にはプログラミングの境地が見えているのです。

お金でかいけつすることはできない。

コンコルドを使っても見つけることはできない。

誰かに頼み込んでも連れて行ってくれることはない。

手助けすることはできても、
最後には自分の力で到達することでしか行くことはできない。

そんな昔話に出てくるような、
幻想の土地が見えているのです。



ソフトウェア会社の社長が元プログラマーであった方が良い理由はここにあります。

どれだけ言葉を並べても、
どれだけ図解を並べても、
その*境地*は決して見せられるものではないからです。

しかしその差は、
開発するソフトウェアへ確かに反映されるのです。



どれだけ言葉や図を並べても伝えられない物、
見えなくても百聞は一見にしかずな物、
そのひとつが*境地*なのではないでしょうか。

USBテザリングを試してみた

ポケットWiFiを使うほどではないにしろ、
外でネットに接続したいことはよくある話です。

最近はノートパソコンを持ち歩く機会が増えてきたのでなおさらです。



そこでUSBテザリングとしてPdaNetを試してみることにしました。
※標準機能？そりゃあんた(ry

インストールさえ突破すれば、
使う事自体はそこまで難しくありません。

Android側で有効→ノートパソコン側で有効にするって感じかな？

インストールそのものも、
翻訳をサボらなければ簡単な操作であることが分かります。



後は3Gの速度の勝負です。

この投稿はPdaNet経由なのですが、
ちゃんと電波環境が良いところであれば実用に耐えてくれるようです。

まあブログの投稿だけであれば、
外付けのキーボードを挿した方が良いとは思いますけどね。

Webサイトの閲覧については、
少なくとも/.Jは実用に耐える速度に見えました。



あとこの方式の最大の利点は、
Androidのバッテリーを心配しなくても良いことです。

常に充電状態にあるので、
ノートパソコン側のバッテリーのみを気にすれば大丈夫…なはずです。



別にPdaNetである必要はありませんが、
月額支払うほどじゃ無いけど外で使いたいときもある人にはオススメです。

同じような境遇の方は、
まあチャレンジしてみればいいんじゃないでしょうか。

半世紀前より稚拙なセキュリティ

もうすぐ今やっているプロジェクトが終了するのですが、
このプロジェクトにはひとつ面白い点が存在しました。

それはプロジェクトの名前がまったく関係の無い単語で、
いわゆるコードネームになっていたところです。

まあ全く使われていなかったんですけど、
もっと流行って使われるようになって欲しいとは思います。



その理由をお話しする前に、
皆さんは"大脱走"という映画をご存知でしょうか。

捕虜収容所からトンネルを掘って脱出を図るお話しなのですが、
トンネルに人物の名前でコードネームを付けていたのです。

人物名なので、
怪しまれることなく堂々と話すことができます。

これにより秘密を保ちながらも、
円滑に作戦について話し合うことができたのです。



これと同じことを、
現代でも応用することができるわけです。

プロジェクト名を全く関係のない名前にしてそれを共通認識にすれば、
いちいちX社の案件などと気をつけて話すよりずっと効果的です。

今回のプロジェクトは外で話す機会が無かったので効果が薄かったですが、
おおよそのプロジェクトでは役に立ってくれるでしょう。

いつも何で実施しないのかと不思議に思っている次第です。



セキュリティは人間側の対策も重要なんて言われていますが、
だったら精神論だけではなくこうした具体的な対策を立てて欲しいものです。

人間側の対策は半世紀前より退化しているなんて、
そんなの絶対おかしいよ！

間違い探しはやる気だけでは難しい

よくバラエティ番組とかで、
"間違い探し"クイズがあったりします。

大抵は比較的早いグループとそこそこのグループ、
そして、
結局答えを見るまで気が付かないグループに別れます。

毎回必ず同じ結果になるわけではないですが、
同じ人が同じグループに属する確率は相当高いように感じられます。

気が付かないグループの人達は血眼になって間違いを探すのですが、
やっぱり見つけられるのは稀な事のようです。

バラエティ番組を視聴している人であれば、
だいたいの方は同じ感想だと思います。



一方で、
仕事で資料の校正を行ったときのことです。

もう10回は見直しをしたのですが、
それでも他の方の平均と比べるとボロボロと誤字・脱字が発見されました。

そのとき呆れ顔をされながらこう言われたのです。

「やる気があるの？」と。



その人がバラエティ番組をよく見ているのかは知りませんが、
どちらも"間違い探し"という点では酷似しています。

"間違い探し"にはやる気では覆しにくい個人差があることを、
何とか理解していただけないものなのでしょうか。



まあ"間違い探し"に限らず、
人間の個人差は普段思っているよりも遥かにばらつきがあります。

自分にはできて他の人ができないからと言って、
それをやる気のせいにしていませんか？

それは個人差であるかもしれませんよ。

Japanese Bloggers Infoに登録しました

トラックバックが無いことのディスアドバンテージが想定より大きいのではないかと思い、
Japanese Bloggers Infoに登録してトラックバックを利用してみることにしました。

クリボウさんの記事にはBlogger関連で大変お世話になっており、
もはや足を向けて眠ることはできません。(方角はわかりませんけど)

しばらくはテンプレートがちょこちょこ変わるかと思いますが、
登録直後のごたごただと思ってください。

別に人気ブロガーになるつもりはありませんけど、
相手に伝えず一方的に記事にするよりかは行儀よく…と言えるのかな？

まずは様子を見てみることにしましょう。

詐欺の定義(再考)

以前に詐欺の定義について考えたのですが、
まるで駄目だったのでもう一度考えてみました。

以前は、

「情報の不平等を利用した取引」

と定義しました。

ですが全然ダメです。

例えば料亭の秘伝の味なんかは顧客が知らない情報と言えますが、
そこに文句を言う人はいるでしょうか。

職人の真似できない匠の技なんかも、
暗黙知の情報と言えるかもしれません。

もちろんこれらは詐欺ではありません。

詐欺は情報の非対称性から来るという仮定はそこまで外れてないのですが、
それだけだと詐欺ではない取引まで含んでしまうので修正が必要です。



顧客が不利益を被ったら？

う～む、価値なんて視点によっていくらでも変わるから難しそうです。

顧客満足度？

ならクレーマーを相手にしたら全ての店が詐欺になってしまいます。

いえ、考え方を変えましょう。

情報の非対称性がどこに発生すれば詐欺になるのか？

商品の欠陥を伝えてないのは詐欺くさいですが、
企業機密の仕組みを使った性能向上なんかは詐欺ではない…

そう嘘を付かなくても致命的な問題を隠していれば詐欺と同じ。
だから嘘では詐欺の範囲をカバーしきれない。

ん、もしかして…

「商品(サービス)の価値に対して情報の非対称性がある取引」

ということでしょうか。

どうやって高品質の商品を提供できるのかについてなら、
情報の非対称性は問題となりません。

でも商品の価値で隠し事や嘘があるのであれば、
それは詐欺だと糾弾されるのではないでしょうか。



おもしろいのは、
これは物によっては売り手ではなく買い手が詐欺師になる可能性もあることです。

オーダーメイドなんかがまさにそれです。

値段を決めてから顧客が必要な情報を後出ししてねじこむなんて、
まさにそれではないですか？

確かに顧客にとっても後から判明した情報なのかもしれませんが、
それならば値段を変更しなければ適正な契約とは言えません。



なるほど、
既に出来上がっている商品を取引するのと、
まだ出来上がってない商品を取引するのとでは、
詐欺の形も変わってくるのかもしれません。

あれ？

これって経営者の間では常識だったり？

SIerが技術力を求めない理由

今イノベーションのジレンマを読んでいるのですが、
その中に興味深い一文を発見しました。

特徴と機能が市場の需要を超えてしまうと、その違いは意味を失う。

これは実体験でもよくある話です。

一人暮らしを始めた頃に電子レンジを買ったのですが、
申し訳程度にオーブン機能がついたかなり安いものを買いました。

自分に取って余分な油をカットできたり、
カロリーを測定できたりする機能までは必要無かったのです。

最低ラインさえキープしていれば、
後は値段しか見るところはありません。



これをSIer所属のプログラマーで例えてみるわけです。

ここでいう特徴や機能を、
プログラマーの技術力に置き換えて考えてみてください。

最低ラインの技術力さえキープしていれば、
後は値段しか見るところはありません。

…と言い換えられませんか？

つまり一定以上の技術力は市場の需要を超えていて、
その価値は一切見向きもされなくなってしまうわけです。

だから他の需要であるコミュニケーション能力などが推奨されてしまうわけです。

市場的にはその方が価値があるわけですから。



しかし電子レンジと大きくことなる点は、
顧客は自分の要望を電子レンジほどに明確化していないことです。

要望(≒需要)が明確化していないなら、
要求されるプログラマーの技術力も明確化していないはずなのです。

これは顧客かSIerが市場の需要を過小評価しているのではないでしょうか。

もしくは両方なのかもしれません。

SIerという市場に技術力という価値を認めさせるには、
この認識を改めてもらう必要があるのだと思います。



そしてこれは技術力だけで解決できる話ではなくて、
多分に経済のお話が絡んできます。

経済の知識とは負の相関がありそうなプログラマーには、
少々辛い話のように思えます。

餅は餅屋、
経済や市場の話は経営者が解決すべきスコープではないでしょうか。

値段だけの競争が不毛なことは何よりもご存知のはずです。

値段以外の価値があることを、
市場に認知してもらうように働きかけてもらえないでしょうか。



もしそこまでプログラマーに任せてしまった場合、
経営者は何の為に存在しているのでしょうか？

SEにも種類がある

自分はよくSE(笑)と言っていますが、
(笑)が付かない場合があるのをすっかり忘れていました。

略さずに表記しますと、

「システムエンジニア(笑)」

「ソフトウェアエンジニア」

と(笑)が付かないSEがあるのです。


まあ後者の意味でSEと呼ばれるなら良いかと聞かれると、
自分はやっぱり「プログラマー」と呼ばれたいです。

単純に「ソフトウェアエンジニア」の定義をよく分かってないだけなんですけどね。


はぁ…なんで設計と実装を分けられると勘違いしてしまったんでしょう。

一旦分けてしまうと、分けられるほど簡単なことしかできなくなってしまうというのに。

あ、人月が余計にかかって保守性も落ちるからSIerは利益がでるのか…

気が重くなる…

YAGNIと拡張性の原則

YAGNIでは、
必要になるまで新しい機能は追加しないとあります。

つまり今必要なものだけを実装しろということです。



UNIX哲学の拡張性の原則では、
拡張性に備えた実装をするべきだとあります。

つまり未来を見据えて実装しろということです。



このふたつは時勢においては矛盾しているように見えますが、
その内容はまったく相対するものではありません。

このふたつのお話しをつなぎ合わせると、
「今必要な機能だけを実装しよう、でも後に拡張するときの準備だけはしておこう。」
という感じでしょうか。

よくこの拡張性を機能と捉えられることがあるのですが、
並のプログラマーなら拡張性は常にある程度考慮しながら実装しています。

拡張性を用意するのに時間がかかると思っている人は、
経験が無いか実力の低いのではと疑ってしまいます。

よほど抽象化のレベルを上げない限りは、
拡張性は実装と同時進行で実現されるべきものなのでYAGNIに引っかからないのです。



むしろここで過剰に反応する人たちは、
意味もなく拡張性を狭める設計をするような気がします。

log4jのロガー名は階層構造が取れるのに、
階層構造ではないロガー設計をして後で泣いていたSEを見たことがあります。

SIerは上流だとか下流だとか言っていますが、
こういうことを考えて実装するには邪魔な区切りではないでしょうか。



まとめます。

YAGNIとUNIX哲学の拡張性の原則は同居できます。

しかし技術力が低かったり、
設計者と実装者が分けられているとその恩恵を享受することは難しいです。

少しでも同居した実装ができる範囲を広げられるように、
もっともっと努力していかなければなりません。

統計でﾆﾔﾆﾔ(・∀・)パート11

久しぶりにブログのアクセス統計ネタをひとつ見つけました。

参照元のURLを見てみると、
googleの画像検索でひっかかった例があったのです。

ひっかかった画像のある記事はこちらなのですけど、
よりにもよってこのチラシの裏に描いたような落書きを…

画像の数で言えば料理の写真がダントツのトップなはずなのですが、
他にも載せている人があまりに多くて引っかからないということなんだと思います。

別にオリジナリティあふれるすごい料理ってわけでもないですし。

よし、これからはもっと料理を…ってそれよりも部屋の掃除がもっと大事です。

インストールでも導入でもなければ

「アプリを『取る』」って何？を読んで、
確かに『取る』って言う表現は何かがおかしいということに気がつきました。



何がおかしいのでしょう？

この場合『取る』という意味は、

　『取る』　＝　『ダウンロード』　＋　『インストール』

として使われています。

どうにも意味が『ダウンロード』の方に引っ張られていて、
『インストール』がおざなりになっているように感じます。



う～ん、では『入れる』なんてどうでしょう？

これで『インストール』の方は…と思ったら『ダウンロード』の意味が薄いですね。

どっちの意味も連想させるような言い回しにした方がよさそうです。



…

……

………

なら『詰める』なら！

アプリケーションに手を伸ばし(ダウンロード)、

袋に入れる(インストール)するようなイメージです。

袋(容量)がいっぱいになったらもう入らない点でも一致します。

おろ？

何か余計遠ざかったような…

抽象化は現代の魔術と言えたり言えなかったり

どこまで抽象化して物事を考えられるかという点において、
人間には相当な個人差があるということが経験則的に分かっています。

単純に言ってしまえば、
できる人とできない人が居るということです。

プログラミングの技法としてこれだけ体系化されてもなお、
できない人にはできないというのは違和感を覚えます。

高校くらいまでの理数教科で、
多少なりとも先天性を求められるものがあったでしょうか。

実際はどうなのかはともかく、
地力と学習量次第で習得可能だと思われているんじゃないでしょうか。

言い方を変えると、
学習の*再現性*が薄いのです。

科学の領域ではないのです。

学んでできるようになるとは限らないのです。

しかも、経験則では先天性であることが疑われています。



これではまるでファンタジーに登場する魔術です。

魔術理論という体系化された学問がありながら、
それを修めることができるかに才能が絡んでくるのです。

“ウィザード級のハッカー”が、
どれだけ気の利いたメタファーであるかを思い知らされます。

外見の効果も魔法に見えるなら、
そこに至るまでの道筋すら魔術的なのですから。

そういう意味では、
この世界に魔術は確かに存在するのかもしれません。



ただファンタジーと違うのは、
抽象化は人間の優劣を決定づけるほどの要因ではないということです。

絵が描ける、描けないと同レベルと思っていいかもしれません。

現実に魔術が当たり前になった世界でも、
案外それくらいの影響しかないような気がします。
(時勢にもよるとは思いますけどね。)



現実に魔術はありませんが、
魔術と同じようなものは確かにあるようです。



さあ、今日もMPの使いすぎには注意しながら頑張りますかね。

上質な記事が少ない訳

自分は/.Jをよく読んでいるのですが、
記事以外にも気になる点がいくつかあります。

その中のひとつなんですが、
画面下部にどこぞから引用された名言が表示されるのです。

ある日のこと、
その欄にこんな言葉が表示されていました。

「にわかな奴ほど語りたがる -- あるハッカー」

この言葉は、
自分に対して理屈ではなく心に訴えかけるような納得感を与えました。



なんと言いますか…

ある道について学べば学ぶほど、
自分の矮小さに気がつくのでおいそれと発言できなくなります。

もちろん慎重にデータを集め、
根拠を揃えてからなら何かしらを発表することもあるでしょう。

しかし、
勢いにまかせた発言はだんだんと減っていくように思えます。



逆ににわかさんは、
まだ矮小さに気がついていない状態です。

その優越感に身を任せ、
何も気にせずどんどん発言します。

ただでさえにわかさんの人数は道を極めつつある人よりずっと多いので、
悪質な発言や記事、論文や書籍が数多く出回ることになります。

これは発言の為のハードルが低い媒体であるほど顕著だと思います。

つまりはインターネットの情報が玉石混交なのは必然となるのです。



でもその中のどこかに、
素晴らしい情報は確かに紛れているのです。

それを抽出することだってインターネットはできるはずです。

インターネットの情報が玉石混交であったとしても、
その中の玉が見つかりやすいようにはしていきたいものです。