ひとり会社の起業について学んだ10のこと - GoTheDistance
note.com 僕の間違いじゃなければ、時々はてなのブログでコメントを頂いた方のように思う。Python関係で。大変お世話になりました！ 法人の設立にあたっての事務処理と、会社運営のお気持ち編を、自分の体験からまとめてみます。2016年6月にノリ（そうだ独立しよう）だけで起業して7年ほどひとり。今は2人体制になった。 会社を大きくする方法はなんもわからんので、そういう内容を期待される方はすいません！沿わないと思う！ 1. 決算処理は専門家に任せたほうが良い 自分は前職の会計事務所でお世話になったため、起業当初から会計事務所を利用させてもらっている。年間30万弱。決算処理込み。 6月1日に創業したけど、タイミング的に6月になっただけで、深い意味はなかった。会計事務所的に3末はGW進行と重なるので避けたほうがいいかも。 決算処理は確認しないといけない事項が多すぎて、素人がいくら確認しても漏れ
｢つくるプロ｣と｢売るプロ｣のあいだ - GoTheDistance
転職して３ヶ月が経ちました。１日が終わるのがとても早く、１週間単位で振り返ると「まだ○曜日か〜｣なんて言いつつも、１ヶ月経つと｢今まで何やってきたんだろう・・・。｣と焦るような日々を過ごしています。 その間いくつか感じたことがあるのですが、一番大きかったのは｢つくる側｣の人間なのか、｢売る側｣の人間なのか、要は自分はどっちのプロフェッショナルとして商売をしていこうとしていくのかということでした。 前職にいた頃は｢プログラマでもなんとかやれるし、提案や管理といった分野でもいけるいける｣と思っていました。いざとなればどっちでもできる。そういう自分でいたいという思いが強く、前職の会社の安定している顧客基盤を通じて折角だから上流工程といわれる部分を担当したい、だってそれは他の会社では難しいから会社の能力で色んな自分の能力を試していきたい。そんな思いでずっと過ごしていました。 でも、これが通用するの
プログラミングだけできればいい、なんてことは無いさ。 - GoTheDistance
なんで管理について書きたいのか 動機です。 単純に「プログラミングだけできればいい」「SIする人は要件定義だけやれ」という声を聞くと切ないからです。 ただし、わたしは個人的に、開発というお仕事においてプログラミング技術が何を差し置いても最重要だと思っていますから、その軸は絶対にぶれない、ということを念押ししてから始めたいと思います。 ひとりにはなりきれない空を見あげる これも昔思ったことなので、取りとめも無く書いておきたいと思います。 技術リテラシーが死んでいる人間が立ち上げた or 回しているプロジェクトは高い確率で砂上の楼閣のように崩れ落ちていく。だからプログラミング技術に代表される技術リテラシーは必要不可欠。だけど、全員が全員その道を突っ走ると今度はビジネスにならない。取ってきたシーズをプロジェクト化できない。僕は後者が出来ない自分でありたくないという思いから、スーツ的な何かを２年ぐ
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
BPELとXPDLの違いについて - GoTheDistance
面白いPOSTがあったのでご紹介。BPELとXPDLってどう違うんですか？という問いに答えるものです。これが一番わかりやすい説明だと思います。 XPDL and BPEL BPELの性質 BPEL is an "execution language" designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from pointtopoint. For this reason, it is best suited for straightthrough processing or dataflows visavis application integration. BPELという言
ハイテクの日本がエンジニアを枯渇させている - GoTheDistance
NewYorkTimesにこんな記事がありました。日本の理系離れについてまとめられた良記事です。今日はこの記事の紹介。ぜひ原文にトライしてください。 High-Tech Japanese, Running Out of Engineers 理系離れが日本で進んでいるから理系の大学がやっきになって入学者集めにやっきになっていることや、日系の会社でもゆっくりと外国人エンジニアの採用やインドやベトナムに仕事を発注し始めているという記述から始まっています。 It was engineering prowess that lifted this nation from postwar defeat to economic superpower. But according to educators, executives and young Japanese themselves, the youn
java-ja第７回〜アルファスーツとBuriのお話〜 - GoTheDistance
第一回チキチキ 『Buriの旨さを味あわせてやる』〜やっぱぶりは寒ブリだよね〜に参加してきました。これが目当てでjava-jaに入ったようなものです。既にいろんな方がまとめエントリを書かれています。是非これらのエントリもご覧下さい。 その中で僕個人が特に響いたことを書いておきます。 Who is your customer？ 誰をお客様にしたいのか見えていないのでろくなシステムにならないのだ、というご指摘。根源的で当然のことだからこそ見えなくなるこの矛盾。あなたが直接対面しているのは本当のお客様、つまり実際にこれを使って業務を行うお客様ではないことが多層構造のこの業界では多い。プライムの案件でも実際に対面するのはお客様の情報システム部であることが多い。僕が今コンサルとして入っている仕事も、クライアントは情報システム部の方だ。その裏に本当のお客様がいる。だからこそ、「誰のために、何を実現する
ヒョウタンツギな現代システム事情をRESTでぶっとばせ！ - GoTheDistance
昨日休日出勤して3冊に及ぶKINGJIMを斜め読みしてふと思ったことをTwitterにぼやいた。 ものすごーく高いお金をかけて基幹システムを作っても現場で使っているのはExcelで、そのExcelをベースに手で個別システムに打ち込んで基幹にバッチでつないでいる会社がどれほど多いことか。 http://twitter.com/gothedistance/statuses/721944022 何でこんなことになってしまうかというと、この辺りが大きな原因かな。 基幹システムで管理したい単位と業務で管理したい単位が違う。 基幹システムは情報システム部が、業務アプリは個々の部が勝手に作っている。 1番においては、基幹システムで管理したい単位は仕訳を行うために必要な単位で業務に必要な単位はそれよりもっと細かい商品単価であるとか商品単位であるとか業界標準の何とかコードであったりとかする。特に流通・小売と
Getting Real 第1章を和訳してみた - GoTheDistance
公式ページの邦訳に魂が入っていないのとid:elm200氏の邦訳に刺激されて、公式ページの第1章だけ、オレ流で邦訳してみた。予想よりかなり難しく、３連休の最終日に頑張ってしまったのは秘密だ。ウケたら調子に乗って、いつか続きをやる。 Getting Real 第1章原文 Getting Realとは 顧客に喜んでもらえるWebアプリを作りたいって？じゃあGetRealする時だ。Getting Realは、より少なく、より早く、より良くソフトウェアを作るためのやり方のことだ。 Getting Realは、ソフトウェアにおける現実を表現するもの(チャートやグラフ、ボックス、矢印、図式、ワイヤーフレームとか)を全てすっとばして、実際に動くものを作るってことだ。 Getting Realは、より少なくするってことだ。より少ない集合体、より少ないソフトウェア、より少ない機能、より少ない事務作業、つまり
JavaとRubyの間にある、ベルリンの壁 - GoTheDistance
ネタ元はこのあたり。 SIer と Rails とエンタープライズと エンタープライズにおけるRailsの価値とは 弊社の某エロい人がRoRに萌えており「おお、なんて生産性が高いんだ。もうWebアプリなんて全部これでいいじゃないか。」とか本気で思ってそうなので萎える。言語の違いは時にはビジネスモデルの違いにつながることが理解できないようだ。言語ってのは文化なの！これからはRubyを全面的に取り入れ開発標準もRubyだぁぁぁぁとか言い出したらどうしよう。グーで殴るしかないかｗ 本来、コード量の少なさや、CoCを前提とした設定の少なさが価値を発揮するのは、メンテナンスの場面です。読み込まないといけないコード量の少なさと、少ないコードの変更で修正ができることが、その理由です。そのためには、大前提として、Ruby（on Rails）らしい、プログラムを作っておくことが必須なので、マネージャはその辺
維持管理なんてやめちまえ - GoTheDistance
はてなやライブドアのようなIT業界の話ではなくSI業界における運用の断片的なお話です。最近ちょっと運用系の方々とお話しする機会があって、色々思うことがあったのでメモっておく。ちょっと飛躍しているけどそこはご勘弁。 SIerとしては開発ポッキリで終わってしまうのではなく、顧客のシステムの運用を任されたいと思っている。そうすれば預かっているシステムのライフサイクルにそって、また新たな開発案件が降ってくることだってあるし、そのシステムに関連するシステムのビジネスが子供のようにくっついてくる。また、運用しているから信頼を得られる。それに開発みたいに一発作れば終わりじゃないので、定期的にキャッシュが入るのも大きい。 だが、そんな運用の最前線にいるエンジニアは不遇な側面が強いようだ。業務知識が求められるがゆえになかなかローテションがきかない、また工数が大してもらえないので数字が上がらない、常に鈴をつけ
SIerという奇形児と、SIという珠玉の仕事 - GoTheDistance
先日のエントリーがアツいことになっており、初のホッテントリ入りに若干興奮している今日この頃です。同じような問題意識を持っておられる方が多くいらっしゃることがわかり、改めて書いてよかったなぁと思っています。 話の流れは相当グダグダなのですがあのエントリーで表現したかったことは、「アメリカにSIerが存在しないのである」⇒「アメリカは素晴らしいのである」というのが骨子ではなく、いわゆるディフェンシブなシステム開発を強いられているSIerというのは、いわば奇形児のような存在ではないかということです。 改めて、ディフェンシブとは 言わずと知れた名エントリから。 ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。 なぜそ
ワークフロー管理って何よ？ - GoTheDistance
現在BPM製品の研修を受けています。業務フローをちょこちょこデザインしたりする中で、結局の所ワークフロー管理って何をすべきなのかを考えていたんですが、id:habuakihiroさんのこのエントリがズバっと来た。 ワークステートエンジンとは何か〜Long Way To S2Buri〜 その１ ワークステートエンジンとは何か〜Long Way To S2Buri〜 その２ 特に「おお！コレだ！」とひざを打ったのはこのくだり。 つまり、休日かどうかを判定するのもひとつの仕事だし、請求処理もひとつの仕事といえるわけです。そして、複数の仕事を連ねてひとつの価値連鎖を作り上げているのが業務フローであり、その連なり方が複雑になったときにフロー制御としての分岐が発生します。これは決して仕事（＝関数）の中と絡み合ってはいけないのです。 詳しくは原文を見て頂きたいのですが、ここで重要なのは「複数の仕事を重ね
不安マネジメント＝プロジェクトマネジメント - GoTheDistance
先日までこういう状態だったので、思わず膝を打ったのがこのくだり。 プロジェクトに参加した大多数の人間は，「漠然」とした不安と安心を持っているだろう。全く何も感じない人間はいないはずである。しかし，各個人の性格的な問題，人間関係，業務上での上司の評価，さらに利害関係などが複雑に絡み，その結果，そのような不安や安心を言葉として口にされることは稀である。つまり，プロジェクトメンバーのほとんどは，悶々とした気持ちで開発を行っている。 この状態は，最もいけない状態である。 天使やカイザーと呼ばれて〜不安を認識することの重要性 不安が人間系により表立ったものとして顕在化せず、「やっぱり破綻した」といったような事を第三者に言われてしまう虚無さといったら…。 不安はまず認知して、その不安を無くさなければならないのだということをプロジェクトが認識して、適切な対応策をとらなければならない。単なる杞憂に終われば
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
