- On 2016-06-27
- For OSS Japan on Facebook
- By 藤原 由来
藤原 由来(@sky_y)と申します。文書変換ツールPandocの普及活動を中心に行っております。
初見での失礼を承知で、数点コメントさせてください。
- ITエンジニア？
- 事務職？
- 管理職？
- 社内全体？
- 取引先？
- ステークホルダーも含めた業界全体？
- 特に、ビジネスフローとITシステムの主従関係に着目するべき。
- A. 主：ビジネスフロー、従：ITシステム → 米国で主流
- B. 主：ITシステム、従：ビジネスフロー → 日本で主流
- 米国でERPやクラウドが上手くいっているのは、ビジネスフローが標準化されているから。
- 日本でそれらが上手くいかないのは、ビジネスフローが各々の会社に最適化されすぎているから。
- 結果として日本のSIerは、ITシステムの方を、ビジネスフローにカスタマイズ・チューニングせざるを得ない状況が続いている。
- ざっくり言えば、Webサービス会社の取りやすい戦略。
- 長尾さんのおっしゃる「生産性」は、正確にはこの領域だと私は解釈しました。しかしそれは、あくまでも「チームの規模が十分小さく、かつチームメンバー全員のスキルが十分高い」という条件下のみで成り立つというのが、私の見解です（要議論）
- ツールについては、皆様ご存じだと思うので、省略します。
- ざっくり言えば、大手SIerが取りやすい戦略。
- この場合、個人のこだわりを一方的に押しつけることは、大抵は悪手である。
- こだわりを押しつけるなら、合理的な根拠が必要である。
- このスレッドにいらっしゃる方は、かなり技術スキルが高いと想定するべき。
- 一般のSIerにおける「システムエンジニア」技術レベルは、おそらく相当低いことを仮定した方がよい。
- Gitを習得させる前に、まずコマンドラインの習得が困難である、という仮定が妥当。
- 「プログラマ」の技術レベルは幾分ましであると思われる。かなり下の下請けであれば、上記3.の「小規模チーム戦略」を取りやすい。
- 一般のSIerにおける「システムエンジニア」技術レベルは、おそらく相当低いことを仮定した方がよい。
- チーム内で意思疎通が密にできる関係性であれば、ツールの選択肢は増やせる。
- 上記3.の戦略が取りやすくなる。
- チーム内で意思疎通が困難である状況であれば、できるだけ"チーム内通信"が事態が発生しないように、注意深くツールを選択する。
- 例えば後者の場合、会社でプリインストールされているツール(MS Office, Outlookなど)を優先する方がうまくいく。開発環境もVisual Studio(C#)のように、公式ドキュメントが充実しているものが望ましい。以上から、事実上、作業用クライアントとして採用されるOSは、Windows(or Web系OSSが強ければMac)になりがち。この文脈では、デスクトップLinuxは論外である。
- ……という前提で、OSSはどれだけこの領域に入り込めるか？という議論をすべき。
- OECD の定義: 賃金÷労働時間
- 注意：これは雇用主の視点。賃金は会社にとって費用の一部である。
- 「賃金」は、もう少し抽象化して「コスト」と言い換えられる。
- 損益計算書(P/L)の基本式: 利益＝収益－費用
- 会計レベルでは、正確に「費用の削減」「収益の増加」のいずれかが、従業員の同一パフォーマンスで実現できれば「効率性が上がった」と言える。
- 会計よりも広く言えば、「見えないコスト」もコストの勘定に入れるべき。特に、人間の脳に対する「認知コスト(cognitive cost)」が重要である。
- 例1: 実務経験がほとんどない一般的な文系エンジニアが、コマンドライン(コマンドプロンプト/Unixシェル)を習得するには、かなりの労力と時間を要する。
- このことを、「コマンドラインの習得にはかなりの認知コストを要する」と言う。
- 例2: AtomとVimを比べると、Vimの方がAtomよりも、習得のための認知コストが圧倒的に大きい。
- 参考: The Cognitive Cost of Doing Things http://lifehacker.com/5798202/the-cognitive-cost-of-doing-things
- OSSに慣れている我々にとって、比較的最近に現れたコマンドラインツール(AWS, Docker, 各種パッケージマネージャなど)を新たに習得するのが容易なのは当たり前の話である。なぜなら「コマンドライン事態の概念の習得」「Unixコマンド一通りの知識の習得」という、多大な認知コストを要する通過儀礼を既に過ぎているから。
- しかし、文系エンジニアにとっては、コマンドラインツールの習得は容易ではない。その習得のための認知コストが多大であり、十分問題になる。
- この観点は、「個人レベルの生産性が高いエンジニア」ほど見落としがちであるので注意すべき。それはチームの規模を拡大したときに、初めて「生産性の壁」として現れる。
- 例1: 実務経験がほとんどない一般的な文系エンジニアが、コマンドライン(コマンドプロンプト/Unixシェル)を習得するには、かなりの労力と時間を要する。
思いついたことは以上です。雑多なコメント、大変失礼を承知で書かせていただきました。
コメントについては、
- 上記の各論に対するコメントは、このgistのコメント欄へ
- 上記を越える総論については、OSS Japanにおける長尾さんのスレッドへ
お願いします。
藤原 由来 (@sky_y)
池田です。
2-1. 「日本でそれらが上手くいかないのは、ビジネスフローが各々の会社に最適化されすぎているから。」
と言うのも、経営層や現場が、各々の会社の大したこともないビジネスフローに固執しているのが問題だと思います。
数十の生産管理システムに関わってた過去がありますが、、だいたいの顧客企業が、自社独特と言うのは、世の中に
おいては、独特でもなんでもない、ちょっとしたオプションで済むことばかりでしたので。。
実際、会計や給与計算などは、既にパッケージソフトで、日本でも済んでますから、個別開発を極力さけて、
プログラムコーディングを、顧客案件でのシステム構築では行わないのが良いと思います。
大元のパッケージ、OSS の大元に対してのコードを寄付するなどの方向、もしくは、汎用的に使えるアドイン開発など
の方向に、優秀な技術者は向かったほうが生産的だと思ってます。