: 2.文件文化
: 如同上一段「Software Engineer v.s Programmer」所述，文件在日本傳統軟體公司扮演
: 著重要的角色，以前端工程舉例，日本傳統軟體公司會要求Software Engineer把畫面的
: 每個UI components都列出來，甚至每個component要傳什麼properties也要詳列，寫完之
: 後再經過一層一層的approve後才能開始開發，這對於工程師來說，是很無聊的一件事，
: 在台灣的時候通常都會先討論、設計出個大方向後，就會開始做，然後再慢慢優化，而在
: 日本傳統軟體公司的mindset，比較相信只要把文件寫到完美，就沒有什麼難的事情了，
: 但因為軟體開發沒有辦法事先就確定每個小細節，文件導向的結果就是 ：
: 花了大把時間規劃後->get approval -> 發現不可行需要大更動->再改文件->再 get
: approval…由此拖慢了迭代速度。
: 3.開會文化
: 開會也是日本傳統軟體公司很重要的一環，因為那是很好刷存在感的場合，你開越多的會
: 、給人感覺就是做越多的事情。開會大部分是用來討論需求及上述技術文件，而這些會常
: 常會遇到的兩個問題，一個是開會的人數很多、卻只有兩三個人在講話，另一個是日本人
: 似乎不擅長再開會場合做決定，很少會聽到有人說：「好，那我們xxx就決定這樣做了」
: ，比較常聽到的是「xxx這樣似乎比較好」「好，不然我們大家回去想一下，三天後我們
: 再來開一次會」，我覺得這跟文化有很大的關係，也可以從日文這個語言窺知一二。
: 所以就「產品迭代速度緩慢」來說，我覺得日本IT公司需要：
: 願意 take ownership 做決定 、改變現狀的人才
感謝大大分享
在此小弟說明一下有關日本人的開會文化
日本人有一個非常關鍵的民族性，就是群體形式
就是說你活在社會上一定要跟隨著群體
具現化到生活上，
1. 大家都在排隊所以我也來排隊
2. 大家都在欺負某個人所以我也只好欺負他 (霸凌)
3. 開會需要大家來討論 (即便有沒有你參加根本沒差)
就能夠十分了解這個民族性對他們的生活產生的影響。
在管理學上，群體語言有個很大的盲點叫作風險分散
會議決定了什麼，但結果不佳：
這個會議是大家一起決定的喔~ 不是我自己決定的
最後出包大家都有責任啦!!
會議最後什麼都沒決定：
因為大家都不同意阿，議而不決大家都有責任啦!!
假設會議有10個人參加，每個人分到的責任看起來就變成1/10
有100個人參加就看起來會被稀釋成1/100
有沒有看起來很熟悉~~
這也是民主社會共有的通病之一
然後咧，大家都去開會，
開會又沒效率，在那邊浪費時間，
等到你可以作自己的工作時，早就接近下班時間了
日本人的加班就是這麼產生的。
如果你們公司有類似情形的，
不妨給管理者看看下列馬斯克的文章
https://www.cw.com.tw/article/article.action?id=5089415
— 過多會議是大企業的禍害，而且會議似乎只會隨時間愈來愈多。除非你確定你有提供
有價值的意見，否則請擺脫所有大型會議。就算你的意見有價值，也請簡明扼要。
—也請你擺脫頻率太高的會議，除非你應對的是極度緊急的議題。緊急問題解決後，會議
頻率就該驟減。
—如果你無法為會議加值，走出會議室，或減少講電話的時間。離開並不會顯得沒禮貌，
硬把人留下、浪費他的時間才是粗魯的事。
最後回到原波第二點的文件文化，
其實也是相同的狀況，
因為上面有很多人蓋過章get approve，
表示他們都同意，所以有問題他們都要負責喔~~
為了讓責任稀釋到最低，自然就需要更多的橡皮圖章囉。
以上，為身在日企的感想文