レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

開発

威張る人たち

「威張る」って、言葉は知っててもこの年まで幸いあまり威張ってる人を見たことが無かった。でも、ちょっとづつ威張ってる人を目にするようになってきて、滑稽な姿に笑ってしまう。 威張るって、自分が気持ち良いだけでなんのメリットも無い行為だなぁ、なん…

SI開発で再利用が必要なのは部品ではなくチームだ。

この半年、巨大なシステムの開発で学んだことの1つは、SIという業態の中で再利用が必要なのは、部品ではなくチームであるということ。 チームに蓄積するノウハウや暗黙知こそ再利用するべきで、案件の度に体制の伸縮を繰り返すやり方では、いくら部品化や共…

トラぶってグチャグチャに行き詰まるからこそ勘や発想力が養われる

伸び悩む若手のエンジニアのひとつのタイプは、まじめで努力家だけど、どうにも勘が効かないというやつです。彼らは、実直でまじめだからキチンとマニュアルを手順どおりにやるんですが、敷かれたレールから外れることに非常に弱いのです 彼らに対するアドバ…

机に向かって取れる解決法だけを並べて「限界だ」なんてあきらめてないか?

プロジェクトで発生する様々な問題の答えは、IT技術や開発の方法論だけではありません。 問題解決のためには、あらゆる手段を視野に入れてのぞむ必要がありますが、 僕らエンジニアは「あらゆる手段」を狭く取りすぎていることがあります。 「あらゆる」と言…

設計者として一流になりたいなら足で稼げ

開発の仕事をするためにもっとも大事な力の一つは”判断力”であり、判断のために一番頼りにするべき情報は、自分の手・足・目・耳で稼いだ情報だと思います。 それを実感する出来事が、このシルバーウィーク中にありました。 この休み中、僕は10月から東京に…

どうやったら気持よく前向きにチャレンジングな選択がしやすくなるか?

安全策が後手後手を生む - 山本大の日記に頂いたトラックバックの中の、以下の問いかけに答えてみる。 どうやったら、現場のみんなが気持よく前向きにチャレンジングな選択がしやすくなるか?何かアイデアや事例があれば教えてくれると嬉しいです。 http://n…

安全策が後手後手を生む

場当たり的な対応で工数が少なくてすみ、影響範囲も少ないが、コードは汚くなるという案と影響範囲が広いし工数も掛かりそうだが、コードは綺麗になるという案があるとき、僕は、よほどの差でない限り、コードが綺麗になるほうを選ぶ。 ここで場当たり対応を…

理解してもらうための文章 10ヶ条

あなたは12歳の4月1日午前ごろに何を考えていましたか? と聞かれても何も浮かばないが、 中学校の入学式で何を考えていましたか? と聞かれると、様々な記憶が呼び起こされる。 人間は、仕様や定義、数値といった情報を理解するようには出来ていない。 だか…

本番リリースの最大の障害は申請書という・・・

本番環境に乗せるには まず、IDの申請書を書いて、 デプロイモジュールの申請書を書いて、 PMさんに承認してもらった上、 お客さんに申請して承認を貰わないといけない。 これにより、凡ミス対応なのに休日出勤。 あーあ、まぁミスってしまった俺が悪いね。 …

ルールを厳格にしてもソースコードは綺麗にならない。規範コードを提供しろ。

今のプロジェクトはJavaで、保守フェイズの新規機能追加なので既存コードをよく読む。お世辞にも、綺麗なコードとは呼べないし、オブジェクト指向の観点でも下の中ぐらいのもんだ。*1 しかし、このプロジェクトの初期段階で書かれた開発者向けガイドを読んで…

プロジェクトのバッドエンドパターン

プロジェクトが上手く行くためには沢山の要因があり、 「これをやれば絶対うまくいく」という銀の弾丸はありません。 しかし、反対に「これをやったら確実に失敗する」という バッドエンドへ向かうパターンは、存在します。 たとえば、最近実感するひとつの…

難攻不落のデータ移行を完遂したのは早い決断とデイリーデータコンバート

プロジェクトの成功要因 - 山本大の日記 先日の日記の通り、最近システム開発のリリースを無事完了しました。 今日は、そのシステムでのデータ移行の話。 移行不可能? このプロジェクト、 業務はさほど難しいことはなく、本来は難易度の高いシステムではあ…

自動テストとデイリービルドの組み合わせは最強!

自動テストとデイリービルドを組み合わせることの超絶な威力を感じてる。 しかし、開発の中に上手く自動テストを組み込めていないプロジェクトは多い。 デイリーでテストコードを流しておくと、修正による副作用を最低でも1日以内に発見することができるよう…

1プログラマとして生産性を見直す。

普段の仕事はアーキテクトやDBAやらフロントSEが多いんですが久々に、1プログラマとして、自分の関わっていないフレームワークで自分の関わっていない仕様書に則ってプログラミングをしました。やってみると、結構気づかなかったことに気づきます。 プログ…

エンジニアの能力を「生産性」と呼ぶのはやめたらどうだろう?

エンジニアの能力を「生産性」と表すのが、業界の認識間違いを引きずる原因の一つだと思う。 生産性とは、決まったものを作り続ける性能を表す。「この自動車工場のラインごとの生産性は、1日に100台だ。」という文脈なら正しいが、 たしかに、エンジニアの…

生産性測定フェーズ

開発の生産性とは、マラソンを走るときの個人個人のペースに似ている。人の係数は当てにならないし、過去の自分とも少し違う。現在のコンディションと、道のりの難易度にもよる。 つまり、走り出してからしかわからないものだ。 そうであれば、全員が自分の…

システム開発で再利用可能な最大のコンポーネントは開発チームだ。

開発プロジェクトは知識産業です。 プログラムは知識労働の成果ですが、 知識労働の一番大事なエッセンスは、 それを生み出す「過程」にあると思います。つまり知識労働で別のプロジェクトでも再利用可能なのは 知識とその所有者だと思います。その考え方を…