ただの作業者（ワーカー）と呼ばれないための、たった1つのやるべきこと - レベルエンター山本大のブログ
エンジニアであるかどうかに関わらず、どんな仕事であっても 作業者(ワーカー)と、それ以外を分ける基準は一つだと思います。 それは判断することです。 僕は、判断する量が多いか少ないかで、その人の仕事上の価値が大きく変わると考えています。 もしも、まったく判断をせずに仕事をしているなら、その人の価値はワーカーです。 ワーカーが悪いわけではないですが、ワーカーはいつもたやすく取って代わられます。 優秀なワーカーもいます。それはそれで価値があります。 でも、ある人が自分で判断をするたびにその人の価値は上がります。 「権限も役職もないから、判断なんてできないよ」 と言う人がいます。 たしかに判断は責任を伴います。責任者が判断するべきというのは正論のように見えます。 でも別の見方をすると「役職を与えられたら、いきなり良い判断ができる」というものではありません。 そう考えると、判断できる人に権限があたえ
設計書よりもユーザーマニュアルを書こう！ - レベルエンター山本大のブログ
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージＩＤのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版２」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく３つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
はよプログラマとかエンジニアとかから脱却せんかい。 - レベルエンター山本大のブログ
プログラマの誇りがどうこうと書いていていうのもなんだけど、 プログラマが下手に誇りを持ちはじめた昨今。 いい加減、うんざりしてきた。職業ぷろぐらまな面々に。 作る技術がスキルのすべてだと勘違いしてるぷろぐらまに。 誰をターゲットに吠えるわけではないけれど、 我慢してることを言います。 仕事＝きれいなコーディング 仕事＝疎な設計 仕事＝きれいなドキュメント とか、そんなことで満足してんなって。 作る技術をバックボーンにして、 話をまとめる力をつけて、 要件をまとめる力をつけて、 交渉をまとめる力をつけて、 費用抑える力つけて、 お客さんの要件を引き出して、実現して、貢献して、 初めて仕事が成り立ってるんだろうが、 ビジネスが成り立つんだろうが。 目指さんかい、営業からテストまで1人で全部実現できるぐらいの境地を。 一周して来いって。 それができるまではずっとワーカー。 #追記 ワーカーは煽り
与えられた環境と分析し、戦い、乗り越えることで、与える側に立つ。−募集に対するQA - レベルエンター山本大のブログ
一緒に働いてくれる人を募集とか呼びかけてみる - 山本大の日記についてトラックバックで質問をいただきました。 これはとても有難い反応ですので、感謝の気持ちと共に、僕なりの答え方で答えさせていただきます。 【トラックバック】 採用募集について、幾つかの質問 - @katzchang.contexts Q 「大中規模の〜」とありますが、規模とは何のボリュームをさすのでしょうか（ユーザ数？データ数？ステップ数？）？ また、どの位が中規模以上となるんでしょうか？ A 僕らが携わっているシステムは100万ユーザであり、大規模といえるでしょうね。 それに対して僕が1年前に携わったシステムは、総ステップは100万ステップ以上ありましたが、 保守プロジェクトで、2人で追加機能をつくっただけなので小規模プロジェクトでしょう。 じゃあ、何が正しい答えなの？と思うかもしれませんね。 僕らが提示した「条件」は応募
一緒に働いてくれる人を募集とか呼びかけてみる - レベルエンター山本大のブログ
この不景気のご時勢にあって、ありがたいことにクロノス東京は人が足りません。 なので、とても大きくて有名なシステムのJavaシステムアーキテクチャを策定するという仕事に ワクワク感を感じる人を探しています。 プログラマーの誇りを取り戻すために協力してくれる人を。 まだ東京にきて間もないクロノスですが、 この会社の東京での仕事の中核になって支えてくれる人を募集したいと思っています。 でもぶっちゃけ技術について、新しくて面白いことについて、 語らい、共に夢を見られる仲間が欲しいです。 僕は、大学のころから「鶏口牛後」がひとつのポリシーでした。 牛の尻となる（大企業の端っこにいる）よりは 鶏のくちばし（小さい企業でも先頭）となれと、 と言う意味で、僕らクロノス東京は、まさにそういったフィールドです。 同じ年代の同じようなスキルでも、大企業の末席にいるのと 小さな企業の先頭にいるのでは得られる経験値
机に向かって取れる解決法だけを並べて「限界だ」なんてあきらめてないか？ - レベルエンター山本大のブログ
プロジェクトで発生する様々な問題の答えは、IT技術や開発の方法論だけではありません。 問題解決のためには、あらゆる手段を視野に入れてのぞむ必要がありますが、 僕らエンジニアは「あらゆる手段」を狭く取りすぎていることがあります。 「あらゆる」と言いながら、机の前、パソコンの前に座って取れる方法だけにとらわれていたことが 僕自身にもありました。 そのプロジェクトのエンドユーザーさんはとても田舎の工場で、 僕が勤務してた大阪の市内からは、車で行って2時間（高速代などで10000円）、 電車で行くと2時間40分（片道3000円）かかるところにある、 なかなか厳しい立地条件のお客さんでした。 僕はこの案件で、要件定義から参画しましたが、 ミーティングをするために、客先に出向いても往復に4時間以上かかるので せいぜい3時間しかミーティングの時間が取れません。 このため時間的にもお金的にも、ミーティング
設計者として一流になりたいなら足で稼げ - レベルエンター山本大のブログ
開発の仕事をするためにもっとも大事な力の一つは”判断力”であり、 判断のために一番頼りにするべき情報は、自分の手・足・目・耳で稼いだ情報だと思います。 それを実感する出来事が、このシルバーウィーク中にありました。 この休み中、僕は10月から東京に出てくる部下のためにマンション探しをしていました。 いくつもの物件情報の中から特に目を引いたのが、駅から徒歩3分という物件でした。 ほかの物件は、同じ価格帯だと大体徒歩8分から10分なので、大いに魅力に感じました。 その物件を見に行くことにして現地へ行ってみると、内装も間取りも問題ないレベルでした。 そこで徒歩3分ぐらいなら、ちょっと駅まで歩いてみようと考えました。 手元に地図を持って、いざ歩いてみると全然遠い！ 3分どころか10分ほどもかかってようやく駅に着きました。 物件情報が間違っていると文句を言っても、 「基準にしたがって表記しています」と
データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
よい聞き手になりたいなら、絶対に質問を考えながら話を聞くこと！ - レベルエンター山本大のブログ
「コミュニケーション上手は、聞き上手である」 といったことがコミュニケーションの本なら必ず書いてある。 聞き手として、そのコミュニケーションを有意義な時間にするための秘訣がある。 プレゼンを聞きに行ったり、顧客に要件定義のヒアリングをしに行ったり 上司と面談をしたり、部下の面談をしたり、どういうコミュニケーションでも共通する。 どんなものであっても、話の聞き手になったときは 絶対に質問をすることだ。 あなたが誰であっても、相手が誰であっても、問答無用。 質問をするためには聞きながら質問を考えること 「最後に、何か質問はありませんか？」 と聞かれてから考えては思いつかないものだ。 狙っている異性と、良い感じでおしゃべりしてるときは 話をしながら次の質問やフィードバックを考える。それと一緒。 講師をしていても思うんだけど、スピーカーは質問してくれた人のことしか覚えていない。 学芸会で緊張したと
スケジュールを作って、「問題対私たち」の構図に持ち込もう - レベルエンター山本大のブログ
スケジュールを作るプログラマが一番効率が良い。 - 山本大の日記のエントリに プログラマが作ったスケジュールはいつも壊される - @katzchang.contextsでトラックバックを頂いたので返答します。 すべてに返答差し上げたいところですが、長くなるので部分的に。 id:katzchangの言ってる状況は、昔僕もよく経験しましたし納得できますね。 僕の場合はそういった状況に陥らないために、自分がマネジメントをする立場になりたいと考えるようになり、現在はやばそうなプロジェクトに１SEとして入っても、そうそうトラブらなくなったので、ある程度の結果は出ていると思います。 好きなプログラミングの仕事に集中したいなら、プログラミングスキルと共にマネジメントスキルをツールとして持っておくことは大事だと思います。 とは言え「マネージャになれ」というのは解決策としては遠回り過ぎるので、もう少し現実的
スケジュールを作るプログラマが一番効率が良い。 - レベルエンター山本大のブログ
現場の周りのプログラマさんたちが残業する中、 僕が毎日定時で帰って高品質なプログラムを作れる理由は、 僕が自分でスケジュールを作ってから仕事を始めるからだ。 僕が今の現場に入って始めにリーダーさんからこういわれた。 「スケジュールがきついので、 管理工数がもったいないから、管理資料に手間をかけたくありません。 イキナリ作業に入ってもらってかまいません。」 若い頃ならうっかりその言葉に惑わされているところだが、 そうはいかない。スケジュールがきつい時ほどコントロールが必要なのだ。 何を先にやっておかないといけないか、 今週末までにどこまで進めておけば安心か。 これらがわからなければ、不安に駆られるばかりだ。 不安を取り除くという意味だけでもスケジュールを組むことは非常に役に立つ。 ドラッカー風に言えば、 「ミッションに集中するにはマネジメントを駆使しなくてはならない」 ということだ。 プログ
テストのエビデンスが品質を下げてる実態 - レベルエンター山本大のブログ
今の現場は、テスト結果の精密なエビデンスが求められる。 今日はバグつぶしそっちのけで、テスト実施結果に対するエビデンスを採っていた。 数100項目のテストケースに対する画面キャプチャやデータキャプチャのエビデンスを採る。 これを綺麗に整理して、お客さんのハンコを貰わなくては本番にあげられないルールだ。 コア部分のバグ改修できるのは僕だけだが、まにあわないのでバグよりもエビデンスを優先した。 品質よりも品質保証を優先したわけだ。 う〜ん、事情はわかるけど、、、あほくさい。 バグを見つければ見つけるほど、強烈なエビデンス編集作業があるから テストをやってくれてるプログラマーさんも、恐る恐るテストを叩くようになってしまった。 っていうか200ページを越えるテストエビデンスをお客さんに確認させるのってどうやろ。 超大手sIerのBigなドMっぷりには、恐れ入りました。 本質的なサービスに集中できる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
