So-net無料ブログ作成
検索選択
ソフトウェア開発組織が持つべきカルチャー ブログトップ
前の10件 | -

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

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選書)


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


実装パターン

実装パターン

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

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

ソースコードを調べる

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

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

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

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

Use the Source, Luke

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

テストを自動化する

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

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

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

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

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

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

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

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

Source Code Controlへ最低でも毎日コミットする

今更言うまでもないですが、SubversionなどのSource Code Controlを使用するのは当たり前です。しかし、意外と普段の開発で使用していない人やチームがあったりします。

たとえば、プロトタイプ開発で開発者のPCにしかソースコードが存在しなかったりします。開発者に、プロトタイプのソースコードはどこにあるのかとか、きちんとソースコード管理に入れているのかと聞くと、開発者のPCにしかなかったりするのです。そして、チームリーダがソースコード管理に関心を持っていないため、ソースコードがそのような状態で開発が続けられていることがあります。あるいは、時々一つのファイルにまとめてバックアップしていますとか。

日々の開発では、最低でも一日に一回はコミットして帰るのが原則です(本来、コミット頻度はもっと多いはずですが)。しかし、開発者のPCにしかソースコードが存在しないような状況であれば、本来チームリーダは、Subversionなどに入れなさいとか毎日コミットしなさいと言い続ける必要があります。そうでなければ、明日の朝、開発者のPCが立ち上がらなくなって、コミットしていないソースコードを失ったり、開発者が何かの事情で長期休みになった時に、開発が進んでいたはずなのに、実際にはソースコードが無いという状況が発生することになります。

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

コードをレビューする

最近では、コードをレビューすることの重要性は多くの書籍で述べられています。しかし、組織によっては「レビューを行った」という事実が重要視されて、「質の高いレビューが行われた」ということにほとんど関心が払われていない場合があります。そうなると、実際にシステム全体を結合テストすると、非常に初歩的なコーディングミスで障害が発生することになります。

1999年の頃だったと思いますが、2週間以上調査された不具合の報告会に出た時に原因が「変数の初期化忘れ」というものでした。それで再発防止策として何があるのかと聞かれて、コードをレビューすれば良いのではと回答したら、「じゃ、ガイドを書け」と上司から指示されて、「Code Review Guide」を書きました。

当然、ガイドを書いただけではレビューは定着しませんので、ガイドの教育を多くのエンジニアに行い、実際のレビューを私自身が行いました。当時、C++言語での組込開発が始まることもあって「C++ Coding Standard」を書いて、さらに「Memory Management Library for C++」「Thread Library for C++」と関連するライブラリの設計も行いました。そのようなガイドやライブラリを実際に使用する開発チームに対しては、2000年の後半から2002年初め頃まで、ほぼ専任のレビューアとして現場でレビューを行っていました。多い時には、週に4日ぐらい一日中レビューということありました。

今日では、フォーマルなレビューからペア・プログラミングを通してのレビューなど様々なレビュー形式があると思います。しかし、重要なことは、コードの読みやすさ、エラー処理、防御的プログラミングなど様々な観点からコードがきちんと書かれているかをレビューすることです。

特に初心者のコードは徹底してレビューする必要があります。そうでなければ、先輩達が経験してきたであろう間違いをもう一度実体験することで、結果的にプロジェクトの開発期間を延ばしたり、デスマーチを引き起こしたりする場合があります。

たとえば、C言語でローカル変数のアドレスを関数から返したり、他のスレッドやタスクに渡した場合にはどのような挙動になるのかは不定です。それが原因で発生する障害の調査には時間がかかったり、仮に障害が修正されても、QA部門によりバグ管理されて、そのためのバグDBの更新、ソフトウェアの再リリース、QAでの再確認という追加工数が発生して、結果としてプロジェクトの工数を増大させてしまいます。一方、開発内でのレビューでこの程度の初歩的な誤りは指摘して修正していれば、将来プロジェクト全体に余分な追加工数を発生させることを未然に防ぐことができる訳です。

ソフトウェアの品質を上げると同時にプロジェクト全体の工数を減らすには、きちんとしたレビューに工数をかける必要があります。しかし、現実は「品質の作り込みよりスケジュール優先」ということで途中の中間マイルストーンは守れても、結合テストに入ると多くのバグを出してプロジェクト全体のスケジュールを延ばしてしまうソフトウェア開発が多いのではないでしょうか。

ソフトウェア開発のスケジュールでは、いい加減な開発でも結合テストまではスケジュールが守れたという「奇跡」を恣意的に起こすことはできますが、品質の悪いソフトウェアでは結合テストの終わりのスケジュールを守るという奇跡を起こすことはできません。

※ Robert Martin著の『アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技』の付録には「奇跡」の面白い話が掲載されています。

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