イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。
2018年4月25日にはてなさんのオフィスでプレゼンしたときの資料です。 ※このスライドは、2017年1月に公開した資料 ( https://speakerdeck.com/makoga/regional-scrum-gathering-tokyo-2017 ) に「社外評価者」の取り組みなどを追加した内容になってます。 ---- 2018/05/15追記 このスライドを公開後、下記2点を懸念する声がいくつかありました。 ・プレゼンスキルだけが高い人が過剰に評価されるのでは。 ・社内政治やコネを作るのがうまい人が過剰に評価されるのでは。 それを受けて、工夫していることを別ブログとして書きましたので、ぜひ読んでみてください。 適切な技術力評価をするために工夫していること https://note.mu/makoga/n/nfafc523957f3 ---- 2019年2月5日追記 スライドだ
学生時代バイトで個人指導の塾講師をやっていて、座ってられない&話が聞けない中2とか、アルファベットのaとdとbの区別が付いてなくてbog とかdopple とか平気で書いちゃう中3とかを担当していた。 そういうレベルの子供でも、ちょっとした一言というかきっかけが見つかれば変わるし、偏差値27から50超のだいたい普通レベルまでもってくことは、片手間の個人指導の大学生バイトでも割と難しくなかった。 逆に私にとっては、普通の子を出来る子にする方が簡単じゃなかった。本人に勉強への自発的意欲があって家庭の協力があれば偏差値60超くらいまではいけたけど、そこから先は元々の素養がないとダメかなぁという感じだった。個人的な体感だと65を超えるのは元々の素養が大きく左右するなぁと思っていた。 アホの子を普通の子にする役目は、他のバイト講師仲間の誰もがやりたがらなかった。私はアホだったからそっちのが性に合って
質問箱とかやっていると「こんなことがあって落ち込みます。どうしたらいいですか?」「メンタルが弱いのですぐに落ち込みます。」みたいなのが多くて、みんな落ち込んでいるんだなあ、と思った次第です。 かくいう僕も、メンタルが水気の多い豆腐くらい弱いのです。なんか老舗の旅館とかで出てくる豆腐みたいな感じです。あれおいしいよね。 なので、昔は落ち込んでる時が多かった気がするのですが、いろいろがんばった結果、落ち込むことがかなり少なくなり、落ち込んでも数時間でどうでもよくなるという感じになりました。 生まれ持った性質とかメンタルの強さではないので、他の人にも応用できるかなあ、と。というか、メンタルの強い弱いは、どちらかというと、物事に対してどう考えるかの習慣にすぎないんじゃないか、とも思っています。 というわけで、落ち込まないための工夫をちょっと紹介していきたいと思います。 (単に歳をとって気にしなくな
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 最近、メンター制度として新入社員や若手のメンバーに対して、先輩をつけて相談事に乗ってあげたり、仕事のサポートをしたりといったような教育プログラムを組む企業が増えています。このメンターという役割は、ちょっとした訓練が必要だったりするのですが、このあたりの研修や訓練をせずにいきなり明日からメンターね!なんてことがままあります。
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。
こんにちは、らくからちゃです。 なんだか、こちらの記事をきっかけとして、色んな方から『長時間労働あるある』が出ているみたいですね。 ちょっと私も鎖自慢をさせていただくと、先々週の土曜日から元気に連勤中ですヽ(=´▽`=)ノしかも何故か、今週は今日(金)・明日(土)と泊まり込みの研修です。ウエーイ! まあ色々と私が未熟だったところに不運な事故が立て込んでしまい、何だか素敵な状況になってしまったのが発端ですが、流石にずっと働きっぱなしだと何が何だかよく分からなくなってきますね(まだブログ書いてる余裕ある分マシな方だと思いますが・・・) それはさておき、いつもの改札を出て階段を登ろうとしていたら、こんな物がはられていました。 皆さん、10月は年次有給休暇取得促進月間です。社畜労働をしてる場合では有りません。清く正しく美しい国民であれば、仕事と生活の調和のために、『プラスワン休暇』で連続休暇を実現
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く