僕は器用貧乏です。色んなことがそこそこできるという、一般的なキャリア論では最もダメな部類に入ると思います。餅は餅屋。ドラッカー先生も言うてはる。あなたは何によって知られたいのか、それが重要だと。 エンジニアとしてキャリアをスタートさせて、恐ろしいことに10年以上の月日が経ちました。残念ながら、エンジニアとしては絶対に大成しないという確信があります。コードを書くのは好きです！でも、要素技術を突き詰めようという気持ちがすごく弱いのです。1つに絞り込むってことが、生理的に出来ない...全く違う分野に対して興味を持ったら、もう止められない。 そんな人って、実は技術職のエンジニアでも結構いるんじゃないかなっと感じたので、ブログ書きました。1つの分野の専門性が築けなくて悩んでいるのなら、「そーゆーの向いてないわ、俺」で諦めちゃったらいかがでしょう？ 僕のように。 僕より優れたエンジニア、僕より優れた営

言いたいことがストレートに伝わる良い文章だと思います。 simplearchitect.hatenablog.com ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。 では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。 確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？ 僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエア

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

あるあるネタだと思いますが、組織がより優れたパフォーマンスを出す為にやっちゃいけないことが「出来る人とできない人がいた場合、出来ない人のためにレベルを下げること」です。 優れた解決策を持ってる人に合わせよう コードのバージョン管理で、出来へん人が「あの僕はGit使えないんでZIPで差分管理して欲しい」とか言い出した時に「そうだね！出来ない人に合わせないとね！」とはならず「Git覚えて」となるでしょ。優れた解決策を持ってる人が、結局は出来ない人を助けている。わかりやすいでしょ。— やきう大好きござ先輩 (@gothedistance) 2015, 12月 24 簡単にいえば「↑」のようなことです。非エンジニアの方にはわかりにくい例ですが、Excelをファイル名＋日付＋バージョン名で複製して管理するのはとても大変ですよね。そんなことをしなくても良いツールがあるんです。それを使える人がいるのであ

発表資料はこちらにございます。 Bpstudy#92 エンジニアの経営学 from Michitaka Yumoto www.slideshare.net お金の流れについて知ったから良いエンジニア人生を築ける理由にはならないんですけど、会社組織と無関係では生きていけないので... 会社組織の論理ってものがあります、と。その上で仕事とお金の関係だけは精査して整理しておかないと色々不幸なすれ違いもあるんじゃないかなってことで、その辺をまずお話させて頂きました。現場に居続けるのもなかなか難しいチョイスになると思いますし。 この資料を作るにあたって本屋さんや図書館で経営学と書いてある本を結構読んだんですが、どの本でも組織運営について多くのことが書かれておりました。会計の話は触れていない本も多かった。ビジネスモデルの構築であったり経営戦略理論であったりというのは、時代が変わると再定義されてきてい

べき論というのは「義務を果たすこと、理想を実現しなければならないこと」などを強く主張することだけど、何も生産的な要素がないなぁとつくづく感じました。 べき論で自分の考えが無駄に縛られて精神的な自由さが奪われてしまう。べき論はしないことも同時に規定するので、自ら望んで板挟みになるようなもんだ。「すべき」と「しないべき」の板挟みの果てにできるのは「かくあらねばならない」という強烈な固定観念。強烈なリーダーシップを発揮することもあるが、思考の引き出しが１つしかないので、切羽詰まると正論(**であるべきだ)としか言えなくなってしまう。 べき論は終わりがない。言われたら言われるほど、自分に課されている義務や理想が膨らんで負担が大きくなってしまう。本当はミニトマトぐらいの大きさでしかないのにね。そして、その精神的負担は常に付きまとう。終わりが無いから。何を言ってもべき論で返されたら、これほどめんどくさ

この記事面白かったです！ 「出来る」と「実装する」の間には多くの解決すべき問題が含まれているから気をつけろよっていう警鐘を鳴らしている記事なのに、「出来るからやるって単純バカなんだけど」っていう反応が多いのが印象的でした。その理由の９割は、タイトルに「エンジニアはネ申」って書いたせいだと思うけど。 私からは、社内業務システム内製を通じて感じました、創造主であるところのエンジニアとハッピーに仕事をするためにはこういうことを一緒に考えよう、っていう話をしたいと思います。 実装可能と実現可能は別問題 前述の記事も僕の補足も、主題はこれだけ。だいたいそんな感じ。でも、順を追って説明します。 技術的に実装可能なのか否かは、当然一番最初に考える問題です。そこでNoならこの話は終わります。技術的と簡単にまとめますが、エンジニアによって判断基準は全然違うから悩ましいです。そこは差し引いて、単純に求められた

日本実業出版社の今野様より献本御礼。 「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則 作者: 細川義洋出版社/メーカー: 日本実業出版社発売日: 2014/07/10メディア: 単行本（ソフトカバー）この商品を含むブログを見る なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術に続く、細川氏の第２作。前作ではITシステム開発の難しさを題材に網羅的にユーザーやベンダーがプロジェクト運営で失敗してしまうポイントを挙げられておりました。いわば、入門編という位置づけですね。本作では実際にプロジェクト運営でモメてしまう所も判例を通じて論じており、いわば「実践編」という立ち位置になっています。モメてしまうポイントを先回りして、フェーズ毎にヘルスチェックをして頂いております。 本書は女性弁護士キャラは出てきません。悪しからず。 システム開発は複雑系の極み 本

全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ

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

Twitterで流れてきたのでつい見てしまいましたが、この方の連載は全体的にやっつけ感が否めないですね。 なぜ“ダメなシステム”は無くならないのか？ - なぜ“ダメなシステム”は無くならないのか？：ITpro この"ダメだしとっつあん"があの手この手で言わんとしてることは｢上流工程と下流工程の分断は悪であり、ダメなシステムはそこから生まれている｣ということですので、この記事を読んだ人は連載読まなくて大丈夫です。僕が書いたこのエントリ読んでください。もっと突っ込んで書いてあります。 ｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistance もうそろそろぶっちゃけてもいいでしょ。ダメなシステムができる理由は簡単だってことに。ウオーターフォールが逆流できないせいだ/丸投げするからダメ/リスクをとらないからダメ/技術力のないやつが舵を取るからダメ・・・ってさ

インターネットの備忘録（はてなブログ版）にインスパイアされました。交渉や調整で、僕が感じている「やってはいけない」ことを、便乗して書いてみます。 1. 相手の面子を潰してはいけない 自分の主張を通す為には相手の言っていることの弱点を突いて｢あなたが間違っている｣というものだと仮に思っているのであれば、あなたは色んな人の面子を潰しまくることになりますので、利害が絡む交渉ごとは一切お引き受けにならない方がよろしいかと思います。交渉下手な人間は、利害に関する交渉で行き詰まると相手の間違いを非難する方向にいきやすく、それは結果として自ら交渉を難航させる種を散弾銃で乱れ打ちしていることになります。 感情と感情がぶつかったら、もうそれは交渉ではありません。口喧嘩です。 2. 間違い探しに終始してはいけない 交渉や調整ごとは、どっちが正しいか的な軸で考えてはいけません。自分が正しいかどうかは、関係ありま

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

ITを活用した経営戦略を考える上で非常に示唆に富むエントリだったので、ご紹介。２回は読もう。じっくり読もう。 http://www.searchengineoptimization.jp/for-local-web-design-company-to-survive これはWebサイトを業務システムに置換しても、全く同じことが言えます。頭の痛い問題です。 使い手と作り手の溝について 下記の記述に危機感を持てるかどうかで話は全く変わります。恐らく、一度でも自分で仕事を請けてWeb制作したことがあればすごく身につまされることでしょう。 熱心にウェブの活用に取り組んでいる地方の中小企業は数多く、全国津々浦々まで無数に偏在しています。その彼らが、一様に困っていることがあります。それは「相談相手になってくれる専門家が近くにいない」ということです。 (中略) ウェブ制作会社ならお近くにもあるでしょう。