1分間ジェフ・ベゾス ~Amazon.comを創った男の77の原則~ を読んで

Amazonの創設者ジェフ・ベゾスの思想や名言について綴られた本です。

1分間ジェフ・ベゾス

今年6月に、あるIT見本市でAmazonに関係するセミナーを受講した際、
「Amazonはここ3~4年、利益率が1%未満」ということを聞いて「ホントか~???」と思っていましたが、
本書を読んで本当なんだということが分かりました。

なぜ、利益率が低いのか。
それは、徹底した顧客重視の経営だから。
「利益を出すのは簡単で、かつ愚かなこと」つまり、「挑戦し続ける」という思想があるから。

また、社員に対する待遇は、他のIT企業と比べると高くない。
高くないのになぜ優秀な人材を採用できるのか。
「何か大きなことがやってみたかったらアマゾンをめざせ」という程、
待遇ではなく挑戦や経験できることに魅力を感じられるため。

共感できる部分については少しずつでも実践していこうと思います。(^O^)/

 

いいね!ボタンがつくようになりました(*^^)v

新規投稿した記事毎に、「いいね!」ボタンがつくようになりました。\(^o^)/

コメントするまでもないけど「いいね!」ボタンなら押してもいいという方、是非押してFacebook等の別メディアにブログが紹介されるようにご協力お願いします。!(^^)!

 

『会社を変える分析の力』を読んで

2014年6月18日に福岡で開催された『日経BP社 ITイベント2014 九州』で、『大阪ガスにおける経営に活かすデータ分析』のセミナーを受講した際に無料で頂いた講演者の著書である。

会社を変える分析の力

著者は、大阪ガスでデータ分析をビジネスに活用されているプロである。

データ分析と聞くと、大量データを難しい計算式などで計算して、ある法則を導き出すというイメージであるが、それだけではビジネスを変えることはできず、以下のフロー全てを行って初めてビジネスを変えることができるということであった。

  1. ビジネス課題を見つける
  2. 分析問題を解く
  3. 分析結果をビジネスの意思決定に使わせる

各ステップ役割分担してはという考えもあるが、全てのプロセスに主人公として務め通す気概がなければビジネスを変えることはできないということである。
この考えについて、「やはりそうだよな」と納得させられた。

ウェブ上では、データ分析力を競うコンテストサイト「kaggle」というものがあり、企業が抱えるデータ分析課題を開示し、懸賞金を出して、優れたデータ分析を公募するというサイト。
つまり、企業は社員としてデータ分析者を抱えなくとも、世界中の優秀なデータ分析者の力を借りることができるということである。

ビッグデータにも言及されている。

  • ビッグデータは打出の小槌ではなく、そこからイノベーションが勝手に生まれてくる訳でなない。ビジネスへの展望なしでは役に立たない分析結果があふれ出るだけ。
  • 成功事例を見てみると、分析の前段階で明確な目標を持っている。「カード不正利用の検出率を上げよう」や「ユーザーへのリコメンデーションを改善して売上を伸ばそう」など。

活躍できる分析者に共通する行動パターンとして上げられている分析者9カ条は、分析者に限らず身につけるべき行動パターンと思ったので以下に挙げておく。

  1.  ビジネスの現場に出よう、ビジネス担当者とコミュニケーションしよう
  2.  整理整頓を心がけよう
  3.  なぜ?なぜ?なぜ?
  4.  データをビジュアル化しよう
  5.  他人のデータを疑おう
  6.  Simple is better
  7.  ざっくり計算
  8.  文章を書こう
  9.  うまくいかなければ、目的に立ち戻ろう

 

カテゴリーを指定できるようになりました!!

この社員ブログの新規投稿画面で、「カテゴリー」を指定できるようになりました!!!

下の画面キャプチャの通り、新規投稿画面の右下にカテゴリーを選択する欄がありますので、これから投稿する際は、投稿内容に当てはまるカテゴリーを選択するようにお願いします。(^^)

※選択しなかった場合は、「未分類」を選択したことになります。

新規投稿画面

カテゴリーを指定することで、社員ブログトップページの右端のメニューの下の方に、カテゴリーのリンクが表示されるようになり、そのリンク先ではカテゴリーに属する記事のみ表示されます。

カテゴリー一覧に新たなカテゴリーを追加してほしいというご要望があれば、Webサイトリニューアル委員会または社内システム担当にご相談ください(^_-)-☆

以上、ご協力お願いします。<(_ _)>

本当に使える開発プロセス

今年に入って、複数のお客様から
「品質を維持しつつ開発期間を短縮するために開発プロセスの見直しが必要だ」
というお話しを頂き、模索している中で上司よりお勧め頂いた本を読んでみました。

 

本当に使える開発プロセス

 

大きく第1章と第2章に分かれており、
第1章が本当に使えるシステム開発の進め方について、
第2章がクラウド対応のシステム設計書の作り方についての内容だったので、
今回は第1章だけを熟読しました。

 

第1章も以下のように開発プロセスに応じて解説されています。
・システム企画(目標設定、業務プランニング、システムプランニング、基本計画策定)
・要件定義
・基本設計
・詳細設計
・プログラミング
・テスト

 
まず所感としましては、
内容が業務システムを対象としたものでしたので、
我々がメインで行っている地図開発にそのまま適用できる内容ではありませんでした。
ただ、いくつかヒントとなる内容はありましたので以下に記載します。

 
システム企画フェーズは、なかなか携わる機会がないですが、
基本計画策定において「段階的リリース」を前提として
「業務結合度」と「システム結合度」を考慮したリリースセット(リリースする単位)を導き出すという内容が、
開発プロセス見直しの1つのポイントになるのではないかと感じました。

 

要件定義フェーズについては、特別目新しい内容が書かれていた訳ではないですが、
ユースケースを活用する上でシナリオの質を高める「INVEST」というテクニックや、
肥大化する非機能要求に対処するための「非機能要求グレード活用シート」の具体例が記載されており今後活用できると思います。

 

基本設計フェーズについては、画面設計、データ設計、機能設計も行う必要がありますが、
アーキテクチャ設計をメインに記載されており、かつ業務システムに対して既製品を活用することを前提の内容でしたのであまり参考になりませんでした。
ただ、業務フローをベースにドメインモデルを作成しデータ特性を分析する上での以下の注意点が参考になりました。
・少しずつモデリングする
・シンプルに作る
・モデルを公開する

 

詳細設計フェーズについても、特別目新しい内容はなく、
画面設計においては実装技術を使って実際に動くものを見せることでユーザーがイメージし易く、
プログラミングフェーズでその成果物をそのまま使用できるという内容は正にそうすべきだと思いました。
また、プログラム設計書(フローチャートなど)を作成しない場合は、
プログラムコードによってその役割を果たすべきで、
そのためにはコードの共同所有の意識を高める必要があり、それを促進する施策として
XP(eXtreme Programming)では「ペアプログラミング」「テストファースト」「CI(継続的インテグレーション)」が
謳われているが、これらを実践することは難しいということで、
「パターン(デザインパターン)」の使用を薦められていました。

 

テストフェーズでは、受入テスト駆動開発を勧められていましたが、
これについては我々も既に実践している内容です。
あとは、チケット駆動開発として、BTS(バグトラッキングシステム)やITS(課題トラッキングシステム)などの
チケット単位でプロジェクトのタスクを管理してテストやバグの状況を可視化することで
リズミカルにテストを進められ、要求や設計などの情報と紐づけられるので作業の見通しが良くなるということでした。
このチケット駆動開発を行うには、「CI(継続的インテグレーション)」という
プログラムコードの修正結果とチケットを自動的に紐づけてくれる仕組みが必要とのことです。
この仕組みのことを「ALM(Application Lifecycle Management)」と呼ぶらしく、
「定義」「デザイン」「ビルド」「テスト」「展開」という一連のプロセスとアクティビティを
シームレスに連携する仕組みだそうです。
代表的な統合ALM製品として「Microsoft Team Foundation Server」が挙げられていましたが、
習熟期間や目的が明確でないと導入しても効果は出にくいと注意書きがありましたので、
地図開発において有効かどうか実際に触って確認してみたいと思います。

 

アルミホイル指輪

健康ネタです(^^)

『アルミホイル指輪』ってご存知ですか?

頭痛、生理痛、肩こりなどの痛みに、アルミホイルが効くんだそうです!!

この画像のようにアルミホイルを適当な大きさに切って、指輪みたいに指に巻き付けるだけ。

アルミホイル指輪

肌の水分がアルミホイルのアルミニウムと反応して金属イオンが発生し、巻いた箇所のツボや経路に刺激を与えて、痛みや不調を緩和するのだそうです。

お金かかりませんので、諸症状のある方は是非試してみてください(^^)/

※残念ながら私は諸症状がないので効果を確認できてません(^^;

 

ゼンリン 住宅地図と最新ネット地図の秘密

画像

本部長より紹介頂き、読みました。

ゼンリン  住宅地図と最新ネット地図の秘密

我が社が大変お世話になっているゼンリン様の

  • 地図事業の歴史
  • 調査員の方々の苦労話
  • 東日本大震災の被災地地図作りのエピソード
  • カーナビ地図の進化
  • 車を制御する地図

について、要点をしっかり押さえ、分かり易く書かれていました。

社員の方は必読です!!!!!!!!

特に、開発に携わっている方は、以下だけでも読んでください。

  • 第3章 「カーナビ地図の進化を追う」編
  • 第4章 クラウド、ビッグデータ時代の地図

2020年の東京オリンピックに向けた地図事業がイメージできるのではないかと思います。
また、余裕があれば「第1章-3 東日本大震災~被災地の地図づくり~」も読んでみてください。
思わず涙が出てきてしまいました(^^;

日頃は目先の仕事のことしか考えられていなかったりしますが、「地図づくり」という大事業に関わらせて頂いているということに気づかせてもらえる1冊ですよ(^0_0^)

 

日経SYSTEMS (6月号) 読みました!

 

 


★どうする?日本のプログラミング力不足

今回の記事を読んで、
プログラミングする仕事が減ったと感じていたが、それはわが社だけの話ではなく、
日本全体でそうだったのだと気づいた。
プログラミングする仕事が減ったため、プログラミングする機会も減り、
プログラミング力がないSEが増えているという状況である。

色々な会社のプログラミング力向上のための教育について書かれているが、
どこも実業務に絡めたプログラミング教育体制を導入されていると感じた。

現在の我が社のような中小企業で実施できる教育について
今回の記事を参考にして考えていこうと思う。(-。-)y-゜゜゜

 


★プロジェクト成功と育成を両立する、仕事の振り方

仕事を振る時に重要なことは、
相手のレベルを正しく認識することと、
そのレベルに応じて目的や手段の伝え方を変えることだと思う。
今回の記事では、そのレベルに応じた振る側の対応についてアドバイスされている。
レベルがよく分からない時は、低いレベルの対応から始めるというのは、
以前上司からアドバイス頂いたことでもあった。(その逆をよくやりがち)
「30%ルール」「20分ルール」「週間ゴール」「イエローフラッグ」「チェックポイント」という
5つのテクニックについて紹介されており、
普段できていることとできていないことを再確認する良い機会になった。
PLの方は是非ご一読ください。(^^)/

 


★現場リーダーのための調整力養成講座 ~第3回:「ありがとう」を引き出す交渉力~

以前、「ハーバード流交渉術」という社外セミナーに参加して、
そこでも「交渉は勝ち負けではなく、一緒に問題解決する場」であることを学んだが、
それを前提とした上で、今回の記事にある「返報性の原理」を活用して交渉することで
相手に感謝の気持ちを抱かせてWin-Winの交渉ができるのだと感じた。
いずれにしても、交渉前の準備が必須であることは最近特に痛感している。
交渉でお悩みの方は是非ご一読を(^-^)