人を育てるという責任 - rabbit2goのブログ
少々前の記事になるけれど、日経ビジネス2010年11月29日号にH&M（へネス・アンド・モーリッツ）の紹介が載っていた。スェーデンに拠点を置くH&Mはユニクロ同様に、商品企画から販売まで自社で行う小売企業(SPA)で、全世界での売上は1兆2000億円、フルタイム従業員は54,476名という巨大な会社だ。 そんなH&Mを支える経営理念として、3つの基本姿勢が有るという。 1つは、リーダはどの部門でも常に自分の代わりになる存在を育てなくてはならない「NEXT ME」。次が非正規・正規などの最初の採用形態や配属先にこだわらない「背番号なし」。最後が、退社した社員が再入社して幹部に登用されることもある「出戻りOK」。 日経BP SHOP｜日経ビジネス2010年11月29日号 入社時の「同期」とか、「新卒」「中途」という妙なこだわりが非常に多い日本の会社から見ると「背番号なし」はなかなか潔い考え方だ
その仕事は無駄ではない - rabbit2goのブログ
ソフトウェア開発における実務作業は様々なので、その中には必ずしも直接的に役立たない（ように見える）ものも有る。ソースコードを書いたり、障害を修正するような作業はアウトプットが明確だし、その成果が明快だけど、後付の資料を作ったり、開発支援のような作業を行っていると面白くない作業に嫌気が差すのか、こんな台詞を聞くことがある。 どうせ仕様書を作っても誰も読まない。 どうせ情報共有システムを作っても誰も使わない。 どうせ改善活動を行っても誰も喜ばない。 いずれも「どうせ」という少々投げやりな態度が特徴で、そう言いたくなる気持ちも確かに分かるのだけど、だからと言って適当な作業を続けてしまうのは勿体無いことだと思う。 もちろん「より多くの人に読んでもらえる資料にするためにはどうすべきか？」と前向きの改善策を考えるのも必要だし、理想的にはこうした考え方を持ち続けるべきなのだけど、実際問題として仕様書のよ
開発プロジェクトの見える化 - rabbit2goのブログ
様々な開発プロジェクトを横断的に見ていると、情報共有という面で大きく2つに分類されるようだ。 プロジェクトに自信が有るところは「情報を見せる」 プロジェクトの進捗、問題等が一目で分かるようにTrac等で公開されている。 Trac等を参照することにより、現時点の状況がすぐに分かる。 プロジェクトの状況について、担当者全員が同じ認識を持っている。 資料や情報の在処が明確にまとめられているので、あちこちを探し回る必要がない。 事前の情報共有が出来ているので、打合せでも本題に関する議論が直ちに始まる。 プロジェクトに自信が無いところは「情報を隠す」 プロジェクト管理は誰かのメモか頭の中で行われており、部外者には全く分からない。 手作業で進捗をまとめているので、現時点の状況が分かるのは次の日だったりする。 プロジェクトの状況について、各担当者間で認識が異なる。 資料や情報の在処が不明確。各担当者が自
考えるべき改善の方向性 - rabbit2goのブログ
ソフトウェアの品質を上げるための改善策を議論すると、決まって「チェックリストを追加しましょう」「確認作業を行いましょう」「仕様書を作成しましょう」など追加作業が必要になることが多い。確かに今まで何か足りないモノが有ったから問題が発生したわけで、その対策を打つために何かアクションが必要になるのは分かるけど、そもそも時間が足りないから作業が出来ていなかったはずだ。それなのに、さらに時間が必要になるアクションが解決策になるのは変な話だと思う。 「疲弊する開発者」でも書いたように、現場の開発者はあれをやれ、これをやれと言われ続けて疲れている状態だ。だから、作業の積み増しはもう不可能なのだ、そこで、必然的に解決策の方向性も、もっと作業を減らす方向に向かなければならない。例えば、こんな方法を考えるべきではないだろうか？ もっと手を抜く方法 もっと安上がりな方法 もっと短時間で済む方法 もっと簡単な方法
真似すれば及第点は取れる - rabbit2goのブログ
あまり知られていないことかも知れないけれど、仕事として行う多くのことは大抵の場合「上手くやっている人のやり方」を真似ると上手くいく。自分の仕事を上手く進められなくて困ったとか、どうしてあの人は上手く出来るのだろうと疑問に思ったら、上手い人の行動を観察して、そのやり方を自分に取り込んでしまうと良い。同じやり方を繰り返すことで、少なくとも及第点は取れるようになる。不思議なことに、仕事を上手く進められない人に限って自分独自のやり方にこだわり続けて落とし穴にはまり込んでいる事が多い。これは少々勿体ない話だ。 世の中に溢れる仕事術の中には、個性を生かせ！創造性と独創性こそがキミのセールスポイントになるのだ！と言うニュアンスのものが有るけど、それは人並み以上に出来る人が考えるべきポイントであって、実際の現場ではそんなものは必ずしも必要とはならないことも多い。例えば、人をまとめるリーダ役をやると分かるけ
開発現場の不満を取り除くのがリーダの仕事 - rabbit2goのブログ
ソフトウェア開発現場に種々の不満は尽きないけれど、そんな担当者の不平、不満、要望、要求を一つ一つ取り上げて対処し、決して無視しないのがリーダの大切な仕事ではないかと思う。担当者が快適に、しかも気分良く仕事を進められるからこそ、チームとしての力が発揮できるのであり、成果物のQCDにも繋がるのだろう。チーム管理というとメンバに対して「あれをやれ」「これをやれ」と指図することが仕事だと思われがちだけど、同じくらいに大切なのはその仕事がスムーズに進められるようにお膳立てをすることだと思う。 優れたプロジェクトリーダは、メンバとの話の中から種々の問題を確実に捉え、解決に向かって努力することが多い。仕事の進め方、作業方法、工夫など、仕事に直結することから間接的なことまで、チームや開発者の個人レベルで改善出来る問題は少なくないはずだ。「チームとしてここまでは改善出来る、これは理由があって対処できない、こ
忙しい人の特徴 - rabbit2goのブログ
自分では「「忙しい」は禁句」と思っているので、決して「忙しい」を口にしないようにしているのだけど、周囲を見ると「忙しい」人だらけだ。でも、本当に皆忙しいのだろうか？本質な作業で忙しいのなら分かるけど、実はどうでも良いことに忙しい人もいるようだ。その一例。 無駄なことばかりやっている 直接話をしたり電話一本かければ済むことを、長々とメールに書いて送るのは止めたら？ 何でも自分でやっている 本当に自分でやる必要があるの？OJTを兼ねて、グループの若手に任せてみれば？ 些末なことばかりやっている どうでも良いことはバッサリと切り捨てたら？もっと本質的なことに注力すべきでは？ 非効率的なやり方でやっている 既存のツールやサービスを使えばもっと効率化できるのだけど、それを知らない？ 必要無いことをやっている 作業が必要と思い込んでいるのは、実は本人だけだったりする。誰か教えてあげて！ ちなみに「忙し
求ム、障害分析アナリスト - rabbit2goのブログ
終了した開発プロジェクトの問題分析を行っている。「バグの源流をたどれ」の如く、なぜなぜ分析で問題の根本原因を探り、抜本対策案をまとめるのが目的だ。さすがに限られた時間内で全障害を検証するのは不可能なので、優先度の高い問題のみをピックアップしてから分析を行う。Tracのチケットに記載された情報を元に、仕様書の記載ミスなら変更前後の仕様書を見比べ、コーディングミスなら該当するコミット状況を確認し、テスト漏れならテスト手順書の記載を検証するといった感じだ。 開発対象も開発者も異なるプロジェクトを見ているけれど、いずれの開発でも共通の傾向があるので面白い。 障害は偏在する 全ての障害が一様に分布するのではなく、特定の機能、開発者、モジュール等に著しく偏って発生することが多い。パレートの法則ほどではないけれど、その偏り方は目に見えてはっきりと分かる程だ。 類似の障害は繰り返し発生する 一つのプロジェ
アイデアマシンガン - rabbit2goのブログ
会社では自社製品向けのソフトウェア開発を行っている。受託開発はやっていないので、仕様決定に関する自由度はかなり高い。流行りの技術を使って開発することだって出来るし、新しい技術にチャレンジする機会も生み出すことが出来る。もちろん営業部門や企画部門と話し合って製品の方向性を決める必要はあるけれど、自分のアイデアをいくらでも入れ込む機会はあるので、悪くない環境だと思う。 そんなわけで、開発の現場では常に新しいチャレンジが求められる。会議の場で課内のメンバーに求める内容はいつもこんな感じだ。 製品の機能、使い勝手を向上させるアイデアは無いか？ 他社製品と差別化出来るアイデアは無いか？ もっと売れる製品を生み出すためのアイデアは無いか？ 開発効率をさらに高めるアイデアは無いか？ 新しい技術、開発手法を生かせる場面は無いか？ しかし、転職してきた人や派遣社員として来た人の中には今まで受託開発しかやった
蓄積がモノをいう - rabbit2goのブログ
私の机の脇に積み上げられた技術書の山を見ながら、会社のボスキャラが質問。 ボスキャラ：「この本を全部読んだら、技術士になれるのか？」 私：「これだけ読んだら受験願書を取り寄せても良いですけど、試験の合格には全然足りません」 ボスキャラ：「...」 言うまでもないことだが、知識の幅と深さを極めるには多くの経験と長い時間が必要だ。学生のような一夜漬けの勉強では、その場しのぎにはなっても本質的な知識は身につかない。自分の手を動かして、実際に動くモノを作ってみる等の経験を積んで、ようやく自分の知識として習得できるのだ。そもそも、本を読んだだけで事足りるのなら、誰も「英語が話せなくて困る」ことなんてあり得ないはずだ。 例えば、技術士試験も同様だろう。願書を出してから、知識の習得のために本を読んでいるようでは、その分野で長年の経験を持つ人に敵う訳がない。パケットキャプチャ一つやったこと無い人がネットワ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Software Assurance Measurement – State of the Practice
状態遷移表設計におけるＳＰＬＥ実践ガイド Ver.1.0
Software Product Lines: Reuse That Makes Business Sense
Variability in Software Produce Lines
Product Line Analysis: A Practical Introduction