って自分の事だから、分かっちゃいたのだが、最近とみにそんな状態。
朝は部署の2年後の話を詰めて、昼間は今の仕事をして、夕方は兼務先の仕事をして、夜は実装の調査。
んで、次の日は、サーバーインフラを見て、他チームと体制づくりの折衝、そんで他部署と一緒に機能を作って、夜にはメトリクスの仕組みづくり。
頭を切り替えるのが辛くて、なかなか仕事を振り返る事が出来ない。
2011年07月12日
そこまで器用では無かったらしい
2011年04月03日
初めての人の管理に向けて
第1回 「計画的にやれ」が悲しいほどメンバーに通じない理由 [@IT]
今期から5人の仕事を見なきゃいけない。
直接、管理対象の人が付いたことないから(いつも上の人ばっかだった)、今までに無いことを色々考えなきゃいけない。
リンク先の記事な出来事も先期に起きていたような事だから参考になりそう。
ここ数年の活動のおかげで、色々と作業がシステム上にデータとして乗るようになってきた。これを利用して、上手く管理できるように今期は頑張ってみる。
ざっくり、まとめると以下の事を出来るようにしよう。
- 「アポイントメント」と「タスク」の比率を把握する
- 「タスク着手日」を把握する
- 「予定工数(見積もり)」と「実工数」を把握する
2009年11月06日
想いを伝えるのって難しい
ビジョンやコンセプト、大まかな計画を皆に伝えるために文書にまとめているのだが、なかなか上手くまとまらない。
なので、そこら辺歩いている人を捕まえては、この資料で「言いたい事伝わる？」とか聞いて、「〜の辺りどうなってるの？」「論理飛びすぎ!」とか色々意見貰って修正している。
どうも小さい頃から、あまりそういうのを考えるのが得意ではなかったので、結構苦戦中。とはいえ、これは乗り越えないといけない壁だよな〜。
2008年02月28日
三次元半導体の偉い人の言葉
舛岡教授が語る[Tech総研]一文より。
――日本のエンジニアを見て思うことはありますか？
現状に文句を言う人が多すぎると思います。
会社の仕事を100％こなしたうえで自分の好きなことをやれと言いたいですね。
与えられた仕事が満足にできない人は、新しいことなどできないと思います。
私が東芝時代にフラッシュメモリを開発したのは、本来のDRAM開発を終えた後の、プライベートな時間を使ってのことです。SGTもそうでした。
「オレは本当は優秀なエンジニアなのに、会社がダメだから能力が発揮できない」などという人は、そんな言葉をいった瞬間に本人がダメになります。
そもそも、自分のやりたいことが会社でできるなど思わないほうがよい。
キモに命じておきます。
2007年04月26日
仕事が速い人から学ぶ
基本的に残業はしない主義です。
プログラム作っていると波があるのでノッているときは敢えて残るとかいうことはありますが、原則としてちゃっちゃと仕事終わらせてさっさと帰る、がポリシーです。
んで、ちょっと面白そうな記事がなぜか仕事が速い人の習慣」 [Lifehacking.jp]
他の仕事が速い人が何を重視しているのか学ぶのはためになるかと。
2007年01月07日
モチベーション管理は重要よん
「うつ」にならない、繰り返さない [@IT]
仕事のしすぎには注意しましょうって事で。
2006年12月28日
無料で行えるTOEIC MINI TEST
2006年10月18日
インターネットを使って英語を学ぶ
2006年10月16日
社長のプレゼンがツマラナイ理由
プレゼン上手と思われる４つの基本ステップ [AllAbout]
会社などでプレゼンする事/される事はままあるが、
7割がた面白く出来ない/ないのです。
1スライドの情報が多すぎる〜という基本中の基本が出来ていないプレゼンも見かけますが、そうではなく資料はできてるけどプレゼンは面白くないな〜、
と感じるのがあってずっと原因が分かりませんでした。
んで、AllAboutの記事を見て、ハタッと思いました。
上記URLでポイントとしているのは以下の4点です。
- 最初に主題を伝える
- 論理的に話を組み立てる
- トップダウン型とボトムアップ型というストーリーを作る
- 相手にあわせたストーリーを考える
これを見てて気付いたんですが、この中で1つだけ他と性質が少し違うものがあります。
「相手にあわせたストーリーを考える」です。
何が違うかって、厳密な意味で準備できないんです。
聞き手は実行時に決まる
主題を伝えるとか、ストーリーを組み立てるのは事前準備で幾らでも遂行できます。
自分がどう伝えようかという話なので、周りに殆ど左右されない静的な行動です。
が、「相手にあわせたストーリーを考える」ってどうでしょう？
事前にどういう人達かは大まかな情報は大体もらえます。
作る側はその情報を想定してプレゼンを作成するでしょう。
が、実際にプレゼンする場に集まった人達の調子・雰囲気とかを踏まえた情報はどうでしょう？
それは実際に行う直前まで分かりません。
事前にキチンと準備して、さて話すぞと思ったときに、
自分が用意した話と実際の聴衆が期待している話がズレている。
そういうときに、「プレゼン資料は出来ているのにつまらないな、この人」と思うのではなかろうか。
開発者集めて、SOX法対応しましたという話をするお偉方のプレゼンとかね。
メールでいいよ、そんな話。
2006年09月29日
思考の行き着く先がデザインパターン
酔っ払って書いたせいか、ボロクソに書いてしまった後輩の件ですが、
後輩との仕事も4日目になってようやく真価を発揮。
満足感を得られる仕事ができてきました。
オロオロしながらもそれなりな設計ができてきました。
将来も考えると多少不安がありますが、1日で設計だとこんなもんでしょう。
しかし、最近考えた結果がデザパタと似てるということが、
段々と多くなってきたな〜。
何はともあれ既存のコードに影響をあまり与えずに、
機能追加できそうなので良しとしますか。
最後に「今日は、所用で早く帰る」と言ったら、
「その間に実装しておきます!」と言っていたが、どうなったかが気がかりだ。
2006年09月27日
基本こそ王道なり
状況
先日から開始したさっさとモノを創るプロジェクト
[記事]。
とりあえず2日目が終了。
忙しい時には忙しいことが重なって、色々な役職が振ってくるのは何の因果か。。。
成果
ペアモデリングとかペアプロとかどんなものかと思ったけど、
ドメインの知識差が激しくてあまり発見はできず。
時間が無いって言うのもあるかもしれないけど。
成果として目立ったのは、先日の成果としてリリースした物件のフィードバックと、
仮説で立てた仕様を実装してみたら、無駄が多いということがわかったということ。
考察
どんなに時間が短かろうと、要求分析→設計→実装→テスト→リリース
というサイクルから受ける利益が、
一番大きいということが再認識したのは重要かも。
XPに頻繁なリリースがあるというのも頷ける。
今後は散発的に出さずに内々にリリース計画を立てて、
管理していく姿勢は必要そうだ。
丁度折り返し地点である明日が要だ。
2006年09月20日
英語漬けやってないけど、TOEIC900点欲しいよね!
2006年08月05日
下手な写真とモデリングの関係性
ビールを撮影して幾星霜。
いつも似たような構図で全然面白みがありません。
携帯を構えて2秒で撮影しているとはいえ、この体たらく。
これでは、ビールも浮かばれません
そんな中先輩の一言。
「本当に撮りたいものを決めて、他は切り取るんだよ」
ハッ Σ(ﾟ□ﾟ)
モデル作成の時と一緒ジャン！！！
気づいても、出来はしないけど・・・。
2006年08月04日
レビューアの品質責任ってなんじゃらほい？
仕事でレビューアをやらさせてもらっているが、
イマイチ分からないのが「品質に責任を負う」ということ。
後輩(だけじゃない気もするが）のレビューをしていたとき、
ボロボロ指摘が出て一段楽した際に、
さる先輩のお方が、
「次工程に進むか判断しないの？」
との御言葉。
実のところ成果物は歯抜けすぎて、次の工程に進むには苦しい品質だったのだが、
今回はスケジュールもあり、次の機会に修正すると相成ったわけだ。
(それ自体は、別に先輩達とネゴとれているからいいんだけど）
でも、この状態だと品質に責任ってとれないような気がする。
っていうことは、レビューの場で品質がうんぬん判明するようじゃ、
既に時遅しでもっと前に察知しなきゃならんってコト？
入社当時程、仕事が少ない時期なら成果物を随時盗み見るとかいう芸当ができたが、
今じゃそんな暇はありゃしないし、一体どう関わればいいんだろう？
むぅ、悩む〜。
