プログラミング上達には「コードレビュー」が大事という話

はじめに

こんにちは。
最近、「コードレビュー」で自分の未熟さを思い知ったと同時に、プログラミング上達には「コードレビュー」を受けることが大事だということを実感しました。
なので今回は「コードレビュー」について書こうと思います。

「コードレビュー」のススメ

レビューって何?

IT用語辞典より引用。

システム開発において、作成された仕様書やコードなどの成果物を開発者とは別の人が詳細に調べ、仕様や要求を満たす内容になっているか、誤りや不具合が無いか、資源の浪費や不必要な冗長さ、極端な低性能などの問題が無いかなどについて開発者にフィードバックする工程をレビューという。

また、一般の外来語としては、書籍や映像・音楽作品、ビデオゲーム、公演など鑑賞したり、店舗や施設を利用したり、製品を購入・利用したりした人が、対象を評価することや、感想や論評を文章や評点などの形に表したものをレビューということが多い。

レビューする人のことを「レビュワー」(reviewer、レビューアとも)、レビューされる人のことを「レビューイ」(reviewee、レビュイーとも)と呼ぶ。

「コードレビュー」をすると何がいいの?

自分がレビューの中でも大事だと考えるのは「コードレビュー」です。
中でもプログラミング上達過程における「コードレビュー」は、実際に手を動かすことと同じくらい勉強になります。
考えられる効果は下記の通りです。

  1. プログラミングに関する良いお作法、書き方を知ることができる。
  2. 自分の書き方の悪いクセを知ることができる。
  3. いわゆる「クソコード」がどんなものか理解できる。
  4. 開発言語に関する良い知見を得ることができる。

どんな場所でコードレビューして貰えばいいの?

社内でしてもらえる場合はそれでもいいですが、オススメは勉強中の言語のコミュニティの勉強会に参加してレビューをお願いすることです。
社内だとその会社の技術力が低かった場合、逆に悪い習慣を身につけてしまうこともあります。
その点、コミュニティの勉強会には少なくとも1人はその言語に精通した人がいるので、良い知見を得られやすいです。
関西、かつrubyコミュニティだと西脇.rb、Kobe.rb、Shinosaka.rb、Kyoto.rb、Rails Follow-up Kobe、Rails Follow-up Osakaなどがあります。

効果の高い「コードレビュー」をする上で必要なものは?

「コードレビュー」の効果を最大限に引き出すために必要なものがあります。
それは「テストコード」と「GitHub」です。

まず「テストコード」。
これはレビュアーからの指摘を受けてリファクタリングする際に役立ちます。
これがないとリファクタリング後に新たなバグを埋め込んでしまっていないかどうかの担保が取れません。

次に「GitHub」。
プログラミングスキルが低いうちはコードレビュー中に次々に指摘を受けていっぱいいっぱいになりがちです。
そのため、事前にレビューしてもらうコードのプルリクをGitHubに作成しておきレビュアーに公開、コメントをつけてもらうことでレビューの時間を効果的に使うことができます(プルリクに関する説明はここでは省きます)。
また、レビュー後の備忘録、メモとして使うこともできます。

参考リンク

下記リンク先のQiita記事にテストやコードレビューの必要性が詳しく書かれています。
ぜひご一読ください。
qiita.com

コードレビューの事例

ここからは実際のコードを見て、コードレビューの効果を実感してみましょう。

おまけ付きの駄菓子屋さんでもらえる飲み物の本数を求める

まずはbonus_drink.rbというプログラムです。
コードレビューとリファクタリングRails Follow-up Kobeでしてもらいました。
仕様に関する問題は下記の通りです。

ある駄菓子屋で飲み物を買うと、空き瓶3本で新しい飲み物を1本プレゼントしてくれる。
最初に購入した飲み物の本数から、トータルで飲める本数を算出するプログラムを作成せよ。
また、最初に100本購入した場合、トータルで何本飲めるか。

次にソースコードです。
まずはリファクタリング前を見てみましょう。

class BonusDrink
  def self.total_count_for(purchase)
    purchase + calculate_bonus(purchase)
  end

  private

  def self.calculate_bonus(purchase)
    bonus = 0

    if purchase >= 3
      purchase -= 3
      bonus += 1
      bonus = bonus + (purchase / 2) if purchase > 0
    end

    bonus
  end
end

コードの説明をすると、まずtotal_count_forではpurchase(購入本数)とcalculate_bonusで算出したおまけの本数を足しあわせてトータルで飲める本数を算出しています。
calculate_bonusではまずbonus(おまけの本数)を0で初期化し、purchase(購入本数)が3本未満である場合は0を返すようにしています。
purchaseが3本以上であった場合、purchaseから最初のおまけと交換した本数を省き、bonusを1本分カウントアップしています。
そして2本目のおまけ以降は交換したおまけを含めて3本になったらおまけと交換できます。
つまり2本購入すればおまけと交換できるわけです。
そこで最初のおまけに購入本数を2で割った商を足しあわせ、最終的なおまけの本数として返しています。
説明するとこんな感じなのですが、上記のソースコードを初めて読んだ人にとってはロジックの根拠がわかりづらい書き方になっています。
それではリファクタリング後のソースコードを見てみましょう。

class BonusDrink
  BONUS_PER = 3
  BONUS_GET = 1

  class << self

    def total_count_for(purchase)
      purchase + calculate_bonus(purchase)
    end

    private

    def calculate_bonus(empty_bottle)
      # 空き瓶3本目まではおまけなし
      return 0 if empty_bottle < BONUS_PER

      # 最初のおまけ + (最初のおまけと交換した空き瓶を引いた残り本数) / (2本目のおまけ以降はおまけ一本を含めて3本)
      BONUS_GET + (empty_bottle.to_i - BONUS_PER) / (BONUS_PER - BONUS_GET)
    end
  end
end

リファクタリング後はリファクタリング前と比較して大分すっきりしましたね。
特にcalculate_bonusに関しては7行(空白行を除く)あったソースコードがたった2行(空白行とコメント行を除く)になっています。
ではどう変わったのか見ていきましょう。
まずはクラスメソッドのprivate化に関してです。
下記のように書くことでcalclate_bonusはprivateなメソッドになっていそうですが、実は外部から呼び出すことができてしまいます。

private

def self.method_name
  # 実装
end
irb(main):001:0> require './bonus_drink'
=> true
irb(main):002:0> BonusDrink.calculate_bonus(10)
=> 4

下記のように書くことで、privateなメソッドになり外部から呼び出せなくなります。

class << self

  private

  def method_name
    # 実装
  end
end
irb(main):001:0> require './bonus_drink'
=> true
irb(main):002:0> BonusDrink.calculate_bonus(10)
NoMethodError: private method `calculate_bonus' called for BonusDrink:Class
        from (irb):2
        from /Users/moritsukamasatoshi/.rbenv/versions/2.1.1/bin/irb:11:in `<main>'

次に変数名です。
リファクタリング前はcalculate_bonusの仮引数名がpurchase(購入した本数)になっていましたが、おまけの交換対象は購入した瓶の本数ではなく空き瓶の本数です。
そのため、リファクタリング後は仮引数名をempty_bottle(空き瓶の本数)に変更しています。

最後にcalculate_bonusの実装と定数化に関してです。
リファクタリング前は数値がベタ書きされていてどういう値なのかよくわかりませんでした(いわゆるマジックナンバー)。
リファクタリング後はおまけと交換する本数とおまけでもらえる本数の2つの数値が定数化されており、どういう数値かはっきりわかり、ロジックの意味もわかりやすくなっています。
定数化したおかげで本数の条件が変わった場合でも改修しやすくもなっています。
更にコメントで補強することでよりリーダブルなコードになっています。
このようにロジックの根拠がわかりづらいケースでは、コメントを有効利用すると読みやすくなります。
また、リファクタリング後はcalculate_bonusの最初で条件に合致した場合0を返すようにしたこと及び式をまとめたことにより、より簡潔な記述になっています。
ちなみにrubyでは最後に評価された値を戻り値として返すため、今回のcalculate_bonusの先頭行のように明示的に値を返す場合以外はreturnを省略するのが主流な書き方です。

三角形の形を求める

次はtriangle.rbというプログラムです。
コードレビューとリファクタリングはKobe.rbでしてもらいました。
引数で指定した辺の長さで形成される三角形の形を表示するプログラムです。
まずはリファクタリング前のソースコードです。

require 'nkf'

class Triangle

  class << self

    def display_shape(line_a, line_b, line_c)
      lines = [line_a, line_b, line_c].map { |line| NKF.nkf('-m0Z1 -W -w', line).to_r }

      # 引数に整数、小数、分数以外が指定された場合String#to_rで0/1に変換されるため、ここでメッセージを表示する
      return '辺の長さは0より大きい整数、小数、分数を半角または全角で入力してください!' if or_less_zero?(lines)
      return '三角形じゃないです><' unless triangle?(lines)

      if equilateral?(lines)
        '正三角形ですね!'
      elsif isosceles?(lines)
        '二等辺三角形ですね!'
      else
        '不等辺三角形ですね!'
      end
    end

    private

    def or_less_zero?(lines)
      (lines[0] <=> 0) <= 0 || (lines[1] <=> 0) <= 0 || (lines[2] <=> 0) <= 0
    end

    def triangle?(lines)
      (lines[0] + lines[1] <=> lines[2]) == 1 && (lines[1] + lines[2] <=> lines[0]) == 1 && (lines[2] + lines[0] <=> lines[1]) == 1
    end

    def equilateral?(lines)
      lines[0] == lines[1] && lines[1] == lines[2]
    end

    def isosceles?(lines)
      lines[0] == lines[1] || lines[1] == lines[2] || lines[2] == lines[0]
    end
  end
end

puts(Triangle.display_shape(ARGV[0], ARGV[1], ARGV[2]))

簡単にソースコード、主にdisplay_shapeの説明をします。
まず渡されてきたコマンドライン引数を全角から半角に正規化し、Rationalクラスの(有理数、つまり分数を扱うクラス)オブジェクトに変換します。
次にコマンドライン引数のバリデーションを行い、有効な値だった場合は三角形の形を判定し、その結果を表示します。
ソースコードを読むと、三角形の形を判定しているメソッドの中身の条件式が非常に冗長な書き方になっていますね。
Rationalクラスのリファレンスを読んだ際に<=や<等が載っておらず、<=>(UFO演算子)のみがあったため、Rationalクラスでは<=や<等の演算子が使えないと勘違いしたことが原因です。
実際はRationalクラスはComparableモジュールを継承しているため、<=や<等の演算子も使えます(リファレンスに載っていないのは<=や<がオーバーライドされていないからです)。
それではリファクタリング後のソースコードを見ていきましょう。

require 'nkf'

class Triangle

  class << self

    def display_shape(line_a, line_b, line_c)
      lines = [line_a, line_b, line_c].map { |line| NKF.nkf('-m0Z1 -W -w', line).to_r }

      return '辺の長さは0より大きい整数、小数、分数を半角または全角で入力してください!' if zero_or_negative?(lines)
      return '三角形じゃないです><' unless triangle?(lines)

      if equal_all_lengths?(lines)
        '正三角形ですね!'
      elsif equal_two_lengths?(lines)
        '二等辺三角形ですね!'
      else
        '不等辺三角形ですね!'
      end
    end

    private

    def zero_or_negative?(lines)
      lines.any? { |line| line <= 0 }
    end

    def triangle?(lines)
      (lines[0] + lines[1] > lines[2]) && (lines[1] + lines[2] > lines[0]) && (lines[2] + lines[0] > lines[1])
    end

    def equal_all_lengths?(lines)
      lines.uniq.size == 1
    end

    def equal_two_lengths?(lines)
      lines.uniq.size <= 2
    end
  end
end

puts(Triangle.display_shape(ARGV[0], ARGV[1], ARGV[2]))

まず不要なコメントに関してです。
BonusDrinkの時と違い、リファクタリング前ではコードの悪いところ(to_rが変換できない文字列の場合は0/1を返すことを利用し、コマンドライン引数が0以下かどうかを判定する箇所で一緒に判定してしまっている)を補強するためにコメントを使っています。
このような場合はコメントを使うのではなく、コードの方を直しましょう(今回は時間の関係で直していません)。
リーダブルコードにもありますが、「優れたコード > ひどいコード + 優れたコメント」です。

次にコマンドライン引数が0以下かどうかを判定するメソッドに関してです。
名前が文法的におかしかったため、変更されています。
negativeはrubyのメソッドnegative?から来ています(negative?は0未満、つまり負の値かどうかを判定するメソッドです)。
実装の方を見ると、リファクタリング後は下記のようになっています。

lines.any? { |line| line <= 0 }

any?の説明に関しては下記を参照してください。
any? (Enumerable) - Rubyリファレンス
rubyにはこのような便利なメソッドが多数用意されているため、これらを駆使することで簡潔なコードを書くことができます。
また、ここは下記のような書き方もできます。

!lines.all?(&:positive?)

all?の説明に関しては下記を参照してください。
all? (Enumerable) - Rubyリファレンス
上記の引数のような書き方の説明は下記を参照してください。
Rubyのmap(&:name)というのはどういう意味? - QA@IT
今回はより意味を解しやすいという理由で前者の書き方を採用しました。

次に三角形かどうかを判定するtriangle?メソッドに関してです。
リファクタリング後はかっこで囲うことで1つ1つの条件式がわかりやすいようになっています。

次に三角形の形を判定するメソッドに関してです。
リファクタリング前はequilateralやisoscelesといった意味のわかりにくい名前でしたが、リファクタリング後は平易な単語を使用して意味がわかりやすいようになっています。
また実装部分では、リファクタリング後はレシーバの配列のユニークな値の配列を返すuniqメソッドと配列のサイズを返すsizeメソッドを使ってより簡潔なコードになっています。

最後にリファクタリング後のソースコードに残っている課題に関してです。
今回は時間の関係で着手しませんでしたが、リファクタリング後のソースコードにはまだ改善すべき点が残っています。
まずdisplay_shapeメソッドにいくつもの処理を含んでしまっている点です。
メソッドの再利用性を高めるためには、適切な単位に処理を分割しておくことが大切です。
display_shapeでは下記の処理を行っており、それぞれのメソッドを作成することが必要です。

  1. 入力値の正規化(半角文字への変換)
  2. バリデーション(入力値のチェック)
  3. 三角形の形の判定
  4. 文字列の表示

またTriangleクラスはインスタンス変数やインスタンスメソッドを持たずクラスメソッドのみのため、クラスではなくモジュールにすべきという指摘も受けました。

まとめ

上述の2度のコードレビューで多くの知見を得ることができました。

  • rubyのprivateの仕様
  • 良い名前の付け方や命名の際によく使われる英単語
  • 良いコメントと悪いコメント
  • rubyの比較演算子について
  • rubyの便利なメソッド
  • メソッドの適切な機能分割
  • クラスとモジュールの使い分け

皆さんもコードレビューをどんどん受けて、綺麗で読みやすいコードを書けるようになりましょう!

最後に

ここまでお読みいただきありがとうございました。
何かご意見・ご感想あればコメントもらえるとありがたいです。

近況報告

はじめに

ご無沙汰しています。
気づけば前回の更新から90日以上たってしまっていました。
今回は最近の自分の近況を報告したいと思います。

近況

ソニックガーデンのトライアウトに参加した

5月頭から以前から志望していたソニックガーデンのトライアウトに参加しました。
ソニックガーデンの中途採用の過程は下記のようになっています。

  1. トライアウト(レベル1→面談→レベル2→技術試験→社長面談)
  2. 見習い
  3. 一人前(正式契約)

自分が現在取り組んでいるのはレベル1です。
レベル1では提示される質問への回答と技術的な学習を行います。
質問は1問回答するごとに次の質問が提示されます。
だいたい20問くらいありそうです(表示される進捗率から推定)。

自分は現在1問に対して1週間またはそれ以上(他者からのレビュー含む)かかってしまっており、単純計算でレベル1だけで5〜6ヶ月ほどかかってしまうことになります。
文章の構成を考えるのはブログのおかげでだいぶ上手くなった実感があるのですが、自分の考えをまとめたり文章の自然で伝わりやすい表現を考えたりするのに時間がかかってしまっているのが現状です。
なんとかして書き上げるスピードを早めていきたいところです。

また技術的な学習も含めて、今は制限時間を設けず取り組んでしまっています。
今後見習いとして採用された後のことも考えて、事前にかかる時間を見積もり計画的に物事に取り組む習慣をつけていきたいと考えています。

昔の体を取り戻すためにダイエットを始めた

現在、昔の体に戻すためにダイエットに取り組んでいます。

きっかけはインターネットテレビabemaTVでアニメ「ハイキュー」の一挙放送を観たことです。
「ハイキュー」は週刊少年ジャンプで連載中の高校バレーボール漫画です。
ジャンプにありがちな特殊能力ものではなく、王道のスポーツ漫画です。
高校時代に運動系の部活やってた方はぜひ一度「ハイキュー」観てみてください。(もちろん原作でもOKです)
高校時代に戻ってまた部活がやりたくなることうけあいです。
自分の場合、ダイエットだけでなく鬱になってから足が遠のいていた草野球にもまた参加するようになりました。
「ハイキュー」のおかげで以前より考えてプレーするようになり、以前より楽しくプレーすることができています。

話が「ハイキュー」のことにそれてしまったのでダイエットの話に戻します。
自分は鬱になってしばらく気持ち的な問題から運動に取り組めませんでした。
そのせいで溜まりに溜まった体重はついに90kgを超え、体脂肪率も30%を超えてしまいました。
そのため、現在は食事のカロリーコントロールと運動でダイエットを行っています。

摂取・消費カロリーのコントロール、体重・体脂肪率の記録は「あすけん」というアプリとタニタの体組成計を使ってやっています。
「あすけん」は無理なくダイエットするにはうってつけのアプリで、自分は月額300円のプレミアムコースに加入しています。
プレミアムコースになるといろいろと便利になるのでオススメです。
もちろん無料版でも効果はあるのでぜひ使ってみてください。
続けるコツは厳密すぎず、ある程度大雑把に記録していくことだと思います。
www.asken.jp

運動の方はビリーズブートキャンプ(基本プログラム・腹筋プログラム)と30分ほどのジョギングをできるだけ毎日しています。
もう少し体力が戻ったらジムでのウェイトトレーニングや水泳も取り入れようと思っています。

ちなみに「あすけん」での記録開始から3週間で体重が約1kg減、体脂肪率が約1%減です。
高校時代の体重が65kg前後だったのでまだまだ道のりは遠いです。

勉強会への積極的な参加

西脇.rb、Kobe.rb、Rails Follow-up Kobe、Rails Follow-up Osakaといったruby勉強会に積極的に参加しています。
最近はトライアウトで作ったプログラムをソースコードレビューしてもらっています。
このことに関しては別の記事で書こうと思います。

最後に

とりあえずソニックガーデンに入れるように毎日精進していきます。
ブログも最低でも月1くらいの頻度で書けるようにしたいところです。
何かご意見・ご感想あればコメントもらえるとありがたいです。

西脇.rb&神戸.rbでテスト駆動開発とオブジェクト指向プログラミングを学んできた

はじめに

こんにちは。
今回は先々週の土曜日、西脇.rb&神戸.rbの勉強会「手を動かして学ぼう!テスト駆動開発オブジェクト指向プログラミング」に参加してきたのでその参加レポートを書きたいと思います。

nishiwaki-koberb.doorkeeper.jp

当日の内容

  • 問題発表(当日の問題はこちら
  • グループに分かれて回答を実装
  • グループ毎の代表者のコードを全体でレビュー

参加してみた感想と勉強になったところ

テスト駆動開発は実装の粒度を小さくして作る

テスト駆動開発に関しては本やブログなどで読んで多少知っていたつもりでいました。
しかし、自分は最初テストケースを全て書いてから実装しようとしていて、そのことに関してAkiさんから注意を受けました。
確かにテストケースを全て書いてから実装していては実装途中で誤って機能を壊してしまっても何が原因かわからないですよね。
それではテスト駆動開発をしている意味がなくなってしまいます。
今回学んだテスト駆動開発の流れは下記の通りです。

  • テストケースを1つ書いてテストを実行し、失敗または成功するのを確認する。
  • 成功したら次のテストケースを書き、失敗したらまだ実装されていないということなので機能を実装する。
  • 実装が完了したらテストをもう一度動かしてみて機能が仕様通り実装されているかどうかということと実装したことにより機能が壊れていないかということをたしかめる。

プログラミングは実際に手を動かす&コードレビューしてもらわないと身につかない

プログラミングは実際に手を動かさないと身につかないということを改めて実感しました。
例えばattr_readerとインスタンス変数の関係。
最初、fareが読み取り専用の場合インスタンス変数にどうやって値を入れるかど忘れしてしまっていきなりハマってしまいました。
正しい書き方は下記のとおり。

class Ticket
  attr_reader :fare

  def initialize(fare)
    @fare = fare
  end
end

attr_readerはクラスの外部からのアクセスを読み取り専用にするのであってクラス内部の場合は単純にインスタンス変数に値を入れればいいだけの話でした。
あとはクラス変数と定数。
最初はJavaのstaticのようにクラス定数にしようとして下記のような書き方をしようとしていました。

class Ticket
  @@FARES = [150, 180, 210].freeze
end

Ticket.FARES[0]

しかしRubyではクラス名.定数名という参照の仕方はできません。
またRubyではクラス定数という概念はなく、1文字目が何であるかでローカル変数、インスタンス変数、クラス変数、グローバル変数、定数のいずれかであると認識されます。
https://docs.ruby-lang.org/ja/latest/doc/spec=2fvariables.html
そのため@@変数名という書き方をするとクラス変数として認識されてしまいます。
正しくは下記のように書きます。

class Ticket
  FARES = [150, 180, 210].freeze
end

Ticket::FARES[0]

また、コードレビューに関しては今回は同じグループだったしなじゅんさんにお願いしてレビューイ(レビューを受ける人)を譲っていただきました。(しなじゅんさん、ありがとうございました)
コードレビューでも下記のような色々な知見を得ることができました。

  • 配列やハッシュの名前は複数形にする
  • Rubyのメソッドは必ず戻り値を返すので戻り値としてtrueやfalseを返す場合はreturn trueと書かず式を1行書くだけでいい
  • RSpecでテストケースを日本語で書く場合はexampleの方がしっくり来る

今回の勉強会でプログラミングを素早く身につけるためには自分で試行錯誤しながら実装し、実装後にコードをレビューしてもらうのが一番だと改めて感じました。
勉強会後にしなじゅんさんから大阪でアクティブなruby勉強会の話を聞くことができたので、今後はそちらにも参加して自分のコードをレビューしてもらう機会をどんどん増やしていこうと思います。

yuyaさんのプログラミングに対するこだわりが凄かった

yuyaさんがプログラミングに対する並々ならぬこだわりを持たれていて、凄いなと感じました。
ただ、奥が深すぎて途中から自分の理解が追いつかない部分があった。
いつかyuyaさんみたいにプログラミングに対する深い考えを持てればいいなと思いました。

ソニックガーデンについて詳しく聞くことができた

今回勉強会に参加した理由の一つには「ソニックガーデンの採用について詳しく知る」ということがありました。
今回の勉強会にはfounderの伊藤さんの他にもう一名ソニックガーデンのメンバーが参加していました。
その方は今月からソニックガーデンに入社した方で、ソニックガーデンのトライアウトや入社に至るまでのプロセスに関して色々と伺うことができました。
実際に入社した方からの生の情報、それも最近の情報を聞けたのですごく有意義でした。

当日の写真

f:id:sanfrecce-osaka:20170116120614j:plain
f:id:sanfrecce-osaka:20170116120638j:plain
f:id:sanfrecce-osaka:20170116120647j:plain
f:id:sanfrecce-osaka:20170116120651j:plain

最後に

ここまでお読みいただきありがとうございました。
何かご意見・ご感想あればコメントもらえるとありがたいです。

岩田松雄さんの「チームリーダーのための7つの習慣」を読んでみて感じた事、思った事

はじめに

こんにちは。

皆さんはスティーブン・R・コヴィー博士の著書「7つの習慣」を読んだことはあるでしょうか?

7つの習慣」は国内で200万部売れたビジネス書の大ベストセラーです。

今回はその「7つの習慣」を身につけるため、「7つの習慣」を元スターバックスCEOの岩田松雄さんが自身の経験に基づいて読み解いた著書「チームリーダーのための7つの習慣」を読んでみました。 

チームリーダーのための「7つの習慣」

チームリーダーのための「7つの習慣」

 

 

思ったこと・感じたこと

チームリーダーでない人でも非常に読みやすい一冊

この本はタイトルこそ「チームリーダーのための」となっていますが、チームリーダーでない人でも非常に読みやすい本です。

本書の構成は下記の通りです。

  1. パラダイムと原則
  2. 第1の習慣 主体的である
  3. 第2の習慣 終わりを思い描くことから始める
  4. 第3の習慣 最優先事項を優先する
  5. 第4の習慣 Win-Winを考える
  6. 第5の習慣 まず理解に徹し、そして理解される
  7. 第6の習慣 シナジーを創り出す
  8. 第7の習慣 刃を研ぐ

1が第一部、2〜4が第二部「私的成功」、5〜7が第三部「公的成功」、8が第四部「再新再生」という構成です。

それぞれの章では「7つの習慣」で書かれている習慣や原則を岩田さんの経験に基づく豊富な具体例・例えを用いて解説されており、抽象的で理解しにくい単語もわかりやすい単語に置き換えられているので、内容が非常に理解しやすかったです。

原作「7つの習慣」を読んで途中で挫折してしまった人やあまり理解できなかった人、いきなり原作を読むのは気が重いという人でもとっつきやすい内容です。

 

真に成功している人や組織は「7つの習慣」を実践している

成功している人や組織は意識しているかしていないかを問わず、「7つの習慣」を実践しているなと感じました。

ここでいう成功とは、単にお金をたくさん稼いでいるとか世界に名だたる大企業であるとかそういうことではありません。

言葉にするなら「自身だけでなく周囲の人や組織を幸福にするような人や組織」といったところでしょうか。

会社でいうなら売上やCS(顧客満足度)だけでなくES(従業員満足度)も高い会社のことです。

例えば、ソニックガーデンやスターバックス、ディズニーリゾート、未来工業などがそれに当たります。

これらの会社には下記のようなことが言えます。

  1. 社員一人ひとりが自分の行動に責任を持っている(=主体的である)。
  2. 明確なミッションやビジョンがある(=終わりを思い描くことから始める)。
  3. 社員の教育やコミュニケーションなど第二領域のタスク(重要度は高いが緊急度は低いタスク)に力を入れており、またマニュアルがない(=最優先事項を優先する)。
  4. 社員も顧客も満足度が高い(=Win-Winを考える)。
  5. 社員間や顧客との間に強い信頼関係がある(=まず理解に徹し、そして理解される)。
  6. 各々が異なる長所を持っており、弱いところを補い合っている(=シナジーを創り出す)。
  7. 各々が自身の現状に満足せず、常に己を磨き続けている(=刃を研ぐ)。

本記事では各習慣の説明を省いているため、「なんでこの習慣とその項目が結びつくの?」というところもありますが、そのあたりは本を読んでもらうと「なるほど」と実感してもらえると思います。

 

今の日本に必要なもの、それは「パラダイムシフト」

パラダイムシフトとは、パラダイム(ものの見方・捉え方)を変えることです。

以前、ソニックガーデンの倉貫さんがFacebookで下記のようなことをおっしゃっていました。 

上記の発言では、「今の日本社会は未だに高度成長期のパラダイムにとらわれており、そのパラダイムには限界がきている。そこから脱するためにはこれまでとは違う新しい価値観が必要だ」という趣旨のことが述べられています。

ここでの「新しい価値観」への移行のことこそ、パラダイムシフトのことだと思いました。

これからの日本は人口が減少していき、成長率の伸びには限界があることが目に見えています。

そんな状況に対して、日本に必要なのは「新しい価値観」への移行、パラダイムシフトなのではないかと思います。

 

同一にこだわるのはナンセンスである

これは「第6の習慣 シナジーを創り出す」での一節です。

これを読んだ時、なるほどなと思うと同時に日本の教育のことが頭に浮かびました。

日本の教育は過程・評価方法ともに画一的な方法をとりすぎだと思います。

例えば昨今話題になっている「プログラミング教育の必修化」です。

プログラミングはあくまで論理的思考を鍛えるための教育方法の手段の一つにすぎないと思っています。

それを画一的な指導・評価方法で教育することに疑問を感じます。

もっと各生徒各先生ごとの違いを尊重し、シナジーを生み出すような教育をしてほしいと思います。

個人的には漫画「暗殺教室」に出てくるE組のようなクラスが一つの理想だと考えています。

暗殺教室は非常に面白い漫画なので、ぜひ一度読んでみてください。

アニメ化もされているのでそちらもオススメです。

おわりに

以上、「チームリーダーのための7つの習慣」を読んで感じた事、思った事を書いてみました。

この記事を読んで「一度読んでみようかな」と思っていただければ幸いです。

ここまでお読みいただきありがとうございました。

あと今回は試しに本の内容はあまり書かず、自分が読んで感じた事、思った事をメインに書いてみたのですがどうだったでしょうか?

何かご意見・ご感想あればコメントもらえるとありがたいです。

関連書籍

岩田さんは他にも何冊も本を執筆しておられます。

どの本も役立つ内容が満載なので何冊かオススメの本を貼っておきます。

ぜひ一度、読んでみてください。 

ミッション 元スターバックスCEOが教える働く理由

ミッション 元スターバックスCEOが教える働く理由

 
「ついていきたい」と思われるリーダーになる51の考え方

「ついていきたい」と思われるリーダーになる51の考え方

 
「君にまかせたい」と言われる部下になる51の考え方

「君にまかせたい」と言われる部下になる51の考え方

 
スターバックスCEOだった私が社員に贈り続けた31の言葉 (中経の文庫)
 
スターバックスCEOだった私が伝えたいこれからの経営に必要な41のこと

スターバックスCEOだった私が伝えたいこれからの経営に必要な41のこと

 
ブランド 元スターバックスCEOが教える「自分ブランド」を築く48の心得

ブランド 元スターバックスCEOが教える「自分ブランド」を築く48の心得

 

 

仕事の基本が全くできていなかったので今後のために自分の行動を振り返ってみた

はじめに

皆さんこんにちは。

皆さんは仕事の質は高い方でしょうか?

また仕事のスピードは早い方でしょうか?

自分は以前から仕事の質が低く、スピードも並以下なのが悩みでした。

そんな時、ソニックガーデンの倉貫さんのブログで下記の3つの記事に出会いました。

kuranuki.sonicgarden.jp

これらの記事を読んだ結果、自分は技術スキルやコミュニケーションスキルを高める以前にそもそも仕事の基本が全くできていなかったことがわかりました。

そのため、今回は上記の倉貫さんの記事から仕事の基本を確認し、これまでの自分を振り返って見たいと思います。

 

この記事の目的

この記事では自分のような仕事の基本ができていないがために嫌な思い、苦しい思いをしている人を少しでも減らすため、仕事の基本を確認し、これまでの自分の何がいけなかったのかを確認します。

この記事を読むことで仕事力の向上につなげることができれば幸いです。

 

仕事の基本7つの当たり前

倉貫さんの記事では質とスピードを上げる仕事の基本7つの当たり前として下記を挙げられています。

  • 目的を確認して「そもそも」を考える
  • 「タスクばらし」をして見積もりをする
  • 他の仕事を含めて優先順位を整理する
  • 週単位と日毎でスケジューリングする
  • 仕事単位で見積もりの誤差を確認する
  • 適宜相談を兼ねたコミュニケーション
  • 定期的に「ふりかえり」して改善する

上から順に見ていきます。

目的を確認して「そもそも」を考える

仕事に取り掛かる前に、今からする仕事の目的は何なのか、そもそも何のためにその仕事をするのかを考える必要があります。

これをしておくと何がいいのかというと、重要性によるタスクの優先順位付けがしやすくなるということと、タスクの消化の際に無駄のないやり方、最短経路を選択することができることです。

これらのことにより、仕事全体の生産性を向上させることができます。

例えばドキュメントを作成する場合、目的が社員だけが見る備忘録の作成なら身内がわかりさえすればいいので文章の体裁を整えるというタスクは重要性が低く後回しまたは必要ないとわかります。

自分の場合、仕事の前に仕事の目的を確認するということができていなかったので、本来の目的とは関係ない作業をしてしまい、結果として全体の仕事量が増えてしまって残業が多くなってしまったり、優先して終わらせるべき作業が後回しになってしまったりしていました。

 

「タスクばらし」をして見積もりをする

この「タスクばらし」は7つの基本のうち、セルフマネジメントをする上で最も大事な、初歩のスキルです。

倉貫さんも「社会人1年目のうちに身につけておきたいスキル」だと述べられています。

「タスクばらし」とは仕事をタスクに分解することです。

具体的なやり方は下記の通りです。

  1. 仕事のゴールを確認し理解する
  2. ゴール達成のために必要な項目を順番にリストアップしていく

1でゴールを確認しておくことで、2でリストアップした際に不要なものは排除することができます。

また、ゴールをしっかりと理解しておかないとタスクに分解していくことができません。

2で分解する粒度は「時間」で考えます。

大体30〜45分、長くても1時間単位で分解します。

ここで「時間」で考えるには、タスクにかかる時間を見積もる必要があります。

見積もりは最初から正確である必要はありません。

経験を積み、修正を繰り返すことで次第に正確な見積もりができるようになるのです。

自分はこれまで事前にタスクにかかる時間の見積もりをせずにタスクに取り掛かっていたため、1つのタスクに大量の時間を費やしてしまっていました。

また、事前にタスクばらしをしていなかったため、詳細なタスクが把握できずとりかかるのが後回し後回しになってしまっていました。

例えば「コピーアプリを作成する」という仕事に対して、タスクばらしを行っていなかったため、そこに至るタスクが把握できず、結果いつまでも後回しにして手つかずの状態が続いてしまっていました。

 

他の仕事を含めて優先順位を整理する

優先順位をつけるには重要度と緊急度で判断します。

ここで重要なのは「7つの習慣」でいうところの第二領域(重要度高・緊急度低)のタスクにしっかりと時間を割くことです。

多くの人は第一領域(重要度高・緊急度高)や第三領域(重要度低・緊急度低)に時間をとられがちですが、第二領域のタスクをしっかりとやっておくことで第一領域や第三領域のタスクが発生するのを防止することができます。

例えば先に紹介した「タスクばらし」も第二領域のタスクです。

重要な作業ではありますが、今すぐやらなくとも仕事には取り掛かることができるからです。

しかし、タスクばらしをしていないとどうなるかは先に述べた通りです。

結果として第一領域や第三領域のタスクが増えてしまい、それらのタスクに忙殺されることになるのです。

自分もこれまで第二領域のタスクを疎かにしてしまい、第一領域や第三領域のタスクの消化に追われてしまっていました。

 

週単位と日毎でスケジューリングする

まず日曜の晩か月曜の朝に1週間の過ごし方をシミュレーションし、書き出します。

その後、毎朝もしくは前日の夜に1日の過ごし方を考えます。

倉貫さんのブログには書かれていませんが、1週間の過ごし方のシミュレーションはある程度ざっくりとしたものでいいと思います。

詳細なスケジュールは毎朝もしくは前日の夜に考えるからです。

こうして1週間及び1日のスケジュールを事前に立てておくことで、急な割り込み作業が入ったとしても修正をしやすいです。

自分は以前会社にいた際は、毎日スケジューリングをしていなかったのでいつも行き当たりばったりでした。

結果、急な割り込み作業が入るたびに慌ててしまっていました。

 

仕事単位で見積もりの誤差を確認する

見積もりの誤差を確認するにはタスクにかかった時間を計測することが必要です。

見積もりと計測時間を比較し、次回の見積もり時間を修正していきます。

こうして修正を繰り返していくことで見積もりの精度が上がっていくのです。

自分は現在、togglを使って時間を計測しています。

しかし、タスクばらしをしていなかったため粒度が大きすぎ、せっかく計測した時間をうまく活用できていませんでした。

時間を計測するだけでは意味がなく、タスクばらしをやって初めて計測した時間に意味が出てくるのです。

 

適宜相談を兼ねたコミュニケーション

日頃から相談を兼ねた雑談をすることで、いつでも気軽に相談できる関係性が構築されます。

日頃から周囲とのコミュニケーションを怠っていた自分は、以前の現場で困ったことがあっても中々相談できませんでした(現場が炎上していたということもありますが)。

 

定期的に「ふりかえり」して改善する

仕事の質とスピードを上げていくには定期的に仕事の仕方を見直す必要があります。

「ふりかえり」はK(Keep:良かったこと)P(Problem:悪かったこと)T(Try:次に試すこと)でやるのがオススメです。

一人でやるよりも、他人からのフィードバックを受けた方が効果的です。

詳しい進め方ややる上でのコツは下記を参照してください。

kuranuki.sonicgarden.jp

自分の場合は、ふりかえりをやってみたことは何度かあるのですが、同じ現場に同じ会社の先輩や同僚がいたことがほとんどなかったため、あまり効果的にすることができませんでした。

また、先の第一領域や第三領域のタスクで手一杯になってしまいふりかえりに時間を割くことができなかったこともありました。

どうしても同じ現場や会社にフィードバックをもらえる先輩や同僚がいなければ、勉強会を開いてそこでフィードバックをもらうといいかもしれません(まだ自分もやったことはないのですが…)。

 

終わりに

今回自分の行動を振り返ってみて、いかに自分の生産性が低かったかということを嫌という程思い知らされました。

今後は7つの基本をしっかりと身につけ、イケてない社会人を脱却し、仕事のできるプログラマーになれるよう日々精進していきます。

また、冒頭で紹介した倉貫さんの記事はどれも理解しやすく、非常に役に立つので社会人としての経験年数を問わずぜひ一度読んでみてください。

ここまでお読みいただきありがとうございました。

何かご意見・ご感想あればコメントもらえるとありがたいです。

岡田裕之さんの成幸プログラム公開講座に参加してみた Part2

はじめに

皆さんこんにちは。

今回も前回に引き続き、岡田裕之さんの無料公開セミナーに参加してきました。

今回のテーマは『相手が自分の本音に気づく「心の質問」』です。

講座についての詳細はこちら。

hiroyukiokada.com

内容と感想

コミュニケーションで重要なのは「伝える」ではなく「引き出す」

コミュニケーションで重要なこと、それは相手の本音を「引き出す」ことです。

これは営業やコンサルの例で考えると分かりやすいと思います。

よくある営業の手法として自社商品の特徴や導入するメリットばかりを伝える方法がありますよね。

でもあれではなかなか契約には結びつきません。

なぜなら相手がその商品を必要としていないからです。

そして必要としていないのは相手が問題と捉えていないからです。

できる営業は相手の本音、問題と捉えていること(話している時点で問題と捉えているとは限らない)を引き出します。

そしてそこから相手の問題を解決する提案を提示します。

だからできる営業は契約が取れるのです。

また一言付け加えておくと、ここでいうコミュニケーションは楽しく雑談をすることは除きます。

 

モノや出来事を抽象化すると信頼関係を築きやすい

相手の本音を引き出すには「質問」が必要です。

しかし質問がうまくいくためには相手と信頼関係を築けていなければなりません。

いきなり「あなたはなぜその商品を買いたいのですか?」と聞いても、信頼関係が築けていない人相手に本音を言おうとは誰も思いませんよね。

この信頼関係を築くためには相手の話を受け止めようという姿勢が必要です。

そしてそのためには高い視点を持つこと、つまりモノや出来事を抽象化して考えることが大切です。

なぜ抽象化して考えることが大切なのか。

それは抽象化して考えることであらゆることが「想定内」になるからです。

相手の本音を聞くために質問するのですから、相手がどうくるかわからないという前提で、全てを受け止めることが重要なわけです。

一方でまずいパターンとしては下記のようなものがあります。

  • せっかく出た相手の答えを、自らはねのけてしまう
  • 相手の意見に、「そのまんま反応」してしまう(同じ抽象レベルで話してしまう)

1つ目は何かの相談をしている時を思い浮かべると分かりやすいと思います。

相談している時に自分の考えを述べてそれを頭から否定されてしまうと、信頼関係が崩れて相手の意見を聞く気が無くなってしまいますよね。

2つ目は、例えば「筋力トレーニングの方法を知りたい」という問題に対して筋力トレーニングのことだけを考えてしまうようなことです。

ここでより抽象化できていれば、もっと相手の本音に沿った解決策を提示できます。

「筋力トレーニング」を「ダイエット方法」に抽象化できていれば、もっと効果的なダイエット方法、例えば有酸素運動やスタジオのプログラムを提案できます。

セミナーでは抽象化の練習としてモノや出来事の上位概念を考えるワークを行いました。

例えば、飴なら「飴→お菓子→気配り」、動画鑑賞なら「動画鑑賞→コミュニケーション→楽しみ」といった具合です。

 

質問はまずクローズド質問でジャブを打ってからオープン質問で本音を引き出す

質問にはイエスかノーかで答えられるクローズド質問と相手が質問に対して自由に答えられるオープン質問があります。

オープン質問では相手がどんなことをしたいか、どんなきっかけだったのか、どんな思いや意味を持っているのか、そこから何が得られるのか、何を求めているのかを引き出します。

本音を引き出すにはオープン質問なのですが、いきなりだと相手にストレスがかかってしまうため、まずは比較的簡単に答えやすいクローズド質問をうまく活用して、事前に会話のエンジンをかけておく必要があります。

 

自分が欲していたスキルの一つが今回の「心の質問」だった

自分は今後、ソニックガーデンという会社で働きたいと考えています。

そこでは必要な能力の一つとしてホスピタリティーが挙げられています。

現在の自分のスキルで一番ネックに感じているのがこのホスピタリティーです。

www.sonicgarden.jp

ホスピタリティーの内訳としては以下のとおりです。

  • 困っている課題の本質を引き出す問いをする
  • 複雑な現状と課題を抽象化・整理して理解する
  • 抱える課題を解決する方法を論理的に説明する
  • 解決した後の具体的な状態を絵にして共有する
  • 話し合いが脇道にそれないよう上手に進行する

今回のセミナーでわかったコミュニケーションでの最終的な目標は「自分も相手も気付いていなかった真の目的を発見し創造する」ことです。

これは上記の1点目に合致します。

また、モノや出来事を抽象化して捉える能力は2点目に合致します。

今までどうすれば身につくのかわからずにいたので、今回のセミナーを受けて少しスッキリしました。

しかし本格的に身につけるとなると、いわゆる「本科」といわれるコースを受講しないといけないのですが、受講料が30万円弱と決して安い買い物ではないのでどうするか非常に迷っています。

 

終わりに

今回のテーマは自分が本当に知りたかったテーマの1つだったので非常に有意義でした。

次回のテーマは『誰よりも伝わる「心の言葉」』で12/18(日)の14:00〜16:30にあります。

まだ受付中なので興味のある方、時間のある方は是非受けてみてください。

ここまでお読みいただきありがとうございました。

何かご意見・ご感想あればコメントもらえるとありがたいです。

話し方教室「TALK&トーク」の授業を受けた振り返りと感想 Part7・8

参加の経緯

以前のブログをご参照ください。

sanfrecce-osaka.hateblo.jp

参加目的

  • コミュニケーション力の向上

授業内容

TALK&トークのHPより引用。

www.e-0874.net

第2回

仕事がデキる人の質問のセンス

「お花見に行ってきた」という相手に、いつ・どこへ・誰と・といった質問だけではもったいない。「写真もたくさん撮りました?」「お酒も呑みながらですか?」のように相手自身の人柄にアプローチする質問ができると、とたんに相手との距離は縮まる。ビジネスで人脈を作る、初対面の人と親しくなる、エレベーターなどでのちょっとした会話がふくらむ力。もちろん婚活や一般的な雑談でも大活躍の質問力。

第4回

初対面の人の気持ちをつかむ

デキるビジネスマンは第一印象が違います。好印象だからすぐに関係を築くことができ、誘われ、紹介が増え、人脈が広がります。会った瞬間「感じがいい!」と思う人には、向こうから挨拶してくれて話しかけて来るようになるから人付き合いも楽に。ビジネスにとどまらず、友人・知人・恋人など人と信頼関係を創るスピードが驚くほど早くなります。

 

上記の通りです。

授業の要点

第2回

  • オウム返しを使うのは気持ちが大きく動いたとき。
  • オウム返しは、短い言葉を返すのが鉄則。
  • 5W1Hの質問だけだと相手の答えが単語になりがちで、会話が盛り上がりにくくなる。
    • いい質問とは相手のエピソード(何がどうなってどんなことを思ったりしたりしたよ、という話)を引き出す質問。
  • 頭の中で、相手の話の絵を思い浮かべることでいい質問につながる。
    • 想像した絵の中に出てくるものや人物について質問する。
  • 質問とは、話し手が実際に体験したものと聞き手が想像したことをすり合わせる作業のこと。
  • 目を向けるのは話題そのものではなく、その話をしている『相手その人自身』。

第4回

  • 人とつながる力のある人は、利益関係にない人にも自分から声をかけ、相手を温かな気持ちにさせ、あっという間にいい関係を築き上げる人。
  • 挨拶するだけでなく、その時にどんな気持ちを送っているかが人付き合いをわける。
  • 挨拶とは自分の優しい気持ちを伝えるためのもの。
  • みんな拒絶が怖い。人は誰でも相手の人から受け容れてもらいたいと願っている。
  • 「あなたは私の大切なメンバー(仲間)です」と伝わって初めて挨拶。
  • 誰もが持つ拒絶への不安をお互いに打ち消すために挨拶がある。
  • 感じのいい人から出ているものは、「受け容れますよ」「安心してください」という受容の気持ち。
  • 誰もが持っている「拒絶に対する恐れ」を取り払うコミュニケーションができる人は、ほとんどの人と、すぐにいい関係が築ける。
  • うちとけ力はアイコンタクト、声のトーン、表情、体の向きの4つから生まれる。
    • アイコンタクトとは自分の瞳と相手の瞳を合わせること。
    • アイコンタクトは「大事なメッセージがあります」というサイン。長すぎてもダメ。一度アイコンタクトをとったら相手の瞳からピントを外す。
    • 声のトーンは高く明るく。
    • 表情は明るく。目が合って、明るい声が出せれば、自然と表情が明るくなる。
    • 体の向きは相手の方を向く。
  • ただ言葉だけの挨拶には意味がない。

 

Keep(実施してよかった事、引き続きやってみようという事)

  • 聞き手に回った際のコミュニケーションで講師からお褒めの言葉をいただき、自信になった(話題が自分の得意分野だったこともあるが)。
  • 今まで自分から周囲を拒絶するような雰囲気を出していたことに気づくことができた。

Problem(上手くいかなかった事、問題と感じた事)

  • 今回受講していたのは雑談メインのコースだったので、「相手の潜在ニーズやミッション・ビジョンを聞き出す質問力」に関しては学ぶことができなかった。

Try(この次にやってみたい事)

  • 岡田裕之さんの成幸プログラム公開講座の第2回を受講する。

hiroyukiokada.com

感想

今回はコース2、聴き方コースの2回目及び4回目の授業でした。

2回目では講師の梶村先生から「楽しそうに聞いていていいですね。相手も話しやすかったのではないかと思います。」とお褒めの言葉をいただき、少し自信になりました。

ただ、褒められた際の話題が自分の得意分野であったこと(パソコンの話題)、まだ質問に詰まってしまう場面があったことから、まだまだ練習が必要だと感じました。

4回目では自分のこれまでの挨拶のダメなところ、それが引き起こしている人間関係上の不都合がわかりました。

今後は挨拶やアイコンタクトを、しっかり気持ちを乗せて行っていきます。

今回で全8回の授業をすべて受け終わりましたが、雑談での話し方・聴き方がメインだったので、今後目標としている会社で仕事をする上で必要になるであろう能力、「相手の潜在ニーズやミッション・ビジョンを聞き出す質問力」を身につけることはできませんでした。

潜在ニーズとは下記リンクで書かれているように「見込みが口にした問題や不満のこと」です。

ventry.jp

目標としている会社では、顧客のビジョンやミッション、業務内容等をしっかりと理解した上で、潜在ニーズが何かを引き出し、システムに本当に必要な機能、優先度の高い機能は何かを見定め、提案する能力が必要であると考えています。

次回参加する岡田裕之さんの成幸プログラム公開講座で、上記の質問力を身につけられればと思っています。

 

最後に

ここまで読んでいただきありがとうございました。

何かご意見・ご感想あればコメントください。