ソフト開発におけるエンジニアリング・マネジメント業務から得られた知見・知識を記録するためのブログ
最近はビジネスの現場において、どこもかしこも「Deep Learning」とか耳にする事が増えてきたと思う。ひとつのキッカケとしてCNN関連で画像認識が人間を超える精度を叩き出した事だと思われる。アカデミックの世界では、もっと前から多くの研究者達が扱っているテーマだと思うが、一般的なフィールドに降りてきたのはここ数年の話だと感じる。そして今後Deep LearningをはじめとするAIがどんどん発展し、未来を楽観的に考える人もいれば、悲観的に考える人もいる。 自分はその中でも前者にあたる楽観的な考え方を持つタイプだ。理由はいくつかあるけど、一つ挙げるとしたら「悲観的に考えても仕方ない」に尽きる...
ソフトの受託開発をしている環境に長年いるが、自分の周りの人たちを見て、ペアプログラミングをしているところは今まで見たことがない。 ペアプログラミングは文字通り一人ではコードを書かず、誰かと一緒に書くことを意味する。ペアを組む人の技能差とか人間関係とかの要因で上手くいかないのかなと思っていたが、別の要因もあるかも知れないと最近思うようになった。 結論から言うと… プログラム開発工程では悩むという時間は考慮していない。すなわち、上流工程の成果物に基づき、手を動かすだけでプログラムが実装できるプロセスモデルに則った考え方なのだ。
以前から、自分がふと思い浮かんだことをメモ（iPhone, iPadの）に追加していたのだが、いっそのこと言いたいことを1枚ずつスライドに起こし続けるのをやってみようと思った。 そう思い当たったきっかけは落合陽一さんの講演映像を見たときだ。質疑応答で落合さんは「スライドが1000枚以上あるんだよね」と言いながら、質問の回答にふさわしいスライドを探し、それを見せながら答えていたのである。
リーダーやマネジャーにとって必要なタスクの一つである権限委譲について日頃思っていることを共有したい。 皆さんは過去にこういう経験がないだろうか？ ある日突然、上司からこんなことを言われる。 「今度の案件、君が自由にやっていいよ」 言われた方は「ああ、任されたんだな」とちょっと感慨深い思いをする。そのときは。 実際にお客さんのところに行き、自分とお客さんの間ではやるべきことが大体固まり、いざ見積もりの段階になる。見積書はワークフローの関係上、上司の承認が必要となり、説明しに行く。そうすると、
今回はチームワークにおけるモチベーションのコントロールについて述べてみたいと思います。まず始めに、モチベーションの重要性について述べ、その後リーダーとしてチームメンバーのモチベーションをどのようにコントロールすべきか述べてみたいと思います。もちろん、私の経験に基づく主観的なものですので「参考」程度に見ていただけたら幸いです。
以前の投稿で報連相が拗れる原因について述べましたが、今回は報連相を円滑に進める為に必要なことについて述べたいと思います。報連相には発信側と受信側の２人が必要になりますが、それぞれの視点で気をつけるべき点を示します。
私自身が２年半前ぐらいから取り組んでいたある習慣が功を奏し、英語力が上がったと実感したので、ここで備忘録をかねてその内容を纏めておこうと思います。 私が実践した取り組みは「英文多読」でした。これを毎日30分（平日/休日関係なく）続けたところ、難しい言い回し（慣用句等）を除き、英文が理解できるようになりました。英語の仕様書やマニュアルも辞書無しで読めるぐらいにはなっています。最初に効果を感じたのは初めてから半年以上後でしたが……。
最近、Twitter経由で以下のようなつぶやきがRTで回ってきました。 いろんなところで耳にする「報連相を大事に！」というアレですが、上の図のような流れを実際の現場で何度も目にしています。もはや「報連相とはこのような現象のことだ」と定義してもいいぐらい遭遇します。
今日たまたま妻との会話で「近所の子供の行動について」の話題が挙りました。妻曰く、 家のフェンスに見るからに危険な乗り方をしている子供がいたから、注意したんだけど、乗ってる本人は「大丈夫だよ〜」と言って全然聞いてくれない。結構強い口調で言っているのに。
