ひとり会社の起業について学んだ10のこと - GoTheDistance
note.com 僕の間違いじゃなければ、時々はてなのブログでコメントを頂いた方のように思う。Python関係で。大変お世話になりました！ 法人の設立にあたっての事務処理と、会社運営のお気持ち編を、自分の体験からまとめてみます。2016年6月にノリ（そうだ独立しよう）だけで起業して7年ほどひとり。今は2人体制になった。 会社を大きくする方法はなんもわからんので、そういう内容を期待される方はすいません！沿わないと思う！ 1. 決算処理は専門家に任せたほうが良い 自分は前職の会計事務所でお世話になったため、起業当初から会計事務所を利用させてもらっている。年間30万弱。決算処理込み。 6月1日に創業したけど、タイミング的に6月になっただけで、深い意味はなかった。会計事務所的に3末はGW進行と重なるので避けたほうがいいかも。 決算処理は確認しないといけない事項が多すぎて、素人がいくら確認しても漏れ
Flutterに出会ったことで脳汁プシャーになった話 - GoTheDistance
Flutterに出会ってしまったせいで、Flutterを中心に生きていこうと考えている私のポエムでございます。 エンジニアとしての頭打ち感 2016年に35で独立した時はエンジニアとして頭打ちを感じていて、エンジニアとして独立することはあまり考えていなかった。初心者ではないけど、上級者になれないなと感じていた。 エンジニア一本じゃ難しいと考えた時、その隙間を埋める役割はありかなと思った。業務系のシステム導入なら、コンサル〜要件定義の上流工程をやり、開発系なら開発寄りのディレクター。その時々で研修講師。この辺を組み合わせて、今までやってきた。 コードは細々と書いていた。JavaやPython、メンテナンスしてるシステム(WPF)やアプリ(iOS / Android)なり、kintoneでjs書いたりWordPressのプラグイン開発みたいなやつをチラホラやってた。小規模な受託なら受けていた。
日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance
先日、アジャイル開発を推進するために大変有意義な資料が公開されています。ESMの木下さんといえば、アジャイル開発の現場にずっと携わってきた著名な方です。 note.com でも、令和2年にこちらの記事が何百もはてブされるのも、おいおいマジかよって思う所がありまして。今までどうやってたのだろうか...。準委任(時間単位のチャージ)以外の選択肢がないやり方だと思っていたので。請負でアジャイルを取りに入れるわけないですよね。一般的なSIerさんでは、どういう理解をされて、どう取り組んで来たのだろう。 アジャイルと受託開発の相性は最悪では ムービング・ターゲットを請負で追いかける自傷行為を誰がやるんだって話と、要件固めて下請けに出せないから誰もやりたがらないよねという話を書き散らしています。 10年前に書いた記事の内容がまだ通用してしまうのも、自分でも少し寂しい気持ちがあります。 gothedis
【書評】その「エンジニア採用」が不幸を生む - GoTheDistance
毎度おなじみ技術評論社の傅さんからご恵投頂きました。 その「エンジニア採用」が不幸を生む ~良い人材を見つけ、活躍してもらうには何が必要か? 作者: 正道寺雅信出版社/メーカー: 技術評論社発売日: 2016/12/07メディア: 単行本（ソフトカバー）この商品を含むブログを見る 結論から先に言いますと、僕が今までご恵投頂いたエンジニアのキャリア本で「ベスト」の一冊です。 採用という切り口でエンジニアのキャリアを見つめ直す 本書は「採用」に絞って、エンジニアが企業組織で良いキャリアを築くためには何が必要なのかを問題提起しています。「エンジニアはもっと採用されるように頑張れ」というクソみたいな話じゃなく、採用すると決めた経営陣、それに従う人事担当者、採用されるエンジニア。この3者の立場を俯瞰しつつ採用コンサルティングとして携わってきた筆者が、重厚な論調で痛快に問題点を指摘しています。 エンジ
プログラミングの学習に最適なWebサービス「CODE写経」 - GoTheDistance
僕が作ったものではありませんが、面白いコンセプトだなぁと思ったので紹介します。(株) レベルエンターの代表、山本さんがおひとりで開発されたサービスです。その名も「CODE写経」です。画像をクリックするとサービスのページにジャンプします。 写経はハードルが高い プログラムの文法に不慣れな初学者にとって、写経は少しハードルが高い。カッコを付け忘れるとか半角を全角で書くとか変数名をtypoするとか、コピペではない手段でプログラムを書こうとすると色んな罠があります。不注意と言えばそれまでですが、何が不注意だったのかもわからないのは可哀想です。 とにかく動くプログラムを書かないと、学習を先に進めることは出来ない・・・ 山本さんはプログラミングを教えるお仕事をされているので、間違えずに写経ができるサービスがあればと思ってこちらのサービスを開発されたそうです。 操作動画 youtu.be Chromeで
事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance
言いたいことがストレートに伝わる良い文章だと思います。 simplearchitect.hatenablog.com ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。 では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。 確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？ 僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエア
地方のIT業界に必要な顧問エンジニアというモデルを考えてみた - GoTheDistance
facebookに流れてきたこのエントリ、衝撃的な内容でした。 risingsun-system.biz 技術者と会話が成立しない うわっ・・・となった。 こちらのお客様は、過去何度も地元のソフトウェア開発会社に仕事を頼もうと、いろんな会社とコンタクトを取られたといいます。しかし残念ながら、どの会社とも取引にいたることはありませんでした。 理由は様々ありますが、煎じて詰めると「技術者と会話が成立しない」ということでした。 自分の住みたい地方のIT業界をより良くするために必要な構造変革とは？ 「業務がわかるエンジニアがいない」→「地方のユーザー企業から元請けの仕事を取れない」→「大手の下請けに入る」→「地元で業務が設計できて実装まで行えるエンジニアが育たない」→「業務がわか(ry」のループに入っている様子が鮮明に見えちゃいました。上記のエントリを書いた方は長野県の方ですが、どの県でも同じよう
「これって、ドメイン駆動設計？」という資料を公開しました。 - GoTheDistance
いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計？ from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが１つ。 で、ドメイン(特にいまやってる物事)を抽象化す
【書評】プログラムは技術だけでは動かない - GoTheDistance
技術評論社、傳様より献本御礼。 プログラムは技術だけでは動かない ?プログラミングで食べていくために知っておくべきこと 作者: 小俣光之出版社/メーカー: 技術評論社発売日: 2014/06/05メディア: Kindle版この商品を含むブログを見る 本書は「技術的な力はあっても、仕事として作った技術を活かした製品やシステムが、使いものにならないことがある。」という問題意識が根幹にあります。技術力を活かして飯を食うために「プログラマとしての仕事力」という観点で自分のキャリアを考え直してみたらどうだろうか、という位置づけになっています。決して技術力を卑下しているわけではなく、技術を活かすのであれば仕事として評価されないとダメだという話です。 いくつか、僕が響いた内容をピックアップしていきます。 作るだけでは仕事にならない プログラマとしての仕事力というのは当然いくつかの能力があるわけですけれど
もしもIT業界の下請け構造が崩壊したら - GoTheDistance
みんな死にかけるかもしれないよ。 ひがさんのSI業界からはさっさと抜けだしたほうがいいを読みました。SIには未来が無いという最後通告のような文面のようにも取れます。江島さんのニッポンIT業界絶望論と併せて読むと、言わんとしていることの輪郭がより鮮明になるかと思います。ご一読を。 非効率極まりない下請け構造でシステムを作る時代が過ぎ去り、プロがはじめから高い品質を提供できるSaaSの時代が到来しているよ、と。ユーザーは必要最低限の投資で済む為、よりスリムで堅牢な企業体になる。IT屋も全部自分で出来るしお客さんが喜んでくれて嬉しいよねというWin-Winなシナリオ。 これが仮に未来像としましょう。そうすると、ちょっと考えれば分かる。ITのサプライサイドにとっては、本当に難しい時代に入るってことが。SaaSの時代というのは、僕ら業界にいる人間にとってみれば「多産多死の時代」ではないでしょうか？変
勉強会が当たり前になってきたから危惧していること - GoTheDistance
どうもこれは眉唾ではないようだ。それに近しい話をチラホラ耳にした。特に会社で、勉強会に理解のあるマネージャクラスの人から。 ブームも一段落しているようですが，まだまだ多数の勉強会が開かれています． それは凄く良い事だと思うし，僕も楽しそうなものや興味のあるイベントには積極的に参加しています． が，そこでどうしても気になってしまう事もあります． なんというか「勉強会」とかに権威的なものが出来てしまって， 「勉強会に参加してるとエライ」 「勉強会を開催したり運営を手伝ったらエライ」 的な空気が出来てしまっているような気がしてるのです． そろそろ JOJO 勉強会について一言言っておくか - YoshioriのBlog 高度に進化すると草刈場っぽくなっていて、いいやつがいたらツバつけておこう的になっているみたい。ここ2年で、急激に市民権を得ている。それだけ裾野が広がったってことなんでしょうけど、
【書評】経験ゼロでもできるプログラミング現場の単体テスト - GoTheDistance
BBQ和尚の同僚の方とは知らずタイトル買いした本ですが、タイトルに偽りなしです。とにかく平易で優しいわりにいちいち実践的で助かってます。最小の努力で結果が出るように配慮されています。 経験ゼロでもできるプログラミング現場の単体テスト 作者: 片桐一宗出版社/メーカー: 翔泳社発売日: 2009/05/29メディア: 単行本（ソフトカバー）購入: 11人 クリック: 564回この商品を含むブログ (26件) を見る この本を買ったきっかけは、とにかくデグレを無くしていい意味で手離れの良いコードを書いて楽がしたい、というもの。その為にはテストツールの使い方よりも、｢どうやってテストコードを書けばある一定の品質が保てるのか｣ということが書いてあるまとまった情報が欲しかった。で、本書をあたりました。 テストコードの書き方がわかっても、テストの内容が不十分であったりテストする単位が均質でなければ意味
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
進化を諦めた保守などありえない - GoTheDistance
山本さんが刺激的なエントリを書いていらした。 場当たり的な対応で工数が少なくてすみ、影響範囲も少ないが、コードは汚くなるという案と 影響範囲が広いし工数も掛かりそうだが、コードは綺麗になるという案があるとき、 僕は、よほどの差でない限り、コードが綺麗になるほうを選ぶ。 安全策が後手後手を生む - 山本大＠クロノスの日記 場当たりなので手間はかからないけどコードが汚染される 挑戦的なので手間もお金もかかるけどコードが綺麗になる それ自体は｢よくある｣葛藤だと思います。 山本さんはよほどの差で無い限り後者を選ぶとおっしゃられており、僕は極めて英断だと思っています。そのような｢英断｣を支持してもらうためにはどうすべきか、という視点で続きを書いていきます。 コードが汚染されてしまうと、システムが技術的負債を抱えることにつながります。とても可視化しにくいコストなのですが、｢ちょっと何かを変更するだけ
知らないと損するフレームワーク思考活用法 - GoTheDistance
ホッテントリメーカーからタイトルを頂戴した。id:phaさんありがと。 社会人なら押さえておきたいフレームワーク思考 : LINE Corporation ディレクターブログが非常に人気で今年のアルファブロガー(というかエントリ大賞に見える)大賞にもノミネートされている。こういう記事はニーズがありそうなので、僕なりにフレームワーク思考についていくつかサンプルを用意し、僕が使うチャートのサンプルを紹介しておきます。 というか1000以上のﾌﾞｸﾏとか・・・嫉妬！激しく嫉妬！！ハンカチ噛んじゃう！！！！ そもそも議論しちゃいけないこと 個人の価値観に依拠し、お互いの主張を出し合っても全体として合意が得られそうにないこと。例えば｢浮気の定義｣とか。こんなのは議論したって全体最適なんて導けるわけが無いので、ビジネスの場では全く持ってムダです。居酒屋でやりましょう。 仕事で議論することの意味 あなた
「仕事力」に散りばめられた金言の数々 - GoTheDistance
最近この本を読んだのですが、随所に素晴らしい言葉が散りばめられていました。僕が特にこれはと思った言葉を貼り付けておく。というか、伝えたくてしょうがない言葉が多すぎる。私が自信を持っておすすめできる一冊です。是非。 大前研一 優れた経営者はみな提案グセのDNAを持っている。 常に自分のやる仕事を文章化して棚卸しせよ。 朝倉摂 専門家として生きる、そういったハッキリとして目標があるのは大切だが、それだけに向かって細い道をひた走る生き方は豊かな仕事を生まない。 感じたことを自分の手で表現する訓練をきちんと積まなければならない。自分のハートをここに込めたとわからせる力量が重要です。 素直になれない人と仕事をすることほど、つまらないことはない。 安藤忠雄 仕事は生涯をかけて自分の可能性を探すことである。 青春とは目標を持って生きている時間のことをいう。 精神を萎えさせないためには、常に勇気を持って挑
スーツにはスーツの道がある - GoTheDistance
勢いで書く。 スーツ側の人は業務内容が密接にプロジェクトや会社の中の話と結びつくことが多いので、はてな界隈ではなかなかスーツ側の人はスーツ側の濃ゆい話を書くことが出来ないことが多いようだ。圧倒的にスーツ側の人間がはてなを始めとしたブロゴスフィア全体で少ないなぁとつくづく思う。QAも少ないけど。この辺をアツく語るブロガー出てこないかなー。 私は200X年に今の会社に入社して、数年間WEBアプリケーションの開発をやった。多くはJavaの案件だった。最後の案件は去年の夏ごろだ。前任のPMが逃げるように辞めていってしまい、非常に複雑なロジックを自分が担当することになった。1500行越えktkr。それを参考にして(これが大間違いだったんだよセニョールorz)２週間かけて作ってみたはいいものの、テストを繰り返しているうちにどんどんボロがでて、結局その当時のPMとパートナーさんに相談して設計からやり直し
SEとコンサルの違い - GoTheDistance
業務上、某有名外資系ファームのコンサルタントと仕事をしています。私も今回始めてコンサルタントと共に働いた中で、あーこういうマインドが違うんだなぁと思った点をメモっておきます。 WhatとHow 開発をやっていた頃は、どんなに上流でも外部設計からの経験しかありませんでした。外部設計と言いつつもぶっちゃけこれ要件定義なんですけど、っていうプロジェクトもあったんですが*1、ある程度要件というのは見えていたので、後はそれをどうやってブレイクダウンするのかという頭の使い方が求められていましたし、そういうのが多かった。 ある意味Howの思考で、どうやったらWhatを担保できるのかが中心的な頭の使い方だった。 それに対してコンサルタントというのは、そもそもWhatが何かもさっぱり分かっていない状況から突っ込まれることが多い。Whatを見つけるためには要件がなければどうしようもないのである、なんて話は通用
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
