「プロフェッショナルエンジニアは後進の育成よりも、自己の能力向上を優先すべきではないか」という意見を複数方面で見かけて考えたこと。管理者としての教育と、技術者としての後進教育は混ぜないほうがよいという意見。そしてエンジニアとして成長を望むのであれば「技術者としての後進教育」は意識すべきだと思っている。 キャリアを積めば、部下を持って管理職になるのが一般的かもしれないが、職人の世界で考えると、自分自身の腕を磨くことこそが一番で、部下を育てるより自分を育てたい。ならば、部下を持たずにキャリアを積む程、余計な仕事から解放されていく仕組みを組織としては用意するのが良いのではなかろうか。— Yoshihito Kuranuki / 書籍：ザッソウ「雑談＋相談」 発売中 (@kuranuki) 2016年5月17日 というのはちょっと乱暴だと思うけどなー、という話 管理者による部下教育 会社組織におけ

むかし会社の先輩からこんな事を言われて、とても共感した。「成功体験は共有する意味があまりない。なぜなら、成功原因がなにかなんて、わからないから」。ソフトウェア開発の世界では沢山の「成功事例」が発表されている。個人の情報発信が発達して、沢山の「成功」が世に溢れる。本当に大切な「失敗談」はどこにいけば知れるのだろうか。 成功要因は一般化できない。 ソフトウェア開発が成功したとして、その成功要因を特定して一般化することは難しい。新たな方法論の適用があったかもしれないが、じつは柔軟性の高いプロジェクトオーナーその人が成功の理由で、方法論は真の成功要因ではなかったかもしれない。もしくは、たった一人の献身的なエンジニアの働きが戦況を変えたのかもしれない。成功は、実力だけではなく幸運の賜物である。同じソフトウェア開発プロジェクトは二つとない。まったく同じように振る舞っても、成功を繰り返すことはできない。

ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ

古い記事になるのだけれど、バージョン管理ツールにコミットログのNGワードを登録するという話が面白かった。ソフトウェアは思考がそのまま品質につながるようなところがある。思考停止に近しいワードを禁止してしまうのも手かもしれない。 コミットログのNGワード 注意するのも疲れるし、大抵の場合は注意しても直りません。 そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。 コミットコメントを意地でも書かせたい - almost nearly dead 単にコメント無しを規制するだけではなく、思考停止してしまうようなワードを禁止しているのが素敵。 また、これに加えて会社名や人名も禁止してしまうのはうまいやり方だと思う。人の名前が出てくるとそこで情報が隠蔽されてしまうし、「問題 VS 我々」のスタンス