ソフトウェア開発現場の生産性向上＠de:code2017で感じたこと
5/23・24でMicrosoftの開発者カンファレンスのde:code 2017に参加しました。目的はもちろん最新技術動向の把握にあるのですが、それと合わせてDevOpsとその言葉の裏にある「ソフトウェア開発の生産性向上」が裏テーマです。今回は、私が聞いて感じたことと日々感じていることと合わせて書いていこうと思いました。所属組織は関係なく個人的な意見ですのであしからず。
私が参加したDevOps系(生産性向上)のセッションは下記です。
- DO08 『変わらない開発現場』を変えていくために〜エンプラ系レガシーSIerのためのDevOps再入門(MS赤間信幸さん)
- SP05 日本企業の生産性を根本から改善する8つの習慣とその事例(Rochelle Koppさん & 米MS 牛尾剛さん)
- DO09 獲れたてOSS × DevOps！自動化三昧を満喫セヨ(米MS牛尾剛さん)
米 VS 日 の生産性
まず、当たり前すぎるのですが、「仕事の総量 = 仕事の生産性 × 時間」(#DO08より)です。より多くの仕事をこなすには、時間を増やすか仕事の生産性を上げるかの 2択しかないわけです。昨今、世の中の働き方改革という名のもとで、残業禁止となり時間を増やすことが難しい現状になっています。では、同じ総量で早く帰らないといけない場合には、生産性を上げなければいけないわけです。改めて言われるとその通りと納得せざるを得ないです。
「アメリカと日本の生産性を比較すると100：62」(#SP05より)だそうです。そりゃ日本人が定時で帰れないわけです。では日本人は生産性が低いのか。日本は重要なこと以外に時間をかけすぎている、米国は本当に自分が付加価値を出せること以外にのみ集中するからそもそもの物量が違う、日本は5つに対して優先度を決めて4つぐらいまでやろうとする、米国では最優先の1つのみやる、だから生産性が低いように見える、重要な1に8割の価値があるから尚更そう見える、個人のパフォーマンスが一概に低いからだけではない、牛尾さんのセッションではそうおっしゃってました。
確かに物量は多い。現場では作業に追われているのが日常で、無駄な作業が多いように私も感じています。生産性向上の前に総量の削減が必要。概ねこの意見には賛同です。ただ1点、一見無駄なことなのかもしれないけれど、そこをやる日本の良さもあるのではないかと思う。勤勉に几帳面にやっていくその通り良さは必ずあるはず。作業量は減らすけれどその点忘れないようにしていきたいな。
個人のパフォーマンス
個人のパフォーマンスについては、米国のレベルを肌で感じたことがないので正直わからないのですが、現場を見ていてパフォーマンスが良いとは感じない。もちろんすごい方とも沢山出会ってきましたが、全体的なレベルを見ると心もとない感じがします。現場でアーキテクトとしてコードの品質チェックしていますが、どちらかというと不安になるレベルの方が多いです。
私個人としてはプログラマは高い専門性が求められる職業であると思っています。Rochelleさんもプログラマが他の業務にジョブローテーションされるのはおかしいと言い切ってました。私はこの点について、大学での教育(専門的な教育)と企業の採用(誰でもSEになれる風潮)に疑問を持ってます。この点について個人として出来ることは限られるので、現場にいるメンバでなんとかするしかないのが現状で、チーム全体の底上げをどうするかを現場レベルから考えないといけないです。
SIerのアーキテクトの役割
赤間さんのセッションでの、「開発技術の進化があれば、その恩恵により開発生産性をは改善されるはず」というのは私が日々思っていることを本当に代弁してくれたような言葉でした。SI業界にまだ10年ほどしか関わってませんが、開発のやり方は全く変わってません。これは、SIerとして反省すべき点だと思いました。もちろん個人としては色々なツールの導入や工夫をしてますが、組織全体として変わってきたかと言われればほぼ変わっていない。また、それに対して何も疑問に感じていないというのはいかがなものか。「日本のSI商習慣(多重請負構造)が問題」「SIerのプロパーが最新技術を知らない」(#DO08より)というのは実に的を得ている。アーキテクトは現場を改善していく責務があると再認識しました。
最新技術の恩恵をどう受けるのか
ソフトウェア開発のプラクティスとしてDevOpsが叫ばれていますが、日本にそのまま当てはまるとは個人的には思っていない。
Rochelleさん&牛尾さんは、DevOpsを適用するためには、欧米文化をインストールしていけば良いとはというアプローチ(8つの習慣)で、出来るところからチームで初めていくことを勧められていました。赤間さんは、DevOpsを支える色々な要素を取捨しながら取り込んでいけば良いとおっしゃっていました。やはり現場レベルから改善を繰り返していき少しずつ生産性を高める必要性があります。
その際に様々な開発技術の恩恵をいち早く受けるためには、「自動化しなくて済むようにする」つまり「巨人の肩に乗る」(#DO09より)という考え方も大切だと思いました。一生懸命仕組みを考えるというより、今の時代は「レールに素直に乗せて上げること」がアーキテクトの役割の1つなのかもしれないなと感じました。
牛尾さんのスライドです。
さいごに
いろいろ書きました(あまりまとまっていないかもしれませんが・・・)が、DevOpsというのは手段の1つであり、導入する目的を考えないといけないことを再認識しました。今回de:codeに参加して、ソフトウェア開発の生産性向上をしたいと改めて思いましたし、出来ることから1つずつやっていき、理想形に近づけていくという地道なアプローチしかないこともわかりました。
使えるものは使っていく、VSTSやAzureなどは素晴らしいのでバンバン使っていきたいと思いました。使えるように説得するところからスタートかもしれませんが笑
