見えない壁に突きあたった中堅エンジニアが学ぶべき、三つのこと | タイム・コンサルタントの日誌から
先週の4月2日(土)に浜松市で、合同シンポジウム「サプライチェーン戦略とプロジェクト・マネジメント」を開催した。主催はOR学会・日本経営工学会・スケジューリング学会で、その配下にある「サプライチェーン戦略研究部会」（主査・日本IBM 米澤隆氏）と、わたしが主査を務める「プロジェクト＆プログラム・アナリシス研究部会」が実行主体だ。 講演者には、倉庫管理システムiWMSの開発元として有名な(株)フレームワークスの渡辺重光会長と、ヤマハの曽根卓朗主席技師のお二人をお招きした。お二人の話はどちらも非常に興味深いもので、渡辺氏はロジスティクスとIoTの広範な展望を話され、曽根氏は通信カラオケの製品開発を題材に、生々しい体験をお話しいただいた。最後にパネル・ディスカッションを行い、わたしもパネラーとして参加した次第だ。 幸い大勢の方に来ていただき、立ち見が出そうになったので椅子を補充したほどだった。製
プログラマの履歴書
「コードを書け。それが履歴書だ」という昔の名台詞が目に留まったので、常日頃感じていることを書き出してみることに。 コードが GitHubで公開してあると、まず採用する側の視点としては非常に助かります。プロジェクトを２、３つ眺めるだけでも、この人が普段どんなことを意識してプログラミングしているのかが見えてきます。例えば、性能を重視しているとか、拡張のしやすさを意識してインターフェースをデザインしているとか。さらに本人の興味の方向性、得意な言語などがわかるが何より嬉しい。過去の経験から、自己申告でJavaができます、C++ができますなどと言うだけの人が期待したレベルでコードを書けた試しがありません。 その次にわかるのがコミュニケーションスキル。基礎的な英語力の判断材料にもなるし、チームを組んだ時のイメージがしやすい。問題を共有する能力も大事。自分一人の頭の中でたくさん難しいことを理解して解決で
デスマーチ・激務に巻き込まれたアナタが取るべき12の対策【メンバー編】 - プロジェクトマネジメントの話とか
新社会人になろうとしているあなたが、「デスマーチ」（＝不眠不休の連日徹夜の炎上プロジェクトを想定します）という激務の壁にぶつかったときに、当記事が何らかの参考になれば幸いです。 私は約10年間、下流工程寄りの仕事に従事した後、上流工程へシフトしました。プロジェクト炎上の火消しにPL（プロジェクトリーダー）やPM（プロジェクトマネージャー・プロマネ）らが右往左往するものの、最終的なしわ寄せが「実装を担う開発現場」に来てしまう現実を、何度も目の当たりに、いや、実際に経験してきました。 根本原因の解明が必要ではあるものの、一メンバーである個人の権限ではコントロールできない要素がほとんどだったりもするわけです。今回はメンバー側の視点として、デスマーチという激務のやり過ごし方、取るべき対処について考えてみましょう。もちろんIT業界以外の「絶賛激務進行中」なアナタもご一緒に！ スポンサーリンク １．責
K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
いつも受け入れられるとは限らない改善提案: 柴田 芳樹 (Yoshiki Shibata)
社会人となって30年間、様々なソフトウェア開発従事していた経験から言うと、改善提案は上位のマネージャや部門長に受け入れられる場合とそうでない場合があります。その中でも、問題が発生してから、その問題を解決するという改善提案は受け入れられることが多いです。しかし、発生するであろう問題を予測して、それに対して事前に対策を打つという改善提案は、理解されなくて、受け入れらないことがあります。 問題が発生してからの改善としては、ソースコード管理用のリポジトリは用意していたが、開発の終盤までビルドは、一人の開発者のPCでしかできなくて、ビルドを間違いなく行う必要がでてきて、やっとサーバで自動ビルドが一日一回行われるとかです。さらに、コードの品質が悪くてバグがたくさん出るので、FindBugsなどの静的解析ツールを導入して改善しますと言った提案です。しかし、静的解析ツールを導入した時点ではすでに遅く、すべ
書類仕事を追いかけて - steps to phantasien
大きなコードベースの真ん中あたりをさわっていると、仕事の大半はリファクタリングに費やされる。機能を足そうと書くコードも 8 割リファクタリングで新緑は 2 割。失敗して捨てるものも多いから、かける時間は 9 対 1 くらいかもしれない。 それどころかリファクタリング自体がプロジェクトにもなりうる。「今四半期はこの腐ったコードどもをなんとかするのが目標」というように。私もいま大きなリファクタリング、あるいはリアーキテクティング、の手伝いをしている。仕事時間のほぼすべてがリファクタリングに費やされる。今の勤務先で通用する唯一の特技がリファクタリングな私にとってこれはたぶん適職だ。 リファクタリングにコーディングの大半を捧げる人は他にもいる。 プログラマ相手の管理職をエンジニアリング・マネージャと呼ぶ。ほぼ全員プログラマ出身。現場に近いマネージャは多くがコードも書く。ただ血気盛んな人を除くと新機
がんばるあなたがプロジェクトを殺す - haradakiro's blog
あまりに暑いのでちょっと怪談を。 今のような仕事のやり方をする前、いわゆるシステムインテグレータに所属していた。まあ、呼び方はいろいろあるのだろうけれど、一番長いこと仕事にしていたのは、いわゆる「火消し」。問題プロジェクトにがあると、プロジェクトに投入されるという役どころだ。まあ投げ込まれるのは大変だけれど、いろいろなものを見ることができた。 投入されたプロジェクトは多種多様だけれど、たいていの場合、すぐに問題があるようには見えない。みんな忙しそうに働いているし、大きな開発プロセスの問題もない。粛々と作業がすすんでいるように見える。でも、クライアントと管理職は怒っている。怒っているから、いろいろな作業が追加されて、メンバーはどんどん忙しくなる。 しばらく見ていると、プロジェクトには必ずある種類の人がいることに気がつく。みんなに頼りにされていて、なにかあると彼(彼女の場合もあるよ、もちろん)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
