人月の神話
【書評】
「人月の神話－狼人間に撃つ銀の弾はない」
ソフトウェア開発分野においては、とても有名な本です。
多くのサイトに書かれていますが、概論はこんな感じ。
・遅延しているプロジェクトへの増員は更なる遅延を招く
・今後10年でソフトウェア開発の生産性を飛躍的に向上させる発展はない
僕のblogはこの本の題名をパロディってるぐらいなので、
この本を崇拝しているかというとそうでもありません。
正直、論も難解だし、あまりにも多くのことが書かれていてまだ理解しきれていません。
副題のセンスからも察することができるように翻訳も分かりにくい。
ん？ そこでその言葉かー？？みたいな。
この本を読破し、各論について検証できるようになったら一流のエンジニアであると同時に
一流の国語学者でもあると思います。
あ、共感できるなーと思った数少ない論は、
・アーキテクチャの外部規定はプログラマーの創造性を制限するものではない
・上司が部下の問題に立ち入りすぎると、部下は隠し事をするようになる
ってなとこでしょうか。
後者は最もなことですが、頭で分かっていても実際できない管理者が多いと思います。
なぜそうなってしまうのか。ダメ上司、ダメ管理者になってしまう過程も調べてみたいですね。
とにかくこの本には多くの示唆に富んでいますが、内容はかなりハイレベルです。
SEを目指すものなら絶対に読むべきと教授に言われて
学生時代に読んだときは３０分でＫ．Ｏされました。
自信が無い方は第18章「人月の神話の命題は真か偽か」から読まれることをお勧めします。
出社拒否が起こるとき
２週間ほど前から、うちのプロジェクトのＯ先輩が出社拒否しています。
出社拒否なんて新聞や雑誌で読んだぐらいだったので、
それを実際に目の当たりにして困惑しています。
うちの会社は忙しいですが、人間関係も悪くなく、給与や福利厚生も良い方なのですが。
Ｏ先輩が消えた後、本人が全て悪いという雰囲気になっていますが、
果たしてそうだったのでしょうか。
Ｏ先輩の問題点はいろいろあったそうですが、周りがその要因となっていなかったか。
どんなに自分にとっては居心地が良さそうなプロジェクトでも、
ある種の人にはそうでないかもしれません。
そういうある種の人を適合できないという理由で切り捨てるのは
問題をもみ消しているような気がします。
今後同じことが起こらないためにも、今回の出社拒否を風化させないで
一度検証してみる必要がありそうです。
ってそんな暇ないのが実情なんですけどね。
ソフトウェア開発の現場で出社拒否というのはどれくらい発生しているのでしょうか？
そして原因として何が多いのか？
気になるところです。（何かご意見・情報あればお聞かせください
SEとして働いてますか？
■ やる気と向上心
SEという仕事についての興味深い記事 がありましたので、トラックバックなるものをしてみました。
やる気や向上心という意志はとても重要だと思います。
頭が良いとかプログラミングができるとかいう能力だけではSEはやっていけない。
能力と意志とが両輪となって連動したときにこそ、すーぱーSEへの道が開けると思います。
しかし、うちのプロジェクトに新規に入ってきた常駐の方でこんな人がいます。
やる気もある。自分から仕事をやりたいとも言う。
与えられた仕事は毎日終電帰りで休日出勤してまで必ず全うする。
仕事の質も悪くない。
にも関わらず、プロジェクトではいまいち信頼されていない。
一体なぜなのか？
■ SEとして働いてますか？
他人のことなのにおこがましいですが、僕が出した結論はこうです。
１．彼はいろいろな意味でコミュニケーションしようとしない
２．そして彼はSEとして働こうとしていない
まず１．
彼は極端に黙々と働く方で、同僚の会話にも加わろうとしません。
仕事上の会話やたまに私的な会話をしてみても、妙に丁寧だったり、
その反動でかいきなりぶっきらぼうになったり、とても不自然。
そして何より会話しているとき人の目を見ない。
ネクラな自分にとっては認めたくない事実ですが、IT業界においても
話せる相手かどうかということがその人に仕事を任せられるかどうかの尺度になるようです。
とくに僕たち若い世代の間ではその傾向は顕著です。
会話の機会を放棄するということは、自分を知ってもらう機会を放棄していることになります。
次に２．
彼は真面目だし、与えられた仕事は責任を持って全うするのですが、
どうも仕事に対する捉え方がまっすぐ過ぎるような気がします。
文句一つ言わないし、作業が楽になる方法があるのにそれを使おうとしない。
よく働くんだけど、何が得意なのかいまいち分からない。
打ち合わせでも「自分ならこれができる」とか「この件に対する自分の考えはこうだ」
という観点からの発言は一切ない。
上から指示されたことを黙々とこなす彼の姿を見ると、
ここはソフトウェア開発の現場なのか、どこかの軍隊の訓練施設なのか分からなくなってしまいます。
上から認められたいという思いが強すぎて、SEとしての自分はどこかに
行ってしまっているような気がしてなりません。
■ SEとして向上するために
いろいろ他人のことについて書き連ねましたが、自分はどうか？
上述したことを踏まえて、僕が考えるSEとしての向上術は以下の３点です。
１．会話しよう
→信頼（仕事）を得るにはまず自分がどんな人間か知ってもらうことが重要。
会話によってお互いに対する誤解も解け、相互理解も深まると思います。
２．判断しよう
→自分で考えた意見を一つでもいいから持つ。上が間違っていると思ったら反論する。
やりすぎると煙たがられますが、最終的には自分で判断ができる人間に
より重要な仕事が任せられると思います。
３．頭を使おう
→我々はネクタイを締めた働きバチではなく、知識労働者だと自覚すること。
この仕事には気の滅入るような力作業もありますが、
そんな作業に直面してもどうやれば生産性が上がるか、どうやれば効率的にできるか、
常に考えて仕事に取り組む心構えでいます。
日頃どれだけ頭を使っているかで、その人のSEとしての向上度も違うはずです。
そして最終的に重要なのは、やはりitproさんの記事にもあるやる気と向上心でしょうか。
やる気と向上心は言わば原油のようなものでしょう。
いくら性能の良い車で原油がないと動きませんからね。
プロジェクトで一番つらい時期
あれから１ヶ月 。
自分が出した問題も解決し、GW明けにやっとうちのプロジェクトも最終フェーズに入ります。
結合テストからシステム統合テストへの移行です。
しかし、まだ「やっと」などと表現できる状態ではありません。
プロジェクトで今の時期が一番つらいかもしれません。
システム統合テストではより顧客が踏み込んでくるのでバグは出せない。
にも関わらずシステムは安定していない。
重要なルートでバグが発生しているにも関わらず、なかなかそれが治らない。
僕が所属するチームでは、まだ消化すべきテストは1500項目もある。
悲惨な状況です。こんな状況でキレイ事は言いたくないですね。
正直な気持ち、ひたすら休みが欲しい。
そして今いるチームとは距離を置いて、なるべく自分の作業量を減らしたい
と思うときもあります。
本当にこんな状態で予定通りシステムを出荷できるのだろうか？
出荷できたとしても正常に動きつづけることができるか？
顧客や上層部の要求が既に無理難題ではなかったか？
こんな疑問が頭をよぎりますが、サイは投げられた以上やるしかありません。
今の開発グループの目標はただ一つ。ひたすら品質を上げる。
そしてプロジェクトをハッピーエンドに導くことです。
1ヶ月前、仕事で多忙な日々を送った人に現れる心の変化には2種類あると書きました。
自分はどちらの人間になるか？
まだ多忙な日々の真っ只中にいるので答えは出せません。
しかし、こんな状態でもblogを書いているぐらいだから、案外この状況を楽しんでいるのかもしれませんね。
平日の昼という非日常的空間
先日、久しぶりに休暇をとりました。
休暇といっても夜勤明けの代休ですが。
平日の昼に外を近所を出歩いてみると全てが非日常的に感じます。
公園で遊ぶ子供の姿、散歩する老夫婦、そして空の青さと太陽の光。
学生時代は何気ない光景でしたが、今ではとても貴重なものに思えます。
最近激務すぎたせいでしょうか。
その日がカレンダー上では赤字で書かれている日だろうが
何の違和感も無く出勤していた状態が２ヶ月近く続いていました。
その日は、ちょっと近くの保養施設にいって温泉につかったのですが、
今の仕事のこと、今までの自分、今後の自分のこと、そして世の中のこと、
いろいろなことに思いをめぐらせました。
最近は日常の業務の延長線上でしかものを見れなかったため、
近視眼的なことばかり考えていましたが、
平日の昼に温泉という非日常的な空間でものを考えたことで
普段見えないことが見えた気がします。
気持ちのリフレッシュにもなったし。
どんなに忙しくても余暇は必要 だと改めて思いました。
自己評価デー
エンジニアの仕事を始めて１年以上が経ちました。
どこの会社でもこの時期、人事考課が行われていると思いますが
今日は1年間の総括的な自己評価として自分の良い点と悪い点をあげてみようと思います。
■ 良い点（成長した点）
・実行力がついた
→業務上必要な基礎スキルは全て習得し、生産性はこの1年でかなり上がりました。
まあ、新人の頃に比べて生産性が上がるのは当たり前ですが。
・物事の問題点を把握できるようになった
→闇雲に言われた仕事だけに打ち込むということが少なくなり、
プロジェクトや仕事上の問題点を把握できるようになってきました。
試験でのバグなんかはかなり高い頻度で発見することができると自負してます。
あとは問題点を改善していける力を伸ばしていきたいです。
・コミュニケーションがうまく取れるようになってきた
→元々内向的で口下手、かつ性格が歪んでいる（苦笑）ところがあったのですが、
この1年で良い意味でだいぶ丸くなったように感じます。
人事考課でも先輩や上司への報告や相談もよくできているという評価を受けました。
■ 悪い点（精進が必要な点）
・創造的な作業経験が少ない
→この1年はデバッグやその進捗管理が主な仕事で、頭の中でソフトウェアを創造し、
それを実現していくという開発の要となる部分の作業経験が少ないです。
今年もこのままだとエンジニアとしての価値はあまり向上しないでしょう。
・物事の良い面にあまり目がいかない
→物事の問題点は見えるようになってきましたが、逆に良いところを見つけて
それを伸ばしたり、吸収していくのがまだ不得意だなと思います。
打ち合わせでも建設的な意見があまり言えません。後ろ向きだな～俺と思うところが多々あり...
・背伸びしすぎる
→自分は上昇志向が強い方で、また難しい本を読んだりするのが好きですが、
背伸びしすぎるところがあります。目的にたどり着くための段階を踏まないで目的にたどりつこうとします。
本当に理解していないのに理解した気になったり、基礎をやらないで応用をやろうとしたり...。
今後は口先だけの薄っぺらいエンジニアにならないように土台をしっかり築いていきたいです。
哀しき開発環境担当者
全ソースのコンパイルを行ったり、
試験用マシンの構築やメンテナンスを行ったりする
いわゆる開発環境担当者がプロジェクトにはいます。
以前、環境に対する質問や要望を彼らに出してもどうも腰が重く、
それはそちらで考えてやってくれ、みたいな回答をされて
カチンときたことが何度かあったのですが、
最近になって彼らがそうなった理由が分かってきました。
よく観察してみると開発担当者はとても損な役回りです。
まず開発者からは彼らが何をやっているのか見えずらいから
仕事の大変さも当然分からないでしょう。
だから環境に対して無理な要求を出してまいがちなところがあります。
自分も含めてプロジェクトには開発環境はあって当たり前だと
思っている能天気な開発者が結構いますが、
やはりそう思っていると環境系で問題が起きても
自分で解決しようとしないどころか原因を追求しようともしません。
経験から言うと、環境系の問題の５割以上は開発者自身が招いたものですが、
開発者の口から出る言葉は「壊れたから早く直して」って感じです。orz (反省
そして何よりも彼らはプロジェクトではあまり大事にされていません。
その割りに問題が起こったときはしっかり責任を負わされます。
なんかいましたよね。
島田紳助が吉本の女マネージャーに手を出した事件で、
「役者がいるから食わせてもらってるのに、あのマネージャー何様だ」
みたいなことを言っている某芸能人。
開発担当者の扱いもそれと同じところがある気がします。
これではなるべく開発者自身で環境の対処をさせようと、
腰も重たくなるでしょう。
開発者をサポートするのが開発環境担当者の仕事でもありますが、
サポートしてもらえなくなる前に態度を改めたほうが良さそうです。
体力がないとSEの仕事はできないという考え方に反対
この業界で仕事をしていると、どうしても体力勝負なところはあります。
だからといって「体力がないとSEの仕事はできない」などと
豪語する人もいますが、そういう考え方には反対です。
この仕事に本当に必要なのは体力ではなくて、頭と効率性なはずです。
この仕事をやっていると、できる人とできない人の間には
かなり生産性に開きがあることが分かりますが、
できる人というのは、別に体力勝負で寝ないで働いているということはなく、
やはり頭が良い。そして、効率性もとても良い。
例えばテストケースの自動生成ツールを使っていたり、
エディタの便利な機能を利用していたりと、
とにかく生産性を上げるための工夫をしているのです。
逆に生産性の低い人は、それを気にしてか日常的に徹夜をしたり、
生産するものの質ではなくて量にこだわっていたりと、
（量のほうが成果として見えやすいですからね）
仕事に対する捉え方が真っ直ぐ過ぎるところがあります。
プロジェクトが忙しくなると、後者のほうが「がんばってるな」と良い評価を受けて、
前者は「周りががんばっているのに一人だけ楽しようとしている」などと
スケープゴートにされてしまうことがありますが、そういうところを見ると
これでもIT業界なのか？？と思います。
まあ、誰も好きで体力勝負などと言っているのではないでしょうが、
体力勝負と言わざるおえない状況に陥ってしまう原因は、
体力勝負という考え方自体にもある気がします。
元々ハードウェアやソフトウェアというものは、
人間が自身の力の限界を克服するために作られたものでもあると思うのですが、
その開発に携わる人間が体力勝負などと現状を肯定してしまってどうするのでしょうか。
こういった意識を変えていかなくては、日本のIT業界はいつまでたっても
労働集約型の構造のままで、真の知識産業へと生まれ変わることはできないでしょうね。
バグを見つけたら・・・
バグシリーズ第3回のテーマは「バグを見つけたらどうするか？」です。
テストをしているとき人のバグを見つけるのはまだいいですが、
それが自分のものとなるとあまり良い気分ではありません。
なるべく事を穏便かつ迅速に収束させようとしがちですが、
バグを見つけたときほど正直にそして慎重に対処しなければいけないと思います。
■ バグを隠す人
テスト工程になると必ず自分のバグを隠そうとする人がいます。
本人は悪意でやっているのでなく、なるべく事を穏便に運びたいのでしょうが、危険です。
こういう人は大事なことを忘れています。
バグを出したのは自分だということを。
バグというのは勘違いやうっかりミスから生じるものですが、
その勘違いやうっかりミスをやらかした人間が一人でバグを修正しようとしたら、
また同じ事が起こるかもしれないという思いには至らないのでしょうか。
■ バグ発見後の調査
バグの修正は、自分以外の第3者（できれば立場が上の人）の
（言葉が悪いですが）監視の下で行われるべきです。
そして修正だけでなく同じ様な問題は他の処理でないか、
またバグを修正したことによる影響はないか、という観点で調査を行い、
その結果をメモ書きでもいいので形にして監視者に見せるべきでしょう。
調査での観点でもう一つ重要なのが、今見ているバグは本当にバグか？
ということです。
修正したと思ったら、実はそのバグは別のバグによって生じた結果にすぎなかった、
という入れ構造のバグもあるので調査はしっかり行いましょう。
■ バグを出すことではなくて見つけられないことが悪い
バグシリーズも最終回になりましたが、最後に言いたいことは、
「バグを出すことよりも見つけられないことの方が悪い」という考えを
職場に浸透させるべきということです。
バグを報告した開発者に対して責任追及と非難ばかりに終始する管理者もいますが、
そういう管理者の下ではバグが隠蔽される件数が増えるだけで、
本当の意味での品質向上には結びつかないと思います。
誰もバグを出さないという意識が薄いからバグを出しているわけではありません。
成果物に対する見直しが不十分であることがより大きな原因でしょう。
職場全体でバグを見つけるという意識が強ければ、再確認にも力が入るはずです。
以上、最近バグを見つけることに生きがいを感じてきた23歳でした。
タイトル変更
blogタイトルを変えました。
今後もひたすらソフトウェア開発とプロジェクト・マネジメントに関する
つたない自論？を展開させていただきます。
てか最近老けたなぁー。
そろそろ若造SEなんて自称できなくなりますね。
さ、今日もこれから会社行ってきます。
ではでは。