俺は東京生まれはてブ育ち、idコールするやつはだいたい友達

もう15年ぐらい前になっちゃうけど、僕ははてなブックマークに人生を変えてもらいました。

はてなでブログを作ったのは2006年

当時の私は、アイ・ティ・フロンティア(現タタ・コンサルタンシー・サービシズ)に勤めていて、Javaを書いていた。プログラミングのネタでググると当時ははてなダイアリーがHITしたのと、はてなグループにエンジニアでブログを書いているヒトが集うのがあったので、それに乗っかった格好。

はてブを知ったのが2007年

なんの記事か忘れたけど、3usersって書いてあるのが見えた。ナニコレって思ってクリックして、ブックマークページに飛んだ。ほーん、こんなブログを読んでブックマークするヒトがおるんか〜で、終わり。

ホッテントリデビューが2007年

これです！朝起きたら見たことない数字になってびっくりしたのを覚えてる。

gothedistance.hatenadiary.jp

内容はすいません、不正確な記述が多いです。SIerの中の人がSIerについて語るポジションが、2007年は僕ぐらいじゃなかったかな。勤めていて感じてたSIerおもんねーわと、ゴタゴタうるせーなお前らじゃあプライムで請けてみろやっていうプライドが、絶妙にブレンドされていた時期です。そのモヤモヤがそのままブログに向かった格好です！

中二病（背伸びした言動や自己顕示欲、劣等感の入り混じった態度）でブログを書いていたのが、2007〜2009年ぐらいでした。プログラミング、当時は全然できなくて。ネットで仲良くなった友人はみんなプログラミングがすごいできるのに。簡単なTwitterAPIを叩くコードすら書けなくて、読めなかったのが、2008年頃です。

プログラミングがろくすっぽできないCOMPLEXがバネになって、筆が進んだ気もする。読んでもらうことが癒しになった部分もあったし、「ほれ、ワイが一筆くれたらこんなもんよ」的な気持ちもあった。なんで読んでもらえたのかはマジでわからん。本人はよくわかっていない。

ブコメと向き合う難しさ

ブログを書く→ホッテントリに入る→あーでもないこーでもない言われる→追記する→あーでもないこーでもない→俺は一体なんのためにこんなことしてんのよ（でもブログは書きたい）

こういう時期が2008〜10年ぐらいでした。別にお前のためにやってんじゃねーよで1ヶ月ぐらいブログを閉じたこともありました。2009〜10年は最も僕の人生で色んな問題が重なった時期なので、ちょっと精神的に追い込まれてた。

ホッテントリに入ったり、今だとXでバズったり（燃えたり）すると、不特定多数から銃をぶっ放される感覚になります。自分の文章に数十人が批評しているのを眼の前にするよ、どっか狂ってしまう。純粋な内容の指摘はスルーして、イチャモンに近いものばかり目につく。言葉選ばずに言うと、ゴキブリ。別に実害はない、お前はお前俺は俺で生きてるよな、でも存在を確認しちゃうと、もうダメ。汚物じゃんっていう。そういう気持ちを抱く自分へもやり場がないし、あったことのないやつに届く言葉もねぇ。そう思っちゃいかんのだが、飛び込んでくる感覚なので、ブロックできない。バランスを取るしか無い。

僕が伝えようとしてることをそのまま受け取る人もいるし、違和感を感じる人もいる。それはコントロールできん。違和感を表明してくれて「俺もそれ、気になってた。スッキリ」というコメントが人気あるのを見ていくうちに、解釈違いで思い悩むのは無駄だと思って、だいぶ楽になった。「多分今頃そいつパフェとか食ってるよ」っていうタイトルの本がありますが、感覚はそれと同じです。

Top Hatenar、覚えますか？

スマートニュースの浜本さんが作ったプライベートプロジェクトじゃなかったかな。これも結構意識しちゃった（笑）

芸風が固まってくると、記事を書くのも速くなったし、「僕がいいたいのこれ」「ツッコミどころはこれ」「解釈が分かれるのはココ」って自動的に整理ができた。このネタはこう味付けしたら伸びそうだな、みたいなのも感覚でわかる。ポエムなら違和感がわかりやすいものほど、伸びる傾向にあります。「それ、なんなん？」って拡散されやすい。また、箇条書きTipsネタ、本の紹介、XXのまとめみたいのは比較的ブクマされやすいので、ゲーム感覚で被ブクマを積み重ねていた時期もあった。

そうは言っても、ふろむださんには勝てない。王の帰還をみんな待ってるから(笑）独特の雰囲気がある。

はてぶで得たもの

大きく2つ。

１つは、ファシリテーターとしてのレベルアップ。記事を読んで頂きブコメやSNSの反応で気になるポイントを色んな方がシェアしてくれるので、「これはこれ、それはそれ」と議論の方向性を自然と整理できるようになり、1対Nの議論をまとめるのが得意になりました。自分の主張を通して人を動かすのが得意になったし、通せないヒトを助けることもできるようになった。

２つは、色んな人と出会い！これに尽きるよ！このブログを通じて会えたヒトは、100人はくだらない。334まではいかないが、会えたヒトは200人ぐらいおるんちゃうか。334目指したい。はてぶで僕を見つけてもらって、人生を切り開く大きなきっかけになった。自分を知ってもらうのは、もちろんリスクもあるだろうけど、メリットのほうが大きかった。

はてブを使う側の記事が多いと思うので、ブクマされる側の体験を記事にしました。

はてなブックマーク20年おめでとうございます！

2006年なので、18(9)年ですか。成人しちゃったね。辞める理由もないので、今後もやっていきます。

今見たら累計「47231」被ブクマでした。次は50,000を目指して、はてなでブログを書きます！

BIG LOVE.

（⇑ この上に「わたしのはてなブックマーク」にまつわるエピソードを書いて投稿してください）

はてなブックマーク20周年記念 特別お題キャンペーン ＃わたしのはてなブックマーク

by はてなブックマーク20周年

生成AI(Claude Code)がエンジニアリングの何を変えるのか

Anthorpicが世に送り出した「Claude Code」に、脳内を震度７でかき回されました。

Devinが出始めた頃は、「お！ええやん！これから楽しみだな！」ぐらいのテンションでした。無邪気ですよね。でも、Claude Codeは「マジかよ・・・（言葉にできない感情)」になりました。人間がコードを書く時代は終わったと頭では思っていても、どこかで「ふーん」ってシニカルでいた自分が、「・・・はい！」と向き合うことができた。

僕のまわりのベテランが腕まくりしてる

40代の友人知人が、Claude Codeでプログラミングに脳汁が出まくっている様子がSNSやリアルで散見されます。自分が今まで手を付けなかった部分の学習をしたり、今まで書いたコードを書き直してもらって「おっほ〜」をキメたり、並行で走らせてペアプロやIssue潰しをやってるようです。

僕が試しているのは以下のちょっとしたトライです。こんな感じ。結果には満足しています。

• 「この指示でどこまで行けんの？」
• 「これとそれのサンプルコードとテスト書いて」
• 「このコードを純粋関数でリファクタリングして欲しい。」
• 「ここにあるコード読み解いて、サマリをまとめて、型の設計について教えて」

僕の能力を超えたAIがコミュニケーションを取ってくれるので、乾いたスポンジに水がグングン染み込んでる感覚を、45になった自分が得られるのが嬉しい。自分の能力の限界を超えてコードを読み解いてくれるので、刺激になります。

適切に設計されていれば実装スキルは新卒程度でよい

この指摘は正しいです。僕も賛同します。

触ってみて感じたのは、「適切に設計されていれば必要な実装スキルは新卒程度でよい」「規模が大きくなると実装の手数が線形以上に増えるので短期間で手数を多く打てる体力が生産性にめっちゃ効く」ということであり、逆に言うと「実装スキルなんてものは人間が思ってるほど重要じゃない」ってこと https://t.co/MyTns0c2BR

— まんじまる (@_manji0) 2025年6月18日

自分はFlutterを1から覚えリードを経て足掛け3年ほどやりましたが、上記の通りです。

簡単に言うと、UIを構築するコード自体に、大きな差は出ません。Text("hello world") レベルのコードに差はありません。何かを表示する「だけ」のコードに、ベテランの匠の技は必須ではありません。いくつかのお作法と、プロジェクトのルールが有るぐらい。

差が出るのは、Flutterがどういう課題感を持ってアプリ開発をしたいと考えているのか、設計思想、状態の管理、ScreenとComponentの分割、エラーハンドリング、APIクライアント、ルーティング、デザインのテーマ / コンポーネント化などです。アーキテクチャで大きな差は出ない。

これらの設計（決め事）によって各々のUIを実装するコードは均一化され、単純化されます。コンテキストが煮詰まって、ノウハウに結実します。ノウハウが結実したら、単純な作業になって然るべき。クラスとオブジェクトの違いがわかり、無名関数でイベントハンドラが書けるぐらいで、受入可能でした。

上記の設計も踏まえて実装ではありますけど、誰が書いても変わらない部分と、誰かが手を入れて決め事を用意しないと破綻する部分があるはずです。前者の領域が生成AIによって拡大します。ここは、疑う余地を感じなかったです。後者の領域は、個別最適なのでまだまだ残ります。

あと、生成AI時代でコードが捨てやすくなったと思う！これが大きいんじゃないかな。コードはどんどん捨てるべき。リファクタリングはコードを捨てて作り直すことで新陳代謝を促す行いだと思っていて、形式的な置換をするのはあんまり意味がない。どうせAIで作り直す前提に立てば、すべきことはテスタビリティの確保・改善だと思います。常識が生成AI側でアップデートされるので、人類はそれに乗るだけになっちゃうかも。

そうは問屋が卸さないぞ！

待ってました、この種のご指摘。

この話、何十年か前に同じことを言ってたんですよ。「適切に設計がされていればプログラマは外注や下請けでもいい」とかそういうやつ。
その結果どうなったかと言うと、という。 https://t.co/reOKVua6Ci

— Yuta SAWA (@sawawww) 2025年6月18日

僕も下請けに出した立場も下請けも両方SIer時代に経験しました。テンプレ設計書で記載できる内容が弱すぎて、コードを書くまでに人間が様々な補完をしなければなりません。実装未経験のざっくり仕様書を出される、など。この種の工程の分断があっては、どうしようもない。

だけど、Claude Codeを初めとした生成AIには、工程の分断が起こりません。ヒトが介在する余地がないから。指示するのと作るのが同じ人間（チーム）のはずです。ざっくり仕様書からコードへの行間は存在しますが、行間を埋める能力は愚かな人類の比ではない。まだ黎明期。上がる一方で、下がる理由がありません。生成AIは工程の分断を殺すキラーアプリケーションになり得ますが、そこまで踏み切る決断ができるかは、別問題。

AIに指示を出すところを丸投げする多重下請け構造を生み出しちゃうかもしれなくて、それが令和の怪談になったらどうしよう。

AIによって普通のハードルが上がってしまう

これは「教育用途で渡すべきタスクをAIに投げたら秒で仕上げてきちゃうんで、若手の育成どうするの」と問題と、「生成AIが強くても、指示を出す自分が最大のボトルネックになり、試行錯誤の楽しみも薄れる / 逃げ場がない」問題の2つがあると思います。

後者は自分なりの立ち位置を掴むしか無い個人的な問題ですけど、前者は根が深い。生成AIが当たり前のプログラミング教育 is 何を、議論し始めないといけないと思います。

若手の育成機会のみならず、フリーランスエンジニアの副業も、減ります。副業のアウトプットがボトルネックで本業に支障が出るように座組を組む組織はないですから、調査・分析・リファクタ系のタスクを投げるケースが多いと思うんですけど、それらは生成AI(Claude Code)の大得意分野です。はじめの一歩の腰が重い優先度ちょい低め系のやつ、持っていかれます。

IaCは最もテンプレ化しやすい領域だと思いますが、そのIaC自体が正しいかは別物だろうし、監視も含めるとそんなに単純な気はしない。コードで運用が自動化できるわけじゃないし、複数の異なるサービスが絡むと思うので。IaC/SRE領域のニーズは生成AI時代も極めて堅調に僕には映る。見当違いだったらすいません。

Claude Codeのようなものが、文章・レポート・音楽・画像・動画・音声の領域に食い込んでくることは明白です。これは間違いないと思う！

月並みだけど、推進力がモノを言いそう

自分が一番得意なのは、↑に書いたようなあるお題を多面的に見て、言語化することです。僕のブログが少なからず読まれているの、コレしか無いと思うので・・・。

考えてもらうことは生成AIで行けるけど、考える意味は自分が言語化するしか無いっす。言語化して、その構造を整理してテーブルに乗せれば議論できる余地が生まれて、メリデメが整った選択肢が作れる。そこから判断と決断が生まれる。そういう目に見えない推進力を、自分は大事にしたい。事実と理想の狭間には、相当深い谷がありますから。

月並みだけど、ソフトスキルもハードスキルも、磨いていくしかないですね。AIと壁打ちしながら、自分で一歩ずつ考えて、進みましょう。乗るしか無いんだから！このビックウェーブ！

「育つ」エンジニアが持っている、最も大事な適性

エンジニアの育成、時間がかかりますよね。つよつよになるには・・・みたいな話は、エンジニアクラスタのSNSで定期的に話題に上がるような気がします。

エンジニアの育成について考えたので、とりあえずアウトプットします。

エンジニア、覚えることが大杉

プログラミングは、基礎文法を覚えるだけなら1ヶ月で一通り学習できますが、仕事にする場合は基礎文法だけでは「全く」足りない。

• HTTPなどの通信規約・TCP/IPの仕組み
• Webサーバ構築などのインフラ・GCP/AWSなどのクラウドサービスへの理解
• GitHub Actionsに代表されるCI/CD
• 認証認可の仕組み(鍵認証/JWT/OAuthなど)
• Webアプリのセキュリティ対策
• HTML/CSS/Reactなどのフロントエンド
• フレームワークなどのライブラリの理解
• SQL/DBなどのデータベースに関する理解
• アプリやるならiOS/Androidのビルドシステム、Flutterの理解
• コードを読み解く技術
• テストコードの書き方・テスト設計に対する理解
• 特定のアルゴリズムへの理解(LLMの仕組みとか)
• 要件定義やプロジェクト立ち上げなどの立ち回り方

( ﾟ∀ﾟ) ｱﾊﾊﾊﾊﾉヽﾉヽﾉ ＼ / ＼ / ＼

書きあげて、改めてとんでもないって思いました。陸上競技の十種競技みたい。全部精通するのは無理だけど、得意分野は持たないと認めてもらえない世界だと思われる。

勝手に育つしか答えがないのか

結論から言えば、YES。きっかけは与えられるけど、そのきっかけをモノにできるかは、自分次第なので。

ジュニア層は等幅で成長するのではなく、飛躍するもんだと思ってます。1.0 -> 1.1 -> 1.2 で1歩ずつではなく、1.0................1.3!!! って感じ。

なんでかって言うと、手を動かした内容が整理して抽象化できて、自分の言葉で説明ができるようになるのに、じっくりコトコト煮込む時間が必要だから。自分の言葉で説明できるようになるには、具体と抽象を行き来しないといけない。相当時間かかる。

課題や知識も与えられるけど、具体と抽象を行き来できる思考回路の構築は、変わることができない。

300時間程度では漢字書き取りドリルをやっただけ

ゼロベースでプログラミングスクール等で基礎文法覚えて、WordPress入れて動かした/Rails入れてTodo作ったっていうのが、300時間ぐらいではないかと思われる。1日3時間で100日だから、3ヶ月。プログラミングスクールの受講期間は「3ヶ月間」が最多【調査レポート】 | Textradeのプレスリリースとも合致するし、スクールだとこれぐらいの期間で結果出るって謳わないと、続けてもらえなさそう。

不都合な真実で恐縮ですが、この状態は漢字書き取りドリルをこなしただけ。文章が書けるわけじゃない。漢字と語彙は全く別で、300時間ではコードを書くための語彙が圧倒的に足りていないと思う。

WordPressが他のWebアプリのライブラリに変わった瞬間、漢字は書けても語彙が無いから、コードで書かれている内容の意味がわからなくなります。語彙力をつけるには時間が必要。具体と抽象の行き来ができる回路の構築に時間がかかります。

自分の体感では、1000時間。1000時間やってみて、これ以上「わかりたい」と思えなかったら、そこで立ち止まって考えたらいいと思う。

フルリモで育成を行うのは極めて困難

技術者教育について | さにあらずで太一が書いたように、リモートで素人やジュニアを育てるのは極めて難しい。「自分がどれだけノウハウが足りていないのか」を言語化できないから。

• 何がわからないのか、わからない。
• 進め方が間違っていることすら、気付けるわけがない。
• 調べたところで正しい情報をつかめるわけがない。

仕事で育成する以上は費やした時間の密度が求められるので、リモートを望むのは無理がある。

来年の春頃から育成前提の採用を行う予定で、カリキュラムなどを作る準備を始めています。でも、フルリモでやりきれる自信がまったくわかない。

リモートでも育成されている会社さんもあると思うので、「やり方はなんぼでもありますわ！」っていう叱咤激励の記事、伏してお待ち申し上げております。

ストイックさが感じられるか

贅沢言うなって言われそうだけど、僕が未経験やジュニアのエンジニアに求めるのは、前述した「具体と抽象を行き来する思考回路」を組み上げる工程に時間がかかることを知ったうえで、時には寝る時間を削ってコードを書くのも厭わない姿勢と踏ん張ってみようとしてくれるか。「このままでは終われんぞ！」っていう気持ちが、少しでも持てるかどうか。

一言で言えば、「もっとわかりたい」と思えるストイックさがあるかどうか。それが全くないなら、この領域は向いてない。この一コマがすごい好きです。

(湾岸MIDNIGHT. 第29巻より引用）

別の領域で同様のストイックさをもてることはあるので、そちらの適性があるってだけ。それに気づけるのだけでも、良かったと思います。

プログラミング、逃げ場がない

ソフトウェア開発は、逃げ場のない仕事だと思います。誰のせいにもできないですから、自分のコードが動かないのは。会社のせい！顧客のせい！同僚のせい！それはできない！書いたのは自分！

自分のスキルはどんどん陳腐化するので、アップデートする必要がある。自分自身でアップデートしていける基礎体力と思考回路がどうしても必要。思考回路が未成熟なら歩みが止まる。そのため、ストイックに自分で自分をアップデートする情熱が必要になる。

20年前に私が新人だった時代は書籍とコミュニティが大きな助けとなった。本代はケチるなと教えてもらったので、毎月数千円の本を何冊も買った。1行でも気づきがあれば、余裕で元は取れる。

コミュニティ、今はどうなんだろう。java-ja黎明期のテンションのコミュニティ、もう作れないのかも。時代が変わったし。でも、外に同士を求めるのは、とても正しい。仲間がほしいなら自分のことを知ってもらう努力が必要で、それは初心者であることを恐れずに自分をWeb上でアウトプットする必要がある。境遇が近い人を惹きつけないと。

懐かしい言葉を言う時が来たか・・・！自嘲はダークサイドだ！

昔は自重だったんだが、これは自分を重んじて良くない行動を慎むという意味らしいから、誤用していた。

自嘲は要らんねん。自分を必要以上に過小評価することは、あなたを認めてくれている人にとっても失礼だよって話 - そーだいなるらくがき帳で、そーだいさんも言ってたように。

未経験・ジュニアエンジニアの方、応援します

この仕事選んで良かったわーって人が1人でも多いほうがいい。教わる側・教える側で色々お話したいなと思いますので、お気軽にどうぞ。https://twitter.com/gothedistanceです。DM解放してます。

Wish You Have a Happy Merry Xmas and your New Year of peace and happiness!!

今年も本ブログをありがとうございましたー！

ウォーターフォールの悪魔化とアジャイルの神格化、もうええでしょう

毎年必ずどこかでウォーターフォールとアジャイルを対立させ「ウォーターフォールwwwww」と味付けしたツイートに待ってましたと総ツッコミが入るムーブがあるように思います。

今シーズンは下記のツイートがK点超えの大ジャンプを記録しました。

今どきウオーターフォール型開発とアジャイル開発の違いをどうこう言う必要はないかと思うが、若手の技術者は間違ってもウオーターフォール型開発のほうに行ってはダメだぞ。失敗は絶対に許されないと連呼する世界と、とっとと失敗しようぜと言う世界では、どちらが成長できるかは明らか。 https://x.com/toukatsujin/status/1863023816290762841

Xでは多方面から「いやいやいやいや、どんな世界線ですかそれ？！」と突っ込みが入った。失敗の許容度がゼロか100かってなんぞ？っていう感じ。そらそうよ。

これを受けて木村氏は「批判の中で呆れたのは、開発手法の話と取り違えた人が多すぎることだ。私のツイートは間違ってないし、そんなことを言ってるのではない」と第2ラウンドの鐘を鳴らされた。以下の記事になる。

最も重要なのは「とっとと失敗しようぜ」、アジャイル開発は人月商売の毒が回ったか | 日経クロステック（xTECH）

残念ながら、無料会員登録が必要だ。

私は心に刃を当て、無料会員登録という荒行を成し遂げ、ご高説を承りました。

その私が言う。読む必要はない。

雑にまとめた木村氏の主張

アペリティフにどうぞ。

ウォーターフォールが絶対に失敗するな、アジャイルがとっとと失敗しよう。その真意は以下にある。

開発手法の話ではなく、失敗を恐れずチャレンジし続けるマインドがあるかないか、それをビジネスモデルとして是としているかの違い。クラウドの上に自社プロダクトを開発して挑戦する会社は、新しいマーケットを開拓するために「とっとと失敗」して、正しく高速に新しいチャレンジをしている。アジャイルの骨子はここにあり、それを具現化したシンボルとして最たるものが、GAFAMに代表されるBig Techだ。

ウォーターフォールは工程の逆流が許されない。なぜなら、悪の組織ITベンダーは上意下達を前提に下請けに流す多重下請け構造を敷いており、そのために完璧な仕様が前提となるからだ。完璧な仕様、それはお客様の要望を全て取り入れたもの(御用聞き）。下請けの会社に入ったら、与えられた仕様に基づいて、なんのチャレンジもなく仕様を変えることもできず御用聞きのコードを書くようになる。私がそうだった。なにもいいことはなかろう。

そのような組織文化・マインドの違いについて論じているのに、開発手法が良い悪いを言っても意味がない。ウォーターフォール型がダメなのは論ずるまでもない、それぐらいわかれ〜

こんな感じ。

あ、そう・・・

古いネタで恐縮ですが、心の中のエリカ様が「別に・・・」って。生産的な教訓が何も無い。しょうもないITベンダーに就職したらすぐ逃げろはわかるけど、ウォーターフォールとアジャイルの理解は深まらない。

マインドを持ち出すから生産的な話にならない。ウォーターフォールとアジャイルとは開発方法論だと思いますよ。あくまでも。応用は効くかもしれないけど。

ウォーターフォールとアジャイルの対比に感じた「ボタンの掛け違い」を、自分なりに整理しました。メインディッシュをご賞味ください。

ウォーターフォール＝多重下請けの悲哀？

PDCAの「C」はリリースした機能を使うことで検証しないと意味が薄いのは、ウォーターフォールもアジャイルもない。水に砂糖を入れたら甘くなるぐらい自明。

そんな自明なこともできない多重下請け構造は何やねんって話は、工程の分断によるビジネスモデルの悲哀。ウォーターフォール＝多重下請けにすり替わってる気がする。ビジネスモデルの話とソフトウェア開発の方法論がぶつかるから、水掛け論に終わるように感じた。

人月という単位ほどわかりやすいものはないし、一人が一人以上稼ぐことはできないが損することもないので、合理性はあるんだよな・・・。プロダクトやサービスに昇華できない会社がうんちって断罪するのも、生産的な教訓がゼロ。

あるいは、ウォーターフォール＝一括請負？

一括請負＝ウォーターフォールなのかもしれない。お互い不幸だと。使ってみないとわからんから、と。納品のない受託開発やればいいじゃない、と。チーム貸しの契約で御社専用のITラボどうっすかのほうがええでしょう、と。

だがしかし、エンジニアをレンタルするという考えに至らない会社も多くあるように思われ、その場合は成果物責任を問えない契約は飲めませんという考えも、根強く残っていると思う。責任追わせられるの重要ですからね、発注する側は。開発◯万円・運用△万円で丸投げできる契約、求められません？現実はキビシー。

注文住宅の工事に入ってから、やっぱり住みづらいんで図面引き直せ。これはあり得ないんで勘弁してくれって話、至極全う。意味がわかりません。行間の誤解は双方にあるし、難しいよねその綱引き。その綱引き、もうええでしょうと申された！わかりみ！

ただ「これ合意したけど、そもそも仕事回んねーわ」っていう状況までこじれたら、我々IT側の運営責任も問われて然るべき。こんな状況になった免罪符にアジャイルを持ち出すやつはいねーよなぁ？！？！

僕のまわりだけかもですが、求められるのよ、請負。特に受託開発のようなオーダーメイド商品は。ウチも（求められて納められると判断したら）直で請負でやっています。高度な綱渡りを自分のリスクでやる変態がいてもええでしょう。頼むわ。

単純にPDCAの回し方の違い？ほんま？

アジャイルが機能単位で「P→D→C→A」を細かく回すとしたら、ウォーターフォールは全機能を対象に「PPPPP→DDDDD→CCCCC→→AAAAA」を回す前提になってる気がする。ほんまかいな？ 請負・委任関係なく、フェーズを切って設計してリリースすれば、進め方としては同質だと思われる。受託者と発注者のリスク配分の問題だけにも見える。

工程の逆流が起こってしまうと大変なことになるので、それを防ぐ方法は細かくリリースして軌道修正しましょう。だって全機能を一気に実装して調整できなかったら死ぬから、と。ただ、ウォーターフォールでアジャイル的な進め方が可能と考えると、両者を区別できる判断軸を僕はほぼ失った。識者の意見を頂戴したい。自分の理解が浅いのだと思う。

企業にITが根付く温度差、千差万別

納品のない受託開発やITラボ型開発を提案されて「いいっすね〜」となる会社は、かなりDXが進んでらっしゃると思う。これらのビジネスって、一言で言えば内製化支援。

今使っているソフトウェアやSaaSなどでちゃんとビジネスが回り、そこから継続的な改革が必要で自分たちで舵取りする合意が取れ、請け負うとかじゃなくてプロが助産してくれる環境がベスト。そういう意思決定だと勝手に推測する。「ビジネスを支えるITを内製して育てるための支援」という王道、素晴らしい。両手を上げて賛同します。アジャイルだぜ。

ITでビジネスを変えられる所に至ってない会社も当然多くある。エンジニアを雇用する意味を見いだせないので、ソフトウェアを調達する。その考えがあかん、と。発注者が勉強して賢くなれ、ITを根付かせる努力をせよ。仰るとおり。でも、どうやって？ 開発方法論に答えはないように思う。

ウォーターフォールやアジャイルという話で、企業のビジョンや組織文化などのソフトな話にどう影響を与え、事業会社にITを根付かせる一助になるのか。ビジョンや組織構造に目を向けるなら、そういう立ち位置で意見交換をしたいものだ。

仕様を調整する力がないなら、デスジャイル

本記事を書くのにアジャイル、ウォーターフォール、プロジェクトなどでツイート検索した。一定のボリュームがあったのが「きちんとウォーターフォールを経験したほうがいい」的なもの。その背景は、以下のようなものだと推察する。

何かの機能を実装する時に、ライブラリを入れてなんとなく動かすところから始める。ライブラリの背景やポリシーは理解せずに。DeepLinkやりたいって言われたんで脳死でFirebase Dynamic Link入れた、みたいな。

選定した理由が要件(制約)から逆算して詰めた結果じゃないから、応用が効かない。ひどい場合だと、テストケースをまともに作れない。コードを書いて動かすだけなら(AIが助けてくれるのもあるよね)、できちゃう。動きはするけど、自分で要望→要求→要件→設計→実装→検証→リリース→運用改善みたいな一連の流れを経験してないから、仕様を調整すべきというアンテナが育たないのかも。そういう、"ジュニア++フリーランス"に痛い目を見た話が昇華して、ウォーターフォールを経験せよにつながっているっぽい。

仕様を調整する力がないアジャイルは、デスジャイルだろ。北斗の拳の究極版読んでて、降りてきた。あべしジャイル→デスジャイル。冗談は置いといて、仕様の調整が機能しないスプリントが何本も走ったら負債一直線では・・・

先に要件ガチで詰めて調整しても死ぬときは死ぬ。ウォーターフォールとアジャイルどっちやねん以前の問題で、乱暴だけど「即死とゆるやかな死、どっちがいい？」という悲しい結末が。即死のほうが傷が浅いケースもあるからなぁ。

こちらが締めのデザートになります。

目の前のお仕事に向き合おう

ウォーターフォールの悪魔化とアジャイルの神格化、もうええでしょう。ウォーターフォールが日本的商慣習とくっついて悪魔化された一種の怪談、ネタで楽しむにしても、もうええでしょ！

目の前にある仕事、それが今のあなたの仕事の全て。僕もそう。

「このままやり続けて良いのだろうか」的な疑問もわいて来るはず。開発方法論やビジネスモデルの狭間に落ちて、うまくいかなくて、つまづくこともあるでしょう。思うようにはいかん。そこで止まらないこと。生まれて来た疑問を考えるのが、次の「目の前のお仕事」になる。それを片付けたら、質の違う課題が出てくる。そんなもん。

はい、この話はもうおしまい！明日からプロ野球のストーブリーグの話に戻るよ！

"それ、おかしくね？"をリリースしよう

いい言葉だなと思って。

組織が抱える過度な忖度文化の解消をゴールとした、中長期伴走プログラムです。社内ヒアリングの結果から、定点的なギャルによるメンタリングの実施やギャルを交えたMTGを実施します。 CGOドットコム [CGO.com] 公式サイト | ギャル式ブレストであらゆる組織・人々にギャルマインドを

今年から取り組んでいたネイティブ→Flutterアプリのリプレースのリードが落ち着いたんで、段々と上流の方に登って横串通す立場に片足を突っ込みつつ、他の会社のマネジメントレイヤーにいる人たちと意見交換してるんですが、どこもかしこも"組織が抱える過度な忖度文化"の香りがしてて。

自分の経験に基づいて感じる「なんか、おかしくね？」っていう大切な気づきを、言葉として表現に落としてリリース出来ていないという言葉でいいのかな。

「なんか、おかしくね？」ってすごい大事なサインだけど、その違和感を恐れずに出せる人って、あんまりいないみたい。

違和感を表現するって、難しいことなんだろう。「はい」っていうの簡単。飲み込めば良いから。悪いことに、何も良いことがないけど。自分がうまく飲み込めない違和感をリリースしないと、「そういう考え方もあるんだ」という発見に繋がらないし、色んな考えを元に良いリスクの取り方が覚えられないように思う。うーん、もったいない。

個々は優秀なプレイヤーが集まったとしても全然結果が出ないとしたら、"過剰な忖度"が後ろにあるんじゃないかなぁ。過剰な忖度で推し量ってるのは相手の心情じゃなくて、余計なことをして望まない変化を生み出したくないっていう「事なかれ」なのでは。事が起こらないプロジェクトがあるわけないっしょ〜。

ほんと、つまんない話だよね。

正しいことを正しくやろうって言うと総論賛成だけど、正しいことを正しくやるために大変な思いをしようっていうと、誰もやらないよねｗ そういう状況ってイケてない状況を作り出したことで落っこちたボールがあってさ、これがまたずしーーんと重いコトが多いのよ。それをさばける地力がないと重さに潰れちゃうから、アサインする立場の人はそういう忖度はしてね。正しい忖度だから。

自分の違和感をぶつけるってどこかしら批判的な言葉になる。ぶつける相手がさ、役職が上とか会社の立場が違うとさ、「やぶ蛇」ってやつが顔を出す。そんなこと言ってもね！（自分が損するだけで）意味が無いよね！っていう。正しいこと言うてもそうならないでしょ、この会社みたいな。ボトムアップで何かを変えてくれるとも思えんわ、的な。誰もが通る道。

でも、おかしいと思ったことはおかしいって言えない職場で働くの、無理じゃないですか？ それが言えれば苦労はしないってのもあると思うけど、飲み込んでも苦労するし、吐き出しても苦労するよ。残念なことに。飲み込むにしてもそのままじゃ飲めないから、何かで流し込むとすると、心はざわついたまま。どっちに転んでも何かしらの苦労はあるんだから、恐れずにリリースしたほうが良いって。そしたら、何かしら次が見えるでしょ。終わりの始まりだとしても、新しい何かが始められる。飲み込んだら袋小路。

おかしいものはおかしいし、筋が通らないものをそのまま通しても、つまんない。時限爆弾みたいなもので、ミスであったり何かしらの不都合という形で黒ひげ危機一発でドーン、よ。たまたまナイフを刺す役目に回っちゃったら、ねぇ？ 辞めてさ、「ざまあみやがれぇ！」で終わらせたい気持ちもわかるけどさ、その後に入ってグダグダな状況からリードする僕にも忖度してよｗ

しわ寄せが来るのはあなたのせいじゃないから巻き取る意味は無いかもしれない。残念だけど、どうせ次でも「それ、おかしくね？」と向き合う時は "絶対" 来る。自分のためにも、自分の経験に基づいた考えをキチンとリリースしようよ。つまんないでしょ、そういうのが言い合えないところで働いても。

20代は「なんでやねん！おかしいやろ！ボケカス！」っていう反発心が強かったけど、40代になってから「・・・つまんねぇ話だな〜どんだけだよ〜」という反発心に変わってきたような気がする。

When the world gets in my face I say, "Have a nice day!"

Have A Nice Day!

ひとり会社の起業について学んだ10のこと

note.com

僕の間違いじゃなければ、時々はてなのブログでコメントを頂いた方のように思う。Python関係で。大変お世話になりました！

法人の設立にあたっての事務処理と、会社運営のお気持ち編を、自分の体験からまとめてみます。2016年6月にノリ（そうだ独立しよう）だけで起業して7年ほどひとり。今は2人体制になった。

会社を大きくする方法はなんもわからんので、そういう内容を期待される方はすいません！沿わないと思う！

1. 決算処理は専門家に任せたほうが良い

自分は前職の会計事務所でお世話になったため、起業当初から会計事務所を利用させてもらっている。年間30万弱。決算処理込み。

6月1日に創業したけど、タイミング的に6月になっただけで、深い意味はなかった。会計事務所的に3末はGW進行と重なるので避けたほうがいいかも。

決算処理は確認しないといけない事項が多すぎて、素人がいくら確認しても漏れるもんは漏れる、間違えるもんは間違える。別表を作るのは仕訳を打つより大変。会計事務所にやってもらったほうがいい。

なので、税理士でも会計士でもよいが、何かしらお世話になりましょう。

2. 社保引き落とし対応してるネットバンクがコスパよし

ネットバンクの多くは、社保の口座引き落としに対応していません。自動引き落としに対応していない場合、自分でPayEasy経由でATMで振込をしないといけない。

イオン銀行とGMOあおぞらネット銀行の2社は、対応しています。私はUFJがメインバンクでしたけど、2024年度からはGMOあおぞらネット銀行に切り替えました。

ただ、GMOあおぞらネット銀行さんが管理画面ログイン初手で、年利14%の創業支援ローンのダイアログを強めに出してきたことに、下品じゃねって思ってる。それ以外は特に文句はないｗ

カードはAMEXにしました。ポイント還元率とANAマイル還元率がよく、補償の幅が広いため。月何百万も使うような規模じゃないし。

3. 節税に魔法はない

法人税で取られるか個人の所得や年金で取られるかの2択で、どう転んでも刈り取られる。基本は個人に還元です。年金受給額にも影響があるし。

小規模企業共済（積んだら所得税から控除される）、倒産防（損金扱いになる）はおすすめ。保険（主に社長の生命保険）はあんまり節税にならない印象。

手当も考えたけど課税対象なのが多い。家賃補助も課税される（給与の一部とみなされる）ので旨味が少ない。非課税なのは交通費と出張手当ぐらい。出張いかねー。電車のらねー（リモートだから）

事前確定届出給与も、支給額に応じて所得税は発生する。とりあえず出します宣言だけして、業績がよかったら出すようにすれば良い。出せなかったらそれまで。誰も罪に問われません。

節税に魔法はないけれども、森羅万象此経費でもある。ほとんどの費用は経費になりえます。遠慮せず！経費として計上していきましょう。何かしら、道はある。

4. 無担保で金利2%以内なら借入MAX

自分はコロナ禍で、金融公庫の融資を受けた。無担保で実質金利負担がないというすごい条件。引っ張らない理由がない。20年に申し込んで5年で組んだ。もうすぐ終わってしまうので、3倍界王拳でおかわりしたいけど、さすがにこの条件では無理だろう...

フリーキャッシュがあればあるほど、会社にいろんな選択肢が残る。選択肢を作る原材料は、余剰資金のみと言っても過言ではない。

1000万引っ張るとして、2％の負担だと60万。5年払いだと60ヶ月なので、60万だと毎月1万プラスして返済すれば良い。悪くない費用だと思っている。次は信金さんで組もうとしている。S信用金庫さん！頼むで！

5．助成金・補助金の情報は定期的にウオッチ

ひとり法人でも法人なので、助成金や補助金が受けられる資格を有することは往々にある。これだけ国からの支援があるとは知らずに驚いた。業績が昨年より悪化した場合、コロナ禍の影響もあって補助金を有する資格を得られることが多いので、業績が悪化した時は公的支援を要チェック。

ITの世界だと、IT導入補助金というのがあり、これが使えるかどうかはとても良く聞かれるんで導入業者にトライすべき！ウチも今年やるから！

６．ゼロ→イチは丸投げしてはいけない

自分が一切やったことがない物事は、絶対に丸投げしない。他人に作業を依頼する意味・自分のアウトプットの違いなど、振り返ることが一切できません。

自分はWeb開発が専門なので、WebマーケティングやWebデザイン、パンフレット等の作成などは専門外です。それでも、まずは自分でやってみる。マーケティングなら本を読んで見様見真似で広告を出す、デザインならWebテンプレ買ってハメ込むだけでもいいから、レイアウトを組んで実装する。パンフレットもFigmaでそれっぽいのを作ってみる。

自分でやってみれば、出来上がったプロの仕上がりとの差異が明確になって、「ほぇ〜」という気付きが得られる。ここがお金が取れるポイントなのかという、価値の引き出しも広がる。

７． 実力よりも高めの仕事しか来ない

仕事として受ける以上、絶対にできるなという勝算が高ければ高いほどよいのは間違いない。ITのような不定形な成果物を作る仕事は、特にそう。

ただ、色んな仕事をひとりでやってみて、殆どの場合は「近しいことをやったことはあるし、出来ない理由はないように見えるが、やってみないと全部できるかわからぬ」というケースが多い。

自分の中で『これくらいの力がついたら、これくらいの仕事をしよう』と思っても、その仕事は来ない。必ず実力よりも高めの仕事が来る。それは「チャンス」だから、絶対怯んじゃだめ。

ネットでよく見かけるタモさんのお言葉、貼っておきます。要出典。

できることと求められることの谷間が必ずあり、それはチャンスだと仰っている。谷間のない仕事なんてこねーってわかっていれば、谷間に対する橋の架け方を覚えていくのみ。

この谷間に出会うのが楽しいと言えば楽しいので、会社をやってるところはあります。時間は犠牲になる所は多いですけど。

８．仕事仲間 is 財産

同じ価値観を持っている仕事仲間の存在が、何よりも自分を助けてくれる。なので、自分も少しでも助けられるようになりたい。創業時からおかげさまでずっとお付き合いのある会社さんもあるけれど、ほどんとはプロジェクトの終わりであったり、担っていたロールが不要になる「卒業」に伴い、契約が終わる。

仕事が見つからないより仕事仲間が見つからないほうが、まずいと思っている。最初の会社の同期に教えてもらったブログというプラットフォームで、java-ja を始めとするコミュニティに出会えたのは僥倖としか言いようがない。

飯を食いに行ける仕事仲間が思い浮かばないと、ちょっとした相談もしにくくなるし、刺激ももらえなく or 与えられなくなるので、なんでこんなことをやっているのだ、悪い意味の「僕は僕であるために」に追い込まれてしまうかもしれない。

９．知っているかではなく、知られているか

人脈が大事なのは間違いない。ご紹介で私も生きている。会社としては微妙だが。

人脈というのは、自分が誰を知っているかでは無い。全然ない。名刺を交換した程度じゃ何にもならない。実際の所は、自分が他人に「この人はXXXの人だ」と知られているか。これが人脈の意味だと思われます。

自分が知られているから、つながりが持てるわけ。

知っているだけだと「綾瀬はるかを知ってます」というのと同じ。そりゃ向こうは著名人だもの、知ってるよね。でも、自分は綾瀬はるかと会ったこともないし、メシも一緒に食ったことがないので、連絡の取りようがない。

そのためには、良い意味で自己PRをしないといけない。自分はブログがきっかけだった。やっぱり本音を言わないとね、人は自分のことを面白い人だねって思ってくれないんじゃないかなと思っていて、なるべくフラットに本音を伝えるように、伝わるように、コミュニケーションを取れるよう努力しています。

10．成果は人ではなく設計によって生み出す

スキルと成果は比例しません。成果は、適切な権限と制約によって設計されるべきものです。ゴルフと同じです。最低限のショットが打てないとコース回れないけど、成果を出すにはコースマネジメントが必要ですよね。その設計する準備が整っていないなら、採用は時期尚早ではないかと思っています。業務委託の方に入ってもらうにしても。

ご本人の現在のスキル、与えられるべき権限と制約をどう設計するかを考えられるよう、努力しています。その中で、ここで仕事すると面白そうだな感じて頂ければ、嬉しい限り。もちろん、スタートアップでエンジニア誰もいなくてファーストペンギンになる人を採る時は別だけど。事業がないから。

よくある「自走できる人材募集！」みたいなやつ、あれで「よっしゃ！ワイは自走できるで！御社で働きたいなぁ！」って思う応募者がいらっしゃるのでしょうか・・・？ かなり疑問に思っています。即戦力が人手不足なのは当たり前。なんでワイがお前のために働かなあかんのよって思われて当然じゃないですかね。零細法人なら尚更です。

特に能力のある方ほどイニシアチブがあるかどうかを気にされます。イニシアチブ＝好き放題ではないので、その制約を考えないと、後で苦労するケースをチラホラ漏れ聞いております。人にまつわることは日々勉強でございます。

引用した記事の森本さんも書かれていましたが、法人としては1人でもチームは1人ではない。助け合える所は助け合うべきなんですけど、同種のエンジニアが集まってプロジェクト分担みたいなスキームを上手に組めたことがない。船頭多くして船山に登るになるから。これも今後の課題。

興味ある人でダラダラ話しましょう〜。X（旧Twitter）で適当によんでくーださい。

当事者意識を持てという言葉の向こう側

エモい資料が上がっていた。こういうのは大好きだ。一筆くれてやるしか無い。

speakerdeck.com

この資料のあるページに引用された岩田さんの以下の内容が、Xで色々出回っていた。

誰かのお役にたったり、
誰かがよろこんでくれたり、
お客さんがうれしいと思ったり、
それはなんでもいいんですが、
当事者になれるチャンスがあるのに
それを見過ごして
「手を出せば状況がよくできるし、
　なにかを足してあげられるけど、
　たいへんになるからやめておこう」
と当事者にならないままでいるのは
わたしは嫌いというか、
そうしないで生きてきたんです。
https://www.1101.com/president/iwata-index.html

知っててやらないのは、知らないよりタチが悪いかナ

知っててやらないは、知らないより悪い。当事者意識を最も単純に表現しているのはこの一文でしょう。私はそのように教わった。

手が出ないままだと塩漬けすることになる。改修が出来ないので、濃淡はあるにせよ組織のケイパビリティは下がるから、働きにくくなる。それが度を超えると人災を生み出す。もっとひどくなると、負の連鎖が巻き起こり大きな経営上の判断ミスが生まれて、倒産に向かうような気がする。誰が悪いんだろう。

何打でホールアウトできるかわからないゴルフ

ほとんどの組織運営上の問題は、放置しても倒産に直結するようなものではない。この問題を放置したらサービスが売れない・モノが売れないことに直結すれば対策が自明になるから、問題にならない。

対策が自明じゃないから問題になるように思う。例えると、何打でホールアウトできるかわからないゴルフ。「最終的に、どこまで」を手を出せば良くなるか、わかんない。未来から逆算して考えられるわけなくて、ピンが何ヤード先にあるかわかんねーけど、方向はあっちだからティーショットを打つ。そんな感覚。ゴルフは結局一人でやるしか無いので、それも似てる。キャディはドライバーに変わることはないから。

「手を出せば状況がよくできるし、なにかを足してあげられるけど、たいへんになるからやめておこう」という状況は、そういうものに見える。

やらないと出来ないことを、取り入れよう

当事者として逃げられぬ局面、多かれ少なかれあると思います。

そんな時に支えになるかもしれない、湾岸ミッドナイトの一コマをご紹介します。超一流のチューナーである、山本和彦の言葉。

これはいつもオレ自身に言い聞かせていることなんだが、
やらなければできないが大事なんだ。
でも人は知恵がつくと、「できるからやる」になるらしい。
それは結局、「できないことはやらない」だ。
それではその先の走りは引き出せない。
湾岸MIDNIGHT 第37巻

コンフォートゾーンなんて言葉使わなくても、これだけで表現されている。とてもいい言葉。やらなければできないことを行ってリスキリングしないと先細りするという示唆。

本を読んでも、できるようにならない。漢字は書き取らないと書けないのと一緒。それ以上でも以下でもないので、書き取れるものからトレースして、自分のやり方をどこかでつかめば。躊躇しないで。その結果としてハードワークになっちゃうかもしれないけど、甘受するしか無いかなーと思う。心理的安全性という言葉がコンフォートゾーンの免罪符になっているケースもある気がして、逆だろ逆って思う。そこから抜け出す為のものでしょう。

誰かと協調してやらないといけない、方針を決めないといけない。いきなりドンと渡されてもまず失敗する。だから、自分で片がつく範囲で、やらなければできないことをやる。そうすれば自分で見つけた何かが残る。見つけるに至った過程が、明文化は難しい経験値として。

自分で片がつく範囲で、やらなければできないことを片付けていくと、だんだんそれらがつながって、ゴルフじゃないけどコースの攻略法を自分の手数からはじき出せるようになる気がする。でかいIssueをひとりで倒せってではなく、でかいってわかってるなら細かくしろだし、細かくできるなら座組を組むために相談できる人を探せになる。そうやってアクションが取れる単位までに分解していけば良い。でも、やらなければできないアクションを取ったことがないと、それもできない。

組織のケイパビリティを左右する経験

この種の経験、フリーランスだと積みにくい。立場上与えられないと言うか。フリーランスを揶揄して「ワーカーとしての経験しかない」っていう話の向こう側は、組織のケイパビリティを左右するような意思決定を下してリードしたことがないのに、どうやって組織の中でバリューを出すのかという問いだと思ってます。そこにはステークホルダーという地雷原を歩いてどう捌くか、そういう明文化しにくい過程も入っている。私は初手がエンプラだったので、その種の議論をする同僚・先輩・上司・外注先がたくさんいあった。ペーペーから役員層まで全員と何かしら関わって仕事ができた。その時のコミュニケーションの節々が活きている。

社員と外注ではタッチできる情報や会議体に差がある。発注して頂いている組織の抱えている課題を共有できるような環境に、なかなかフリーランスの立場だとタッチさせてもらえない。求められていないことも多い。

そうはいっても、社員100%で構成されている現場って、絶滅しているような。人材斡旋ビジネスが盛んなITでは特に。社員が採れないし、採っても辞める。外注は契約がある限り辞めないので、調達して品質が良ければ困らないけど、プロパーがマネジメントして云々という話も。それでプロパーがやりがいを無くして辞めちゃう気もするけど。

組織のケイパビリティを左右する意思決定は、様々な所属先を含めたチームでやる時代になったと思う。最も必要なのはファシリテーター（旗振り役）かな。「手を出せば状況がよくできるし、なにかを足してあげられるけど、たいへんになるからやめておこう」とワルツを踊るための議論をファシリテートしたい。それが40代のワイの個人的テーマ。

問題意識を共有する会ってイベントを、何回かやった。そろそろ再開しないとな。

note.com

息を吐くようにブログを書いていたあの頃

「インターネット老人会 Advent Calendar 2023」12日目の記事です。

adventar.org

インターネットとの出会いは iBook G3と共に

自分のPCデビューは、1999年。当時仲の良かった友人で唯一ネットについて色々教えてくれたY山が、「だれもマカーがいねぇ」と呪詛を唱えるもんだから、何も考えずにMacを買った。これだ・・・懐かしい・・・！

最初のプロバイダーに選んだのは、AOLでした。マカーの友人が入ってた過疎ってる英会話サークルに自分も顔を出していて、プロバイダーを聞いたら「AOLがいいぞ、チャットで外人とお話できて面白いぞ」と聞いた。やってみた。タイピングが遅すぎて、helloしか打てんことに嫌気が差した。brbだけは覚えた。実際問題、何を聞いて良いかもわからんしうまいこと話せねぇわ！たまに夢に出てくる。

次の思い出は「ご近所さんをさがせ！」というサービスに登録して、麻雀友達が当時できたこと。自分は当時20歳そこそこだったけど、30歳近いT桑さん。ギターと麻雀というキーワードがあって、家がアホほど近かった。卒業しちゃったら全然会わなくなってしまった。

www.gokinjo.net

自分の時代は、ちょうど東京めたりっくがADSLをやり始めた頃。「ブロードバンド」という言葉が踊るミレニアム世代で、ろじぱらや侍魂を初めとしたテキストサイトを巡回しつつ、最強のアングラリンクみたいなサイトをめぐりながら、エロと職人FLASHまとめサイトばっかり見てた気がする。健全な男子学生である。

社会人になってブログを書くようになった

自分にとってのインターネットの99％はブログなので、ブログの話をしたいと思います〜。

2005年だと思う。当時はライブドアがGoGoしてた時で、ブログと言えばライブドアだった。何人かの同期でブログを立ち上げて、書き始めた。自分が文章を書くのが好きだって自覚はなかったんだけど、1ヶ月経っても何かしら書いてるのが自分だけだったので、書くことが得意なんだなと知った。2005年は間違いない。当時の僕はデスマ案件で400時間働いていて、日々の残業時間を日記に書いていた。(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ みたいな絵文字使っていた。

ライブドアのブログは当時の会社にバレちゃったので、消した。「渋谷で働く社長のブログ」のタイトルをオマージュしたのが運の尽き、案件のちょっとした愚痴と地名で身元が割れたという。特に減俸もなかったです。コンプライアンス〜。秒速でアメブロに移り、きっかけは忘れたけど、はてなに移動した。

これがはじまり。

なんだこの xusersってやつは

だらだら備忘録を書いていて、1年ぐらい経ったある日。ブログのパーマリンクの右側に、赤い文字で xxusersって出た。これが、はてなブックマークとの出会い。この記事だったと思う。

gothedistance.hatenadiary.jp

インターネット老人の皆さんはNiftyServe等でネットコミュニケーションをされていたと思いますが、自分にとってのネットコミュニケーションのデビュー戦はホッテントリに入ったブコメの数々であった。

興奮が最初に来たけど、次に来るのは「どうしたらいいんだこれ」でした。

「あ、はい、そうっすね、でも、そこで話の腰折られても。そんな事言うて無いと思うんやけど、どう伝わったんだこれ」みたいな、どうにも処理できない気持ちは出ます。20代で若かったので。AさんがBさんに告白して付き合えたやったね！という話に、フラれたCさんの気持ちにもなってくださいみたいなこと言われると、萎えちゃう。どこ見てんだお前はって。1:Nのコミュニケーションで反論できる場がないし、反論記事をあげようもんなら「うぷぷぷ、こいつなんなんｗ」みたいな反応をされてしまう。

ヨッピーさんとは比較にならないけど、自分がいない所でぐだぐだうるせーなー！とは思ってました。ちょっとだけよ。

yoppymodel.hatenablog.com

当時の僕の心の支えは、まなめはうすでしたね。まなめはうす。まなめはうすは推し度に対して★の大きさが違ったんだけど、なにかの記事ですげーでかい★がついたんよ。まなめがいい感じに言及してくれてたんで、読み取ってくれる人もおる〜ってなったんよね。そこから、段々と自分の書いた記事が読みたいっていう人がいるんだなって思えてきて、楽しくなってきた。

ブロガーとして最も気が合うなと感じてるのは、id:takerunba っすね。波長が合う。意見は違っても。字面の向こう側が飛び込んでくる感じ。たけちゃんならこのネタの意味を汲み取ってくれるよな〜という安心感があった。当時、よく引用させてもらった。押上のレバ刺しの店、最高だったな。もう食えないけどさ。

2007〜2008年の頃に出会った人たちは今でもずっとなにかしらつながっていて、交流させてもらっていて、自分の財産になっている。そうなったのは、自分がブログで本音を書いてきたからだと思う。

インターネットで本音を言う若さ

本音が書いてある文章は読み手に届く。言葉じゃなくて、想いが届く。自分はそう思ってる。人の本音ってすごい力があると思う。インターネットで発信すると、特に感じる。読んでて面白いなーって思う文章は、どこかしら本音が見え隠れしてるもん。コンビニ店長(G.A.W)さんとか、理知と本音のバランスが最高だった。また文章書いてほしいなー、インターネットで。

自分はインターネットで本音を書いた文章を公開して、後悔もしましたが、概ね良好です。はてなのおかげです！僕のインターネットの恩人は、Googleとはてなです。

1979年生まれなので、44歳になった。信じられん。28歳のブログ反射神経はもう無い。というか、あの頃一緒にブログ書いていた人たち、みんな書かなくなったな。体力がないだけなのか、反発しても消化できる大人になったのか、未成年の主張よろしくエモさが最前列に来なくなったのか。それはわかんね。

今年の6月に、すごく好きだった上岡龍太郎さんが鬼籍に入られた。重厚さと軽快さを併せ持ったトークと、プライベートで会うと面倒くさ・・そうじゃないやんほんま人懐っこいおっさんでしょーっていう感じの愛嬌があって、すごく好き。

来年はそろそろ、上岡龍太郎モードでブログを書き始めますわ。本音をインターネットで言ってこそ、パイセンの冠つけられるってもんよ

フロントエンドの開発スタイルの変遷とFlutterというお話をさせて頂きました

毎度おなじみBPStudy。治夫さん、ありがとうございました！

bpstudy.connpass.com

108枚のスライドはこっちです。50分で話すボリュームではないですね... 煩悩が多くて、申し訳ありません。

speakerdeck.com

GUI→テキスト→全部コードへの流れ

前半部分は、僕なりのGUI実装考古学みたいな感じの話です。Webブラウザが業務システムで使われる前はWindowsしかない時代で、Windowsデスクトップアプリケーションが作られていました。その時使われていたのが Windows Formで、GUIでテキストボックスとかボタン等をペタペタとドラッグして貼り付けるというスタイルです。このスタイルは一見簡単そうに見えますが、ロジックの再利用性は低く、テキストじゃないのでデザインの再利用性も低いです。IDEのプロパティウインドウでスタイルとイベントハンドラの有無を見るみたいな世界なので、今だと考えられないっすよね。

iOSも、UIKitの時代はGUIベースでした。Interface Builderにパーツを貼り付けて、IBOutletで紐付けてロジックを書くのは同じです。UIKit用語が多くて癖があるのでぱっと見て何のコードか分かる人は少ないと思います。昔はStoryboardもなかったので画面遷移は全部コードで表現したので、画面遷移の全体像を追うことが難しかった。Storyboardで少しは良くなかったと思いますけど、もう戻りたくはないです！ごめんな！

GUIだと再利用性が低く、画面の動的な動きもUIでは一切表現できない。可読性が高いようで低いので、この縛りプレイの中で秩序あるフロントエンドのコードを書くのは相当な習熟が必要だと思います。

テキストでUIを書き、ViewModelとバインドする

GUIはさすがにない！ということで、WindowsForm→WPFに進化したのが最初だと思います。WPFになると、XAMLというXML拡張セットでビューを書くことができます。TextBox Value="{BInding UserName,UpdateSourceTrigger=PropertyChanged"} HorizontalAlignment="center" みたいな感じのXMLがズラズラ続きます。XAMLそのものはよくできていて、Androidのxmlファイルのスキーマよりずっと直感的でした。AndroidのXMLスキーマ中途半端。

XAMLで定義したビュー情報に差し込むデータとロジックはどーするのって話ですが、ここでViewModelが登場します。TextBoxに差し込む値や、TextBoxのChangeイベントを受け付けるためのモデルクラスが登場して、ビューと紐付けます。WPFではこれらの仕組みを「データバインディング」と表現しています。テキストボックスの値が変わると、ViewModelのプロパティのSetterが自動的に呼び出されます。そのためのお作法がちょっと複雑なんだけどね。

ViewModelと特定のビューのイベントハンドラが紐付いてしまうと密結合になって再利用性がないので、UIが特定のイベントを実行したい場合には「Command」というインターフェイスを1枚挟みます。Commandを挟むことで、Commandを実装するViewModelのインスタンスが隠蔽されますので、ViewとViewModelが差し替え可能になります。GUI開発では、イベントは同じだけどコールバックだけ差し替えたいケースがメニーメニーなので、Commandインターフェイスで1枚挟む設計はワンダホーです。

UIがテキストで表現できたのはいいんですけど、今度はデータバインディングに必要な規約が重く感じます。素のWPFでMVVMやると即カオスになりますので、Prism/LivetのようなMVVMフレームワークも学ぶ必要があると思います。簡単なことをやってるのに結構なコードを書かねばならないので、重苦しい感じを受けるかもしれません。Webだと、サーバーサイドのテンプレートエンジンで吐き出したHTMLをjQueryでDOM操作して状態管理するみたいなコードを書いてしまうとカオスになって辛い、という経験をされている方は多いと思います。

やった！全部コードでかけるぞ！

React, SwiftUI, Jetpack Compose, Flutter。コードでUIを表現できコンパイルできるようになりました。Flutterで言うと、TextFieldというクラスのキーワード引数に、フォントの太さや下線などのデザインの設定、changeイベントなどのイベントハンドラ、入力チェック等のバリデーションロジックを全部書くことができます。見通しメッチャ良くなるのと、ロジックが書けるのでコンポーネントとして切り出して再利用することが容易です。表現力の高さは正義なのである。

これらのフレームワークに共通している、宣言的UIという考え方があります。 UI = f(state) という公式があって、UIは、その画面が持っている状態(state)によってその都度ビルドされ、ビルドされたUIを可変にしないということ。つまり、textBox.text = "aaa" みたいなコードは1度書いたら終わり。なので、FlutterのWidgetが持ってる変数は（多分）全部finalです。finalになってるので、stateの変化によって何が変わるのかViewに書かないといけないので、UIで担保する動きが把握しやすく、見通しが良くなります。やっぱこうだよな〜。

UI = f(state) を考えると、キーとなるのは state です。状態をどうやって管理するのかで、アーキテクチャがだいたい決まります。画面ローカルの状態とサービス全体で管理する状態の2つがあると思いますが、それらをいい感じに管理する方法を考えないといけなくて、Flutterも色々な流派が生まれました。2023年1月時点で最も勢いがあるのは、おそらくRiverpodです。Flutter界のロックスター、Remiさんの傑作でございます。

2022年にアーカイブとなりましたが、私がFlutterを始めた時にバイブルとして愛読していたのが、こちらのレポジトリです。Flutterでアプリを作るために必要な考え方や主要なライブラリのサンプルがいっぱいあるので、是非Forkして読むといいです！！！

github.com

自分はUIKit→Flutterにジャンプしたので、宣言的UIと全部コードで書けることの嬉しみ、上記レポジトリで教えてもらったコードの書き方や設計思想の違いにぶったまげてしまい、この2年ぐらいFlutterにハマってしまいました、というわけでございました。

全部コードでUIを書くスタイルは関数に関数を取る関数型プログラミングの書き方に慣れないと何もできないので、苦手意識のある方はそこに慣れることから始めると良いと思います。map/filter/reduce/extendみたいなリスト操作が関数型の書き方をしてます。これに慣れると、ロジックが全て式で表現できるので見通しが良くなります。

後半のFirebaseとか使ったライブラリの実装などは特に捕捉することはないです。Flutter関係ないけど、Cloud Firestoreってホンマに使うのが難しいプロダクトだなと思います。クエリの制約がいつか牙を向いてしまうリスクがずっとあるので。当初は必要ないと思ってたけど、Havingに近いことやらないといけなくなっても、未来のことはわからないもの。RDBのようにクエリの表現力が無限大であればプロダクトの価値にデータストアが後追いできるけど、KVSでは厳しい。Firestoreのデータモデリングは奥が深いです。

GUIってプログラミング教育に良いなと思った

発表内容とは関係ないですが、GUIはオブジェクト指向を学ぶのにメッチャ良いと思います。自分が作ってるオブジェクトがUIとして表現できて、結果を目で見ることができる。視覚から入れますから。たい焼きの型がクラスで、たい焼きがインスタンスなのだという寓話より、2つTextFieldがあって、ひとつはフォントサイズが違う、ひとつは文字色が違う、でも元は同じTextFieldで、属性が個別に定義されているだけを例に取るほうがピンと来てくれるんじゃないかと。こういうのを目の前にすれば、オブジェクト指向のイメージが広がると思う。

次はたぶん3月です

RDBのデータモデリングについて、野球を絡めて資料を作って発表する予定です。BPStudyのBPは、BeProudでもあり、BaseBall Playでもあります。野球というドメインをRDBに落とし込む、マニアにはたまらない構成にしたいと思いますので、どうぞよろしくお願い致します。

「りあクト！ 第3.1版」三部作は間違いなくスゴ本です

Flutterを書き始めると、始祖であるReactの存在が非常に気になりました。というわけで、実践的な入門書と各所で話題になった「りあクト！」３部作を全部買いました。

TypeScriptの入門書及びReactに限らずフロントエンドエンジニアの入門書として、この三部作を超えるのは現状どこにもないでしょう。

oukayuka.booth.pm

普通の技術書で組版した日には、1000pは余裕で超え1500pも見えてくるかというボリュームです。第3部のあとがきで初版と2版時に「もっと丁寧に説明してほしい」という声が多かったので、紙に製本する事情を取っ払って本気出したよ？みたいなことが書かれていますが、ここで本気を出すのがどれだけ大変か。。。数年前にPythonの入門書を書いた私は理解できるつもりです。まーよくここまで歴史的背景を調べて書いてくれたものだと思います。

大いに助けられました点について、まとめました。ご査収ください。

Reactを読み解く基礎体力がついた

三部作の第1部は「言語」に関することがメインです。ES2015以降のJavaScript及びTypeScriptの言語仕様の解説です。

非常にクリアになったのが「文」と「式」の違い。関数型の書き方なんとなく気分ええわぐらいでしたけど、値を返す式の組み合わせが左から右へ評価され最終的な値へ到達する形が「シンプル」やな〜と感じさせてくれました。宣言的な関数定義は正義だ。

あやふやだったTypeScriptの型の理解もグンと促進されました。第4章の「TypeScriptで型をご安全に」で基礎体力が上がったと思います。

変数・関数・オブジェクトに任意の型を設定でき、型の演算・共用・交差・条件・推論・型ガードなど、型をHackして安全性を高めるTypeScriptの基本を学べました。

コードリーディングの補足説明が丁寧で、引っかかりがちなポイントを教えてくれる。<T, A extends any[], E extends Error> 的な宣言を見ると「ちょっとまって・・・」ってなりがちだったので、大変助かりました。

この本で書かれている(事実上と言っていいのかな)Reactのコードの大半は、関数型のコード with TypeSafeなので、その基礎体力が無いとReact辛いになると思う。でも、それが見えてきたので、ググってでてきたReactのコードの大半はスラスラ読めるようになったので、嬉しみ〜！

JSXは慣れの問題

気持ち悪いのはJSXのせいじゃなくてHTMLのせいだと思うのよね。Webブラウザがクライアントである以上、HTMLから逃げられないじゃん。JSXのほうがアウトプットイメージが湧きやすいのは僕だけですかね。

FlutterだとHTMLに当たる構文がないので大変気分が良いし、items.map((e) => ListTile(child: Text(e.name)) っていう書き方でUI書けて気分が良い。Vueだと難しいみたいだけど、Reactだとできる。コードでUIを表現できる気持ちよさを感じたので、本でも書かれているけど、JSファーストでやりきるReactのあり方は好き。

「Container Component」と「Presentational Component」

分割単位の指針として、「Container Component」と「Presentational Component」という考え方を明文化してくれたのは、自分にとって大きかった。

FlutterのWidgetの設計は基本これですよね。この指針は重要で「ロジックを除外した静的に動作するUIを作り、必要な状態を定義してType化して、外から与えられるようにする」に留意すれば、まぁひどいコンポーネントにはならないはず。外の定義が、Hooks/Propsの違いはあるけれど。

自分はFlutterから入ったので、この本で書かれている「Mixins」「Higher Order Components」「Render Props」に共通している「ロジックを追加がするとWidgetツリーが汚染され、追加するロジックの分だけ階層が深くなる」歴史的辛みを知らなかった。Hooks によって始めてReactはコンポーネントシステムの外に状態やロジックを持つ手段を手に入れたとしたら、それは辛いわ。Hooks後にReactやれてよかったよｗ

Reactはコンポーネント、Flutterはウィジェットだけど、UIをコードに落とす設計思想は大変参考になるので、Flutter力もこの本を熟読すると間違いなく上がる。フォルダ分けでガタガタ言ってるぐらいならこの本読んだほうがいい。

Redux + Effect Hook

React自体は関数型でUIを表現するシンプルなものだとしてもちゃんとした Web アプリを作るためにReduxや非同期処理ミドルウェアの組み合わせが前提になったのは辛いね〜。本にもあるけど「牛刀をもって鶏を割く」ってやつは、技術者が嫌いなアプローチだろう。State Hook+useEffectで各コンポーネントは書けるから、コンポーネント間で取得したデータを共有したいときは Redux を併用するのは凄くシンプルに見えた。

Recoil 気になります

本にも紹介があったけど、Recoilというフレームワークを使ってみたいな〜。

FlutterのRiverpodとコンセプトが同じに見える。state hookを各自グローバルに定義できるし、familyで引数取れるのも同じ。Suspenseを使って宣言的な非同期UIコンポーネント(RiverpodだとAsyncValueが近い)が作れるのも良さそう。Selectorのオプションの豊富さは、RiverpodのProviderの使い分けになんか似てる。

フロントエンド力をつけるなら「りあクト！」で決まり

Reactを読み解く為の基礎体力をつけるなら、この３部作しか無いでしょう。基礎体力には、なぜそう書くのか、及び、なんでそういう書き方はあかんのかも同時に知る必要がある。その説明がとんでもないので3版で分量が3倍界王拳した本作ですが、ほんとにここまで書ききって頂いてありがとうございます以外の感想がない。

三部作の学習メモをとるのにNotionを使っていますが、こんな感じです。改行入れて4.3万文字近くありました。入門書でこんだけのメモ取ったことないわ。コスパすごいですよ。5000円だもん全部で。この本の先生役の雪菜さんクラスの単価を考えるとね、すごいことです。

つらくないReact開発ってあるけど、Reactの辛みの9割はモダンJS＋TypeScriptの基礎体力のなさだと思います。ReactというSDKの理解はそこまで重くないと言うか。iOS SDKの理解に比べたらだいぶ楽な気がする。

りあクト！学習記録

著者の大岡さんに最大級の感謝を込めて、書評書きました。I ♡ React, can't thank you enough!!

oukayuka.booth.pm