diff --git a/Appendix-Note/beginning-story.adoc b/Appendix-Note/beginning-story.adoc
index fb71ad564..2591c83e7 100644
--- a/Appendix-Note/beginning-story.adoc
+++ b/Appendix-Note/beginning-story.adoc
@@ -134,7 +134,7 @@ http://azu.github.io/slide/udonjs/github-issue.html[一人で使えるGithub Iss
 自分もiPhone等のモバイル端末から直接Github Issueを立てられるようにして一文字のtypoのIssue等を大量に立ててチェックしていきました。
 
 HTMLで見られるようにするとモバイルでも十分文章のレビューは出来るので、
-作って置いたIssueをTiDD(チケット駆動開発)の要領で処理していくと文章の修正もやりやすかったです。
+作って置いたIssueをTiDD(チケット駆動開発)の要領で処理していくと文章の修正もテンポよく進められました。
 
 ここでもGithub Issueを活用していましたが、typoのような小さな修正と新規セクションを書くような大きな変更では、
 使い方の違いがでてきた気がします。
@@ -142,5 +142,7 @@ HTMLで見られるようにするとモバイルでも十分文章のレビュ
 どちらもブランチを切ってコミットする所までは同じですが、
 小さな修正はコミットメッセージに `fix #108` というように書いてマージするだけで、わざわざpull-requestはしてませんでした。
 
-大きな修正はpull-requestを作って、そのpull-reqeust単位でもう一度確認することで、
-ミスが少なくなっていた気がします。
\ No newline at end of file
+逆に大きな修正はpull-requestを使って進めることで、
+マージする前にもう一度確認しやすかったりやTravis CIによる自動テストが走るため、
+ミスが減った気がします。
+