教育・計画4月

記事:仕事関係の人とプライベートでも遊びますか?

URL:<http://el.jibun.atmarkit.co.jp/jibun/2009/04/post-9d34.html>

感想: 個人の感想ですのであしからず、プライベートと仕事を分けているからこそ人生うまく良くなると私は思います。 仕事は仕事、プライベートはプライベート。 「個人主義」が強くなっている・・・良いじゃあないですか! 自分を強く持っている人間が増えている良い証拠ではないかと思います。

記事:自分流を人に押し付けていませんか?

URL:<http://el.jibun.atmarkit.co.jp/horisusumu/2009/02/post-3689.html>

感想:指導と託けて、自分のやり方を押し付けてるとしか言えないですね。

記事:わたしが、あたらしい勉強に目覚めたワケ

URL:<http://el.jibun.atmarkit.co.jp/freeskill/2009/02/post-f12b.html>

感想:この選択肢は、とてもシンプルで良いですね 兵士を続ける 兵士を辞める 司令官を目指す

記事:認めたくない自分も認めてみる

URL:<http://el.jibun.atmarkit.co.jp/colinta/2012/12/4-5ea7.html>

感想:「自分にあることをある、と認めること。」この言葉が良いですね

記事:仕事なんかしなくてもいいじゃない

URL:<http://el.jibun.atmarkit.co.jp/ahf/2013/03/post-ab2f.html>

感想:時間外に自分のしたい事をしている。正直、確かにこっちの方がよく考えますね。しかも実に面白い。 そういう時間があるから、仕事もできるもんですね。 仕事ばっかりしていたら、心が廃れますね。

日経SYSTEMS 5月号 (トヨタ流 5つの技)

チーム一丸となって開発しているのに納期に遅れる。
利用部門を唸らせるシステムを開発したいのに時間が足りない。
このような現場の悩みを解決するには、開発スピードを高めることが一番。
ということで、トヨタ流の5つの技が紹介されていたのでまとめてみた。

 

■時間仕分け

作業を以下の3つに仕分けすることを時間仕分けという。

(1)「利用者の価値に直結している時間」
(2)「利用者の価値には直結していないが必要な時間」
(3)「利用者の価値に全く必要のない無駄な時間」

この仕分けを行うことで、利用者の価値に直結しない時間に気付き、
減らそうという意識が現場に生まれるとのこと。

各時間の例は以下の通り。

(1) 開発のWBSに記載された作業
(2) 問合せ調査やテスト環境構築
(3) 協力会社への発注に伴う事務作業や社内の打合せ

各タスクを上記3つに意識的に分類し、
価値直結作業の時間を増やすことで生産性アップに繋がる。

また、PMがメンバーの価値直結作業時間を奪い取っている例として、
定例会議でメンバー1人ひとりの進捗を確認する例が挙げられており、
自身の進捗報告以外の他メンバーが進捗報告しいている待ち時間は無駄な時間と記載があった。
情報共有的に必要な場合もあるので一概に無駄とは言えないのではないかと思うが、
記載のとおり他メンバーの進捗報告を聞いていないメンバーも確かにいるので、
そのような定例会議の内容を改善すべきなのではないかと思った。

 

■作業ばらし

作業の細分化。
例えば、「バインダーに収められた資料のコピーを取って枚数を記録する」という作業であれば
・コピー対象の資料をバインダーから取り出す
・資料を持ってコピー機まで歩く
・コピー機のボタンを押し、終わるのを待つ
というように細分化できる。
このように細分化した作業に対して、目標時間を割り出し、
担当者のスキルレベルや経験を加味して「基準時間」を割り出すという。

各担当者が各作業の実績を0.1時間単位で記入し、基準時間をオーバーした作業の
状況把握を行い対策を施す。
短い時間のタスクに対する対策なので、戻りが小さくすむ利点がある。
また、複数プロジェクトにおいて、常に基準時間をオーバーする作業があれば、
それに対して対策を打つことで開発スピードを高めることが出来る。

また、この施策を行うにあたって、
担当者が細分化された作業に対して実績時間を0.1時間単位で入力するのは
面倒ではないかと考えたらしいが、実績を入力するのはせいぜい5分で、
リーダーにどんな作業をしたかわざわざ報告しなくて済むことから
メンバーに問題なく受け入れてもらえたとのこと。
このように、メンバーに受け入れてもらうための考慮が必要である。

 

■A3レポート

問題に対してどのような対策を講じるかを、
A3用紙1枚に問題、原因、対策などを整理したものである。

作成者は、作成する過程で頭が整理され、他のメンバーも
その説明を聞きながらA3用紙1枚を参照すれば問題から対策までを一通り把握でき、
チーム全体で対策を素早く共有し実行できるため開発スピードがあがるとのこと。

この手法を活用したことはないが、
次のなぜなぜ分析をした結果、一連の問題から対策、実行スケジュール、効果確認までを
A3用紙にまとめるというイメージと理解した。

 

■なぜなぜ分析

こちらはおなじみの手法。

ただ、「再発した問題の対処に追われる時間が減る分、開発スピードが上がる」
と記載があったが、この意味が理解できなかった。
再発防止策を実施して再発しないからという意味だろうか?

補足コラムとして、「なぜなぜ分析を見ていて文章を書くのが苦手なITエンジニアが多い」
という記載があったが、まさにその通りだと共感しました。
主語がなかったり、論理的に繋がっていなかったり。
「なぜなぜ分析を行い書くことで、分かり易く表現する力を習得できる」というのも納得。

 

■セットベース開発

初めて聞く単語であった。
通常我々が行っている開発は機能設計段階である1つの仕様案に絞込み
詳細設計に移る「ポイントベース開発」で、その1つの仕様案が適切なら
開発スピードは速いが、見当が外れた時は大きな手戻りが生じる。

これに対して「セットベース開発」は、複数の仕様案を同時並行で検討し、
その過程で市場ニーズや新技術への理解を深めていく手法とのこと。

請負開発メインの現状では、顧客に理解頂いたうえで実施する必要があるが、
自社の開発を行う際には有効な手法と感じた。

 

■急がば回れの浸透策

これらの技を浸透させるためには以下のような気遣いが必要とのこと。

(1) メンバーが日頃ためているガスを抜く場を設ける
(2) ありたい姿をチーム全員で考える
(3) グラフや付箋紙を駆使し、成果を早めに実感できるようにする
(4) 社内ルールに縛られないプロジェクトにして始める
(5) 個々の改善策はいつやめてもいいことにする
有効な手法であったとしても、実践するのは現場のメンバーであり、
そのメンバーに理解、納得して実践してもらうための気配り、
これは上司の手腕にかかっているのだと思う。

Associe 2013年 5月号

机術

机術には成果を上げるヒントがあるそうです。

「分ける」「詰める」「表示する」「移動する」といったテーマ別に、できる人の机術が紹介されています。
効率的に作業をこなせるように、自分なりの整理方法を構築しようと思います。

他にも、仕事机で昼寝するコツが書かれてあり、ためになりました。

特集2では、『挫けない心を育てる思考と習慣』でした。
世界で活躍するトップアスリートが、ストレス社会を生き抜くヒントを教えてくれています。
自分もがんばろうと思いました。