)は、アメリカ合衆国のプログラマ、作家。オープンソースのスポークスマン的な役割を果たしている。呼び名も知られている。Japaneseフリーソフトウェア/オープンソースソフトウェアの開発手法が、Linuxによってどのように変わったかという内容。一人のウィザードか魔術師の小集団による開発スタイルから、「目玉の数さえ十分あれば、どんなバグも深刻ではない」という大人数による開発に変わっていく。あたりがこのスタイル(バザール型)を確固たるものにしたと思う。Gitを作ったリーナスの偉大さよ!最近は、スタートアップ(特定の営利企業)でも、GitHubを使った開発フローが採用されているので、スタートアップもオープンソースのようにソフトウェアを開発していると考えることもできる。スタートアップのソフトウェア開発にとってもたくさんヒントがある。あとは、とにかくリリースしろって言う考え方。リリースして、ユーザーも巻き込んで直していけばいいと。リードホフマンあたりの発言にもつながる。最初、伽藍とバザールを読んだ時にソフトウェア開発を仕事にしたいなと思った記憶がある。スタートアップ的アプローチと、オープンソース的アプローチだと、いまでもオープンソース的アプローチのものにあこがれがあるのはここら辺の影響なんだろうなと。ブロックチェーンが世界を飲み込もうとしている現在だと、その二つにもあまり違いはないんだけど。いいソフトウェアを作ろう以下引用よいソフトはすべて、開発者の個人的な悩み解決から始まる。ポールグレアムのいう、自分が欲しいものを作れや、ジャックドーシーがいう、自分が見たいものを世の中に生み出すとかも同じ趣旨。いわゆる、「必要は発明の母」ってやつ。ガリバー旅行記のジョナサン・スウィフトの言葉。エジソンも引用しているからかなり有名。捨てることをあらかじめ予定しておけ。今でいう犠牲的アーキテクチャ。式年遷宮が必要ってやつ。理想的なソフトウェアは、工具がいらず、素早く分解できて、素早く組み立てることができる拳銃みたいなものだと思っている。壊せて、すぐに直せる。まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。これはスタートアップも同じだと思う。スタートアップも課題が大切だという。課題が見つかるわけではない。まとめに行動すると自然と見つかったりする。初期のアイデアにこだわる必要がない。初期のアイデア(課題)なんてダメダメだから。まともに初期アイデアに向き合わないとだめ。そのうちに正しい課題を見つけることができる。あとは、僕が尊敬する経営者がいっている、「本来ならとても計算可能に見えないような問題を計算可能な問題に落とし込むスキル」というのを磨くことが今後は大事なんだろうね。賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。ロジックよりも、データ設計が大切という話。完成(デザイン上の)とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。これもいい言葉!!!最後にとにかく読むべき。プロセスアーカイブ2018/062018/022017/072016/112016/102016/072016/05WEBサービス・スマホアプリのプロトタイプ構築支援サービスです。