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

こんにちは、らくからちゃです。 なんだか、こちらの記事をきっかけとして、色んな方から『長時間労働あるある』が出ているみたいですね。 ちょっと私も鎖自慢をさせていただくと、先々週の土曜日から元気に連勤中ですヽ(=´▽`=)ﾉしかも何故か、今週は今日(金)・明日(土)と泊まり込みの研修です。ウエーイ！ まあ色々と私が未熟だったところに不運な事故が立て込んでしまい、何だか素敵な状況になってしまったのが発端ですが、流石にずっと働きっぱなしだと何が何だかよく分からなくなってきますね（まだブログ書いてる余裕ある分マシな方だと思いますが・・・） それはさておき、いつもの改札を出て階段を登ろうとしていたら、こんな物がはられていました。 皆さん、10月は年次有給休暇取得促進月間です。社畜労働をしてる場合では有りません。清く正しく美しい国民であれば、仕事と生活の調和のために、『プラスワン休暇』で連続休暇を実現

働く時間を激減させながら、増収増益を続ける。掲げるのは、従業員の健康を企業価値創出の基盤と位置づける「健康経営」。斜に構えた人からは「キレイ事」「夢物語」などと言われそうな話だが、実際にそれが十分できることを証明している企業がある。しかも、構造的な長時間残業やメンタルヘルスの問題が指摘されるIT（情報技術）産業にだ。 残業時間を激減させると同時に増収増益を続けている、SCSK。数年前までは他のIT企業同様に労働環境の問題に悩んでいた同社に、何が起きたのか。仕掛け人の中井戸信英会長・健康経営推進最高責任者が、その要諦を語った。 日経ビジネスは6月15日号の特集で活力ある働き方を実現する「戦略投資」として、健康経営を推進することが、エクセレントカンパニーの新条件であることを示した。普通の企業よりも「厳しい条件」から出発したSCSKの取り組みは、多くの「働く人」や企業経営者にとって参考になるはず

In an attempt at damage control, the CEO of the equity management startup Carta, Henry Ward, today emailed customers, telling them that if they are concerned about “negative press” tied to the out In the Lego-like world of Roblox, about a hundred blocky avatars march through a lamplit street, wielding Palestine flags that are larger than their own animated bodies. Characters dressed like cartoo

「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり

1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い

ほうほうと思って内容見ていたのですが。。。ちょっとだけ。 プロジェクトマネジメントで大切な一つのこと まあ、プロジェクトマネジメント語る上で、スケジュール管理や課題管理など、色々管理しなければならないことがあります。 PMBOKでは、以下の様なことを管理しろとあります。 総合管理 スコープ管理 タイム管理 コスト管理 品質管理 人的資源管理 コミュニケーション管理 リスク管理 調達管理 ステークホルダ管理 教科書的には上記のような管理が大切なのできちんと行いましょう、というのが答えになるんでしょうけど、それだけだとつまらないので。。。 オッサンが考える、プロジェクトマネジメントで一番大切なことは何か、と聞かれればぶっちゃけ「計画」かな、と答えます。 要は、不確定要素がなくやるべきこと明確で、ステークホルダーの誰もが文句を言わないような状態に持ってきて。で、スケジュールも余裕。予算もきちんと

はじめに 技術を学ぶというのはすごい個人差のあることだと思います。 個人特性もあるし、興味の向く対象も違う。 組織にはいろんな人間がいる。 そんな中、いくら「技術力を学ぼう！」と啓蒙しても、 響かないことってありませんか。 最終的には人それぞれの問題にはなってくるのだけれど、 それって、現場ロックインが一因なのではないかなと思う。 現場ロックインの定義 「特定ベンダー（メーカー）の独自技術に大きく依存した製品、サービス、システム等を採用した際に、他ベンダーの提供する同種の製品、サービス、システム等への乗り換えが困難になる現象」をベンダーロックインという。 (Wikipediaより引用) 現場ロックインは僕の思いついた単なる造語で、 「特定のプロジェクトに特化した技術や顧客の事情を重視しており、 その他の現場に移動しても殆ど役に立たないローカルルールに依存している現象」を指す。 会社に対して

最近会った人とよく話すのが、ソフトウェアプロセス技術がロストテクノロジーになってるんではないかということです。 ソフトウェアプロセスというのは、「プロセスがよいソフトウェアをつくる」という前提のもと、どのようなタイミングでどのような成果物を作り、どのような管理をし、どのように検査をしてソフトウェアを作るかという手順です。 そして、プロセス技術というのは、そのようなプロセスを構築し運用し改善する技術です。 このようなソフトウェアプロセス技術は、1995年くらいから2000年くらいにかけて盛り上がり広まりかけたのですが、そのタイミングでWebが広まりはじめ、「Webは進化が速い」「作るものがどんどん変わる」などを合言葉に、「アジャイルプロセスを採用する」という名目でなんら管理されないプロセスが普及しました。その結果、プロセス技術は完全に下火になっているように思います。 もちろん、Webの発展段

なかなか面白い記事を読みました。 正直、「自分の意思決定の正しさに価値を置いている人」は一生改善しないのではないかと思っている。 詳細に指示を出せば出すほど無能になる人について - ベンチャー役員三界に家なし まずマイクロマネジメントして見て、結果が出せる人とどうにもこうにも自分の思い通りにしたい人を分けること。 そして後者を戦力から外すことを行ってほしい。 場合によっては無理に稼働させず、コストと割り切って隔離する方法も検討すべきだ。 ふえー。いるよねこういう人。あるある感が凄すぎてたまらん… で、まあ直接は関係ないんだけど、仕事を「任せる」ということについて最近思うこと。 現場で見ていると、リーダーにもいろんな人が居て、いろんなレベル感があります。この業界特有の問題なのか、単にうちの現場にそういう人が多いだけなのか、はたまた世間一般的にそうなのかはわかりませんが、叩き上げリーダーに多い

とあるプロジェクトのリーダーというか、会社でちょっとした仕事のまとめ役をやった。 そんな中で見えたことがあったのでメモ。今後の自分のために。 あとリーダー経験がやたら就活で重視されたのも分かった気がした。 ＜リーダーから見た印象の良い行動＞ ・レスポンスが早い（最重要） とりあえず、「見ました！了解です！」くらいがあるのと無いのとじゃ全然違う。 というか、リーダーの立場って結局独りよがり感すごいのでレスポンスあるとかなり安心します。はい。 ・少しでもいいから改善策を提案してくれる ほんとーに些細なこともでいい。一番はこちらが作った何かを改良してくれるの最高。ちょっと記載もれしてたところ指摘とかでもいい。 別に自分がわかっててあえて後から書こうとしてたところも「ここ抜けてると思います」っていうのでもいい。 何も言わずにいる人より全然良い。というかちょっとしたことがクリティカルヒットなので、こ

精度高く工数を算出しても，単価の設定がいい加減ではコストがブレる。職種や工程はもちろん，地域やスキル・レベルでも相場は変わる。人月単価の相場はどうすれば把握できるか。専門家に解説してもらった。（本誌） 「SEの人月単価100万円は高いか，安いか」――。皆さんはどう思うだろうか。あなたが勤めている会社の規模で答えが変わるかもしれない。勤務地が首都圏か地方かでも，答えが違うだろう。人月単価注1の相場観は，人によってバラバラなのが実情だ。 筆者が勤めるアイ・ティ・アール（ITR）ではベンダーがユーザーに提示した見積もりを精査する機会が多い。そこでの経験から，見積もりの現場では人月単価について次のようなことが起きていることが分かっている。 ●ベンダーごとに異なる 中級SEの人月単価は，大手ベンダーでは95万円から190万円，中堅・中小ベンダーでは65万円から120万円だった。このように大手ベンダー

2015-03-19 エンジニアスタートアップは１人でいいから通訳を雇ってくれ 「エンジニアの言葉を通訳する人間が必要」 前の会社でよく言われていた言葉であり、「通訳」が必要なくらいエンジニアとビジネス側には隔たりがあるのだ。 私はマーケティングやファイナンスの人間だ。何をやっていくら儲けるかを考えるのが仕事。なので、無駄なコストをカットして、注力すべきところに投資したり上手にヘッジすることがミッションだ。 だが、その仕事の中でやっかいな存在にあたるがエンジニアだ。 彼らは何をしているのかよくわからない。外注のデザイナーやコーダーは何を作っているのかがよくわかるけど、正社員メンバーの、システム基盤？だのアルゴリズム？だのやっている人たちについてはまったくパフォーマンスがわからない。 部署横断のミーティングなんかやると温度差に驚く。 営業「営業の仕組みを変え、売上をキープしつつコストをダウン

上流工程に積極的に参加を 当事者意識が欠けてはいないか それまで付き合いのなかった大手ITベンダーに、システム構築を発注した。他のネット広告企業のシステムを構築した経験があり、SEのスキルも申し分ないと考えて、仕事を任せた。 ところがこのプロジェクトは要件定義の段階でつまずいた。我々は経営層や利用部門の要望をまとめきれず、要件定義が遅れた。そこで、このITベンダーの営業担当者やSEに、作業の進め方に不備がないかどうかアドバイスを求めた。 すると営業担当者は、「要件定義は担当の範囲外です」と言う。SEは当社に常駐しており、我々の苦労を把握していたはず。だが、「要件定義書が完成しなければ、開発作業に着手できません。納期を守るためにも急いでください」と、他人事のように言ってくるだけだった。 もちろん、要件固めはユーザー企業が責任を持って進めるべき作業であると分かっている。しかし、こちらが助言を求

最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意

＜　前回　｜　目次　｜　次回　＞ 今回はＰＭＯの役割や具体的な仕事について考えてみましょう。 １回目で少し触れたとおり、組織・プロジェクトによって様々な形態のＰＭＯがあり、それぞれＰＭＯに求められることが違います。１回目に以下の３つの事例をあげました。 (1) 実プロジェクトに参画し管理や技術支援を行う。事務局も担う。必要に応じてトレーニングを計画し導入する。 (2) プロジェクトマネジメントや開発の基準・標準を策定して、組織内のプロジェクトに基準・標準の適用を促す。 (3) 組織内で立ち上がっているプロジェクトの状況を纏め、組織長に報告する。 この事例毎に具体的な仕事をあげてみましょう。 (1)　実プロジェクトに参画し管理や技術支援を行う。事務局も担う。必要に応じてトレーニングを計画し導入する。 この形態は、中規模～大規模プロジェクトに設置するＰＭＯですね。大規模プロジェクトになると、イ

最初に、損益分岐点の説明からはじめよう。企業は、製品やサービスを売って売上を得る。しかし、世の中にタダの物はないので、そこには必ず費用（原価）が発生する。その費用が製品の販売数量に単純に比例する場合、企業は売上に比例した利益を得ることになる。この関係を図(a)に示す。横軸は、売上である。工場の視点から言うと、売上向上すなわち稼働率向上を意味するから、横軸は稼働率と見てもよい。縦軸は金額で、実線が売上高を、点線が費用を示す。費用は純粋に、売上高に比例する。これを変動費ともいう。売上に伴って、変動するからである。たとえば製品を作るのに必要な原材料の購入費がそうだ。あるいは、製品を加工するための外注費などもそうだ。 ところが、企業にはこれとは別に、売上高にまったく関係なく、固定的に発生する費用がふつうある。これを固定費という。その典型例は、設備機械の減価償却費である。あるいは、従業員の給料なども

作業途中のメモです。バッチ処理の定義を確認しようとしてWikipediaをはじめとして幾つかのサイトをみてました。その時に目に入ったのが、下記の文章です。 利点 バッチ処理には以下のような利点がある。 ・多くのユーザーがコンピュータのリソースを共有できる。 ・処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。 ・人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。 ・高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。バッチ処理 - Wikipedia これだけみると、人件費に対してコンピュータリソースが高い時代の産物なんですよね。今は、クラウドの登場で、有り余るコンピュータリソースをほぼ自由に低コストに使える時代です。そもそもバッチ処理である必要があるか、考える必要がありますね。特に夜間バッチにつ

風邪引いてしばらくブログ更新サボってました。 上記記事について、気になったので。ブコメで言及ももらったし。 ウィキペディアのバッチの利点って若干記載が古い 多くのユーザーがコンピュータのリソースを共有できる。 処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。 人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。 高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。 バッチ処理 - Wikipedia バッチをリソース目的だけで使うってずいぶん古い話だなあ、と思って編集履歴をたどってみたら、2006年の記載でしたか。 記載をたどってみると分かるんですけど、上記の内容って「メインフレーム」のバッチ処理に対する利点なんですよね。 そういった意味では、現在のバッチの設計とはちょっと概念が違うんじゃないかな

今回の題名は前回書いた『「できない人」にいくら教えても「できる人」にならないのか』のもじりである。 前回記事は、想像以上に多くの方に読んでいただいた。この場を借りてお礼を申し上げる。ただ、なぜ読まれたのか、その理由を書いた当人は今ひとつ分かっていない。 「身も蓋もない発言」をそのまま紹介したのが良かったのだろうか。それでは柳の下のどじょうを目指し、別の「身も蓋もない発言」を紹介してみたい。今回は営業の話である。 「無理です。なぜ請けたのですか」 営業担当者（以下営業と表記）が仕事を受注してくる。その仕事を実際に手がける技術者を集めて、仕事の内容や納期、費用などを説明する。 説明を聞いた技術者は唖然として言う。 「無理です。こんな仕事をなぜ請けたのですか」 反発を見込んでいた営業はあらかじめ考えていた台詞を使って現場を説得、いや、制圧にかかる。 「競合に勝つには、この条件で提案するしかなかっ