日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

JavaScriptを有効にし、Cookieを受け入れ、以下のブラウザを使うことで完全なコンテンツが楽しめます。
Mozilla Firefox 3.0(Get Firefox)・Opera 9.6・Safari 3.2・Lunascape 4/5(Gecko)・Lunascape 5(WebKit)
Internet Explorer 7/8とそれを使うIEコンポーネントブラウザ(Lunascape・Sleipnirなど)

それはきっと製品愛だ

僕が今の職場に配属になった時は、開発組織は技術分野別で構成されている――ということになっていた。

製品ごとに必要な技術分野の人を集めて、そして開発活動を行うという体裁だった。

これがこの4月に名実ともに解体され、製品別の開発組織に移行した。

以前はこの形式だったそうなので、元に戻っただけだが。


もっとも、うちの部については、すでに数年前に実質的に製品別の開発組織になっていた。

そもそも、当初から部のメンバーとある製品群の開発担当はほとんど一致していた。

もともと、この製品群の開発者は1つの部に集まっていて、その大半はエレキ技術者だった。

社内全体としてもエレキ技術者は人数が多く、技術分野別といっても2つの部に分けてマネージメントを行うことになった。

エレキ技術者を集めた2つの部には、それぞれ重点分野が設けられていたのだが、

実質的には一方の部にはこの製品群の開発者の大半が流れ込んだ。例外はメカ技術者とあと少し。


その後、本部レベルの組織変更の巻き添えで小変更が行われたのだが、

このときメカ技術者が転入、逆にこの製品群に関わらない技術者は転出した。

この結果として、元の製品別の開発組織とほとんど同じ形になった。

ただ、この時点では全社的には「修正された技術分野別の開発組織」という位置づけだったのだが、

この4月で全ての開発組織が製品別になり、名実共に技術分野別の開発組織は解体された。


技術分野別の開発組織が解体するにあたって、社内のポータルサイトにセンター長が感想を書いていた。

だいたいこんな内容だった。

  • 技術分野別の開発組織で技術力強化につながることを期待していて、メカ分野(主に筐体設計)などうまくいった試みもある
  • 製品群を越えた技術者のアサインがうまくいった部分もあるが、限定的だった
  • 一方で、開発現場の技術者の「製品愛」に支えられた面も多かった

技術分野別の開発組織では、製品の責任を持つ部署の役割が重要なはずだが、不甲斐ないという声もあった。

そこを支えていたのは開発現場の技術者の「製品愛」だったことを認めざるを得ないということらしい。


製品別の開発組織にするのは、製品のライフサイクル全般に、開発現場が積極関与して欲しいという意図と受けとった。

うちの職場は実質的に製品別の開発組織になっていたので、あまり大きな組織変更はなかった。

ただ、部長のメッセージで「言われたものを作るだけでは下請けに過ぎない」「ビジネスがわかる技術者になって欲しい」と言っていた。

技術分野別の組織のときは、製品責任部署からの下請けという側面もあった。

それを否定して、この製品群の関わるビジネスをよく理解して、現場から提案して欲しいというのは変化だよね。

従来から現場の技術者はやってたことなんですけどね。それこそ「製品愛」だ。


ここまで書いてきたことから読み取れるとおり、僕の配属されたとき、今の職場はエレキ技術者の部署だった。

確かに僕はエレキ技術者なのだが、一方で組み込み分野のソフト技術者としての活躍が期待されての配属だった。

実は技術分野別といいながら、この部署に限っては、エレキ技術者の中にソフト技術者を混ぜていたのだ。

なぜそうなっていたのかというと、従来の製品別組織のときからそうだったからというしかない。

以後、マイコンのソフトウェア開発を主にして、論理回路設計、エレキ評価も担当していた。

得意分野が生かせる範囲で、その時々に必要とされている業務を割りあてられた結果なのだが、

こういうことができたのは、本来の意味で技術分野別の開発組織ではなかった証拠である。


これは僕にとってよい面もあったが、この4月はこの体制の欠点が現れた時でもあった。

というのも、配属時から一緒に仕事をしていたチームリーダーが、部内の他の課に異動になったからだ。

この結果、課内でソフト技術者は自分1人になってしまった。

プロジェクトによって、課を越えてのアサインは普通に行われているので、他の課のソフト技術者と一緒に仕事をするときは問題ない。

ただ、自分1人でマイコンのソフトを担当するケースもすでに発生していて、

その場合は、チームリーダーにレビューに参加してもらうなどしてアドバイスを得ていたが、今後は課内に適任者がいないことになる。

元チームリーダーも引き続き部内にいるので、必要時は引きずり戻して頼ろうと思っているが、

ソフト技術者の層の薄さが顕在化してしまった瞬間でもある。


製品別の開発組織になってサイロ化が加速しないかなとかいう懸念はあるんだけど、

製品内に横たわる組織の壁の方がはるかに問題という判断があったんだと思う。

とはいえ、技術分野別の組織でも、製品群を越えて技術力強化できていたのは限定的だった。

そんな中で比較的うまくいっていたメカ分野の連携は、今後も続くようだ。

うちの部はエレキ技術者を主とした組織だから、部内でソフト技術者は取り残されがちだが、

一方でソフトウェア開発部署の取り組みに相乗りさせてもらうことは、以前からやっているし、今も続いている。

方法はいろいろってことだね。それぞれ難点はありますが。


Author : hidemaro
Date : 2019/04/11(Thu) 22:44
電気・数学・物理 | Comment | trackback (0)

Tools