タグ

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

  • もし「フリーランスだけの会社」を作ったらどうなるのか - GoTheDistance

    先日、フリーランスで働いている仕事仲間とランチをした際に、表題のようなテーマで盛り上がりました。私の周りでは同じようなことを考えたことがある方が多いようです。 実際にこんな事をやるという話ではなく、こんな会社を作ってうまくいくのかねぇ... という程度のレベルです。話に上がったことを中心に、まとめてみました。 フリーランスだけの会社とは、どんなものか 一言で言うと正社員という身分ではあるが、会社に縛られることなく各々が自分の事業を行うような会社です。 フリーランスになった人も何人も知っていますが、会社が持っている恩恵は大きいことを充分知っています。端的には、会社の都合が兎にも角にも優先されてしまう硬直さが受け入れ難く結果的にフリーランスになったという人も多くいます。自分で今日の仕事をデザインし、いつ仕事を開始して何を区切りとするのかを、自分で決めることができる「生き甲斐」を求めている人も、

    もし「フリーランスだけの会社」を作ったらどうなるのか - GoTheDistance
  • Pythonが独習できるオンライン学習サイト「PyQ」のレビュー - GoTheDistance

    社内の主要開発言語にPythonを取り入れたことで著名な(株)ビープラウドさんが、Pythonのオンライン学習プラットフォーム「PyQ」をリリースされました。 pyq.jp 佐藤社長のご厚意でアカウントを発行頂き実際に使用してみたので、使用感をレビューします。 問題構成 以下のセクションに別れています。他にもいくつかありましたが、チュートリアルからWeb開発まで用意されています。 チュートリアル Python はじめの一歩 Python 初級 Python 中級 実務でのPython はじめてのWebアプリ Web初級 画面構成 2ペイン構成です。左側に問題(クエストと呼ばれています)の説明と解説、右側がPythonのコードを実装して実行結果やテスト結果の表示を行う場所になっています。工夫されているのは左側の説明の箇所で、写経前と写経後のコードの差分が見れるようになっており、自分で間違いに

    Pythonが独習できるオンライン学習サイト「PyQ」のレビュー - GoTheDistance
  • 地方のIT業界に必要な顧問エンジニアというモデルを考えてみた - GoTheDistance

    facebookに流れてきたこのエントリ、衝撃的な内容でした。 risingsun-system.biz 技術者と会話が成立しない うわっ・・・となった。 こちらのお客様は、過去何度も地元のソフトウェア開発会社に仕事を頼もうと、いろんな会社とコンタクトを取られたといいます。しかし残念ながら、どの会社とも取引にいたることはありませんでした。 理由は様々ありますが、煎じて詰めると「技術者と会話が成立しない」ということでした。 自分の住みたい地方のIT業界をより良くするために必要な構造変革とは? 「業務がわかるエンジニアがいない」→「地方のユーザー企業から元請けの仕事を取れない」→「大手の下請けに入る」→「地元で業務が設計できて実装まで行えるエンジニアが育たない」→「業務がわか(ry」のループに入っている様子が鮮明に見えちゃいました。上記のエントリを書いた方は長野県の方ですが、どの県でも同じよう

    地方のIT業界に必要な顧問エンジニアというモデルを考えてみた - GoTheDistance
  • Eメールで作業内容を管理するのはやめましょう - GoTheDistance

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

    Eメールで作業内容を管理するのはやめましょう - GoTheDistance
  • アジャイルに限らず開発手法の議論は不毛になりやすい理由 - GoTheDistance

    アジャイル開発に対する論争が盛り上がってるので、僕も便乗しまーす。新野さん、秀逸なまとめありがとうございました。 「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ - Publickey 僕も2年半前にアジャイルって受託開発との相性が最悪な気がする - GoTheDistanceという記事を書きました。アジャイル開発ってかなり牧歌的なので、内部ならまだしても外部の仕事を請けてキチンと回すのは難しいのではと書いたら、多くの方が「そりゃそうよ」と反応してくれました。その頃から、これを"ケツカッチン"な仕事で行うのは困難だと感じておりました。コミュニケーションが密に取れないと動けないじゃん。 議論の軸をもっかい振り直すと、アジャイルが確約出来る内容はあくまで人材育成・組織風土形成という不定形なサービスでしかないんじゃないでしょうか? アジャイルな組織になりたいから

    アジャイルに限らず開発手法の議論は不毛になりやすい理由 - GoTheDistance
  • コードで周りを動かせるエンジニアになろう - GoTheDistance

    CAREER HACKさんというWEBサイトに掲載されている、エンジニアのキャリア論レポートが盛り上がっていると聞いてやってきました。 「エンジニア技術以外の武器を持て」ー nanapi けんすうに訊く![3]│CAREER HACK エンジニアよ、ゼネラリストなんて目指すな!―VASILY 金山裕樹のキャリア論[2]│CAREER HACK Geekなぺーじ:「汚いコードでいいよ」は夢の環境であると同時に悪魔の囁き Blogger Alliance | 404 Not Found コードの綺麗さの先にあるもの - Fashionable Life で、盛り上がっている論点は「技術以外のことも出来るように vs ゼネラリストなんて目指すな」と、「汚いコードでも稼いだもん勝ちってそりゃあんた」っていう2点なので、その辺書いてみたいと思います。 ゼネラリストなのかスペシャリストなのか 自分で

    コードで周りを動かせるエンジニアになろう - GoTheDistance
  • クラウドがもたらしたSIの価格破壊の果て - GoTheDistance

    クロノスの山さんと飲みにいきました。遅刻してすいませんでした>< 僕らの興味はやはりSIビジネスがどうなってしまうのだろうかという点で、色んな観点から話が盛り上がった。 クラウドの台頭によって、ビジネスでITを利用したくても出来なかった層にIT技術の裾野が広がっていく。SIは自前でシステム環境を構築することで差別化を図り儲けていた側面も強かったけれど、クラウドがハードのアウトソースを加速させた事でシステム開発案件の単価は下がっているし、価格下落話には枚挙に暇がない。目の上のたんこぶではあるが、業界のパイは小さくなったとしても優秀な人間にお金が回るようになれば長期的には良いこと的な帰結を考えていた。 でも、その歪みがひどい事態を生んでしまったようで・・・ 一方、SIおよびSEのこれからに暗い影を落とす話もある。関西のあるSE派遣の企業のはなし。 何十人もの新人さんを集めて、無料でプロジェク

    クラウドがもたらしたSIの価格破壊の果て - GoTheDistance
  • 富士通の3万人SE職務転換大作戦は成功するのか? - GoTheDistance

    全文は紙面でないと読めないのが残念ですが、非常に気になるニュースが飛び込んできました。 富士通、余剰SE変身作戦 富士通がグループで抱える約3万人のシステムエンジニア(SE)の大がかりな職務転換に乗り出した。一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むSEは仕事がなくなり、余剰人員問題が顕在化するからだ。野副州旦元社長の急進的な改革路線を修正した富士通はSE余剰問題で軟着陸を目指すが、クラウドの奔流にのみ込まれる危うさもはらむ。 富士通、余剰SE変身作戦 実は富士通グループさんには弊ブログを頻繁にご覧頂いておりまして、企業ドメインの中では最もアクセスの多いドメインであります。クロールしにきているのかなと思うぐらい。ブログで言及している「なんでもかんでも受託開発では、もうSIビジネスで成長することは出来ない」という危機

    富士通の3万人SE職務転換大作戦は成功するのか? - GoTheDistance
  • はてなのエンジニア退職劇に思うこと - GoTheDistance

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

    はてなのエンジニア退職劇に思うこと - GoTheDistance
  • それでもアジャイルに未来があるとすれば - GoTheDistance

    前回のこのエントリの続き。 アジャイルって受託開発との相性が最悪な気がする - GoTheDistance 受託開発との相性の悪さについて問題提起をしてみたのですが、アジャイル開発って内製向きだよね以上のことが言えなかったので、もうちょい掘り下げてみます。 アジャイルや受託という切り口で書いてみたんですが、僕も頂いた様々なフィードバックを鑑みて考えたところ、受託も内製も滝も俊敏も関係なくて、要は「前工程の成果物を後工程で活用できず断絶されている」ということが全ての根幹にあるように感じた。 ソフトウェア開発は「設計→実装→テスト→改善」のサイクルを回して初めてPDCAが回るのに、我が国では何故か「設計でPDCA」→「実装でPDCA」→「テストでPDCA」という感じになっていて、前工程の成果物が後工程でフィードバックができず、やる必然性の無いことを違うレイヤーで繰り返しているんですね。で、当然

    それでもアジャイルに未来があるとすれば - GoTheDistance
  • 面白いことは他人がやりたがらない事の中にある - GoTheDistance

    僕は「他人がやりたがらないこと」に興味を持ちます。リスクを取らないと血が騒がないという子供じみたしょうもない性格が大きな理由ですが、面白そうだなって感じることは基的に他人がやりたがらないことが多いのも一因です。 このブログをずっと続けて16000近くブクマを頂きましたが、ブクマが集まることは発信者にとってプレッシャーになることもあります。でも、読み手のことを先回りして「ああ言われたらどうしよう」「こういわれたらどうしよう」と波風立たないようなことを書いては、誰も僕を評価してくれなかったと思います。どこから弾が飛んでくるか分からないけど持論を展開してホッテントリ等に入ったりするから、評価して頂くきっかけや軸が生まれて、今がある。叩かれるのは誰だってイヤだし、書いてもカネが貰えるわけでもないし。ブロガーのメリットは対岸にあって、海を自分で渡らないと享受できないもの。損な側面がいっぱいあるけど

    面白いことは他人がやりたがらない事の中にある - GoTheDistance
  • 最近SIerがだいぶヤバくなっている件 - GoTheDistance

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

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

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

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
  • エンジニアの未来サミット0905に行ってきた - GoTheDistance

    0905:エンジニア・サバイバル | エンジニアの未来サミット … 技術評論社へいって来たので、速報レポ書いておきますね。 当は遅刻せずに行くつもりが、人限定郵便なるものが午前中に来なかったことと弊社社長に捕まってしまい色々コミュニケーションとってたら遅れてしまい、第1部は1時間ばかり最初見れなかった>< 第二部は、後ほどの実況ログをぜひご覧ください!津田さんメソッド、やっぱりすごい有益。この言葉使うの申し訳ないんですが、「tsudaりに行く」だけでも結構価値があるんだなーと思った。 こういうイベントって、特定のテーマに沿ったカッチリした結論なんて絶対出ないと思うんですね。パネルなんか特にそうですし。で、200人近くいたら当然各々の問題意識やおかれている状況は異なる。そんな中で、何か1つでも拾って帰って頂けるような言葉・気づきさえあれば、僕はそれでいいんだと思います。その意味で、今回の

  • 知らないと損するフレームワーク思考活用法 - GoTheDistance

    ホッテントリメーカーからタイトルを頂戴した。id:phaさんありがと。 社会人なら押さえておきたいフレームワーク思考 : LINE Corporation ディレクターブログが非常に人気で今年のアルファブロガー(というかエントリ大賞に見える)大賞にもノミネートされている。こういう記事はニーズがありそうなので、僕なりにフレームワーク思考についていくつかサンプルを用意し、僕が使うチャートのサンプルを紹介しておきます。 というか1000以上のブクマとか・・・嫉妬!激しく嫉妬!!ハンカチ噛んじゃう!!!! そもそも議論しちゃいけないこと 個人の価値観に依拠し、お互いの主張を出し合っても全体として合意が得られそうにないこと。例えば「浮気の定義」とか。こんなのは議論したって全体最適なんて導けるわけが無いので、ビジネスの場では全く持ってムダです。居酒屋でやりましょう。 仕事で議論することの意味 あなた

    知らないと損するフレームワーク思考活用法 - GoTheDistance
  • 簿記と会計と財務の違いについてまとめてみた - GoTheDistance

    また、お金の話についても、そもそも簿記(booking)・会計(accounting)・財務(financial)の区別がついてない人が多いです。 株式会社スターロジックの羽生章洋が書いてるブログ:起業・経営の必要条件 「やべー正直わかんねぇ、オレってだせぇ」と思った紳士淑女のために、ざっくりまとめてみました。突っ込みはゆるふわでお願いします>< 簿記とは 企業が日々行う取引から、貸借対照表や損益計算書を作成するための元ネタ(総勘定元帳)を作ることです。単式簿記・複式簿記とかもあくまで方法論です。ただ、企業組織の場合は家計簿とは違い、発生したお金の結果だけではなくその原因について因果関係を踏まえて帳簿をつけていかないと、プラスとマイナスが正しく管理できない。つまり、5万でEeePCを買ったという行為だけを管理するのが単式簿記で、5万円のEeePC入手&現金5万円の支出を紐付けて管理するのが

    簿記と会計と財務の違いについてまとめてみた - GoTheDistance
  • プログラマが仕様を決めればいい - GoTheDistance

    最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部

    プログラマが仕様を決めればいい - GoTheDistance
  • 1