プログラマブルな基盤を売るということ ~100年企業を目指して~｜Seiji Takahashi@ベースマキナ
ポエムです！ 長いのでまとめローコード・ノーコードという言葉の括りは大きな意味をもたず、「プログラマブル」という表現が妥当 プログラマブルな基盤を作って売ることは、課題解決の幅を最大化する。複利でのアセット積み上げが可能で、ひいてはコンパウンド・スタートアップの地盤を作りやすい利点がある この基盤は最初から覚悟を決めて作らないと、後追いで構築するのが難しいため商材としての希少性が高い プログラマブルな基盤は、売り手に高い課題探索・抽象化能力と海外サービスへの強い関心が求められる こうした基盤を事業として成長させることは、将来「Sell work, not software」の時代が来たとしても生き残る手立てを作る最良の手段になりうる まとめても長いですね… はじめに皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋と申します。 現在弊社では、ソフトウェアエンジニアの
そのテクノロジーは隣人と国を救うのか｜Seiji Takahashi@ベースマキナ
要するに起業して、サービスを作りました。同志を募集しています。 長い自分語りなのですが、サービスを公開した直後の人間の所信表明として生暖かく読んでもらえればと思います。 サービスを公開しました先日、これまでステルスで開発・営業活動等をしていた社内管理画面作成サービス「ベースマキナ」を一般公開いたしました。 思った以上にお問い合わせであったり新規のご登録を頂き、感謝の想いに尽きません。 開発者一同が「きっとこの基盤なら自分達を含めWeb企業でサービス開発をしてきた方が何度も車輪の再発明をしてきた管理画面を作らなくて済むようになる」と信じて、持てる限りの技術でプロダクトを作っています。 公開時にも以前から相談させて頂いたエンジニアや事業者の方々にシェアいただき、一定話題に挙げていただきました。 ただ、自分としてはSaaSというサービスの提供方式やエンジニア文化を大事にするというのは手段で、本当
理想の技術選定 | timakin（ちまきん）
個人的に技術選定について想いを馳せた記事です。 技術選定と妥協最近とても技術選定について悩んでいます。技術選定とは常にジレンマを伴い、各エンジニアの感情がぶつかり合うセンシティブなトピックです。 技術選定が「悩む価値のある問題」であるのは明確で、サービスそのものの市場領域を選ぶときほどではないけど、開発組織が長期に渡って健全にワークするか、というのを決める、非常に重要かつ長期にわたる問題だからです。 加えてこれは個人的な話ですが、僕は自分のエンジニアとしての性格なのか、「ビジネスとしてうまくいくスピード感があるのか、明確な課題があってそれを解決しているのか」という意見は前提にしつつ、ある程度技術的新規性に重きを置きがちなタイプという自覚があります。 なので、僕個人は技術選定となると、新規技術の導入に逸る気持ちを意識して抑えなくてはならないことが多いです。ただ別にそこまでネガティブな感情を覚
よかれと思って内緒にする問題｜Seiji Takahashi@ベースマキナ
つまり・組織で情報の不透明性が問題になる時、必ずしもその不透明性は悪意や信頼性の無さから生まれるわけじゃなく、よかれと思ってやった結果生まれるかも知れない ・フルオープンにできなくても、情報の確定度合は可能な限りオープンにすべき 1on1で明らかになった不透明性この間1on1をチームメンバーとやっている時、情報の不透明性が問題になった。具体的にいうと、仕様議論が途中の機能について、「あの機能はいつから開発開始なんだろう」「開発スコープは？」という、疑問の声が上がっていた。 この不透明性が生まれたのは、例えば「外部企業と内密なやり取りがあって、隠しておきたい深刻な事情があった」とか、そういう背景からではない。 むしろ逆に、情報の不透明性の話になるたびに比較的僕の所属するチームは性善説で「できる限り共有しましょう」という議論が起こるので、上下の人間関係が悪いとかではない。教えてと言えばだいたい
なぜ機能を削るのが良いのか｜Seiji Takahashi@ベースマキナ
基本忙しいな〜と思いつつ、幸いにも仲良く仕事ができてることが多い。その理由を考えてた時に気づいたことをまとめたのがこの文章になる。ここで言いたいことはつまり、「機能を削ることはユーザーと開発チーム双方にとって、恐らく各位が考えている以上に良いことだ」ということだ。 なお、サムネは「機能を削ぎ落としていく過程はまるで彫刻製作のようだ...」と一瞬考えた時に程よい画像をとってきたのだけれど、単純にキモいなと思ったのと、的を射ているようで射てない気がしたし、プロダクト開発も彫刻もそんな知らないので、可及的速やかに忘れることにした。 いかにしてチームは殺伐となるかリリース間際やプロダクト開発が長期化すると、えてしてチームは殺伐としがち。自分が関わったチームでのプロダクト開発では、半々で殺伐なシーンと平和なシーンだった。 殺伐な開発は、その後チームの人間関係に消しがたい遺恨を残し、結果退職や倒産とい
CircleCI Orbs開発完全ガイド 2019年度版｜Seiji Takahashi@ベースマキナ
前置きCircleCI Orbsというのは、CircleCIのバージョン2.1以降で有効になった、CI/CDワークフローの一部を共通パッケージとして切り出す仕組みです。 CircleCIはバージョン2.0のメジャーアップデートを経て、一気に実行速度が上がりました。しかし、プロセスの共通化をするにはyamlの記述方法を工夫する以外は特に打ち手がありませんでした。 Orbはまさにその解決策として提示された、CIプロセスのパッケージ化です。 なお、バージョン2.1になったことで、いくつか追加の概念が登場しました。 executors, commands, jobsです。この辺は公式ドキュメントを見ていただくとして、ざっくり言うとexecutorsが実行環境、commands, jobsが実行プロセスの共通化です。 OrbはDockerのイメージと同じく、作ったものをインターネット上で公開するレジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
