はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう！』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章

はじめに プロジェクトマネジメントの仕事をする際に、お客さんに提案ベースの要件定義や設計をする機会が増えてきたので、私の経験に基づいて基本設計の具体的なプロセスや考え方について、整理していきます。 以前投稿した記事の続きですが、未読でもこの記事を理解できるようになっています。 この記事の対象者 基本設計の思考プロセスを学びたい人 ビジネスサイドの要件をエンジニアサイドのシステムに落とし込む流れを学びたい人 ビジネスサイドとエンジニアサイドのコミュニケーション能力を向上させたい人 具体的な事例を通して基本設計を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要です 自分の経験に基づいた内容を言語化しています プロジェクト規模は10名から20名のシステム開発を想定しています(大規模なプロジェクトを想定していません) システム開発の全体像 今回は下記

この記事を読んだ方から有益な情報をたくさんいただいたので追記している。 特定創業支援等事業の認定 法人設立ワンストップサービス gBizID 自分でやっていないものについては各項目で明記している。 なぜ作ったのか？ 自分の興味があった教育分野において、実際にやってみて自ら経験を積み、社会に役立つようなことがやりたいと思ったため。 あと、長くサラリーマンをやって、矛盾している組織が許せない性分だとわかったので、じゃあ自分で組織を作ってみようという単純な発想による。できるだけ矛盾していない組織を作ろうと目指しているが、やらずに文句だけ言うのはフェアでない、という意味合いもある。 フローチャート やることが多く、時系列がわかりづらかったのでフローチャートを書いてみた。 週一で動いた場合、 3 ヶ月ほどかかる。また、灰色の枠は実施していない。 経費について 登記前にかかった費用はすべて創立費、登記

いま僕は「ファンズ」というフィンテックの会社をやっていまして、これからもっともっと伸ばしていきたいと思っています。 そこで採用に力を入れているのですが、面接の場面などでよく「なんでこの会社作ったんですか？」とか「どうやってこのサービスができたんですか？」と聞かれます。 まだ僕らは志半ばだし、成功もしていません。過去を振り返るようなフェーズではないのですが、採用担当から「これまでのストーリーをきちんとまとめてください」と詰められまして（笑）、ちょっと気が引けるのですがnoteにまとめてみようと思った次第です。 僕は、なにかしら飛び抜けた才能があるわけではありません。努力家でもありません。もともとめんどくさがりで、だらしない性格でもあります。 そんな僕がどのようにスタートアップを立ち上げ、経営を続けることができているのか？　せっかくなので、少しでも僕の話が偶然読んでくれた方のヒントになったらい

はじめに 自分は渋谷のWeb系開発会社にて執行役員兼エンジニアをやっています。(新卒入社3年目) 直近では6~8名程のエンジニアがいるプロジェクトで、ディレクトリ設計やissue作成、コードレビュー、スケジュール管理、PMへのUI/UX及び機能提案などを行なっています。 その中で自分が「エンジニアチームにとって開発しやすい環境整備」を色々試し、実践してきたので整理していきます。 この記事の主な対象者 エンジニアチームの開発モチベーションを上げたい人 エンジニアにとって開発しやすい環境の作り方 おことわり 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています 具体的な開発の設計を紹介するものではありません エンジニアが開発しやすい環境作り 5つのセクションに分けて紹介していきます

本を仕入れる前に 別冊　本の仕入れ方大全　１ この別冊について　本を売りたい。少しの利益を得るために、定価ではなく、卸値で仕入れて売りたい。とてもシンプルなことなのだけれど、実はこれが、特に新品の本においては、一筋縄ではいかない。 多くの人は、まず「本　仕入」などのワードで、インターネットで検索するだろう。すると、確かに大手の出版取次のサイトも出てくるが、その他一ページ目に出てくる情報のほとんどは「Yahoo! 知恵袋」などのＱ＆Ａサイトで「本の仕入れ方がわからない」などと質問されたもの

私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト

昨今では、顧客理解 / ユーザ理解に取り組む必要性が様々な所で主張されており、一般常識になりつつある。そして「顧客のことを深く理解すれば、良質な仮説を立案できる」という言説が広く信じられており、マーケティング戦略を検討したり顧客体験をデザインするうえでの前提条件となっている。しかし、このような言説は本当に正しいのだろうか。 結論からいえば「顧客を深く理解すれば、良質な仮説を立案できる、という言説は間違っている」というのが本記事の主張である。この間違った言説が広く信じられてしまっていることが、ミクロな視点では「成果に繋がる施策仮説を立案できない」というビジネスパーソンの悩みの解消を阻んでおり、マクロな視点では企業の成長や競争力向上を阻む要因となっているのだ。 そこで本記事では、顧客理解の必要性・重要性を真っ向から否定することを試みる。「顧客を理解すれば、良質な仮説を立案できる」という言説が間

ひゃくまる @osiroiobake 西尾維新、自身の異様な筆の速さの秘訣について「朝になると寝る前にあった問題が解決しているから一日に何回朝を作れるかが大事。僕は二時間睡眠で一日四回朝を作っている。ジーパンを履いたまま寝ると二時間で起きられると知ったときには嬉しかったですね」と答えていたの忘れられん　狂っとるだろ 2023-02-03 23:14:54

ITエンジニアが投票した「ITエンジニア本大賞2023」発表。AWSの知識地図／ソフトウェアアーキテクチャの基礎／プロになるJava／チームトポロジーなど ITエンジニア本大賞2023 技術書・ビジネス書の各ベスト10と、 大賞を決めるプレゼン大会へ参加する書籍6タイトルが決定しました！https://t.co/0F4WrzoiKX プレゼン大会は2/9デブサミ内で開催します。#itbookaward pic.twitter.com/wrIKNzdRni — ITエンジニア本大賞 (@ITbookaward) January 16, 2023 「ITエンジニア本大賞」は、仕事の役に立った本、初学者におすすめの本、ずっと手元に置いておきたい本など、おすすめの本をITエンジニアがWeb投票で選ぶイベントです。 主催は翔泳社ですが、対象となる書籍は出版社を問わず技術書、ビジネス書全般となっていま

まとめました26話以降はTiwtterで更新中です