タグ

ブックマーク / gothedistance.hatenadiary.jp (9)

  • 株式会社 クオリティスタートを設立致しました - GoTheDistance

    5末で前職のエフ・ケーコーポレーションを退職しました。で、会社作りました。6/1に登記申請を行い受理されてから口座開設と税務署への届出等の細かな手続きがございまして、法人としてスタートするのに1ヶ月かかりました。 quality-start.in StaticPressで作ってS3でホストしてます。WP管理するのがめんどくさくなってしまった。お問い合わせフォームはTayoriというサービスを使っています。 以下、独立に至るまでの経緯を書きましたので、よろしければお付き合い下さい。 独立に至るまでに考えたこと 昨年の今頃から退職は頭にありましたが、次に何をしようと思った時に「これ」というのが浮かなばかった。とりあえず、人に会おう。その中で考えよう。そんな感じで色んな方とランチをご一緒させて頂きながら近況報告をしつつ何をすべきか考えました。 僕がひとりで内製していたこともあり、「業務のわかるエ

    株式会社 クオリティスタートを設立致しました - GoTheDistance
  • Eメールで作業内容を管理するのはやめましょう - GoTheDistance

    BacklogとかサイボウズLiveとかをご存じないクライアント様が結構多くて、そのような方々にとってのコラボレーション・ツールはほぼ間違いなくEメールになります。まずその啓蒙から入って仕事をさせて戴くことが多くなりました。 お打ち合わせの場でAction決めて、その後はちょいちょいメールフォローでだましだましやってこれた時もあったのですが、やっぱこれダメだってことになったので、その話をしたいと思います。 Why Email Collaboration SUCKS そもそも、Eメールは双方向性があるようで無いツールです。Eメールでの各種進捗管理は、以下の点で非常に効率がよろしくありません。 1つのメールに複数の事項が含まれることがある 例えば、Xさんに対してAという事項の修正事項が記載されたメールに対して、Xさんが返信を行ったとします。その返信に対して別のBという事項のご相談があると、追い

    Eメールで作業内容を管理するのはやめましょう - GoTheDistance
  • ノマドワーキングを目的にすると不幸になるのでは? - GoTheDistance

    僕はノマドに対しては否定的なのですが、その心情をうまく表現してくれているのがこちらのエントリ。 そもそも個人的な実感として、一つの組織に所属して、社畜と言われようがきちんとした成果を出す形で働き、組織と一緒に自分も成長した上で、その後独立なりなんなりするのが最終的に自由を手に入れる最も現実的な方法であることは間違いない。 (中略) ノマドというライフスタイルが存在するのではなく、自分にとって最適な形を模索したらそれがたまたまノマドだったというのがライフスタイルの正しい形のはずだ。 ノマドとかライフスタイルをテンプレで語ること自体の陳腐化と正社員とノマドの中間解 - Future Insight いや、もう全く同感。ノマドは目的じゃない。単なる結果でしかない。 典型的なノマド像は津田さんや佐々木さんのような、ご自身のメディアをお持ちのジャーナリストなんだろうと思う。publickeyの新野さ

    ノマドワーキングを目的にすると不幸になるのでは? - GoTheDistance
  • SI業界で技術者が軽視されてしまうのは何故なのか - GoTheDistance

    のSI業界でこそ、専門の技術者の必要性がもっと見直されるべきではないのか? - 達人プログラマーを目指してを拝読しました。この手の議論は定期的に出てくる根の深い問題でありまして、1億年と2000年前から多くの方に言及されています。しかし、それほど大きい問題であるということです。一概にああしろこうしろで片付く問題ではありません。 色々論点はありますが、「技術を売って社会貢献している業態なのに、一番重要な技術者を軽視するってどういうこと?」という1点に集約でき、上記エントリの主題も同じです。技術onlyの専門家の存在が認められないのが問題だと。しかしですね、「技術者そのものを売ってるんだから、軽視云々を言ってもどうしようも出来ない」という果てしない平行線を辿っていることが見えているでしょうか?ブルーハーツの「弱いものたちが夕暮れ 更に弱い者を叩く」というフレーズが思い起こされます。 技術

    SI業界で技術者が軽視されてしまうのは何故なのか - GoTheDistance
  • 営業ができる人とできない人の違い - GoTheDistance

    営業という言葉に良いイメージを持ってる人はかなり少ないんじゃないかと思います。特にエンジニアは営業さんに「泣かされた」経験がおありの方が多いですし。また、電話爆撃営業や詐欺に近いような営業も多い中、益々うさんくささが先行しやすいのかなぁと思ったりします。 ホントはそういうもんじゃないだろって思うので、自分1人で顧客の所に赴き、話をしに行くことも増え、発注側として営業さんの話を聞くことも増えてきました。そんな中で、営業について感じたことを書いてみます。 1. できる人は相手に問いかける、できない人は自分が話し続ける 相手とのコミュニケーションの中で距離感をつかみ、お互いが負担にならないようなコミュニケーションの土台をまずつかむこと。これが恐らく営業のはじめの一歩なんじゃないか、と思っています。 その土台を作るのに、まず自分のことを立て板に水を流したように話す営業がいますが、その時点で僕は「も

    営業ができる人とできない人の違い - GoTheDistance
  • なぜ受託開発は非効率になってしまうのかを考えてみた - GoTheDistance

    受託開発が抱える質的な非効率性に関する考察 - GeekFactoryを読んだ。 受託開発をやる以上は上記エントリで指摘している問題が出てくることが多いので留意したい、という注意喚起として読んだ。「質的に非効率」の意味が「どうあがいても効率よくやれません、残念でした。」という風に読み取れるので、違和感を感じた方もいたのかもしれませんが、残念ながら効率を上げられる要素が少ないので効率性には限界があります。 というか、受託開発が非効率なのは製品をそのまま適用するのに比べたら当然なので、その非効率なポイントを議論して何を導きたいのだという気もする。出来合いのモノを使うかオリジナルを作るかの区別もつかない段階で効率以前の問題だろ、というちゃぶ台返しの極論を言ってみる。そこに端を発して、工数かけた方が儲かる単価商売の悲しい性で丸投げと縦割りが重なってしまい、ますます「どうしてこうなった」状態にな

    なぜ受託開発は非効率になってしまうのかを考えてみた - GoTheDistance
  • はてなのエンジニア退職劇に思うこと - GoTheDistance

    id:naoyaさんがはてな退職し、新しい道を探すことになりました。改めて、はてなユーザーとして感謝申し上げます。はてブというサービスがなければ、その中でアテンションを集めるホッテントリという仕組みがなかったら、今の僕はありません。当にありがとうございます&おつかれさまでした。 id:secondlifeさんが退職のエントリでこのような一文を書かれており、恐らくnaoyaさんも同じような心境だったんだと思います。 エンジニアとしてやっていくとして、はてなに残り 1エンジニアに戻る道ももちろんありました。ただ、自分にとってはてなはあまりにも居心地の良い場所になりすぎてしまっていました。それに自分も慣れすぎて、どうしても他人に甘え仕事に妥協が生まれたり、『会社にとって評価されやすい仕事』を気をつけていてもやってしまう自分がいました。また、長年会社にいるとその会社に役立つスキルを使って仕事

    はてなのエンジニア退職劇に思うこと - GoTheDistance
  • 最近SIerがだいぶヤバくなっている件 - GoTheDistance

    via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃をらう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムでい込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな

  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
  • 1