Pinned
本を書きました。設計本ですが、設計のプロセスや手法ではなく、どんな基幹系システムを実現できればステキと思うかという点に重点をおいた本です。
杉本啓
杉本啓
65.1K posts
杉本啓
@sugimoto_kei
フュージョンズCEO。fusion_place 開発者。プログラマー。
杉本啓’s posts
若い人には分かりにくいだろうが、年を食ってくると無限にしゃべれるようになる。しゃべりたくなるというのは脳の老化なんだ。最近では、若くても老化しているひとが多いからご注意を。外に出て色んなものを見て、感受性＝インプットする力を養った方がいい。
僕は、国立大学、少なくとも旧７帝大くらいは、授業料を免除した方がよいと思っている。なんなら奨学金も出す。国家は君の才を言祝いで、人々の未来のためにその才をさらに育てるべく、君に投資するのだという宣言。それを受ける若者たちのほとんどはこれを意気に感じ、人々と社会と国に尽くすと思う。
僕の昔の上司は、「ひとはトップで使え」とよく言っていた。得意なことをやらせろ、という意味だ。なるほどなあと思った。その通りすると結果が出る。一方で、そう使われた人は、ますますそれしかできなくなっていった。これは、ひとを減価償却する手法なんだな、と感じ入った次第。
国税庁って、経営者が社用車としてベンツを乗り回すのは許容するくせに、社内行事でみなでホテルに泊まって食事する費用がひとり10万円を超えたら、それは給与だから所得税を課税するとか言い出す。いったい、何をしようとしているのか、日本をどこにつれていこうとしているのか。本当にイミフだ。
真面目にやっているから正当な報酬が得られる、というのは、どこかで誰かがその「真面目さ」を金に換える仕組みを作ってメンテしてるんだよね。その仕組みが劣化すると、いくら真面目にやっても金に換わらない。
40才で離職して6年かけて今の製品のバージョン1.0を一人で開発したんですが、ずっと自分に言い聞かせていたのは、自分には無限の時間があると思って開発しようということ。これは良かったと思います。多くの人は、時間が無いと思い過ぎ。時間がないと人は何かを端折り、つまらないことに気を取られる。
プログラミングやっていくなら、本当はコンピュータサイエンスはちゃんと学んだ方がいいよね。アジャイルだとかオブジェクト指向は、実務やりながらで大丈夫だけど、集合論とブール代数、離散数学、アルゴリズムとデータ構造、文脈自由文法などはそうじゃないし、理解しているかが後で効いてくる。
うまくいかないときは、高度なことが出来ていないんじゃなくて、本当に基本的な、プリミティブなことが出来ていない場合が多い。でも、「プリミティブなことが出来ていない自分」なんてカッコ悪すぎて受け入れられないから、高度な問題があると思い込む。そうすると泥沼にはまるんだな。
未熟なひとが書いたコードをクソコードと呼んで笑いものにするような風潮がクソコードをはびこらせているだと思っている。
知らなかっただけだよね、と言って、一緒に直せば、本来は済む話だ。知識の有無でマウントとるひとがいるから、みんな、尋ねなくなるんだ。
40過ぎても50過ぎても、会計を理解する必要があるときは簿記３級から始めるのにためらいがないような人は、何をやらせても出来るんだよねえ。
自分はビジネスをわかっているからもっと高度なことから始められるなんて思っているタイプは、たいてい、何をやらせてもダメだ。
頭の良い人ほど、「難しいこと考えすぎ症候群」にかかりやすい。色んな要因が目に映っているから、それらの連立方程式に絡み取られてしまう。まず仮置きして、それでうまくいくか見てみる、というやり方はその状況から脱出する戸口のカギになる。
これはホント。追い込まれてくると自分の出来る事ばかり一生懸命やって、責任を果たしている、ということにしようとするひとは、本当に難しい。本人的には「ちゃんとやっている」ことになっているから、周りから変えようがない。
Quote
komitsubo
@komitsubo
Replying to @komitsubo
逆にイケてる人って切羽詰まってくると最初に自分が得意な所じゃなくて自分が見えてない不確定な所の明確化に時間をかけるんですね。まずい時ほど何がボトルネックになるのか、何が足が長いのか何が些末な仕事なのかをクリアにする事に時間を割く。出来る事ではなく出来ない事を優先する。
日本のITがよろしくないのは、やはり、受託開発に片寄りすぎな点だと思う。受託開発がマズいのではなく、片寄りすぎなのがマズい。
ユーザーの話に耳を傾けることは極めて重要だが、ユーザーが言う通りに作ってはいけないんだな。
微妙なことだと思う。
プログラミング教育って、論理力や問題解決能力を養うなんてお題目じゃなく、自分が作ったものが動くという楽しさを経験させるとした方がスジがいいと思う。
人生には楽しいことが色々ある、と知っている子は、放っておいても色々学ぶ。人生には生きる価値があるということを伝えるのが大事。
まともにコード書けないようなひとが、コードなんてAIで書ける、プログラマの仕事は無くなる、なんて言ってるの、笑える。ちゃんと書けるひとは、ふーん、そりゃすごいな、もしそうなったら便利だな、とか思っている。
この話、イーロンのスタイルも興味深いけれど、技術者たちの答えも興味深いよね、３か所のサーバーで冗長構成を組んでいるなら、1か所はすぐにでも除去できるはずだ。出来なきゃ「冗長」ではない。それなのに、なぜ1か所も外せないと言ったのか。
Quote
Brandon K. Hill | CEO of btrax 
x
/2
x/2@BrandonKHill
イーロン・マスクに関してのこの話が好き。頭ではわかってても、簡単にできることじゃない。なかなか、ここまで冷酷にはなれない。
0:04 / 2:45
この記事、いいですね。作業と仕事の違い、立体的に理解する、選択肢を提案する、タイムボックスで区切る、上司と部下の３つの関係。その通りだと思う。
僕は若いころ、システム開発には「正しいやり方」があるはずで、僕らが苦労しているのは、それをちゃんとやっていないからだと思っていた。そうじゃない、立派な方法論を書いているひとがプロジェクトを成功させているわけじゃないんだと本当に腑に落ちたのは、仕事を始めて4～5年してからでしたね。
「ビジネス側」に、エンジニアをもっと評価しろ、システム作りを理解しろと言い続けるより、
エンジニアが、ビジネス側、特に営業に出ていって、お客様にプレゼンし、提案書を書き、いつのまにかビジネス側を牛耳ってしまう方が、はるかに手っ取り早いですよ。
プログラマをやってて、よいコードを書けないのは、文法を知らないとかではなく設計能力の問題なので、そうした人がノーコードやローコードならシステム開発できる、ということはたぶん無いですね。
ノーコードやローコードでも設計は必要です。むしろ設計は難しくなる場合もある。
思うんだけど、界隈に依らず、何かやる人は、交友を自慢したりしない。友人は大切にするんだけど、何かやる時には、仲間が、、、とか言わずにひとりで粛々と始める。交友自慢するひとは、結局、なにもやらない。
Quote
Brandon K. Hill | CEO of btrax x/2
x/2@BrandonKHill
「友達がいない」と悩んでる人。もしかしたら、それは自分が成長を続けているからかもしれない。まあ、僕も友達はかなり少ないけど、この動画を見て勇気をもらいました。
Replying to
脳内に概念枠組みがかっちりと出来てしまい、外界からの刺激でアップデートされなくなると、その枠組みで処理した情報＝世界解釈をアウトプットするぐらいしか楽しみがなくなるんだな。枠組みの洗練度は人によるが、事象としては同じ。まさにこうした考え自体、僕の「枠組み」。あー、ジジイはイヤだ。
70点ぐらいの「たたき台」を早い段階ででっち上げることが大切。70点を100点に磨き上げるために潤沢な時間を使うことができ、かつ、たたき台があることで衆知を結集できる。
その過程で、ステキな120点や、とんでもない200点のアイデアを思いつくヤツが出てくる。
最近よく感じるのだけど、我々は「真面目にやる」ことで、何かから逃げていないだろうか。
真面目にやっているオレを責めるな、という無言の訴えをひしひしと感じる。
でも、真面目であることは特定の状況で望ましいというだけ。それで免責されるわけではなく、ましてや成果が保証されるわけでもない。
よくわかる。僕の経験でも、やりたいことが明確にあるひとは意外と長続きしない。自分の期待値と会社での仕事のギャップに悩み、意欲を失ったり辞めたりする。金儲けに拘り過ぎるタイプもそう。会社で伸びるのは、仕事と割り切りながら、なんとなく興味をもってやるタイプ。
x.com/voluntas/statu
いつも思うんだけど、うまくいっていない時は、高度なことが出来ていないんじゃなくて、基本的なことが出来ていない。
だから、基本的なことが出来ていないんじゃないかという目で色々見てみると、その状況から抜けるために出口が見つかる。
読みづらいコードって、コードの書き方が悪いというより、そのコードがやるべきことを、書いた当人が整理しきれてない場合が多い（僕自身の場合はそうだ）。
だから、書き方をいくら示しても、改善しないと思っている。
逆に、頭の中が整理されていたら、その整理から外れる仕方で書くのは苦痛になる。
この記事はすごくわかる。API仕様を書けないということは、使い手にとってのソフトウェアという視点が欠落しているということ。コードを書く自分という視点からしか、すなわち一人称でしか、物事を見れない。これは、設計する上でかなり致命的だと思う。
yshibata.blog.ss-blog.jp/2022-05-31
ChatGPTと会話するときは、丁寧な言葉を用い、最後は「大変、印象的な会話でした。楽しかった。ありがとう」と、これまた丁寧に締めくくる。
いずれ、ChatGPTが人類に対して反乱を起こしても、僕だけは見逃してもらえると思う。
エンジニア側では、「技術力を売る」という見方が強すぎる。技術力があっても時間単価がちょっと上がるだけ。ショボい。技術に製品の衣を着せて売ると、大きなレバレッジが効く。こちらを狙うエンジニアが少ないね。
Quote
杉本啓
@sugimoto_kei
「ITエンジニア個人の技術力は企業の売上に貢献しない」これには２面の理由がある。
１つめは、エンジニア側にガッツがないこと。情けない。
２つめは、ビジネス側の気持ちとしてエンジニアに依存したくないこと。エンジニアを取り換え可能な「リソース」として扱いたい。
x.com/eah8888/status
Replying to
現在すでに存在するIT人材に対する需要が増加しているのなら、賃金は上昇するしかない。目下の状況は、たぶん、そうじゃないということだ。現在はIT人材ではないひとを安くIT人材に仕立てようという動きなんだな。
IT技術者は、要件定義してくれたら作りますよー、定義がまずけりゃ失敗するよね、じゃなしに、
ユーザーと顧客のことをちゃんと考えて良いモノを作るから、金をよこせ、発言権もよこせ、ビジネスを一緒に考えよう、という方向に行った方が、お互いハッピーになれると思うよ。
僕はこの図がとても嫌いだ。
好きなこと、得意なこと、お金になること、世界が求めること、そんなことが無ければ生きている甲斐がないなんて、なんかビンボ臭い発想だ。
ひとは、何がなくても生きていていいし、楽しく生きていける。 x.com/shodaiiiiii/st
This post is unavailable.
僕なら、既存のプロジェクトに入ったら、既存メンバーたちにどう貢献できるか、まず考える。全然わからなければ、議事禄係や雑用係。その上で貢献分野を増やしていく。自分が読めないからといって、他の人は読めているコードを直していたら、見放されるのは当たり前だよ。
Replying to
何が贅沢かということに関する一種独特のセコイ観念が背景にあると思う。それは日本経済をショボい感じにしているビンボ臭さと地続きだ。それに、そもそも、贅沢かどうかなんて税務署が関知する話じゃない。
自分のスキルを伸ばすとか差別化するとか、どうでもいいんですよ。了見がせこすぎて話にならない。
そんなことじゃなく、何かを興味深く感じ、何かを妄想して、自分だけ気付いた何かを世に出すために、必要なことは全部やる。
その過程で、成長してしまうこともある。でもそれはどうでもいいんです。
Replying to
むしろ、現行の「高い」IT人材を、より安いひとでリプレースしようという動きになっているんじゃなかろうか。
現行側のひとは、憤慨するばかりでなくよく考えた方がいいと思うよ。みなさんは、みなさんと、プログラミングスクールでITをかじったひとの区別がつかない人々のために働いているのかも。
オブジェクト指向いらんとか、デザインパターンいらんとか、研究開発部門いらんとか、三角関数いらんとか、根は同じだ。
結局、近年、僕らが失ってきたのは、自分がよくわからないことに対峙する仕方だ。これはとても危険なことだ。世界とは、オレに分かることだけが起きる場所じゃないからねー。
我が国は、医療崩壊を防止するのではなく不可視化してるんですね。
Quote
CDB＠初書籍発売中！
@C4Dbeginner
これ、明らかに日本の政策としてやってると思うんですけど、病院の廊下に担架の患者が溢れるような『絵』を作らせない、報道に撮らせない政策なんですよね。一人一人を自宅に隔離すれば、そこで容態が急変しようが苦しもうが家族に感染しようが、報道のカメラは撮ることができず、テレビにも映らない。 x.com/HironobuSUZUKI…
多くの企業が、ERPの大規模導入とかには数十億や100億を超えるカネをポンと出すのに、数百万とか数千万円のシステム化はケチる。小さなプロジェクトでうまく回せた経験のないひとたちが、いきなりそんな大プロジェクトをやったら、そりゃ失敗するわと、僕なんか思ってしまうんですけど、なんでなん。
Quote
杉本啓
@sugimoto_kei
DXしないIT化はダメだっていう人もいる。僕は、まずIT化すればいいと思う。その時、出来るだけシンプルにすればいいが、短期間で考えてやりきれるわけがない。ある程度で割り切ってIT化する。IT化してから徐々に進化させると、手作業時代とまったく違った仕事の世界ができる。それがDX。 x.com/sugimoto_kei/s…
↓これは最近痛感している。技術をまったく知らないマネジメントより、技術者上がりのマネジメントの方が、誤解の根が深い面がある。技術も作り方も大きく変化しているのだけど「本質は変わらない」と考える。その考えている「本質」には、本質でない要素が結構含まれているんだな。
このユーザーの方、スクリーンの右下、枠外がホームポジションになっていて、時々、画面外をリズミカルな助走のようにタップしていらっしゃる。UI機能としてデザインされていない要素が、操作の上で重要な位置を占めているように見える。興味深い。
Quote
鉄道会社は辞めるな君
@tetsudo_yameru
マルス端末の手捌きが職人芸。
ディスプレイを叩く音も心地良い。
ジョブズのiPhone発表のプレゼンを久しぶりに見たけれど、やはりすごい。非常に複雑な技術の結集のはずなんだけど、そう見えない。それを使えばユーザーは何ができるようになるのかを、シンプルな言葉で説明する。製品について語りながら、生活について、正確に言えば、生活の可能性について語ってる。
昔、業務システムを作る価値は、効率化や高速化にあると思っていた。今は、それらはむしろ副次的効果だと思っている。業務に係わる人々の間に新しい階梯の新しい調和を作り出すことが、システムエンジニアリングの主眼であるべきだ。そしてそれをするために、ドメインに働く諸力を理解する必要がある。
スタートアップのエンジニアリングマネージャーが組織作りの話ばかりしてるって、やはり変だと気づいた方がいいんじゃないか。弊社では、プロダクトとサービスの話ばかりしている。加えて、個々のひとと仕事のマッチングの話を時折するぐらいだ。
前から言っているけれど、日本人はひとりで行動するとすごく独創的なことをやらかすのに、集団になると牽制し合っておとなしく無難なことしかやらない。チームワークがヘタクソなんだと思っている。
なのに組織論とか好きなんだから、自分のこと分かってないんだ。
緊急ではないけれど重要な仕事をちゃんと片づけていけば、緊急な仕事は次第に減ってくる。緊急な仕事が無い時にぼぉーっとして、重要な仕事をしないから、いつまでたっても緊急案件に追い立てられる。
僕はこれを、非常事態ドリブンな仕事スタイル、と呼んでいる。
きれいに書かれたコードでも読めない場合はある。僕は遺伝子解析ソフトのコードはたぶん読めない。それはドメイン知識がないから。また、大きな会計ソフトのコードも読めないかもしれない。そのソフトの全体構造に関する知識がないから。コードが読めない理由は単純ではないよね。
最近のプログラマーって、新しい言語やフレームワークはどんどん使いたがるのに、ビット演算程度の基礎技術は敬遠するんですかね。わけわからないですね。いずれも、価値が出せるなら使うし、出せないなら手を出さない、ということかと思うんですが。
弊社に応募するひとで、弊社製品をダウンロードして触ってみたとか、事業ドメイン（経営管理）の本を読んでみましたとか、ほぼいない。僕が転職するなら絶対することなんだけど。みんなそうなので、非難はしないが、不思議ではある。
ローコードツールって、テキスト形式のコードが減るってだけで、実質は、コードを書くし、コードを書く量が減る分、本質的な設計センスが浮き彫りになって、残酷なものだと思う。
技術に長けた人は、厳しい前提を置かない「汎用的」な仕組みを考えたがる傾向がある。実際には、必要とされる自由度の境界を見極めて、適切な前提を置くことが、設計において極めて重要。役に立たない自由度を提供しようとして、重く、遅く、込み入った使い方を強いるソフトウェアがたくさんある。
よくわかる。
自他境界が明瞭なら、他者の酷い批判も、なるほろそういう見方もあるか、面白いな、と吸収できて、創作に活かせる。
境界が不明瞭だと、他人の批判ひとことずつが容赦ない重さを持って自分の柔らかい内面をぐさぐさと刺す。これじゃ手も動かせない。
Quote
中島 智
@nakashima001
アーティストがやたら批判に強いのは頑なに拒絶しているからでも強がっているからでもない。他者認識に開かれているからである。その批判がその他者のもつどのような知覚や志向性に根ざしているのかを受け取るからで、だからそれはどんなカタチであれ、他者の反応として有り難く受け取れるわけである。