ポエムです！ 長いのでまとめローコード・ノーコードという言葉の括りは大きな意味をもたず、「プログラマブル」という表現が妥当 プログラマブルな基盤を作って売ることは、課題解決の幅を最大化する。複利でのアセット積み上げが可能で、ひいてはコンパウンド・スタートアップの地盤を作りやすい利点がある この基盤は最初から覚悟を決めて作らないと、後追いで構築するのが難しいため商材としての希少性が高い プログラマブルな基盤は、売り手に高い課題探索・抽象化能力と海外サービスへの強い関心が求められる こうした基盤を事業として成長させることは、将来「Sell work, not software」の時代が来たとしても生き残る手立てを作る最良の手段になりうる まとめても長いですね… はじめに皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋と申します。 現在弊社では、ソフトウェアエンジニアの

皆様、ChatGPTでCode Interpreterの機能がリリースされましたがお使いになりましたか？ 僕は大変有りがたーく日常使いさせて頂いており、活用方法について各方面のご意見を伺いたいですが、その話はさておき… こうした劇的な開発体験の変化が予感されると、度々繰り返される議題の１つが「エンジニアやコードの不要論」かと思います。 私自身がローコードツールを提供している会社の経営者なのですが（ヒューマンエラーを減らせる管理画面構築SaaS「ベースマキナ」をよろしくお願いします！）、この類の議論の盛り上がりと日頃情報を追っている最新のツール群との間を照らすと、ギャップを感じます。 端的に言うと、少なくともここ１年くらいで新しく登場するデベロッパー向けのツールを見ていると、コードが不要になる場面が増えると思いきや、逆にコードをしっかり書くツールが増えてきたな、という印象を持っています。 D

要するに起業して、サービスを作りました。同志を募集しています。 長い自分語りなのですが、サービスを公開した直後の人間の所信表明として生暖かく読んでもらえればと思います。 サービスを公開しました先日、これまでステルスで開発・営業活動等をしていた社内管理画面作成サービス「ベースマキナ」を一般公開いたしました。 思った以上にお問い合わせであったり新規のご登録を頂き、感謝の想いに尽きません。 開発者一同が「きっとこの基盤なら自分達を含めWeb企業でサービス開発をしてきた方が何度も車輪の再発明をしてきた管理画面を作らなくて済むようになる」と信じて、持てる限りの技術でプロダクトを作っています。 公開時にも以前から相談させて頂いたエンジニアや事業者の方々にシェアいただき、一定話題に挙げていただきました。 ただ、自分としてはSaaSというサービスの提供方式やエンジニア文化を大事にするというのは手段で、本当

こんにちは。HRBrainでインフラエンジニアをしている間野(@mano_0307)です。 今年の5月にインフラエンジニアとして入社しました。Kubernetesを使っている弊社で、Kubernetesをまったく触ったことのない私のような人間がインフラエンジニアになれるというのが弊社の素晴らしいところです。合言葉は「トライドリブン」。日々トライができる素晴らしい環境です。 Dev環境という各社共通の悩み 多くの会社で何かと困っているのがdev環境なのではないかと思います。 dev環境今日も空いてないよ・・・フルリモートでどうせバレないし、寝ちゃお あれ？久々に使ったdev5環境がうまく動かないよ。・・・(数時間後)あー、最新のmasterがrebaseされてないからAPIのinterface変わってんじゃん！うわー寝よ・・・ そろそろdev環境増やしたいな・・・でも、あの設定も複製しなきゃ

単純に仕事の用事なのですが、俗に言う経営層と言える立場の方々にヒアリングする機会が増えたことで、とあるセリフを頻繁に耳にするようになりました。 「事業の話ができるエンジニアがいないんだよね。本当に困りますよ」です。 これは僕が事業の話をできるとかそういうことを言いたいのではなくて、各社の経営層の切実な想いであり１つや２つの組織で聞いた発言ではなく、あらゆる組織で耳にする強烈なペインであると言いたいんです。 本当に、文字通り、全ての組織でこの発言を聞きました。 僕個人としては、「え？そうなんですか？結構いると思いますが」って当初反応してたんですよね。何故なら、自分の周りには幸い「技術にだけ興味があるエンジニア」が少ないからでして、彼らがそこまでの切実さで何を求めているのかはっきりとわかっていませんでした。ただ、僕も諸事情あって彼らと似たような視点を持たなければいけない状況になり、この発言の理

結論 端的に言えば5W1Hを徹底した文章を書くと良いのでしょうね。 エラーログの責務 日々漫然とエラーログを出力していませんか？私はしがちです。 エラーログの責務が何かを考えたとき、エラーの原因特定だという認識におそらく齟齬が生まれる方というのは少ないのではないでしょうか。 ただ、テストを書いたりクラスの責務を考えながらコードを書くのを面倒に感じる場面があるように、習慣づけていないとエラーメッセージを丁寧に推敲することなく書いてしまったり、そもそも書き漏れのケースがあると思うのです。 とはいえ、エラーメッセージをいい加減に書くとデバッグコストが上昇するし、コンテキスト依存のバグを特定したいのにリクエストに紐づいた値が全く出力されていないと、途方に暮れるだけで根本対応ができずじまいになってしまいます。 よくないエラーログ 「うちは一応エラーログを書いているよな」と思うチームでも、ログを見てす

はあー。これは反省文です。 マネジメント業をしていると、1on1の時に「何か困っていることはありますか？」という問いかけをする人（過去の自分も含む）もいると思うのですが、これはダメだと思うのですよ。 かの有名なドラッカーの『マネジメント』を読んでいたらですね、「最近は、愛想をよくすること、人を助けること、人づきあいをよくすることが、マネジメントの資質として重視されている。だがそのようなことで十分なはずはない。」と書いてあって、「そうですねー」と思ったんです。でも「そうですねー」ってなるほど俺は十分な振る舞いをしたのか？と。知性ある仕事してたか？と。 マネジメントが組織の成果に責任を負う仕事だとするならば、1on1で「困っていること」を当事者に聞きだそうとするのは最悪の手段だと思ったんですよね。マネジメント本や1on1本にはよく出てるメソッドですけれども。 僕が思う理由は２つありまして、「無

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

コロナウイルス感染予防のリモートワーク １週目が終了しました。さきほどアナウンスがあり、3月まで継続とのこと。いい話ですね。 個人的には、毎日リアルタイムのマッピング情報やら海外のトップニュースでコロナの話が出ているのを見ていると、「大丈夫大丈夫〜リモートワークとかPR要素でしかないでしょ〜」とか言ってるのは流石に油断しすぎでは？と思ってしまいます。 ちょっと前にフレックスに変わったくらいの勤務形態なので、チームにリモート勤務のノウハウは全くなかったけど、VPNの設定などの周知が行き届いててスムーズにやれてると思います。 ということで、その辺の管理周りの知見は別の方に任せるとして、働く身としてよかったこと悪かったことを書きます。前提として、私の職種はソフトウェアエンジニアです。 よかったこと1. MTG回数の減少 これは賛否両論ありそうですが、個人的には良かった点です。 MTGは基本的に洗

まとめ・リファラル採用への熱量は思ってるより差が明らかに出てくる ・リファラル採用を後から促進しましょう、は果たしてうまく回るのか（回らないと思う） リファラルこわいリファラル採用は怖い。絶対に敵に回したくない企業が何社かあります。 最近幸いにもお誘い頂く機会が増えて思った事なんですが... 給与などの必要条件を満たした上で、ビジョンでグイグイ目線上げている経営者、その理念を理解した上で行動している採用担当者が時々いて、十分条件が充実している企業が増えてきたという実感があります。 大きな企業でリファラル採用しようとしても、「人手が足らないので来て欲しい」という色合いが強すぎると魅力的に響かないと思っています。 一方で、ベンチャーでも資金調達を済ませてビジョンや採用候補への理解に熱心な人がリクルーティングしていると、正直働いてみたいなと思う気持ちも湧くし、同時に採用広報とかをちゃんとやりまし

つまり・組織で情報の不透明性が問題になる時、必ずしもその不透明性は悪意や信頼性の無さから生まれるわけじゃなく、よかれと思ってやった結果生まれるかも知れない ・フルオープンにできなくても、情報の確定度合は可能な限りオープンにすべき 1on1で明らかになった不透明性この間1on1をチームメンバーとやっている時、情報の不透明性が問題になった。具体的にいうと、仕様議論が途中の機能について、「あの機能はいつから開発開始なんだろう」「開発スコープは？」という、疑問の声が上がっていた。 この不透明性が生まれたのは、例えば「外部企業と内密なやり取りがあって、隠しておきたい深刻な事情があった」とか、そういう背景からではない。 むしろ逆に、情報の不透明性の話になるたびに比較的僕の所属するチームは性善説で「できる限り共有しましょう」という議論が起こるので、上下の人間関係が悪いとかではない。教えてと言えばだいたい

この流れです。 前提基本的に自分はGoのサーバーサイドが主戦場で、カンファレンスにはよく顔を出します。最近はOSSを公開すればいい感じにGithub Trendsの上の方にきて目立つような、芸人っぽいムーブができるようになりました。 ですが、直近プライベートではGo以外にTypeScript(Next.js) でGraphQLのクライアント書いたり、仕事だと前はSwiftやらC++やらPerlやら色々使っていたので、他の方と比べると広く浅い経歴です。 また、大学に入ってから学習を始めましたし、当時はドットインストールが出始めたくらいで、基本的には書籍で勉強していました。大学では授業でFORTRANの授業を取りました。内容は意味わからなかったので同級生に寄生してました。 Progateとかプログラミングスクールとかには頼ってませんでした。無かったので...。なので、「幼少期からBASICを触

最近Next.jsいじってて思ったことなんですが... よくフレームワークのexample見てると、しっかりしたプロジェクトには`realworld`の名称でサンプルアプリが存在してる。中身は決済や在庫管理だったり、スターウォーズ情報を扱うサンプルアプリだったりする。最後の例だった場合、僕はそんなにスターウォーズ詳しくないのでドメイン知識が乏しくて死ぬ。 realworldに書いてあるコードが実際realworldだった試しはほとんどない。データの表現や状態管理周りの共通処理が実運用に転用できるかもしれない程度で、結局のところ運用必要になるミドルウェアへの対応やトランザクションの管理などでは参考例として成立しない。（だからOSSのオーナーがダメというわけではない。それはこのポストで言いたいことと最もかけ離れている） 会社や社外コミュニティのメンバーと一緒にコードを書くことの利点は、運用前提

基本忙しいな〜と思いつつ、幸いにも仲良く仕事ができてることが多い。その理由を考えてた時に気づいたことをまとめたのがこの文章になる。ここで言いたいことはつまり、「機能を削ることはユーザーと開発チーム双方にとって、恐らく各位が考えている以上に良いことだ」ということだ。 なお、サムネは「機能を削ぎ落としていく過程はまるで彫刻製作のようだ...」と一瞬考えた時に程よい画像をとってきたのだけれど、単純にキモいなと思ったのと、的を射ているようで射てない気がしたし、プロダクト開発も彫刻もそんな知らないので、可及的速やかに忘れることにした。 いかにしてチームは殺伐となるかリリース間際やプロダクト開発が長期化すると、えてしてチームは殺伐としがち。自分が関わったチームでのプロダクト開発では、半々で殺伐なシーンと平和なシーンだった。 殺伐な開発は、その後チームの人間関係に消しがたい遺恨を残し、結果退職や倒産とい

仕事とか恋愛とかでよくこのワードを聞くことがあるけど、僕は絶対に使わないようにしてる。端的に言うと嫌い。 「期待しすぎないのが大事だよね」と言ってるのを見ると、どちらかと言うとしたり顔で相手に責任を転嫁してるように感じるケースが多いせいか、あまり自戒として受け取れない。その印象もあってか、結局「期待を下回る人間だと諦めて接すること」を体裁よく言おうとして何も良くできてないケースだと認識してる。 僕の周りは幸い期待しても大体うまく結果が返ってくる人しかいない（過大評価かも知れないけど）。 多分２つ理由があって、 ・そもそものお願いしたいと思ってる物事が少ない ・相手が普通に有能 のどっちかだと思う。 そもそものお願いしたいと思ってる物事が少ない期待する側は期待される側と同程度の労力を払うべきだと思っているので、仕事とかを細かな粒度で分解して、自分の時間を使って教えられる範囲のことだけ最初任せ