ブログトップ 記事一覧 ログイン 無料ブログ開設

室長のひとりごち このページをアンテナに追加 RSSフィード Twitter

2016-05-25

[]システムエンジニアは何歳までなら変われるんだろう 08:18 システムエンジニアは何歳までなら変われるんだろうを含むブックマーク


昨日、60歳くらいの指示待ちシステムエンジニアエントリーを書いたけれど、じゃあ、何歳までだったら人は変われるんだろうなんて思ったことはないですか。


マネージャプロジェクトマネージャをやると変わってほしいな、と思うことがままあるんですよね。ニュアンスとしては成長して欲しい、の方がつい良いかもしれません。


ワタシがマネージャになったのは何歳だったかなぁ。ただ、初めてマネージャ担ったときのチームの顔ぶれはすごかったですね。上は50歳くらいか新人まででどこかの年代が欠けているということはなかったですから。ただ、人数の分布は40歳後半くらいの年代が多かったような。まぁ、自分より年上だったと。


人は2つの性格を持っていると思うのです。1つは生まれ持った先天性の性格。もう1つは体験から身につける後天性の性格心配性などの性格は生まれ持った先天性の性格なので生涯変わることはないと思いますし、役割などの体験を通じた学習によって形成していく性格はその学習の機会を得ることで性質を変えることができるのです。


仕事ですからアサイメントして、プロジェクトへ参加してもらって経験を積んでもらう。OJTとOFFJTを通してできるスキルエリアを広げ、レベルを上げていく。


そうした中で期待している役割とのギャップが生じると変わって欲しい、育って欲しいと思うわけです。


イメージではやはり若い世代の方が吸収力がありそうで変化しそうですよね。そして年齢を重ねると次第に融通が利かなくなり頑固になって変化もしなくなる。


経験値で定量的な測定はしていないのですが、まぁ、その気になれば当時のメンバの名前を書き出して変わった人をカウントすればいいのですけど、結論から言えば、年代関係ないんですね。


どちらかと言えば、本人の思考がどれだけ先天性の性質依存しているか、によります


そう考える理由は、メンバ一人一人との会話と行動の結果を見ているとそう確信が持てるからです。ヒントを出すだけで結果を出すメンバもいれば、何度も動機付けをしても結果を出さないメンバもいるんですね。後者は、そうした動機付けインセンティブを感じられないんでしょう。こうしたメンバも史ごとはきちんとやるけれど、興味のないスキルの伸長は全くもって手を出しません。


ヒントや情報を目の前に置くだけで、あとは勝手にやるメンバはそれを見てやることにインセンティブを感じる性質を持っている。


マネージャにとってどっちが都合がいいかといえば、どっちもどっちです。なにせ生まれ持った性質支配しているところですから、それをどうこうしようとしてもそれは無理なんですよ。そうしたところを無理に変えようとしても変えられないんです。変えられるのは役割などの経験から形成していく後天性の性質の方です。


それを一人ひとりのメンバごとに当たりをつけてこちから出し物を変えていく。そうしたことの積み重ねで成長した、と思わせることが次の成長につながり、チームの成長につながるんです。

2016-05-24

[]60歳くらいの指示待ちシステムエンジニアを見ていると辛い 08:02 60歳くらいの指示待ちシステムエンジニアを見ていると辛いを含むブックマーク


とあるプロジェクトでのことです。そのオジサンの年齢は後から人伝てに聞いたのですがどうやらワタシよりもひと回りも上だったらしい(当時)。前職というかシステムエンジニアとしての専門何かは立ち入って聞くと地雷のような気がして聞いていないんですけどね。なぜここにアサインされたんだろう…。


そういうシステムエンジニアさんを含めたチームがありました。


みなさん、60歳になったとき自分システムエンジニアとしての活躍イメージを持ててますか。もし、持っていなかったら少しでもいいですから想像してみてください。システムエンジニアとしての専門の領域プロフェッショナルリーダなどの役割としてのポジションを具体的にイメージするのです。


どうでしょう自分の顔を鏡に映してそのとき何をしているかを思いを馳せてみてください。


つぎに、60歳のシステムエンジニアに周りが期待することはなんでしょう。豊富経験、難しい課題への対応、柔軟な思考と無理のない推進。そういったことを30年も40年もこの業界で生き延びてきたのだとしたら期待してもバチは当たらないですよね。



同様に先の60歳くらいのオジサンシステムエンジニアに期待されていたことがあるのですよね。


専門家としての経験を生かしプロジェクトに貢献すること

リーシップを発揮してプロジェクトを推進すること


ぱっと出てくることはこの2つです。30年、40年のシステムエンジニアとしての経験を生かしてプロジェクトに貢献して欲しい。30年、40年もこの業界で働いているなら相応の役割を全うして欲しい。周りはそう期待するものです。単価もそれなりなんですから


ところが現実は見事に裏切られます


担当作業自分で推進できない

WBS自分で展開できない

課題を上げることができない

・指示待ち


ひと月も掛からないうちに周りが何かおかしいと気付き始めます。良くよく言動を聞いてみると、できない理由を並べることが多いんですね。他責でできない原因があるなら課題をあげればいいのに。


ひと月経ってみんなで認識したのは指示待ちのシステムエンジニアだったんだ、ということです。だったら、若いシステムエンジニアを同額で雇った方がいいです。若いシステムエンジニア、中堅でもいいですが、そのくらいの年齢の方が吸収力があるしもし同じ指示待ちでも変わる可能性があるし。


でも、40歳を超えて指示待ちのシステムエンジニアには主体的に行動するように変わる可能性はとても少ないのです。これまで何十人もメンバの育成と行動をフォローしてきた経験から言わせてもらえれば、年齢が上がるごとに思考固定化されてしまうのです。ただ、割合は少ないですが変化を新しいもの好きの人もいるので侮れないところが人材育成面白いところです。


こうした経験自分の基礎力はこれからも通用するか、やっていけるかを見つめ直す良い機会です。他人の振り見て我が振り直せ、です。


作業スコープ定義する

納期完了状態を詰める

作業段取りをつくる

WBSを分解する

納期意識した推進する意思

・推進上の課題識別する

課題解決必要な人を巻き込む


何より、自分仕事には責任を持つ。少なくとも自責仕事を止めない。50点でもいいから一旦完了させる。などなど、基礎的なスキルをいつでもどこでもできること。


それができなくなったら、システムエンジニアとして生きてくことをやめる潮時なのかもしれません。10年後に後悔しないためにもまだまだ自分を鍛えなければ。

2016-05-23

[]事例に見る、場当たり的な暫定対処トラブル解決にならないケーススタディ 08:15 事例に見る、場当たり的な暫定対処はトラブルの解決にならないケーススタディを含むブックマーク


事象

うちで淡水魚を飼っていて、その水槽水草を入れておくと淡水魚がいたずらというか食べちゃうんですね。で、だんだんと禿げてくるからいかんなーと思って、余っていた水槽水草だけの水槽を作っておいたら藻が生えちゃって。


淡水魚水槽は、毎週2/3くらいの水の入れ替え、内側のガラス面の掃除フィルター掃除をしていたので同じようにルーチンにのせることに。これで、水草水槽の水も2/3は入れ替わるから改善するかと思えば症状は全く改善されない。


水槽内には用土が入れてあって、藻が薄く皮膜を作るので掃除の際にその藻を棒などで掻き出してクリーナポンプ灯油のチュパチュパするような形状に似たもの)で吸い取ったあとは一見改善したように見えるけれど、1−2日もするとまた皮膜が出来てしまう。


事象による他への影響

棒などで藻を水草用土から分離するように水槽内でかき回し水中に漂わせることでフィルター捕獲しようとすると、当然フィルターが目詰まりするので交換が滴定に発生する。安価フィルタはいえ、毎回新品に交換するのは費用が掛かるので数回はシャワーで汚れを落とす洗浄で使い回しをする運用をしているとフィルターの濾過した側の排水面にも藻が付いている状態が発生した。


別案の調査

藻は水草に絡んだり、用土の表面にあったり、ガラス面に広がったりと水の入れ替えと水槽掃除だけでは一時しのぎの域を出ないので、別の作がないかネットで調べたりしても今ひとつヒットしない中、幾つかの策があることを知る。


薬品で藻を対処できる

海老が藻を食べる


専門家アドバイス

もともと、海老はちまちまと動いてかわいいなぁ、と思っていたところだったので淡水魚を買ったお店に行って、詳しいお兄さんに藻の対策を聴いたところ、


水草が入っているなら薬品は勧めない

海老は藻をだべるけれど気長に。海老自体が増える可能性があるのでそれも楽しみに


ワークアラウンド

ということで、当初予定どおりに海老を藻の対策として投入してみたら…、数週間経っても全くもって効果測定ができないのはある意味、策の検討段階の調査時点で判明していたことなので、やっぱりの域を出ず。


抜本的対策実施

最終プランは、水槽の全面掃除しかいかなと思っていたこ自体薄々認識していたのですが、30センチ程度の水槽でさえ、実行しようとすると割と面倒で時間を取られるもので、それはそれで後回しにしたいという心理が働いていたのは事実なんですよねぇ。


ふと、週末思い至ってその最終プランを実行することに。


スノコに移動キャスターが付いた台に載せ水場に移動して、淡水魚海老を分離した後、水草別に取り出して先ずは藻を取り除く。合わせて成長している水草の絡まっている根をばらす。


根本原因の特定

ひとすくい用土を取り出して洗浄用のオケで注水後にかき回すと半ばヘドロ状の藻が浮いてくる。これを見るともっと早くればよかったとか思うより、原因は用土が藻の寝床であったことを改めて確認することに。


ここから事象の原因がわかったので用土の洗浄後の品質を注水と洗浄を繰り返しながら完了レベルを見出すことに注力する。用土自体の細かな粉末状のものは良いとして藻が残らないように検査に。


記録から基準

その際に注水とかき回して用土を洗浄する際の回数を覚えておき、用土の量に対してのかき回す最低限の基準とする。


水槽自体にも汚れが残ると元の木阿弥なので内側をブラシ洗浄する。同様にフィルターやヒーターも藻の繁殖の温床となるので使い古しの歯ブラシを使って汚れを書き出せる箇所は全部洗ってしまう。


経過観察

洗浄後の用土を敷き直し、洗浄と分離した水草を配置し直して、元の場所に再設置したのち、注水して新しいフィルターを回す。しばらくは注水で立ち上がる用土の粉末が舞うが数時間で落ち着くので経過観察していたが、一向に落ち着かないし若干水が濁っている。


淡水魚海老を戻してバクテリア繁殖を促すも好転しないために、1/6程度の水を入れ替える。


トラブル解消の判断

経過観察すると水が透明になり、安定し、1日経過後も藻の繁殖がないので一旦事象解決と見做すことに。

2016-05-22

[]目的観点のないレビューの指摘には意味はない 09:09 目的や観点のないレビューの指摘には意味はないを含むブックマーク



目的観点のない指摘には意味はありません。


と思います。ただ、レビューや事前の資料確認をする際に、ついつい自分感覚が反応する事柄についていろいろと駄目出しをしてしまう。これは思い直さないといけないことなのだと改めて思うのです。


さて、どうして目的観点が明らかではない指摘には意味がないのでしょうか。


考えれば、思い至ればわかるんですが、それに気づかなければどう仕様もないのですよねぇ。


いくらあなたが優秀だとしても…指摘をするあなたが頭の中で基準としていること、これから指摘対象があったらコメントをしようと思いっている基準について明文化されていないのだとしたら、それはレビューイ側には誰一人として理解することはできないのです。


であるなら、レビュー資料確認をする前に、いや、レビュー対象アウトプットを作る前に目的を共有していればそうした意味のない指摘になってしまうことを回避することが出来るのではないでしょう。


改めて思い直せば、自分基準を示さないことでアウトプットコメントをつけるという行為は、単なる自己満足ではなかったのかと問われれば、実はそのとおり、と言わざるを得ないような気がしてならないのです。


そう思うと、実に間違ったやり方を積み重ねてきてしまったなぁ、と。


もし、目的観点を持っていないなら、自己満足の指摘を防止するためには、そのアウトプット作成した人に指摘してほしい観点を訪ねるほかないのではないかと思い至ると、それはそれで的確に得たい目的観点が得られるわけではないのですけれど。


そうしたケースで聞いてみると、作り手によりますが着手する前に当事者目的そのものについて話をしてイメージアップしなければ現実的に無理であるからです。


もし、指摘の目的やら観点を外した上で、欠陥を隅々まで探して指摘することはレビューアにはアウトプットレビューするスキルがないということを暗に明示しているということなのです。


自戒として。

[]ガールズ&パンツァー 劇場版 発売前に準備するならどんなサウンドシステム06:53 ガールズ&パンツァー 劇場版 発売前に準備するならどんなサウンドシステム?を含むブックマーク

今週は楽しみなガルパン劇場版ディスクが発売になりますね。


極爆を見に行ったのでお家でも再現してみたい、と思ってもそのまま再現は無理ですがホームサウンドシステムちょっと頑張ってヘッドフォンなどを使ってプチ極爆をやってみるならどれがいいかと。


でも何も情報がないところでホームサウンドシステムを選ぶにはちょっとハードルが高そうなのでオーディオビジュアルの専門誌の情報を参考にしてみます


HiVi冬のベストバイ2015 | Stereo Sound ONLINE


サラウンドシステム部門を見てみましょう。


順位製品レビューネットショップ
1位YAMAHA YSP-5600(B) レビューはこちらヨドバシ
2位SONY 7.1ch ホームシアターシステム ハイレゾ音源対応 Bluetooth対応 HT-ST9レビューはこちらamazon
3位DENON デノン TVスピーカーベース DHT-T100Kなしamazon
4位ヤマハ 7.1ch YSPシリーズ デジタル・サウンド・プロジェクター ブラック YSP-4300(B)レビューはこちらamazon
5位SONY 5.1ch ホームシアターシステム Bluetooth対応 HT-RT5レビューはこちらamazon

値ごろ感から言えばDHT-T100Kは2万でランキングの中では最安ですねぇ。HT-RT5だと7万ですねぇ。でもBluetoothからケーブルがなくていい…と思ったら電源ケーブルがいるのでその分コンセント必要になるんだ。これはトラップですね。結局ケーブル呪縛からは抜けられないんですね。


なら、こんな感じのが良いんですけどねー。



スピーカーはこんな感じのが良いですけどねー。




じゃあ、ヘッドホンならと思ったけれどアクセサリー部門にはなかったのでamazonちょっと眺めてみたらこれ気になりますね。レビューはこちら



うーん、どうしよう。

[]艦これ 2016年ゴールデンウィークイベント E5 甲 ボス攻略時の編成 23:30 艦これ 2016年ゴールデンウィークイベント E5 甲 ボス攻略時の編成 を含むブックマーク

ツイッターボス攻略編成を共有してくれたのが参考になったのでお礼の意味も含め。

で、初期編成とはちょっと艦娘も装備も変わりましたね。


記録を見てみると、46戦でボス攻略。実質は、最後の41戦から46戦の6戦でMまで連続してボスまで到達したところが大きいかと。

初期編成からボス攻略までに駆逐艦は入れ替えてみたり、駆逐艦を3にしてむっちゃんを入れてみたりしましたが、結局駆逐艦は4に戻しています


Lで大破とかでると禿るので40戦代は1隻、また1隻とダメコンを積んでみましたが幸いにも使わずに。よかった。あと、キラ付けした方がいいとよく見かけますが面倒だったので結局、1度もやらず。


第1艦隊

f:id:fumisan:20160521231147p:image

  ↓

f:id:fumisan:20160521231150p:image


道中支援、決戦支援空母に搭載する艦載機ちょっと入れ替えてみたりしましたが結局コレで落ち着きました。

決戦支援最初は4姉妹の内の2隻でしたが、40戦少し前からむっちゃん、ながもんのうち長門大和に変えたりと資源的に贅沢しています


道中支援と決戦支援

f:id:fumisan:20160521231146p:image

  ↓

f:id:fumisan:20160521231148p:image

2016-05-21

[]コンセプトや仕様をつめていくときのいい感じのやり方 10:12 コンセプトや仕様をつめていくときのいい感じのやり方を含むブックマーク


コンセプトを作りながら、仕様を決めていく仕事って企画段階とか上流設計では割とあると思うのですが、そうしたときのいい感じのやり方で情報の整理の仕方がワタシ的に割と良い感じのやり方がありますよ、っと。


情報の整理の手順は、こんな段取りで作り上げていきます


  1. A3サイズの用紙を用意する
  2. A3用紙を4分割(2*2)のマス目に区切る
  3. 左上 要件、制約事項
  4. 右上 大きなレベルでの機能又はフロー
  5. 左下 リソース
  6. 右下 スケジュール局面の一つ下のレベルくらい)

A3の用紙に図表を割り付けするとこんな感じになります


タイトルたたき台)日付とか
要件/制約事項                




  
大きなレベルでの機能又はフロー




  
リソース




  
スケジュール局面の一つ下のレベルくらい)




  

A3の用紙としているのはまだ情報のパーツが揃い切っていないとき有効です。情報が揃い切っていないと思っている段階でpowerpointexcelで書き始めてしまうと、綺麗に図形が描けてしまうし、文字も綺麗すぎてなんか出来上がってしまったんではないか、と勘違いするからです。なので、まだ、やわやわ状態ときには手書きがいいです。


要件/制約事項を並べる

実現したい要件があるはずです。それを列挙しましょう。一番大枠のスコープでもあるからです。どっちに向かって進むのかの指針でもあります


次に、制約事項を書き並べます。制約事項は、この作業の前工程要件存在する際に生じるものです。この制約条件は、関係者が見て聞き知っていても後続の担当者が知っているとは限らないのできっちり書く必要があります


そんなこと、関係者なら知っている、は、関係者でなければ知らなくても仕方がないことですし、そう言ったことは明示的にしておいても誰も困りませんから、堂々と記載しておくべきものです。


大きなレベルでの機能又はフロー

このシートでまとめようとしてるコンセプトや方式などで実現する仕組み、機能や処理手続を描き出しますが、その前に、2−3の箇条書きでどんな仕組みにするだとかを制約する事項を書いておきましょう。


その次にスペースに図として機能フローを図表として書き込みます


リソース

リソースですから、人やモノなどこのコンセプトで必要とするリソースを書き出すますが、やはりここでも、リソースの全てとしていることを箇条書きで書きましょう。


次に前と同じように、図表を使ってイメージアップします。体制ならツリー型でもいいですし、資源数であれば表が良いでしょう。


スケジュール局面の一つ下のレベルくらい)

スケジュールの制約事項を箇条書きで書きましょう。そのあとでガントチャートぽいものを4半期とか月単位程度でスケジュールをざっくりと表現します。


ここで明らかにしたいものは大きなレベルので作業の順序やマイルストーンです。


何が見えてくるか

これを書くことで、今知っている情報がどれだけなのか、何が足らないのかを知ることができます情報が足りていそうだ、と思えるということは次工程として必要となる情報が揃っているということです。情報が足りないということは、次工程に進むほど検討がされておらずまだまだ課題が多いということです。


このA3の用紙、それも紙に書き始めることで、頭の中で知っていることを書ききることができ、足らないことは情報を集めることで情報の持っているリンクを集められる、という情報可視化を進められるという見方もできます


特に頭の中に入っていることを表現することは、わかっていたと思っていたことが実は矛盾があって分かったつもりになっていただけということも気づくことができるツールとして利用出来ることから自分のためのフィードバックとして使うことができます