SSブログ
ソフトウェア開発組織が持つべきカルチャー ブログトップ
前の10件 | -

ソフトウェア開発組織が持つべきカルチャー(17) [ソフトウェア開発組織が持つべきカルチャー]

コードカバレッジを品質基準としない

API設計の基礎」の3.8節「コードカバレッジと防御的プログラミング」では、次のように述べています。
テストコードによるコードカバレッジは、そのソフトウェアの品質を担保しません。コードカバレッジが100%だから、品質が高いとは限りません。バグがあるコードでも、テストでコードカバレッジを100%にすることはできます。
ある機能を持つモジュールを開発する場合、そのモジュールのAPI設計が重要になります。APIの仕様には機能や使い方はもちろんのこと、不正なパラメータの場合の振る舞いが記述されていなければなりません(参考:「API設計の基礎」)。

そして、テストコードとしては、その仕様を検査するテストを書くことになります。①適切なAPI仕様、②それに基づく適切なテスト、そして実装です。実装がテストに合格したら、コードカバレッジを計測するわけです。コードカバレッジでは、コードの実行割合ではなく、実際に実行されたコードがどの行で、どの行が実行されていないかを見る必要があります。もし、実行されていないコードがあれば、その理由を考えます。テストが不足しているのであればテストを追加しますし、不必要なコードを書いていればコードを削除するかもしれません。あるいは、防御的プログラミングのために実行されないコードなら、そのままにしておくかもしれません。

このような開発では、①の「適切なAPI仕様」が記述されているかが、まずは重要です。私自身は、多くのAPIのレビューをしてきましたが、適切にAPIを定義できないエンジニアが多いです。ソフトウェアの経験年数が浅いためにできない人もいれば、ソフトウェアの経験年数が長くてもできない人もいます。この①ができていなければ、コードカバレッジは無意味です。残念ながら①の品質を静的に解析できるツールはありません。経験を積んだスキルの高いエンジニアにレビューしてもらうしかないのです。

②の「適切なテスト」では、仕様通りであるかに加えて、入力パラメータの組み合わせが網羅されているかも重要です。不正なパラメータの検査、境界値分析、同値分割などを適切に取り入れる必要があります。①がきちんとされてない場合、②のテストは正常なケースだけだったり、テスト範囲が狭かったりします。不適切なテストを実行した結果のコードカバレッジも、再び無意味です。したがって、ソフトウェアエンジニアは、テスト設計に関する技法もきちんと学ぶ必要があります。

コードカバレッジの数値が、ソフトウェアの品質を担保するわけではありません。しかし、①と②は静的に測定するのが困難なので、コードカバレッジの数値を単体テストの品質基準にしてしまっているソフトウェア開発組織が多くあるのではないでしょうか。たとえば、80パーセント以上のコードカバレッジをもって単体テストを完了とするとかです。そして、その数値だけが一人歩きを始めます。つまり、開発者や組織が、その数値をクリアするという視点だけで活動してしまうのです。極端な場合には、ソースコードを解析して、高いコードカバレッジとなるテストコードを生成する有償ツールを使って目標値を達成することまで行われたりします(もちろん、品質は向上しません)。結果として、①の「適切なAPI」を定義できなくて、②の「適切なテスト」を設計できないソフトウェアエンジニアを大量生産してしまいます。

残念ながら、コードカバレッジの数値目標を長年追っているようなソフトウェア開発組織では、①や②をきちんと行えるソフトウェアエンジニアが少なく、あるいはいなかったりして、①や②をきちんとレビューするという品質向上の活動ができなくなったりしています。

ソフトウェア開発組織が持つべきカルチャー(16) [ソフトウェア開発組織が持つべきカルチャー]

ソフトウェア開発組織に適切なマネージャを割り当てる

「ソフトウェア開発組織が持つべきカルチャー(まとめ)」を掲載してから2年が経過しました。

ソフトウェアエンジニアにとって、その組織で働き続けるモチベーションをもたらす要因は、時代の先端を行くソフトウェア開発だったり、誰と一緒にソフトウェア開発をするかだったりとさまざまな理由があるかと思います。

私自身は、幸運なことに20代、30代、40代と時代の先端を行くソフトウェア開発に従事し、楽しかったことも多かったです。しかし、一方で、モチベーションを下げる要因も色々とありました。その要因の中で最も大きいのは、「ソフトウェア開発の経験がない人が上司」、もしくは、「経験が数年しかない人が上司」というものです。ひどい状況になると、若手のソフトウェアエンジニア達の前で「ソフトウェア開発は給与が安い若い人がやればよい」という発言をするマネージャがいたりします(いました)。

ソフトウェア開発を一生の仕事をとして取り組みたいと思っている若手のソフトウェアエンジニアが属する組織に、間違ったマネージャを割り当てるのは、長期的にその組織が致命的な悪循環に陥る可能性があります。どういうことかと言うと、成長してきた若手のエンジニアが、さらに成長して中堅として若手を指導する立場になる前に、その組織(会社)を離れていってしまうのです。そのような転職が続くと、マネージャとして適切な人材が組織(会社)に残らなくなって、結果としてソフトウェア開発経験がない人がソフトウェア開発組織のマネージャとなり、悪循環を加速してしまうのです。

私自身は、「ミッションステートメント」で述べているように「技術者の育成も重要であり、次世代を担う技術者の育成も続ける」ということで、2000年からJava研修、2016年からのGo研修を続けています。これらの研修は、ソフトウェアエンジニアの基礎体力として一つの言語をきちんと学んでもらうと同時に、バイブル本を通した技術の学び方を学んでもらうことです。おそらく、一人でバイブル本を読破して練習問題まで解いていくというのは、かなり難しいです。それを研修として取り組んでもらい、研修の日には他の受講生の質問も含めて議論したり、プログラミングの解答を見たり、そして懇親会で話をすることで続けられるのです(さらに、プライベートの時間に予習するために、家族の理解も必要です)。

私の研修の修了生には、富士ゼロックス情報システム社の頃からも含めて転職している人もいますし、転職せずに働き続けている人も多いです。もし、研修の修了生の転職率が高いとしたら、それは、研修が「原因」ではなく、さまざまな転職理由があるはずです。ただ、成長し続けるソフトウェアエンジニアが属する組織に、不適切な上司(マネージャ)を割り当てることが、「高い転職率という結果」をもたらすことは間違いないと思います。

ソフトウェア開発組織では、不適切なマネージャを割り当てないように注意しなければなりません。

ソフトウェア開発組織が持つべきカルチャー(まとめ) [ソフトウェア開発組織が持つべきカルチャー]

2011年に主に書いた「ソフトウェア開発組織が持つべきカルチャー」を表にしてみました。評価列は、みなさんの組織ではどうかを振り返って記入してみてください。

ソフトウェア開発組織が持つカルチャーが、個々のソフトウェアエンジニアに大きな影響を与えるということで、一連の記事を書きますとした「まえがき」に相当するのが次の記事です。





スポンサーリンク





ソフトウェア開発組織が持つべきカルチャー 015 [ソフトウェア開発組織が持つべきカルチャー]

1つの言語をきちんと学ばせる


長年行っているJava研修は、「Java研修の目的」でも書いたように、その目的の1つは、言語をきちんと学ぶことです。その言語として、Javaを選択していることになります。しかし、新卒新人で入社して従事するプログラミング言語には様々なものがあります。

多くの開発組織では、言語教育が表面的なものだったり、きちんと学習させることがなかったりします。言い換えると、開発者個人に任せていることが多いのではないでしょうか。実際、私自身も振り返ってみると、社会人となってからの言語学習は、すべてが独学です。そのため、その独学で身に付いてしまった変な癖を直すには、長い時間を要しています。

1つの言語をきちんと組織として学ばせることは(特に若い段階で)、非常に重要です。特に、開発に使用しているプログラミング言語をきちんと学ばせることは重要です。ある時期、Rubyで開発(実際にはJRubyを使用)することにしたある開発では、私も含めて、担当する開発達と一緒に、きちんとした言語の本を全員で読むということを行ったこともあります。また、C++で開発していた60名規模のある開発組織では、新卒新人には『C++ プライマー第4版』を先輩が指導する形式で本1冊を学習させていました(私は全くその教育には関与していませんでしたが)。

1つの言語をきちんと学ばせた後は、さらに新たな言語の学習は、本人の責任でよいと思います。
コメント(0) 

ソフトウェア開発組織が持つべきカルチャー 014 [ソフトウェア開発組織が持つべきカルチャー]

知識教育だけではなく、良い行動パターンを促進する

技術の伝承と良い習慣の伝承」とも関連しますが、日本の企業でソフトウェア技術教育(特に新卒新人の技術教育)を担当している部門やグループは、何を教えたかということで教育体系をまとめようとする傾向があると思います。しかし、個々の教育コースの内容を見ると浅かったりします。

ソフトウェア技術というのは、毎年新しいものが登場し続けますので、すべてを教育コースで教えることはできません。そのため、ソフトウェアエンジニアに身に付けてもらうことは、知識だけではなく、継続して自発的に学び続けるということです。

たとえば、2000年から行っている「プログラミング言語Java教育」は、単にJava言語の知識を学ぶというだけではなく、膨大な自分の時間を使って専門書をきちんと学習する習慣を身に付けてもらうことも目的としてあります。実際、一年間の最後の成果発表会では、「学習する習慣が身に付きました」と発表する人も多いです。

まともに書籍を読むことなく、いつもネットで調べるだけということでは、非常に偏った学習方法となります。私自身が1998年からずっと継続してい行っている朝の専門書の勉強会も、継続して学習するという習慣付けを身に付けてもらうことも目的としています。英語の書籍による勉強会は、知識を吸収するだけでなく、英語で技術書を読むことに抵抗感を無くして、英語で専門を読むようになってもらうためです。また、最低限知っていて欲しいと思う「コンピュータの基礎知識」を学んでおいてもらう必要があるために、いくつかの専門書を用いた勉強会を開催してきました。

コードをレビューするというのは、読みやすいコードを書くということを常に意識してプログラミングする習慣を身に付けてもらうことも目的としてあります。

ソフトウェア開発組織のレベルを上げるには、教育体系を整備するだけではなく、好ましい行動パターンを促進する施策を行うのが長期的には良いと思います。

かつて、私自身の行動パターンをモデルとしていくつかの項目に分類して、それを元にアンケートを作成して、約70名のソフトウェアエンジニアに回答してもらい調査を行ったことがあります。その調査では、どの行動パターンがエンジニアのレベルと最も高い相関を示すかを調査しました。調査結果は今は持っていませんが、いくつかの行動パターンがエンジニアのレベルと相関が高くなっていました。

何が良い行動パターン(習慣)であるかは、ソフトウェア開発組織の中で整理してみるのが良いかと思います。ソフトウェア開発力が弱い組織は、悪い行動パターンを繰り返していることが多いです。

組織の生産性 [ソフトウェア開発組織が持つべきカルチャー]

プログラマー”まだまだ”現役続行 (技評SE選書)

プログラマー”まだまだ”現役続行 (技評SE選書)

  • 作者: 柴田 芳樹
  • 出版社/メーカー: 技術評論社
  • 発売日: 2010/09/04
  • メディア: 単行本(ソフトカバー)

拙著の「第12章 30代、40代の人たちへ」からの引用です。
組織の生産性

 自分自身が継続して学習を続けるというのは、自分自身の成長だけでなく、若手エンジニアや自分が属する開発組織のメンバーにも大きな影響を与えます。ソフトウェア開発では個人差は確かに大きいです。作り出すコードの可読性も含めた総合的な生産性の差には、個人差があります。したがって、長い時間をかけて個々のエンジニアのスキルを向上させていく必要があるのです。そのためには、開発組織の中に見習うべき習慣を持っている先輩や上司がいなければ、その組織の中で若手が勝手に成長するのを期待するのは無理です。

 開発組織の生産性の差は、個人差以上に大きいです。私自身は、様々な開発組織で働いてきましたし、自分自身の開発組織で若手を育成したこともあります。どんなに優秀な新卒新人であっても、間違った開発組織に属してしまうと、数年で変な癖がついてしまい、学習しないことが当たり前になったりします。その結果、経験年数が全く当てにならなかったりするのです。

 継続した学習の習慣化、読みやすいコードを書くことや防御的プログラミングの教育と徹底、コードレビューの徹底を行ってきた組織と、全く何もしなくて本人の成長に任せるだけできた組織では、当たり前ですが、開発組織としての生産性は大きく違います。

 また、1990年代まで当たり前に行われていた手動によるソフトウェアのテストを今日でも当たり前だと思って行っている開発組織と、テスト駆動開発による自動テストを行っている開発組織では、その生産性は大きな差なのです。そして、どちらの組織に属したかによって、若手エンジニアの成長は大きく異なるのが今日のソフトウェア開発の現状です。

 開発組織の生産性の差を作り出すのは、若手エンジニアではなく、30代、40代のエンジニア、マネジャー、管理職だったりするのです。継続した学習をしてこなかった人たちが、ソフトウェア開発組織の中堅となった場合には、その組織全体が成長しなくなってしまう危険性があります。つまり、ソフトウェア開発に対する誤った古い考え方でソフトウェアを開発することになる可能性が高くなります。

 たとえば、1990年代前半は、「オブジェクト指向といえば継承」ということで、差分プログラミングが盛んでしたが、それは利点よりも問題を多く作り出すということで、1995年に出版された『Design Patterns』(翻訳『デザインパターン』は1999年出版)では、「クラス継承よりもコンポジション」を主張していますし、2001年に出版された『Effective Java プログラミング言語ガイド』でも、「継承よりもコンポジション」と主張しています。「オブジェクト指向といえば継承」で学習が止まった人たちがソフトウェア開発組織内の中堅以上を占めてしまうと、今でも継承だけでソフトウェア開発が行われてもおかしくはありません。

 このように、30代、40代となっても継続した学習をすることは、自分だけでなく、自分が属している開発組織の能力にも大きな影響を及ぼすことになります。
あるファイルに記述された形式を大量に別の形式のファイルへ変換するのは本来なら変換プログラムを作成するのが当たりまえです。しかし、時間をかけて手作業で転記し、さらに転記ミスが原因で障害が発生している言い訳が、「担当者のスキルが低いから」と平気で中堅リーダーから言われると、やはり現場の担当者が組織の生産性を下げているのではなく、マネジャーが組織の生産性を下げていると再認識してしまいます。

ソフトウェア開発組織が持つべきカルチャー 013 [ソフトウェア開発組織が持つべきカルチャー]

自分で書いたコードを自分で見直す

コードレビューがきちんと定着しているかどうかの目安の一つとして、開発組織の各メンバーが自分が書いたコードを自分で見直しているかということがあります。形式だけのコードレビューしか行っていなければ、書かれたコードはまともになっていることなく、その結果、書いた本人でさえ自分のコードを見直したりしなかったりします。

自分で見直した結果のレベルは、本人が持っている能力に依存します。しかし、きちんとしたコードレビューが行われていれば、レビューを受ける回数が増えるに従って本人が見直して改善できるレベルも向上してきます。

もし、きちんとしたレビューをしない組織に運悪く属したら、自分自身で様々本を読んで、意識して良いコードを書くことを実践していくしかありません。そのためには、良いコードとはどんなコードであるかを書籍を通して学ぶが手っ取り早いです。その意味で推薦しているのが『Clean Code』や『実装パターン』です。

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

  • 作者: Robert C. Martin
  • 出版社/メーカー: アスキー・メディアワークス
  • 発売日: 2009/05/28
  • メディア: 大型本

実装パターン

実装パターン

  • 作者: ケント・ベック
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2008/12/22
  • メディア: 単行本(ソフトカバー)

ソフトウェア開発組織が持つべきカルチャー 012 [ソフトウェア開発組織が持つべきカルチャー]

ソースコードを調べる

ソフトウェア開発において、自分が書いていないコードであっても、不具合の原因を調べるために、ソースコードを調べると習慣というのは、ソフトウェアエンジニアにとっては重要です。

しかし、実際の開発では、自分が担当しているモジュールでなければ、それ以上調査しようとしない人がいます。その場合には、リーダや上司が、他人のソースコードを調べてでも原因を調査するように指示しているかどうかで、その開発組織のメンバーのスキルに大きな差として現れたりします。

企業におけるソフトウェア開発では、自分が属するチームや設計部門のソースコードしか見られないようなアクセス管理をしている場合があります。そのようなソースコード管理をしている組織では、そもそも他の部門やグループのソースコードを見ることができなかったり、手間暇かけてアクセス権を設定してもらったりする必要があります。その結果、同一商品の中にインストールされるソフトウェアであっても、基本的に他の人のソースコードを調べないという習慣を持ったソフトウェアエンジニアばかりになったりします。そうなると、オープンソースのソフトウェアを使用して何か問題があっても、ソースコードを調べることさえしない人さえいてもおかしくありません。

繰り返しになりますが、何か問題があった場合に、自分が書いていないコードであっても原因を調べ調査するという習慣を持つことは、ソフトウェアエンジニアとして非常に重要なことです。

Use the Source, Luke

ソフトウェア開発組織が持つべきカルチャー 011 [ソフトウェア開発組織が持つべきカルチャー]

テストを自動化する

継続的インテグレーションを行い、テストを自動化して実行することは、1990年代までは普及していません。そのため、技術的負債を多く抱えて機能追加が行われているようなソフトウェアでは、今でも手作業でテストが行わているものが多数存在すると思います。

レガシーコードのテストの自動化には困難を伴いますが、それ以前に問題なのは、テストを自動化することの本当の意味を理解していない開発組織です。たとえば、テストの自動化に本格的に取り組んだことがない開発組織であれば、新たな開発であってもテストの自動化を最初から導入しなかったりします。あるいは、テスト駆動開発と言いながらも、実行は開発者が手作業で行うことで、継続的に実行されなくなり、結果としてテストコードが保守されなくなったりするかもしれません。

また、テストの自動化というのは設計に大きな影響を与えますし、そもそもテストコードがきちんと書かれて保守されていることも重要です。しかし、テストは後で良いという開発スタイルでは、テストするのが困難な設計が行われたり、テストコードがいい加減だったりして、実際には何も成果が上がっていないし、現場のエンジニアの意識の改善やスキル向上がなかったりするかもしれません。

ソフトウェア開発組織が持つべきカルチャー 010 [ソフトウェア開発組織が持つべきカルチャー]

ビッグバン・インテグレーションを避ける

組織におけるソフトウェア開発では、一人で行うことは少なく、プロトタイピングであっても、数名あるいは10名弱で行われることもあります。昔のソフトウェア開発であれば、各人の担当を決めて、各人が実装が終わった後に全部を結合するというビッグバン・インテグレーションが行われて、様々な問題に直面していました。たとえば、各人は開発がスケジュール通りだと常々報告していても、結合で多くの問題を抱えて、結果的にプロジェクトが遅れていくということもあります。

今日、複数名で行うプロトタイピングであっても、ソースコード管理、自動ビルド、自動テストなどを小さいながらも整備してから開発を行うべきです。そして、開発が進むに従って、必要に応じて環境を改善していくことが必要です。しかし、残念ながらチームリーダがそのような認識を持つこと無く、開発を進めている組織もあるのではないでしょうか。
前の10件 | - ソフトウェア開発組織が持つべきカルチャー ブログトップ