【有能リーダの鉄則】同コンテキストでの有能リーダ vs 無能リーダ - レベルエンター山本大のブログ
今僕らのプロジェクトは大きな危機に直面していると言える。 なぜなら、商流の変化からワケの分からない人が大量に流入してきているからだ。 それも、プロジェクトマネージメントメンバーとしてだ。 今、僕らが参画しているプロジェクトは、 某大手メーカーさんの優秀なエンジニアをかき集めた一大プロジェクトだ。 しかし、どれだけ優秀なメンバーを集めても、リーダシップをとるべき人たちがダメだと プロジェクトは烏合の衆にならざるを得ない。 羊がライオンを率いる状況のまずさを実感する。 しかし、このプロジェクトの面白いところは、 過去の巨大なプロジェクトで功績のあった優秀なリーダ（AさんとYさんとYさんの3人）が サブリーダ的なポジションにいて、リーダーの 無能 vs 有能 の比較が同一コンテキストで測れることだ。 プロジェクトは上流工程段階ですでに壊滅的だが リーダーの資質についてエッジの効いたエピソードを集
SI開発で再利用が必要なのは部品ではなくチームだ。 - レベルエンター山本大のブログ
この半年、巨大なシステムの開発で学んだことの1つは、 SIという業態の中で再利用が必要なのは、部品ではなくチームであるということ。 チームに蓄積するノウハウや暗黙知こそ再利用するべきで、 案件の度に体制の伸縮を繰り返すやり方では、いくら部品化や共通化を進めたって効率もへったくれもあったもんじゃない。 部品の再利用は確かに可能で、非機能的な部品やフレームワークは活躍するんだけど、 ドメインオブジェクトのレベルでの再利用はやはり難しいし そもそも部品やフレームワークは使いどころを知っていて、設計や試験を省力化するところまでやってこそだと思う。 システム開発の工程の中で、製造工程はどう考えても一部分であって設計＋試験が圧倒的に長い。（保守期間はもっと長い） 設計や試験に効果を発揮するのは、部品よりもチームだ。 例えば、僕らの現場ではSOAにも取り組んでいて、権威と呼べるような人たちがその設計をや
10年泥は正しい。入ってすぐに自分のやりたいことがやりたいなんて甘い。だけどIT業界には依然として夢はある。 - レベルエンター山本大のブログ
10年前、僕は3流文系私大をギリギリで卒業して、当時花形だったこの業界に入った。 「自分がやりたいことがやれそうだ。」という志望動機が、今思えばいかにも学生の発想だ。 その時、初めて見よう見まねで作ったのはHTMLとJavaScriptで書いた、 どうしようもないWebページだった。 「Webゲームが作りたい」とか一瞬思っていたのだが、 苦心してできたのは思い出すのも恥ずかしいような代物だった。 あの当時の「やりたいこと」など、今となっては微塵もやりたくない。 結局のところ、やりたいことと言っても当時の僕の脳みそは、 世間を知らない低次元の脳みそだし、やれる実力もない。 運よく始められたとしても継続ができないのは間違いなかった。 物事をはじめるのはたやすく、継続するのは難しい。 なぜなら物事にはトラブルが付き物で、簡単なことをクリアし続けると必ず難しい部分が残るからだ。 むやみに作り始めた
つないだ人間関係の数で、その人間の価値が決まる - レベルエンター山本大のブログ
もう、4月。4月といえば、出会いと別れの季節であり、 今日は僕らも馴染みの深い人とのお別れ会でした。 終わりはいつでも、新しい始まり。 別れは、新しい関係性の始まりだと思っています。 こういうときに常に思うことは、人間という生命体についてです。 人間というもの、人との関係性の中に自我、アイデンティティーというものができるものだと思います。 無人島に一人でいたら、自分というものは特に必要なく、 1個の生命体でしかありません。それは人の間にいないという意味で人間ですらないといえます。 20代、30代で築いた人間の関係性の貯金が、 我々の人生を決めるといっても過言ではないと僕は思います。 ちょうど、今日旅立った人は僕と同じ３２歳。 Mさんが、20代と30代前半で培った関係性を、 宝物のように大事にしてくれることを、 僕は切に願うばかりです。 宝物を貯金することが、その人の価値を生む。 20代と3
エンジニアにとって３５歳とは定年ではないが、真価が問われる時ではある。 - レベルエンター山本大のブログ
３５歳には３５歳なりの成長の仕方というものがあります。 ３５年、着実に１年１年、前に進んでいる人と、 確実にどこかで足踏みしてたなぁという人は、はっきりとわかってしまいます。 年齢というのはただの数字だけど、数字には魔力のようなものがあります。 というか、単純でわかりやすいということだけなんだけど、 その人が生きてきた成果と比較するための基準値といいましょうか。 ３５歳と聞くと、 ちゃんと向上心を持ち続けて生きてきたのか、適当に流されて生きてきたのかを どうしても見てしまいます。 ３０歳前後のエンジニアの皆さんに言います。 飛びぬけて技術に自信がある人以外は、 少しでも「リーダー経験」を積んでおきなさいよ。 本当にそこが一番重要だから。 一番汎用的なスキルだから。 人を動かせてなんぼですから。 人が作った土壌・枠組みの上で設計や実装をした経験の多さは、物の数ではないのです。 リーダ経験とい
はよプログラマとかエンジニアとかから脱却せんかい。 - レベルエンター山本大のブログ
プログラマの誇りがどうこうと書いていていうのもなんだけど、 プログラマが下手に誇りを持ちはじめた昨今。 いい加減、うんざりしてきた。職業ぷろぐらまな面々に。 作る技術がスキルのすべてだと勘違いしてるぷろぐらまに。 誰をターゲットに吠えるわけではないけれど、 我慢してることを言います。 仕事＝きれいなコーディング 仕事＝疎な設計 仕事＝きれいなドキュメント とか、そんなことで満足してんなって。 作る技術をバックボーンにして、 話をまとめる力をつけて、 要件をまとめる力をつけて、 交渉をまとめる力をつけて、 費用抑える力つけて、 お客さんの要件を引き出して、実現して、貢献して、 初めて仕事が成り立ってるんだろうが、 ビジネスが成り立つんだろうが。 目指さんかい、営業からテストまで1人で全部実現できるぐらいの境地を。 一周して来いって。 それができるまではずっとワーカー。 #追記 ワーカーは煽り
限界と比較し、相対値として記憶に残る。 - レベルエンター山本大のブログ
今から5年ほど前、東京に来ていたときは奮闘の日々だった。 毎日終電まで現場をこなした後、さらに土日もなく連載記事の執筆などに追われていた。 でも振り返ってみると、あのときの仕事は”今の僕”にとっては余裕な仕事だ。 しかし仕事の難しさは絶対値ではなく、当時の自分の限界と比較したときの相対値として記憶に残る。 あのとき力を出しきったことが、今の自信になってる。 120パーセント出し切ったときに、超えた20パーセントが新たな力になるのだと思う。 常に限界を超えるのは難しいけど、少なくとも100パーセントでやってない人は縮小傾向だといえる。 80パーセントで余力を残して仕事をするのがスマートに見えるかもしれないけど、 あとあと80パーセントがその人の100パーセントになるだけだろう。
たぶん迷ってるだろう教え子たちへ - レベルエンター山本大のブログ
去年、新人研修で教えた教え子たちも、もう現場に入って半年になります。 きっと、たぶん今頃、壁にぶち当たっているんだろうなー。 僕が今入ってる現場でも、教え子たちと同級生の人たちがいて 日々悩んでるように見受けられます。 教え子たちへ。 自分がやっていることに意義を見出せなくなってきた教え子たちへ。 自分はこれでいいのかと疑問を抱き始めた教え子たちへ。 自分のやってることの意義が見出せないのは、 自分をプロデュースしてこなかったからじゃないかい。 僕はこの業界でセルフプロデュースする2つの方法を知ってる。 1つは、自分にあってると思える技術をつけること。 でも、これは一朝一夕では効果が出ないかもしれない。 もう1つの道は、情報通になること。 研修の中でも言ったけど 発信する者に情報は集まる。 現場には、インターネットで検索できない情報がたくさんある。 めちゃくちゃ簡単な話だと、ファイルサーバ
机に向かって取れる解決法だけを並べて「限界だ」なんてあきらめてないか？ - レベルエンター山本大のブログ
プロジェクトで発生する様々な問題の答えは、IT技術や開発の方法論だけではありません。 問題解決のためには、あらゆる手段を視野に入れてのぞむ必要がありますが、 僕らエンジニアは「あらゆる手段」を狭く取りすぎていることがあります。 「あらゆる」と言いながら、机の前、パソコンの前に座って取れる方法だけにとらわれていたことが 僕自身にもありました。 そのプロジェクトのエンドユーザーさんはとても田舎の工場で、 僕が勤務してた大阪の市内からは、車で行って2時間（高速代などで10000円）、 電車で行くと2時間40分（片道3000円）かかるところにある、 なかなか厳しい立地条件のお客さんでした。 僕はこの案件で、要件定義から参画しましたが、 ミーティングをするために、客先に出向いても往復に4時間以上かかるので せいぜい3時間しかミーティングの時間が取れません。 このため時間的にもお金的にも、ミーティング
ノートはメモを取るのではなくページを作るために書く - レベルエンター山本大のブログ
東京へ来てからおかげ様でめちゃくちゃ忙しくいのですが そんな最中だからでしょうか、ノートの使い方について改めて気づくところがありました。 発見した原則は以下です。 ノートにものを書くときは、 メモを取るという発想で書くのではなく、 ノートのページを作り込むと考える。 僕の今までのパターンは、まず打ち合わせでノートを開いて 冒頭に日付と会議のタイトルを書いて、そのまま落書き帖のように キーワードを書いてしまうというものでした。 色分けなども駆使するのですが、どうしても落書き帖の域を出なかったのです。 ページを作るという発想になったのは、ちょっと高めのノートを買ったからです。 モレスキンというノートで、いろんな映画にも登場するフランス製のものです。 モレスキン ラージサイズ 横罫 出版社/メーカー: Moleskin/モレスキンメディア: オフィス用品この商品を含むブログ (1件) を見る お
問題解決指向よりも理想実現指向を - レベルエンター山本大のブログ
『問題解決指向』で物事に取り組むと、悪い点ばかりに目が向く。 せっかく出てきた改善案についても、そのアイデアの悪い点ばかりを粗探しして進まない。 それに対して『理想実現指向』を目指せば、問題そのものを探すことよりも あるべき姿とのギャップを埋めることを重視して、前向きな改善につながる。 そして改善することに目的意識ができ、前向きになる。 問題に目を向けるよりも、理想系を模索すること。
仕事に幅を持たせるポリシーコミットパターン - レベルエンター山本大のブログ
仕事を達成しようとするとき、 あらかじめゴールを決めて始めるのは点を目指すことですが、 あらかじめポリシーを決めて始めるなら対象は面になります。 仕事を御願いする時の状況を考えると 「資料のコピーを10枚とって！」 というのと、 「資料のコピーを会議の出席者分だけとって！」 というのでは、動く側の意識が変わります。 後者の言い方なら、気の利く人なら会議室の出席者の席に並べておいてくれたりするでしょう。 「１０枚」という点ではなく、「会議の出席者分」という、 10と言う数字を導き出した根拠となる方針を提示しておくことが仕事の成果に幅を持たせることになるのです。 仕事をゴールという「点」をめがけて仕事をやろうとすると効率が悪いことが多いのです。 だから顧客や上司から仕事を受け取る際も、ゴールをコミットして仕事を始めるよりも、 ポリシー（方針・指針）をコミットして仕事を始めてみたら成果を挙げるの
標準化に必要なのはフレームワークよりも(美女)エバンジェリストだ - レベルエンター山本大のブログ
でかいプロジェクトで開発標準を定着させるには、フレームワークやドキュメントよりも「標準化伝道師(エバンジェリスト)」を常設するほうが効果があると思う。 開発標準は、その組織の文化だといえる。文章やソースコードで文化を根付かせようとしても上手くいかない。 組織の文化とは人が言葉と行動によって伝承するものなのだ。 希望を言えば伝道師はできれば女性がいいなぁ。 エンジニアは男性が多いからやたらテンションが上がるし、女性の活躍の場も増えるので誰も損をしない。 伝道師は、新規プロジェクト立ち上げ時やフェーズの切り替わり時期に、次フェーズについての標準的手法・技法を全メンバーに伝授する役割を担う。 また、標準についての情報を管理し、プロジェクトごとの開発標準のカスタマイズに関わる。 プロジェクトでの標準化が上手く力を発揮すると品質・効率・保守性などの面で良い効果が期待できるから取り組み事態は素晴らしい
誇りを貫くプログラマのキャリアパス - レベルエンター山本大のブログ
エンジニアの誇りを減退させずキャリアを積むためには、とっとと管理を極めて*1管理の仕事を他の人に振れるようにすることだと思っている。*2 あなたが管理を嫌ってもキャリアアップするにあたって管理という仕事は回ってくる。 管理という仕事に目を背け続けることは出来ない。 僕は、管理という仕事をエンジニアの終着点だと考える必要はないと思っている。 乗り越えるべき通過点なのだと思う。 エンジニアのキャリアアップの中でも管理職の乗り越え方を考える。 原則：エンジニアよ、管理職を超えろ。 会社側の論理で言えば、キャリアの長い人に高い給料を支払うためには、 その人が複数のメンバーの仕事を上手く回してくれなくてはならない。 会社がベテランに求めるのは、チームを引っ張っていってくれることだ。 当然、あなたが管理向きならば問題にはならない。 管理とリーダーシップは両立しやすい。しかし、管理系リーダーが全てではな
偽忠誠心の利用法 - レベルエンター山本大のブログ
「山本さんは会社への忠誠心が高い」と昔からよく言われるが、 僕自身はそういう古めかしい感情はあまり好きではないし、忠誠心を意識して仕事をしているつもりもない。 (しかも、今となっては経営者だから忠誠心というような受身の心構えではやっていけない。) とはいえ「自分のためだけ」に仕事はしない。誰かのために仕事をするように心がけている。 これは綺麗ごとを言いたいわけではない。 嘘でもいいから「誰かのため」と思って仕事をすると 自分の能力を120％発揮できるし、苦しい状況にも耐えられる。結果として、より急激に成長もする。 この偽忠誠心は、僕の成長戦略だ。 自分のために頑張るというのは、ギリギリのところの踏ん張りがきかない。 理不尽な要求や、厳しい案件などに耐え切れない。 耐える意味が見出せない。だから耐えようとしても自己矛盾に陥って鬱になるだけだ。 自分の能力を超えるリスクを取る理由がないから、大
安全策が後手後手を生む - レベルエンター山本大のブログ
場当たり的な対応で工数が少なくてすみ、影響範囲も少ないが、コードは汚くなるという案と 影響範囲が広いし工数も掛かりそうだが、コードは綺麗になるという案があるとき、 僕は、よほどの差でない限り、コードが綺麗になるほうを選ぶ。 ここで場当たり対応を選んでしまうことは、 「現実をみた大人の意見」のように思えるかもしれないが、 僕からすると、大事の前の小事にこだわるという、本末転倒の考え方にしか見えない。 保守で、既存プログラムの修正をやろうという後輩から相談を受けた。 既存プログラムのSQLの一箇所が違うだけのメソッドを作る必要があるとのことだ。 メソッドをコピーして重複したコードを書くことに後輩は納得がいかず、うまい方法は無いものかと僕に相談をしてくれた。 僕は、このメソッドの引数を追加して条件分岐できるようにし、元のシグネチャオーバーロードとして別途定義する案を上げた。 後輩は、我が意を得た
よい聞き手になりたいなら、絶対に質問を考えながら話を聞くこと！ - レベルエンター山本大のブログ
「コミュニケーション上手は、聞き上手である」 といったことがコミュニケーションの本なら必ず書いてある。 聞き手として、そのコミュニケーションを有意義な時間にするための秘訣がある。 プレゼンを聞きに行ったり、顧客に要件定義のヒアリングをしに行ったり 上司と面談をしたり、部下の面談をしたり、どういうコミュニケーションでも共通する。 どんなものであっても、話の聞き手になったときは 絶対に質問をすることだ。 あなたが誰であっても、相手が誰であっても、問答無用。 質問をするためには聞きながら質問を考えること 「最後に、何か質問はありませんか？」 と聞かれてから考えては思いつかないものだ。 狙っている異性と、良い感じでおしゃべりしてるときは 話をしながら次の質問やフィードバックを考える。それと一緒。 講師をしていても思うんだけど、スピーカーは質問してくれた人のことしか覚えていない。 学芸会で緊張したと
Javaプログラマが0円で始めるFlex-ActionScript - レベルエンター山本大のブログ
Javaエンジニアが次のステップとしてFlexに取り組むのはいいと思うんですが、 Javaとは勝手が違う部分があってハマるポイントも多いと聞きます。 たぶんそれは、FlexやActionScriptについて基礎を素っ飛ばしてしまうからなのかなと思い。 じゃあ、Javaを初めて勉強したときの流れで、ActionScriptの学習をしてみたらどうでしょう。 ということで、テキストエディタとコマンドプロンプトだけでFlexを0から始めてみます。 この分厚くて高い本(5800円)をつかって勉強していくけど、無くてもよいです。 詳説 ActionScript 3.0 作者: Colin Moock,永井勝則出版社/メーカー: オライリージャパン発売日: 2008/11/22メディア: 大型本購入: 6人 クリック: 139回この商品を含むブログ (28件) を見る 対象はとりあえず、Winだけ。 で
理解してもらうための文章 １０ヶ条 - レベルエンター山本大のブログ
あなたは12歳の4月1日午前ごろに何を考えていましたか？ と聞かれても何も浮かばないが、 中学校の入学式で何を考えていましたか？ と聞かれると、様々な記憶が呼び起こされる。 人間は、仕様や定義、数値といった情報を理解するようには出来ていない。 だから、読んで理解するための書き方と、物事を定義する文章の書き方は異なる。 定義する書き方の文章とは、たとえば設計書だ。矛盾が無く、漏れが無いことを重んじる。 また、書き手の個性が反映されてしまうと成果物として成り立たない場合があるので判で押したような文章で書く。 でないと書き手が変わったときにニュアンスを合せるのに苦労する。 しかしながら、こういった文章は読みにくいし理解しにくい。 最近僕は、作ったプログラムを説明するドキュメントを書いている。 これは設計書のように形式的なものではなく、 理解してもらうことが唯一の目的というドキュメントだ。 読んで
スケジュールを作るプログラマが一番効率が良い。 - レベルエンター山本大のブログ
現場の周りのプログラマさんたちが残業する中、 僕が毎日定時で帰って高品質なプログラムを作れる理由は、 僕が自分でスケジュールを作ってから仕事を始めるからだ。 僕が今の現場に入って始めにリーダーさんからこういわれた。 「スケジュールがきついので、 管理工数がもったいないから、管理資料に手間をかけたくありません。 イキナリ作業に入ってもらってかまいません。」 若い頃ならうっかりその言葉に惑わされているところだが、 そうはいかない。スケジュールがきつい時ほどコントロールが必要なのだ。 何を先にやっておかないといけないか、 今週末までにどこまで進めておけば安心か。 これらがわからなければ、不安に駆られるばかりだ。 不安を取り除くという意味だけでもスケジュールを組むことは非常に役に立つ。 ドラッカー風に言えば、 「ミッションに集中するにはマネジメントを駆使しなくてはならない」 ということだ。 プログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
