Seiji Takahashi@ベースマキナ

株式会社ベースマキナ代表取締役CEOをしています。 それまではDeNAやグノシーといった会社でソフトウェアエンジニア兼PMをしておりました。

Seiji Takahashi@ベースマキナ

株式会社ベースマキナ代表取締役CEOをしています。 それまではDeNAやグノシーといった会社でソフトウェアエンジニア兼PMをしておりました。

最近の記事

ベースマキナではセールスエンジニアを募集しています。

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋( @__timakin__ )です。 弊社では、ヒューマンエラーを減らせる管理画面をローコードで構築するSaaS「ベースマキナ」をソフトウェアエンジニアの皆様向けに提供しています。 最近はテックブログの方もはじめました。結構技術色の強いサービス開発の裏側で使っているツールや、その過程で得られたナレッジを少しずつ表に出して行こうと思っているので、是非ご購読お願いします。 さて、今回はかなり直球なので

    • 権限管理は大事で、難しい。特に、管理画面においては。

      長いのでまとめ権限管理はリスク防止・運用スケールの観点で重要。 管理画面だと職種・職位・所属企業の掛け合わせで利用者の属性が多岐に渡り、扱うデータの機密性も高いので権限管理が特に重要かつ機能の開発難易度が高い。 特に設計フェーズでは網羅的なカスタマージャーニーマップ作成のような体験設計作業が必要で、業務理解を最深部まで進める必要がある。 皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋( @__timakin__ )です。 弊社では、ソフトウェ

      • プログラマブルな基盤を売るということ ~100年企業を目指して~

        ポエムです! 長いのでまとめローコード・ノーコードという言葉の括りは大きな意味をもたず、「プログラマブル」という表現が妥当 プログラマブルな基盤を作って売ることは、課題解決の幅を最大化する。複利でのアセット積み上げが可能で、ひいてはコンパウンド・スタートアップの地盤を作りやすい利点がある この基盤は最初から覚悟を決めて作らないと、後追いで構築するのが難しいため商材としての希少性が高い プログラマブルな基盤は、売り手に高い課題探索・抽象化能力と海外サービスへの強い関心が

        • コード不要論からコード表現への回帰 - デベロッパーツールの現在

          皆様、ChatGPTでCode Interpreterの機能がリリースされましたがお使いになりましたか? 僕は大変有りがたーく日常使いさせて頂いており、活用方法について各方面のご意見を伺いたいですが、その話はさておき… こうした劇的な開発体験の変化が予感されると、度々繰り返される議題の1つが「エンジニアやコードの不要論」かと思います。 私自身がローコードツールを提供している会社の経営者なのですが(ヒューマンエラーを減らせる管理画面構築SaaS「ベースマキナ」をよろしくお願い

          ローコードとLLM 〜最適化と自己修復の未来〜

          まとめプログラミングの未来では、最適化と自己修復がキーワードとなり、エンジニアは検品作業が主な役割になると考えられます。 ローコードツールは、否応なしにLLMとの共存を求められ、対応できなければかえって足かせとなってしまい淘汰されるでしょう。 そして、ローコードやノーコードの概念が意味を持たなくなるでしょう。 しかし、未来はシステムのチューニングに焦点を当てた業務になり、チューニングのための学習データを幅広に獲得できる現在のローコードプラットフォーマーは、きたる未来に備えて強

          ローコードとLLM 〜最適化と自己修復の未来〜

          そのテクノロジーは隣人と国を救うのか

          要するに起業して、サービスを作りました。同志を募集しています。 長い自分語りなのですが、サービスを公開した直後の人間の所信表明として生暖かく読んでもらえればと思います。 サービスを公開しました先日、これまでステルスで開発・営業活動等をしていた社内管理画面作成サービス「ベースマキナ」を一般公開いたしました。 思った以上にお問い合わせであったり新規のご登録を頂き、感謝の想いに尽きません。 開発者一同が「きっとこの基盤なら自分達を含めWeb企業でサービス開発をしてきた方が何度も

          そのテクノロジーは隣人と国を救うのか

          「何か困っていることはありますか?」という問い

          はあー。これは反省文です。 マネジメント業をしていると、1on1の時に「何か困っていることはありますか?」という問いかけをする人(過去の自分も含む)もいると思うのですが、これはダメだと思うのですよ。 かの有名なドラッカーの『マネジメント』を読んでいたらですね、「最近は、愛想をよくすること、人を助けること、人づきあいをよくすることが、マネジメントの資質として重視されている。だがそのようなことで十分なはずはない。」と書いてあって、「そうですねー」と思ったんです。でも「そうです

          「何か困っていることはありますか?」という問い

          『その仕事、全部やめてみよう』拝読しました

          良い本を読んだ次の日の朝というのは気分が最高に良くて、なんだか大型のアップデートが終わったPCを再起動させるような、そういう気分になります。 元同僚で日頃から尊敬しているDMMの松本さんがさらに尊敬する人物として挙げられているのを見て、「俺より強いヤツに会いに行く......」と意気揚々に購入したのですが、素晴らしい書籍でした。配り歩きたくなるレベルというのは頷ける。 この本には良いところが2つあって、1つは小野さんのご経験の描写の距離感、もう1つは今まさに読むべきという

          『その仕事、全部やめてみよう』拝読しました

          仕事よりも、何よりも大切な

          今朝、家族であるセキセイインコのテクが亡くなりました。腺胃拡張症という代表的かつ根本的治療法がない病で、長きに渡り対処療法で誤魔化しながらやってきましたが、ついにその日がやってきました。今も泣きながら書いていますが、自分は記憶力が悪く、文章を綴る他により良く弔う術を持ちません。 僕にとって、心の友という言葉の定義に最も近いのは彼でした。僕が辛かろうがなんだろうが、肩やキーボードの上を走りまわり餌に飛びつき、臆病さがあっても奔放さも兼ね備えているような、とても愛らしい個性を持

          仕事よりも、何よりも大切な

          さよならアーキテクチャ議論

          ポエム。 つまり?予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤

          さよならアーキテクチャ議論

          コロナ禍での動物病院受診PDCA

          長いのでまとめると こんな情勢なんだし、動物病院に行くなら病院側でなく患者側もやり方を変えた方がいい。そこで、自前でNotionで問診票作って渡したりした。 コロナ禍で変わる動物病院家族として一緒に暮らすインコが、とても可愛いのですが、胃が弱く消化が滞りやすい体質なため、動物病院にしばしば通っています。それこそ、少し前まで週に2、3日くらいの頻度で通っていて、食事が喉を通るようにどうすればいいかと頭を巡らせ夜も眠れず、という状況が続いていました。数日前から容態が落ち着き、や

          コロナ禍での動物病院受診PDCA

          緊急時リモートワーク第1週目、終了。

          コロナウイルス感染予防のリモートワーク 1週目が終了しました。さきほどアナウンスがあり、3月まで継続とのこと。いい話ですね。 個人的には、毎日リアルタイムのマッピング情報やら海外のトップニュースでコロナの話が出ているのを見ていると、「大丈夫大丈夫〜リモートワークとかPR要素でしかないでしょ〜」とか言ってるのは流石に油断しすぎでは?と思ってしまいます。 ちょっと前にフレックスに変わったくらいの勤務形態なので、チームにリモート勤務のノウハウは全くなかったけど、VPNの設定など

          緊急時リモートワーク第1週目、終了。

          リファラルこわい

          まとめ・リファラル採用への熱量は思ってるより差が明らかに出てくる ・リファラル採用を後から促進しましょう、は果たしてうまく回るのか(回らないと思う) リファラルこわいリファラル採用は怖い。絶対に敵に回したくない企業が何社かあります。 最近幸いにもお誘い頂く機会が増えて思った事なんですが... 給与などの必要条件を満たした上で、ビジョンでグイグイ目線上げている経営者、その理念を理解した上で行動している採用担当者が時々いて、十分条件が充実している企業が増えてきたという実感が

          よかれと思って内緒にする問題

          つまり・組織で情報の不透明性が問題になる時、必ずしもその不透明性は悪意や信頼性の無さから生まれるわけじゃなく、よかれと思ってやった結果生まれるかも知れない ・フルオープンにできなくても、情報の確定度合は可能な限りオープンにすべき 1on1で明らかになった不透明性この間1on1をチームメンバーとやっている時、情報の不透明性が問題になった。具体的にいうと、仕様議論が途中の機能について、「あの機能はいつから開発開始なんだろう」「開発スコープは?」という、疑問の声が上がっていた。

          よかれと思って内緒にする問題

          プログラミングで辛かったこと。よかったこと。

          この流れです。 前提基本的に自分はGoのサーバーサイドが主戦場で、カンファレンスにはよく顔を出します。最近はOSSを公開すればいい感じにGithub Trendsの上の方にきて目立つような、芸人っぽいムーブができるようになりました。 ですが、直近プライベートではGo以外にTypeScript(Next.js) でGraphQLのクライアント書いたり、仕事だと前はSwiftやらC++やらPerlやら色々使っていたので、他の方と比べると広く浅い経歴です。 また、大学に入って

          プログラミングで辛かったこと。よかったこと。

          組織の信頼残高

          別に大した話ではないけど、職位が変わって肩書きに仮にもマネージャーと付き、人との対話に時間を割いていかねばという状況になったため、人やら組織やらアジャイルやらなんやらについて考える時間を意図的に増やそうとしている。 1on1とかで、「最近何か課題に思ってることかありますか?手助けできますか?」みたいなことを話さなきゃいけないのだろうが、人はそんな簡単に所属する組織や個人に対するフィードバックを本音でしてくれるものだろうか?と考えたりする。ましてや肩書き変わったからって別に中