罪と罰（23） 蜂群崩壊症候群
「ところで」仕事の話が一段落したとき、荒木准教授は思い出したように訊いた。「五十嵐くんのイニシアティブの方はどうだね」
「うちの部署について言えば、確実に変わってきていますよ」私は荒木准教授が淹れてくれた香り高いコーヒーを楽しみながら答えた。「特に若い連中の変わりようときたら、去年の今頃からは想像もできないぐらいですね」
「箕輪さんだってまだまだ若いじゃないか」
「そりゃ先生に比べれば」私は軽口を叩いた。「まあ、でも、私もいろいろ変わりましたよ。まさかこの年で管理職に就くことになるとは思ってませんでしたから。最初はとても無理だと思っていたんですけど......」
「やってみたら案外できちゃうもんだろ」からかうような口調だった。「人間は大抵のことには順応するもんなんだよ」
「そうみたいですね」
「ま、大抵の権力は腐敗するものだからなあ」荒木准教授の口元に悪戯っぽい笑みが浮かんだ。「箕輪さんもそうならないように」
「......」
荒木准教授には、たまにこうやって人をからかって面白がるクセがある。ひょっとすると、意図的に狼狽するような言葉を投げては、研究のために相手の反応を記録しているのかもしれない。
私はコーヒーと一緒に出していただいたクッキーをかじった。2枚目だ。いつもなら1枚だけで遠慮するところだが、今日はいささか空腹だったのだ。
空腹だった理由は、KSR電機さんを交えた仕様書レビューが、12時直前まで続いたからだ。KSR電機の池田さんたちは、機能そのものよりも、その機能をどうやって実現するのか、ということの方に興味があるようで、どちらかと言えば実装寄りの話題が多かった。機能中心にレビューが進むのであれば、武田さんたちに任せておいて、私は適当な時間に抜けだそうとか思っていた。だが、KSR電機側が出してくるのは、武田さんや久保さんでは、とても答えられそうにないような質問ばかりだったから、必然的に私が応答せざるを得ない。五十嵐さんであれば答えられたはずだが、なぜか自分で答えようとせず、私に振ってくるばかりだった。
とはいえ、五十嵐さんは完全に傍観していたわけではなく、工数がかかりそうな実装の話になると「それは別見積に」といった類いの口上で、たくみに回避してくれた。おかげで結果的に追加された機能の数はそれほど多くなかった。
レビュー後半では、武田さんと久保さんが発言する機会はほとんどなく、質疑応答はもっぱら私が担当していた。武田さんは終始愛想笑いを浮かべて、交わされる会話の内容を、さぞ理解しているようなふりをしていたし、久保さんはすでに会話に参加することを諦めたように、じっとプリントアウトに何やら書き込みを入れていた。
話題が注文番号の採番の件になったとき、武田さんは勢い込んで、欠番が出ないことを強調したが、KSR電機側の反応は鈍かった。
「はあ、なるほど」北条さんがどうでもよさそうに言った。「まあ、番号飛んだら、締日までに赤伝切ればいいんですけどね」
そのときの武田さんの顔を守屋が見ていたら、絶対に「それ見たことか」と言ったに違いない。私は再び、この場に3バカトリオがいないことを感謝した。
12時まで10分ほどを残してレビューが終わったとき、KSR電機の3人は満足度90%といった表情を見せた。
「ありがとうございました」池田さんがお礼を言ってくれた。「まあ、こんなところでしょうね。ここまで詳細な設計書を作っていただけるとは思いませんでした」
それを聞いた武田さんと久保さんは嬉しそうな顔になったが、池田さんの言葉はまだ終わっていなかった。
「正直、こんなに詳しいものを作っていただくより、実装の方に入ってもらっていた方がよかったんですが。まあ、でも、それは御社の問題ですから」
「あ、でも」武田さんは少し意地になったような表情で言った。「御社でメンテナンスされるためにも、仕様書は必要ですよね」
「このシステムについて言えば、寿命はせいぜい2年といったところなので、それほどメンテナンスが発生するわけでもないですがね。ソースがしっかりしてれば、たぶん問題ないです。ソース見た方が早そうだし」
武田さんは何か反論したそうだったが、賢明にも口をつぐんだ。ここで、「若い連中にしっかり設計したシステムの作りやすさを思い出させてやりたかったんです」などと発言したら、一騒動あったかもしれない。
レビュー終了後、私はKSR電機の方たちをエレベータまで送っていきながら、疑問に思っていたことを訊いてみた。
「あの、みなさん、実際に実装とかやられるんですか？」
私より少し年上だと思われる池田さんは小さく笑った。
「課長なんて言ってもね、ま、実際は何でも屋なんですよ。設計から実装からテスト、保守まで何でもやります。おまけに責任までもれなくついてくる」
どこも同じなんだなあ、と共感しながら、私はもう一つ訊いた。
「じゃあいつもこんな風に設計書のレビューとかやるんですか」
「いや、そんなことは滅多にないですね」池田さんは肩をすくめた。「うちはほとんど内製というのもありますが、外部に出す場合でも、うちのコーディング基準なんかを説明するぐらいですかね」
「今回は特別ですよ」じゃあ、今日はどうして、という私の内心の疑問を読み取ったのか、北条さんが横から言った。「御社の五十嵐副部長が、ぜひ実装チームにレビューをお願いしたい、と言ってこられたものですからね」
「え、実装チームに、ですか」
「ええ。正直、ちょっと戸惑ったんですが。でも、来てよかったですよ」北条さんは小声になった。「要件定義の段階から、武田さんにはちょっと不安だったんですよ。あまり実装レベルの話をしてくれなかったものですから」
「箕輪さんとお話ができて、不安なところは解消されましたけどね」八十田さんが付け加えた。
「それは......ありがとうございます」
そのときは深く考えている余裕はなかった。私は慌ただしくKSR電機の3人を見送ると、すぐに自分の外出の準備に取りかからなければならなかったからだ。
大急ぎで持って行くドキュメントをチェックし、印刷し、第2開発課のメンバーにいくつか指示をしていると、とても悠長に食事を取っている余裕はなくなっていた。私は机の中に放り込んであった、いつ買ったのかさえ憶えていないドライフルーツと、カスミさんが分けてくれた卵焼きでランチを済ませると、慌ただしく会社を飛び出さざるを得なかった。途中、日吉駅でグリーンラインに乗り換えるとき、自販機で買ったミルクティーを補給したが、それ以後は何も口にしていない。
「私としては、五十嵐さんがいなくなった後のことが心配なんですけどね」私は3枚目のクッキーをつまみながら言った。「また、元に戻ってしまうんじゃないかと」
「ああ、たぶん、五十嵐くんはその点について、何か手を打つと思うよ。いや、残り時間を考えると、もう打ってるか」
「五十嵐さんも前にそんなことを言ってました。と言っても、具体的にどんな手を打つのか見当もつきませんが......」私はさりげなく荒木准教授の表情をうかがった。
「私にもわからんよ」荒木准教授は苦笑した。「別に決まったマニュアルがあるわけじゃないらしいからね」
「そうですよね」
「ただね」
「はい」
「あまり穏やかな方法でないことは確かだな。はっきり言えば、少し過激な方法になるだろうね。これまでの例からすると」
「過激......ですか」戸惑いながら、私は訊き返した。「それはたとえば、変わろうとしない人を辞めさせるとか、そういうことですか？」
「まあそういうこともあるだろうね」
荒木准教授は詳細の明言を避けたが、私は身を乗り出した。
「でも五十嵐さんに人事権はないんですよ」
「箕輪さん、蜂群崩壊症候群という言葉を知ってるかな」荒木准教授は私の目をじっと見つめながら、聞き慣れない単語を言葉を口にした。
「ほうぐん......いえ、知りませんが」
「簡単に言うと、ミツバチが一晩で大量にいなくなってしまう現象のことだ。コロニー、つまり巣箱から消えてしまうんだ。死体は残っていない。スズメバチなどの外敵にやられたわけでもなく、災害に遭ったわけでもない。女王蜂や幼虫は残っているが、働きバチのほとんどがいなくなるから、コロニーを維持できなくなってやがて死滅する。主にアメリカ各地で発生しているが、ヨーロッパや日本でも現象が報告されている」
「気味が悪いですね」私は顔をしかめた。「原因は何なんですか？」
「ネオニコチノイド系の農薬によって、ハチの帰巣本能が破壊されたため、という説が有力だが、いまだに解明されてはいない」荒木助教授は年季の入った民芸調のコーヒーカップを口に運んだ。「ミツバチは農作物の受粉に重要な役割を果たしている。だからハチがいなくなると、農業生産は大きなダメージを受ける。それで問題になっているんだ」
「......」
「五十嵐くんが、というより、イニシアティブの方法は、それに似ていると言ってもいいかもしれないなあ」
「......よくわからないんですが」
「さっきも言った通り、箕輪さんの会社に対して、五十嵐くんが最終的にどういうアプローチを取るのかはわからないよ。新しいチームが立ち上がり、無事に軌道に乗ったことが確認できれば、それで満足して去って行くのかもしれない。そういうこともあったからね。まあ、それは元々対象の会社の社員が、問題を自覚していた場合に限られるんだが」
新しいチームの立ち上げ。うちの場合だと、第2開発課が発足したことがそれにあたるわけだ。
「ただし、チームを立ち上げるのはそれほど難しいことじゃない。難しいのはそれを維持し、発展させていくことだ。そのとき、最も障害になるのは、保守的な勢力であることが多い。箕輪さんもわかるんじゃないかな？」
私は頷いた。そのとき頭に浮かんだのは、もちろん武田さんや久保さんのことだ。
「五十嵐くんはそういう勢力を崩壊させるのが実にうまいんだよ。まるで巣箱からハチが消えていくみたいに、それを成し遂げるんだな。気がつくと、いつのまにか、抵抗がなくなっている。そんな感じだ」
「それは......」私は脇の下が汗ばんでくるのを感じた。「ちょっと怖いですね」
「しかも、そのプロセスは彼の契約期間の最後の2、3ヵ月で行われることが多い。五十嵐くんの契約は、来年の1月いっぱいなんだっけ？」
「そうです」
「だとすると、そろそろ事を起こす頃じゃないかな。起こすとしたらね」
そう言ってから荒木准教授は私の強張った表情を見て、楽しそうに少し笑った。
「排除とか崩壊とか、ちょっと怖い言葉を使ってしまったけど、それが必ずしも退職強要とか追い出し部屋送りとか、そういうことを意味するわけではないから」
「......十分怖いんですが」
「それは失礼した」荒木准教授はクスクス笑いながら時計を見た。「ああ、そろそろ次の予定の時間だな。忙しいところ、引き留めてしまってすまなかったね。まあ、そう心配することはないと思うよ。これまでイニシアティブが、というか契約した会社が、不当解雇で訴えられたとか、暴力沙汰になったとか、そういうことはないから」
どんなことにも最初はある。そう思ったが、口には出さなかった。私たちはいつものように握手をして別れた。
帰りに日吉駅で降りて、すぐ近くのミスタードーナツで休憩した。傍から見ればサボっているようだが、私にとっては遅いランチだ。
オールドファッションとフランクパイをパクつきながら、私は荒木准教授の言ったことを考えた。今のところ、Webシステム開発部内は、2つの課に分割されたことによって均衡状態にある。ただし、今後のことを考えると、第1開発課の仕事が減っていくのは目に見えている。
それを誰よりも承知しているのは武田さんたちだろう。今からWebシステム開発の最新技術を学んでも、第2開発課のメンバーには追いつけない。かといって、第2開発課の仕事のおこぼれをもらう立場に甘んじるのもイヤだ。たとえば3バカトリオから、あれこれ指示されるなど、武田さんが受け入れるはずもない。
武田さんがKSR電機案件を積極的に受けた気持ちは、痛いほどよくわかる。足立が言っていたように、顧客の要求を引き出す要件定義のスキルにおいては、武田さんたちが先を行っていることは間違いない。ただしそれほど遠くない将来、その差は急速に縮まってくるだろう。その日が来る前に、武田さんは第1開発課が分析・設計フェーズ、第2開発課が実装・テストフェーズという棲み分けを確立しようと狙っていたに違いない。KSR案件によって、その有効性を証明しようと考えたわけだ。残念なことに、午前中のレビューでボロを出す結果となってしまったが。
そもそも五十嵐さんが行ってきた改革は、そのような昔ながらのヒエラルキーに基づく開発体制を破壊するものであったはずだ。今さら時代に逆行するような体制の存続を、五十嵐さんが許容するとは思えない。でも、だとすると五十嵐さんは、なぜKSR電機案件を、第1開発課主導で進めることを許したのだろう。
ドーナツがなくなりティーポットが空になっても答えは出なかった。ひょっとすると答えを出すことを、無意識のうちに避けていたのかもしれないが。
お土産のミスドビッツ18個入りを持って帰社したのは、15:30過ぎだった。
オフィスに入ると、中が何となく閑散としているような印象を受けた。その理由はすぐにわかった。五十嵐さん、中村課長、武田さん、久保さん、村瀬さんの姿が見えない。村瀬さんはずっと外出中だから不思議ではないが、他の人たちがまとめていないのは珍しい。
「おかえり」カスミさんが笑顔で迎えてくれた。「寒かったでしょ」
「寒いです。何か人が少ないですね」
「うん」カスミさんの笑顔が消えた。「武田さんが早退しちゃって。他の人は会議室」
「へえ、あの元気な人が。風邪ですかね」
カスミさんは躊躇いがちに周囲を見回すと、声を落とした。
「午後一番で、五十嵐さんが課長と武田さんと一緒にミーティングルームで何か打ち合わせをやってたのよ。議題は知らないけど」
「へえ」
「1時間ぐらいかな。で、その後、みんな普通に仕事してたんだけど、気付いたら武田さんがいなくなってたのよ」
「いなくなったって」私は武田さんのデスクを見た。「外出したとかじゃなくて？」
「そう。誰にも何も言わずにいなくなってたの。上着とカバンもなかったから、帰ったんだと思うけど」
「電話してみたんですか？」
「久保さんが携帯にも自宅にもかけてみたけど......」
「応答なし？」
「そう。だから、課長がとりあえず早退ってことにしたの」
仕様書星人であることと無関係ではないだろうが、武田さんはルールはしっかり守る人だ。無断欠勤などあり得ない。まして勤務の途中で、黙って帰ってしまう姿など想像もつかない。
「まあそれほど心配することでもないのかもしれないけど」優しいカスミさんは、口にした言葉に反して心配そうな表情だった。
私が思わず蜂群崩壊症候群という言葉を思い浮かべたとき、カスミさんの席で電話が鳴った。カスミさんは短く応答した後、「伝えます」と結んで電話を切ると私を見た。
「五十嵐さんよ。ミーティングルームに来てくれって」
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
elseorand
今回のKSR電機さんの出席者は､出席者としては正直珍しいタイプに思いました｡
業務とシステムの現実を投げ出すこと無く捉えているプロの職業人として｡
こういう方々になれないような連中に
｢君は頭が悪いから､即刻足を洗え｣
と言ってあげるのが優しさですが､
ぬるま湯･ゆとりに浸かりすぎていますから､
｢相手が傷つく｣と怖れて皆さん言わないんですよね｡
参考としては芸術系では講評で滅多切りにするように､
社内で勉強会と演習で､名前付きで比較批評をするとでてこなくなる奴は駄目なので､お薦めです｡
まずはFizzBuzzですね｡
この程度でも差が明確に開きます｡
ここでどうしようもない連中に引退を通告できるようになるのが大切です｡
ans
うーん？
私の普段やっている業務・教義とはかけ離れすぎて参考になりません。
業務の内容を熟知していて、質問すれば打てば響く受け答えで、すぐに疑問を解消してくれる数人います。
そのひとたちはまったく実装ができませんがプロジェクトには欠かせない存在です。
なんだか実装ができなきゃ無条件でダメみたいに聞こえて嫌な感じ。
邪推
KSR電機の担当者は開発者より過ぎで、社内ＳＥとしてはどうかと思うけどな。
こんなんだから今まで仕様の伝達漏れが何回かあって、仕様書固めるようになったとか考えてしまう。
もちろんそんな担当からでもちゃんと仕様を聞き出して固めるのが開発者ですが。
dotJ
＞そのひとたちはまったく実装ができませんがプロジェクトには欠かせない存在です。
五十嵐氏は、たぶん「業務の内容を熟知していて」「実装もできる」エンジニアのチームを養成しようとしているんではないでしょうか。
「上流工程」という言葉があるように、業務のことを知っている人が地位が上、みたいな風潮があり、それはそれで嫌な感じです。
lav
開発プロセスに対する要求にはこたえられなかった、武田さん
ってか、シノハラさんと同じことをやってしまったわけですね。
開発を早くしてほしかったのに、仕様書作りに無駄に時間を費やしてしまった意味で
同じ失敗は五十嵐さんにとっては、許されない話だった
ならば、切るしかないとジャッジになりますね
yamada
いいところで終わるなぁ！
というわけで来週も楽しみにしております。
オンブレ
私の会社にもいます
業務知識はあるし対人折衝もうまいけど、実装経験なしの人
その方に要件定義させても穴だらけなので、結局、後日、実装できる人が出て行かないといけない
時間の無駄なんですが、そういう慣習なのでどうしようもない
異動してほしいとみんな思ってますが、当の本人は重要なポストにいるつもりで、態度も偉そう
イニシアティブと契約したいので、連絡先教えてください
gems
自分のやっていることがお客さんの求めているものと違うとさっしたら、変わるしかないけど、変わりたくない人はやめて新たな活躍できる場所を探すんだろう。
詳細設計を技術力ないひとがやる場合もあるけど、その場合実装時にやりやすい実装方法があれば、言ってくれれば修正するからっていってくれるオジさんたちとは仕事したことあるので、そういう人とやれてよかったのと設計する力も付けれた若かりし頃を思い出し。精進しなければと
ミーミー
要件定義だけやってれば良かったのに…
設計書作らせたのって、確信的ですよね
怖いわー
DumbObj
>「まあ、番号飛んだら、締日までに赤伝切ればいいんですけどね」
それ、めちゃくちゃめんどくさいでしょ。機械のやる仕事。
> まあ、でも、それは御社の問題ですから
設計書検収ってことは、納品物として設計書を要求してるはずなのに"御社の問題"なの？
問題を定義する人が、問題を解く力がある必要は必ずしもないし、
問題を解く力がある人が、うまく問題を定義できるとは限らないと思う。得意分野の違い。
でも、高度な生産技術が3Dプリンターなどの進化でコモディティ化されつつあるように、
問題を解く力のほうが、機械にリプレイスされやすいのは確かだとも思う。
ソフトウェア開発におけるソースコードは、ものづくりにおける3D CADデータなのか、
それともプリントされた造形物なのか？
高度なプログラミング技術がコモディティ化するとしたら、それは何によってか？
仕事として続けていくには、こういったことを定期的に考えなおす必要があるのかなと。
武田さんに幸あれ。
wwJww
武田さんのような仕事の仕方をする人は何人か知っているけど少々煙たがれる程度。
それは人格が武田さんよりずっとまともだからだろう。
だから武田さんがダメなのは能力以前に人格。
自分の落ち度を部下のせいにしている時点で能力関係なくアウト。
以前、部下に恫喝をやらかしているが（恩着せがましさもプラスして）あれが最もひどい。
fluidicB
どんな人にせよ、
空飛ぶサラリーマン
とかにはならないでほしい。
名無し
武田さんはオフショア開発で橋渡し役をやると幸せになれるかも
それか、技術はあるけど、業務知識が不足している人と対等の立場でコンビを組ませるとか(部下にすると話聞きそうに無いので)
>> まあ、でも、それは御社の問題ですから
>設計書検収ってことは、納品物として設計書を要求してるはずなのに"御社の問題"なの？
多分初期の打ち合わせで、設計書の粒度はそこまで求めてなかったんじゃないかと
で、それを超える大作を仕上げてきたので、それに押されて実装の期間が減ってもそっちの問題だよと
暗に最終納品は伸ばせないよ、と言ってるのかもしれませんが
kyo
>武田さんはオフショア開発で橋渡し役をやると幸せになれるかも
私も同じことを思いました。指示書としての詳細設計書はこれぐらいの粒度が必要でしょう。(オフショア先のレベルに応じて・・の話や、技術的にアレだったところはともかく置いといて)
ただ、メンテナンスとして使う設計書は、大まかなモジュールの動作定義が書かれている程度で十分と思います。
引数まで書いてあるような設計書はたぶん私もみません・・。ソースと同じレベルの話が書かれているのなら、動いている方(ソース自体)を真としますよね・・。
とある初心者
なんだか、
実装技術＞＞＞＞＞＞＞＞＞管理能力や業務知識
っていう構図が露骨過ぎてもにょ
asdffdsa
↑あんたは一体何を求めてるんだよ
DumbObj
>名無しさん
なるほど、"御社の問題"っていうのはスケジュール的な皮肉ですか。
スケジュールにしても粒度にしても、このセリフからは、責任感の薄さを感じるんですよね。
発注者として、もう少し積極的にコントロールする意識があってもいいんじゃないかと。
こういう発想になるのは、知らず知らず武田さんに同情しちゃってるからですかね。
匿名
正直、IT業界で、実装技術が皆無だけど管理能力は優れている
なーんて人は、いるわけがないからなぁ･･･。
実装に関する技術や知識があって、はじめて管理能力や業務知識が活きてくるわけだし。
技術や知識についていけなくなったら、そういう能力も死ぬと思わないと。
この時代に100枚紙を印刷するのに、まず活版を作って手作業で行うと、これだけかかりますとか言われても
お前は何を言っているんだ？って事になる。
ワンライナー
FizzBuzzといえば、「ミドリのプログラミングな1日」（電子書籍版の「鼠と竜のゲーム」の書き下ろし追加章）に、ミドリさんが暇つぶしに、ワンラインFizzBuzz剰余禁止というのを考えるシーンがある。自分も試しにFizzBuzzを剰余禁止で作ろうとしてみたが紙を使わないとできなかった。ワンラインというのも難しい。これを頭の中でやってしまうミドリさんはやっぱりプログラミングジャンキーなんだと思った。
実装ができる人は、その気になれば要件定義や設計もできるが、その逆は真ではない。
まあ
ここ何本かはただ底辺土方の溜飲を下げて人気取りに走ってるだけだしね。
管理される側からの支持を得ようとするのは人数比的に正しいと言える。
DumbObj
「プログラマーとして最低限の能力があるかどうかを確かめたい」という抽象度の高い要望を、
FizzBuzzという機械的にテスト可能な仕様に落としこむ能力と、
FizzBuzzのように明確に定義された問題を解く能力とは、種類の異なる能力だと思う。
どちらか一方ができるからといって、もう一方ができるとは限らないと思う。
詳細設計やプログラミングは問題なくできるけど、
要件定義がうまくできない人を何人も見たことがあるので、知識量の問題ではなく、
いかに問題を解くかと、いかに適切な問題を定義をするかとは、
頭の使う部分が違うんだろうと思うし、違う訓練が必要なんだろうと思う。
Masa
武田からしてみれば全能力かけて思いっきり仕事をしたあげくその成果で恥をかき、目障りな箕輪に後始末をさせるはめになって相手に名を成さしめた形。そんなことになったら針のむしろだし、耐えかねて自分から去っていく可能性が高い。
老中追い出すのに待遇を変えず元のように仕事をさせたうえで恥をかかせて自分から辞めるように仕向け、側近の加納、有馬らを有無を言わさず出世させた徳川吉宗のやり方に通じる。去る方からしても正面切って文句言える状況ではないし、ある意味うまいやり方ではある。
nagi
＞「プログラマーとして最低限の能力があるかどうかを確かめたい」という抽象度の高い要望
これは
＞社内で勉強会と演習で､名前付きで比較批評をするとでてこなくなる奴は駄目なので､お薦めです｡
＞まずはFizzBuzzですね｡
を加味しての発言なのかな。
勉強会というものにおいて、各自がFizzBuzzを作ってみて意見を交わたところ
名指しで酷評すると次から出てこない自尊心の高い人は大体ダメにたいして
＞FizzBuzzという機械的にテスト可能な仕様に落としこむ能力と、
＞FizzBuzzのように明確に定義された問題を解く能力とは、種類の異なる能力だと思う。
こーではないと思うんだよなぁ。
お互い酷評でも研磨していくのが勉強会とかで、
それについて来れないのは～であって、種類の違う能力であるから～とはちょっとずれてる気がするなぁ。
あ
番号飛んだぐらいで赤伝切ったりしませんよ。
手書きで書き損じたら、もう１枚伝票切りますか？
切らないでしょ。
実装能力のない社内ＳＥは、自称「社内ＳＥ」なだけなんですよ。
システム部門に居るからと言ってそれだけで「社内ＳＥ」なんじゃないんです。
もちろん社内ＳＥじゃない、システムにちょっと詳しい人も
ユーザー企業のシステム部門には必要なんですけどね。
オフコンの時代からシステム部門があるような会社だと
実装できない社内ＳＥなんて居ませんよ。
実装できないシステムを設計して何の役に立つんですか？
自動車会社のエンジニアが、素晴らしいけど組立てることのできない自動車を設計したとして、それを素晴らしいと褒める会社があると思いますか？
キチンと量産できるような設計をするのが当たり前。
そのためには生産工程を知ってなきゃ駄目なんですよ。
ソフトウェアも同じ。普段は実装しなくても、実装能力はあって当たり前。
Masa
管理と実装の能力について読み返していて思ったこと。
第十六回で「特にマサルは、ゴールだけ明確にしてやれば、途中経過は自分の判断でガンガン進めていける性分だということがわかってきた。優秀なエンジニアは、あれこれ口を出すよりも、好きにやらせておいた方が、大抵の場合、良い結果が出る。」ってあるけど、こんな感じでエンジニアが仕事をしやすいように土台を作ってあげるのが管理だとすると、確かに本人の実装能力は配下のエンジニアほどはいらない気がする。配下の能力を最大限に引き出せる様に手助けをしていればいいわけだから。
周りにも人の力を引き出すのはうまいけれど技術力はあまりないメンバーがいますが、その人のおかげでプロジェクトがうまく回っているのが実感としてあります。
そういう意味で考えると、管理者側の人間の中で進藤だけが(個人的な事情は別としても)五十嵐から別格扱いされているように見えるのは当然かも。本人の能力自体は低いにしても、メンバーの生活状況や健康を観察して常に気持ちよく働けるように気を配っているわけだから。
まぁいずれにせよ武田は管理者失格か。この基準で考えても三バカの能力を引き出せているとはとうてい言えないわけだから。
オレンジ
うーん。
作中の武田さんは、五十嵐さんが居なくなったら元に戻す宣言しちゃったので冷遇されるのは仕方ないとしても、カスミさんみたいに「第二開発課の邪魔はせず既存の保守案件に専念する」という姿勢だったら居場所はあるんじゃないかなあ。
DumbObj
>を加味しての発言なのかな。
いえ、違います。違う話にFizzBuzz使っちゃったのでわかりにくかったですね。サーセン。
実装できる人は要件定義もできるというコメントや、
第2開発課メンバーは武田さんに追いつけるけど、
武田さんは第2開発課メンバーに追いつけないという本編の内容に対して、
私はそうは思わないということです。
武田さんについては学ぶ意識が芽生えればという条件付きですが。
nagi
＞こんな感じでエンジニアが仕事をしやすいように土台を作ってあげるのが管理
でも、ホウレンソウというものがありまして。
部下からの相談に的確なアドバイスを出来ない管理職は多々いるわけです。
なので、土台だけじゃないんですよね。
＞周りにも人の力を引き出すのはうまいけれど技術力はあまりないメンバーがいます
＞が、その人のおかげでプロジェクトがうまく回っているのが実感としてあります。
その方が技術力をつけたらもっとプロジェクトがうまく回るかもしれませんね。
そういう部分の意味だと思いますよ。
＞実装できる人は要件定義もできるというコメントや、
＞第2開発課メンバーは武田さんに追いつけるけど、
＞武田さんは第2開発課メンバーに追いつけないという本編の内容に対して、
要件定義って顧客並びに主に実装するメンバーに説明するという意味もあると思っていて
自分の思ってることを他人に説明するには、その事象について
２～３倍以上の知識を持っていなければ上手く説明できない、んですよね。
例えば、子供が勉強している教科について
（今は忘れてしまってるかもしれませんが、少し勉強すれば）
知識の幅は大人のほうがずっとあるので
的確な説明をしてあげやすいですよね。
なので、武田さんよりもどうすれば実現できるかを予め知ってる（判る）人のほうが
要件定義なりも適切にまとめれると思いますよ。
コツも経験も必要だとは思いますが、必要となる時間は少ないと思います。
Masa
＞ でも、ホウレンソウというものがありまして。
＞ 部下からの相談に的確なアドバイスを出来ない管理職は多々いるわけです。
＞なので、土台だけじゃないんですよね。
それじゃ「仕事をしやすいように土台を作っている」っていわないです。
私が言いたいのは、管理者は個人の技術よりも配下のエンジニアが技術に専念できるような環境作りをできる能力の方が求められているのではないかということです(引用した部分の前後もそういう内容でした)。
だとすると、管理者は顧客要件と期日を正確に捉えて配下のエンジニアに対して何を求められているかをわかるように伝えてそれに基づいたスケジュールも示し、逆に配下のエンジニアから相談や要望があればそれをふまえて顧客や他のチームに必要なヒアリングや調整を行うところまでできないとだめです。でないと個々のエンジニアが技術的な仕事に専念できない。
私があげた技術力は低いメンバーもそういう点は優れていて、私を含めた周りの技術者は他部署との調整やスケジュール管理をその人に任せて技術的な仕事に集中できるから余計なことを考えずに最良の働きができ、結果としてプロジェクトがうまく回っています。
進藤さんの例を出したので話がややこしくなったかもしれませんね。その点ではすいませんでした。
BEL
技術者がやがて管理者になる。技術は日々新しくなる。
基礎的な技術は持ち合わせているけど、新しい技術となると現役の技術者にはかなわない。
あたらしい技術を勉強すれば済む話だが、管理者はその時間をほかのことに使ったほうが
全体の効率はいい。という状況はあるかもしれないがそれはそれでいい。
(いいというか、そのプロジェクトでそうなってるなら、いい)
上流工程に携わる人間が下流工程の人より立場が上なんだという大きな勘違いがあると問題になる。
だいたいが、きちんとコミュニケーションが取れているか否かの問題。
実装力がないなら、実装する人に「この方法とこの方法だったらどっちが楽？」
「こういう設計で行こうと思うんだけど問題ない？」とか確認すればいいだけじゃないの。
「俺がこう決めたんだからその通りに作ればいい」とか言ったり、てるから問題なんだ。
(さらに言うと、そういう人が往々にして給料高かったりするのも問題かもしれんが)
この武田さんも一番の問題点は人間性。
ただ、あまり言われてないけどね、設計力ないプログラマも問題よ。
ろくに設計しないでプログラミングしてるのって、しばしば見るけど。
不治ソフト
五十嵐と教授が単に研究の為に色んな会社にちゃちゃ入れてるだけにしか見えない。
最後は業界紙に記事載って終わりか？
nagi
＞それじゃ「仕事をしやすいように土台を作っている」っていわないです。
＞私が言いたいのは、管理者は個人の技術よりも配下のエンジニアが技術に専念できるような
＞環境作りをできる能力の方が求められているのではないかということです
＞(引用した部分の前後もそういう内容でした)。
んー。書き方が悪かったかな。
土台を作ることは否定してないのよね。
土台だけじゃだめだよね、という意味でホウレンソウをあげただけなんだけど。
例にでている部分でいうとスケジュールかなぁ。
たとえば○○機能はある程度時間がかかるだろうと判断できるのは
自分の経験と実装担当のスキルレベルと難度から計りますよね。
ただ往々にして、実装担当者のレベルって自分ができないとどれくらいのモノかわからないし
担当させる機能の何が難しいか判断できるのは実装経験ないと難しいですよね。
もちろんコミュニケーションもとれることが大前提ですけど。
直接どれくらいかかりそうか聞いてみるとかもありですよね。
ただ比較基準がないと真偽がわからないですけど。
＞私があげた技術力は低いメンバーも （略）
こちらは上とは切り離して考えてまして、ただの感想として、
技術を勉強してくれたらもっとうまく回る（回してくれる）かもしれませんよね。
と思っただけです。
コミュニケーションってITだけじゃなしに
人と接する必要のあるすべての職業において必要だと思いますよ。
なぜか、ITは～ITは～という人がいますけど。
むしろそこまでいくとそれ人としてどーなの？ってレベルですしIT関係なくなっちゃうｗ
DumbObj
>自分の思ってることを他人に説明するには、その事象について
>２～３倍以上の知識を持っていなければ上手く説明できない、んですよね。
言わんとしていることは理解出来ますが、要件定義の内容を説明する際に、実装者よりも
それをどう実現していくかについての知識が必要となるケースは稀では？
あまりに非現実的な要求仕様にならない程度の知識と、
必要に応じて実装者に相談する謙虚さとがあれば十分なケースが多いんじゃないかと。
もしかしたら、要件定義という言葉で表現する領域が違うのかもしれませんね。
念のため補足しておくと、
"設計"は要件定義能力の一部ではなく、基本的に実装能力の一部だと思ってます。
設計できないけどコーディングはできるとか、コーディングはできないけど設計はできる
というのは、単に実装能力が低いと捉えてます。
扱うドメインや利用している技術によってはそうじゃないこともあるのかもしれませんが。
両方の能力が高いのが一番望ましいんでしょうが、
実装知識や如何に実現するかという思考に囚われて、要件定義で失敗する人が少なくないので、
別々の能力としてきちんと捉えておいたほうがいいかなと思ってます。
lav
要求を開発要件として、吸い上げる時、開発要件は常に検証可能でなけれはならないんですよね
という、戯言は置いといて、翌週の展開が気になる
なんか、同じエンジニアライフで展開してる傭兵達の挽歌の、杉野PMと
武田さん、かぶるんだよなぁ
展開もかぶったりしてね
TKFM
要件定義者は業務フローや税制、何をシステム化して何をシステム化しないかなどの判断、法律などの知識を元に暗黙知を言葉にできる人が要件定義をするのが基本であって、実装に関する知識の有無はオプションに過ぎないのでは。
要件定義する側からすれば「開発者も税法や経理の仕事くらい勉強しておいてくれたら楽なのに」というのは事実ですが、かと言ってそれを開発者に求めてしまうと、色々と無理が出てくる場も多いです。
と言うか、そんなスキルある人はなかなか集まりません。
今回の武田さんは、実装技術が無いのに実装(＝詳細すぎる設計)に絡んだのが問題であって、
武田さんは設計書間の矛盾がない事や業務用件からブレていないかを確認することに拘ったほうが良かったのに、と思います。
Jitta
武田さんに技術力がない、ワケではない。
しかし、「今の時代に通用する技術力」は、ない。
私は、勉強することが嫌で、早く就職したかった。
就職して、3ヶ月の研修が終わって工場に実習配属され、最初の仕事を任されて思った。
「一生勉強だ」
武田さんは、技術力がないわけではない。
前職でそれなりの実績もあったワケだし。
武田さんにないのは、時代と共に変わっていこうとする気持ち。
変わっていく技術を習得しようとする姿勢。
あるいは、必要とされる技術が変わっていることに気づくこと。
前回と今回で明らかになったのは、「武田さんには技術力がない」ことではなく、
「武田さんの技術は時代遅れだ」ということじゃないかな。
DumbObj
>「武田さんには技術力がない」ことではなく、
>「武田さんの技術は時代遅れだ」ということじゃないかな。
なるほど。ちょっとした視点の差ですが、見えてくる景色が全く違ってきますね。
武田さんにも技術力はあったと捉えることで、
自分はどうなんだろう？って考えが自然に湧いてきます。
ただ、武田さんのような人が、時代と共に変わっていこうとする気持ちや、
変わっていく技術を習得しようとする姿勢を手に入れることができるものなんでしょうか？
五十嵐さんの導き方次第ではそれもあり得たんじゃないかと思いつつ読んでるんですが、
残念ながら実世界ではそういうケースをまだ見たことはなく、半信半疑といったところです。
KAZY
この業界(に限らないかもしれないが)で必要な能力の一番は「調整」だと思っている。
それは上から下まですべての人間に必要なもので、「調整」ができない人間が上に立つと業務が破綻する。
nnn
「調整」ができる人は、「調整」できない人から、必要以上の要求や期待をされることがあります。自分はできないことで、他人には完璧を求めるような人です。
このストーリーだと、五十嵐さんに対して「武田さんが生きる場所を「調整」できないのか」というような…
これに関しては、「五十嵐さんは主人公の会社に売り込み、主人公のチームを独立させるところでできる「調整」をやっている」「武田さんの面倒まで見ようとしたら、五十嵐さんの契約期間ではオーバーワークになる。ある程度の切り捨てはしかたない」というのが私の感想です。冷酷なようですが…
通りすがり
＞TKFMさん
ごく一部の天才を除いては実装に関する概要知らない奴は要件定義出来ないよ。
なぜなら実装概要知らない奴はシステムと外部の領域の切り分けが出来ないから。
そう言う奴に要件定義やらせると実現できない事までシステム領域に持ってきて
大抵破綻するよ。
nagi
実装経験がなくて要件定義する人で真っ先に人形使いの橋本さんを思い出した。
通りすがり
赤伝だけど、紙で言うところの書き損じと修正印はコンピュータで言えば入力前のタイプミスでしかないから、それを根拠に赤伝切らないと言うのは違うよ。
システムで言うところの確定行為は、実際の伝票では切る行為に相当。
赤伝が面倒かどうかは発生率で語るべき問題で、実際、そんなに衝突起きないんじゃない？