ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog;
半年前から会社でシニアエンジニアという役職で、エンジニアのメンターの役割を担っている。その役割を出来るだけうまく演じられるように、半年間はコーチングの学習を進めてきた。 目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog; なぜ最近コーチングや人間の学習モデルの勉強をしているのか - $shibayu36->blog; 「コーチングのすべて」読んだ - $shibayu36->blog; また、半年間、目標・1on1・評価と一通りの業務をこなし、コーチングの実践が出来た。 そこで今回はコーチングの学習と一通りの実践を通して学んだことで、特に役に立ったと思うことについて一旦まとめてみる。特に役に立ったと思った知識は以下の二つである。 ゴールを決め、現在位置とのギャップを考え、目標を決める 解決案を与えるのではなく質問する ゴールを決め、現在位置とのギャップを
天才エンジニアでなくても10億ドル企業を起こせる | readwrite.jp
今からおよそ10年前、エキサイトの創業者であり現在グーグル・ベンチャーズのパートナーであるジョー・クラウスは明言した。「起業家にとってこんなに良い時代はない」と。クラウスはスタートアップの経済面、つまりサーバやネットワーク、その他コンピューティングに必要な機材の安価さについて述べたのである。 そして10年後、アンドリーセン・ホロウィッツのパートナー、サム・ゲルステンザングはクラウスの発言からさらに一歩踏み込んだ。彼は最近のブログ記事において、コストだけではなく製品開発に必要な能力も歴史的に低いと主張した。 エンジニア未経験者でも起業できるのである。 資金がない？問題なし！いまや懐かしい話だが、アプリケーションを作りそれを元手に起業するためにはかなりの資金が必要だった。ハードは高額。ソフトも高額。ストレージもやはり高額。 一方でエンジニア費用は比較的安価だった。 しかし2005年にクラウスが
ガートナー ジャパン | Gartner Japan
ガートナーのエキスパートから提供する、確かな知見、戦略的アドバイス、実践的ツールにより、ミッション・クリティカルなビジネス課題の解決を支援します。
「もっとスキルを」が引き起こす問題 − ＠IT自分戦略研究所
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルにおける位置付け 前回に引き続き今回も、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けします。 今回の内容は、リーダーシップトライアングルのLoveに関係しています。Loveについては、第10回「正しいことをし、行動力を発揮するココロ」を参照いただければと思います。 ■「Love」（ココロ）の具体的な例が求められている 前回の記事（第13回
「ITアーキテクト」という職種の曖昧な立場
「ITアーキテクト」という職種に関心のある人は少なくないだろう。 ITアーキテクトとは，一言で表現すると「システム（アプリケーション，データ，プラットフォームなど）の“最適な構造”を設計する職種」である。業務に基づく機能要件や，処理性能をはじめとする非機能要件，コストや開発期間，将来のビジネスや技術の変化，といったさまざまな条件を考慮しつつ，情報システムのあるべき構造（ITアーキテクチャ）を考えるのが，ITアーキテクトの役目だ。 日本では数年前まで，日本IBMなどごく一部の大手ベンダーを例外として，ITアーキテクトという職種はあまり認知されていなかった。現在でも，プロジェクト・マネジャやコンサルタントに比べると，なじみの薄い職種と言えるかもしれない。 しかし，ここにきて，そうした状況は少しずつ変わりつつある。そのきっかけの一つとなったのは，経済産業省が2002年末に発表した「ITスキル標準
素早く正規形を見抜く実践テクニック（1/4） － ＠IT
今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。 ではなぜ「第3正規化まで行えば問題ない」のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
