2008-02-23

山崩しなんて本当にできるのか?

組込みプレス Vol.10 が発売になった。特集1 『できるエンジニアの“頭の中”徹底解剖』の記事が今回のブログで言いたいことと大いに関係あるのでまず、紹介しておきたいと思う。

特集1 『できるエンジニアの“頭の中”徹底解剖』の執筆者は、福田 英徳さんで、『C/C++による組み込みソフトウェア開発技法(ソフトバンククリエイティブ)』の著者でもある。『C/C++による組み込みソフトウェア開発技法』は、組込みに限らずソフトウェアに関する開発技法の多くが解説されており、自分はソフトウェア開発技法の辞書代わりに使っている。さまざまな開発技法の具体的な使い方が掲載されており、机上の空論ではない著者が実際に使ってみた開発技法のポイントが書かれている。

さて、組込みプレス Vol.10 の特集1『できるエンジニアの“頭の中”徹底解剖』の一節を紹介しよう。

【『できるエンジニアの“頭の中”徹底解剖』より引用】

 :
 ソフトウェア開発プロジェクトにおける問題を解決する能力は、ほとんどのソフトウェアエンジニアが身につけることが可能な能力です。普遍的な能力といってよいでしょう。必ずしもそうとは限らないのでは?と思われるかもしれませんが、問題解決に必要な力は、実は一つだけなのです。それは問題を解決しようとする意志の力です。必ずこの問題を解決してやろう、という確固とした意志そこが、問題解決に最も必要な力です。
 :
 筆者は、強い意志されあれば、問題解決には必ずしも知識・スキルを「あらかじめ」身につけておく必要があるとは必ずしも考えてはいません。もちろん実際の問題解決にあたっては、土台となるさまざまな知識があった方が遙かに効率的ですので、今持っていないスキルは学習によって身につけることが求められます。
 :
 ソフトウェア工学の知識は、数え切れないほどの過去のソフトウェア開発プロジェクトで発生したさまざまな問題を解決するために、優秀なエンジニアが能力を振り絞って悪戦苦闘した結果の中から、優れた手法と認められたものだけを蓄えた知識体系です。ソフトウェア工学を学ぶことは、過去(あるいはまだ現役かもしれません)に活躍した最優秀なエンジニアの能力の一部を身につけること、といっても過言ではないでしょう。

【引用終わり】

引用した部分だけだと、ヒューマンスキルの話しか書いていないように見えるが、そんなことはなくて エンジニアリング、マネージメント、リーダーシップのことがまんべんなく語られており、かつ、『C/C++による組み込みソフトウェア開発技法』で紹介されている状態遷移設計、構造化設計、オブジェクト指向設計などの開発技法についても触れられている。

ピックアップしたところは、特に問題解決能力に関して書かれた部分であり、これに関しては自分は福田さんとまったくの同意見であり、「問題解決能力(Problem Solving Skill):自ら考え行動する力」の記事に同じようなことを書いたのでこちらも読んでいただきたい。

『できるエンジニアの“頭の中”徹底解剖』の特集記事では、開発手法の話の前にヒューマンスキルが大事と書いている。この点が非常に共感できるところであるし、今日のブログのテーマである「山崩しなんて本当にできるのか?」の疑問につながる。

では今日の本題に入りたいと思う。

Microsoft Project などのプロジェクト管理ツールを使ったことのある方は多いと思う。まず、仕事を細分化し、期間や工数、誰をアサインするのか、どの順番で仕事を進めるかをガントチャートに書いていく。

このツールを使っていて引っかかる点がいくつかある。一つは、ある仕事に技術者をアサインするときに、その人の工数の何パーセントを使うのかを入力することだ。

技術者は大抵、複数の仕事を抱えているので、抱えている仕事のうちどの仕事にどれくらいの時間を振り分けるのかを決めるという理屈はわかるが、振り分けられた技術者はAの仕事に20%、Bの仕事に80%工数を使えといわれてその通りにできるのだろうか?

人間は同時に複数の仕事をこなすことはできないから、例えば1日10時間働くとして、2時間をAの仕事に8時間をBの仕事に割り当てれば、その通りになるが、本当にそんな働き方をするのか?

自分は未解決のAの小さい仕事とBの大きい仕事があった場合、どっちの仕事にしても中途半端の状態のままで別な仕事に移るのは嫌いだ。中途半端にしたAの仕事が気になって、Bの仕事に集中できない。

こういうときは、Aをできるだけ集中して早く片付けでまず一通り完成させてしまう。そして、Bに取りかかりBも一通り完成させる。この時点でAの仕事もBの仕事も完成させるという責任を果たすめどが立って精神的に落ち着く。

そして次に、納期までの余った時間でAとBの仕事をもう一度見直してさらに完成度が上げられないか考える。時間の許すかぎりイテレーションを繰り返し、成果物を洗練させる(リファクタリングする)。

そんな仕事のやり方をする自分にとって、技術者にAの仕事に20%、Bの仕事に80%工数を使えと指示することに強い違和感を感じる。

どちらかと言えば、Aの重要度はこれくらいで、Bの重要度はこれくらいと伝え、どんな工数の使い方をしてもいいから期限までに仕上げてくれと言いたい。

実際にC君がAとBの仕事に使った工数配分を後から分析し、似たようなA'やB'の仕事をお願いする際に、どれくらいかかるのか予測する際に工数配分の数字を使うのはいいが、これから取り組む仕事に対して工数の配分をパーセンテージで示すのはまるで人間を人格のない機械のように見ているようで嫌いだ。

これと同じような話で、「工数の山崩し」というのがある。

Microsoft Project でガントチャートを書いて、プロジェクトメンバーの工数を入力していくと、リソースの配分を別画面で眺めることができる。

ようするに誰に仕事が集中し、誰の仕事が少ないのかをグラフで把握できるのだ。

このときプロジェクト管理ツールは「工数の山崩し」を行う機能を持っている。仕事の集中している人の仕事を仕事の少ない別のメンバーに自動的に振り分け、プロジェクトメンバーの工数を平均化する機能だ。

自分は、この機能を一度も使ったことがないし、この機能ほどナンセンスなものはないと感じている。

少人数のプロジェクトしか経験していないせいか、誰にどんな仕事を任せるのかは、その人の性格やスキルを見て決める。多くの場合、Aの仕事は技術者αにやってもらうのが適しており、Bの仕事は技術者βにやってもらうのかよいなどと判断して割り振る。その結果、技術者αに仕事が集中することも少なくないが、だからといってαに任せようとした仕事をβに振り分けるとうまくいかないことは多い。

「プロフェッショナルの条件」の記事で書いたように、20世紀、21世紀の世の中は肉体労働者よりも知識労働者の方が圧倒的に多い。工数の山崩しの論理は知識技術者を肉体労働者のように考えていないか?

これが10名ほどの小さいプロジェクトではなく100人規模のプロジェクトで、サブプロジェクト単位でのタスクの山崩しなら、もしかしたらあり得る話なのかもしれない。山崩しの対象が技術者個人ではなく、サブプロジェクトであり、サブプロジェクトごとに仕事の配分を変えるというのであれば、サブプロジェクトのリーダーが技術者の性格やスキルを考えながら誰にどの仕事を任せるべきか調整することができるので理解はできる。

しかし、エンジニアの視点で山崩しという行為を考えたとき、同じようなスキルを持ったエンジニアがプロジェクト内に何人もいて、同じ仕事をAさんからBさんにスイッチできるような職場ってあるのだろうか?

ETSSでスコアが同じエンジニアなら仕事をAからBにスイッチできるのか?

ピーター・F・ドラッカーが『プロフェッショナルの条件』で書いているように、知識労働者がメインの現代では、現在のプロジェクトメンバーの構成員をよくみて、それぞれの得意な部分を最大限に生かしてできることを考えた方が、まず、目標ありきで苦手でも必要とされる仕事をメンバに強要するより、より大きな成果に結びつく可能性が高い。

もちろん、技術者の特長を把握し、その特長を最大限活かすようなプロジェクト運営をするには、洞察力の高いプロジェクトリーダーが必要になるが、プロジェクトメンバーや協力会社のエンジニアをまるで物のように扱うプロジェクトリーダーでは、どんなにスキルの高いメンバーがそろっていたとしても、高い成果、品質のよいソフトウェアをアウトプットできるような気がしないのだ。

人はものじゃない。ものじゃないから知識やスキルを組み合わせるだけでは成果をあげることはできない。逆に言えば今知識やスキルを持っていなくても可能性はある。

そういうスタンスに立つと、新しいプロジェクトメンバーを補充しようとするとき、現在スキルを持っているかどうかではなく、足らない技術を身につけるポテンシャルを持っている人材がいないかという視点で人を見るようになる。

自ら足らない点を補い技術を身につける行動を取れる自立したエンジニアであれば、現時点でスキルを持っていなくてもいい。

これと同じことを、組込みプレス Vol.10 の特集記事 『できるエンジニアの“頭の中”徹底解剖』で福田さんが書いているというわけである。
 

2008-02-08

組込みソフト開発におけるプロセス改善

ソフトウェア開発の品質向上に関してプロセス改善が大事という話をよく聞くが、開発の現場にいるときはその重要性についてピンと来ていなかった。

しかし、自分が現場のソフトウェアプロジェクトを支援する側に回って初めてソフトウェア開発のプロセスを定義し実践することが大事だということに気がついた。

組込み製品の生産現場では工程を管理することがとても大事である。工程管理なしに生産品の品質確保はありえない。

また、電気系、機械系の設計においても無限に試作を繰り返すことはできないし、設計を終了し生産を移管するに当たっては使用する部品を決定する必要もあるため、自然と回せるプロセスの回数が決まってくる。

ところが、ソフトウェア開発の場合は明確に工程を設定しなくても「もの」はできる。商品が倉庫に入る前までなら極端な話、無限に修正を繰り返すことができる。

このブログで何度も書いているように、だからこそ規模の小さい組込みソフトウェア開発では試行錯誤的な開発が横行しプロセスが定まらない。設計・分析してから実装するという順番を踏むことができない組込みソフトウェアプロジェクトが数多く存在する。

でも、小規模なプロジェクトで優秀なエンジニアが集まっていると、プロセスを定義しなくても、分析→設計→実装→検証というプロセスを2回から3回回して、かつ、その中で再利用資産も構築するといったことがリーダーの指示とコミュニケーション能力の範囲で可能である。

そんな感じのプロジェクトで商品開発をやっていると、なぜ「プロセス、プロセス」とうるさく言われるのか理解できない。

ところが、そんな現場を離れてうまくいっていないプロジェクトを第三者的に俯瞰するようになると、ソフトウェア品質の確保のためにプロセスの定義が必要であることが分かってくる。

組込みソフトウェアの場合は、すり合わせ的な試行錯誤の開発スタイルから歴史が始まっていることもあって、第三者がだまっていると工程の切れ目ができない。ずるずるの開発になりがちである。(過去の記事:ソフトウェア開発工程の区切りが見えない

電気系・機械系の試作品作りのためのバトンタッチとなる出図(電気回路や機械図面を確定して業者や生産部門に移管する)という行為・セレモニーがソフトウェア開発にはないため、ソフトウェアは踏ん切りがつきにくい。

だからこそ、プロセスを定めてプロセスの切れ目でレビューや設計審査を行うのだが、これがまた形骸化しやすいという問題がある。

組込みソフトでプロセスを定義して、工程と工程の区切りを明確にし、プロセスのインプットとアウトプットが問題ないことを検証するためには、ソフトウェア開発プロジェクトのメンバーにプロセスの存在やプロセスのインプット、アウトプット、そのプロセスで実施すべきアクティビティやタスクを示す必要がある。

言って聞かせることも必要だが、実質的にはプロセスを絵に描いて見せることが必要だと思う。レビューや審査を他部門を呼んで実施するするのならなおさらプロセスチャートを書かないと、関係する部門全部にプロセスの存在が伝わらない。

人間は基本的にはシーケンシャルなつながりで物事を記憶する。だから、それぞれの担当部門の実施すべきアクティビティの手順を示し、どこ時点で他部門と接触するのかを示してあげることで、組織として何をすればいいのか初めて理解されることが多々ある。

多くの部門にまたがって仕事をしたり、調整したりする人でないと、このプロセスチャートはなかなか書けないし、開発の現場にいるとわざわざ他人の業務のことまで書く気にはなれない。

組込みソフトウェア開発では、プロセスを定義しなくても、無限に修正を繰り返していればいつの日かシステムを完成させることができる可能性がある。規模が大きかったり複雑性が高い場合は、品質が低かったり、開発日程が延びたり、エンジニアが死ぬほど残業したりすることもあるが、最終的にリリースにこぎ着けることも少なくない。この成果はいたずらに権利を主張せず、商品をリリースするために寝食を惜しんで働く日本人の気質がなせる技かもしれない。

しかし、このような試行錯誤のアプローチでは、大規模組込みソフトウェアの品質を保持し、開発効率を高めることはできないし、組込みソフトエンジニア自身がクリエイティブな仕事をすることはできない。結果として幸せになることはできない。

大規模組込みソフトウェア開発では、ソフトウェアの開発計画を立案することも、ソフトウェア要求を分析し定義することも、要求を実現するアーキテクチャを設計することも必要である。

それなしに曖昧なまま見切り発車すれば、必ず出荷間際にバタバタするし、結果的に価値の高い商品、顧客満足の高い商品にならないケースが多い。

この問題を回避するためには、組込みソフト開発において、組織としてプロセスを定義し、各プロセスで実施すべきアクティビティやタスクが何かを明らかにする必要がある。

もちろん、定義しただけではダメで、プロセスチャートを示して、プロセスの必要性を理解させ、きちんとできているかどうか監視もしないといけない。

ちゃんとできていないプロジェクトほど、プロセスの必要性を理解しない。分析・設計してから実装するのではなく、いきなり実装を始めてしまう。

だからこそ、なぜ組込みソフトウェア開発においてプロセスアプローチが必要なのかを開発現場に説く必要がある。支援部門に移って、そのことが初めて分かった次第である。

ソフトウェアの設計者の立場からすると、開発の工程はあまり内外に宣言はしたくない。なぜなら、ソフトウェアの最大の特長でもある変更容易性の切り札はいつでも取っておいて、プロセスを何回回すのかはプロジェクトリーダーの権限で自由に決めたいからだ。開発の工程や手順を変える権限を握っているという状態はプロジェクトリーダーとしては気分がいいものだ。

でも、それでうまくいくのは少数精鋭の比較的規模の小さいソフトウェアプロジェクトであり、メンバーの人数が10人を超えるようなプロジェクトでは、プロジェクトリーダーが頭の中で考えているプロセスの区切りはメンバー全員に伝わらない可能性が高い。

自分のソフトウェア設計者としての感覚では、ソフトウェア開発の手順を組織に強制されるのはあまりいい気持ちがしない。「クリエイティブな仕事をしている者に縛りは無用」といいたいところだ。

エンジニアに限らずその道のプロフェッショナルと呼ばれる人々は、常にクリエイティブであるために感受性を高め、アンテナを張り巡らし、創造のためのモチベーションを維持しようとしている。多くの場合、プロフェッショナルクリエーターは自分にも他人にも厳しく、独善的でもある。ソフトウェアエンジニアの場合も同じだろう。えせプロフェッショナルエンジニアも含めてクリエイティブな仕事を追求してい技術者は独善的な部分を持っており、手順を強制されるのを嫌がる。

だからこそ、ビジネス系のソフトウェア開発の世界ではアジャイル的な開発スタイルが考え出され、ウォーターフォールプロセスとの折衷案のような、イテレーションのプロセスが提案されているのだと思う。

クリエイティブなエンジニアが手順を強制されるのを嫌がるという事実はあるとしても、組込みソフトの品質を向上させ、プロジェクトメンバー全員が今現在のプロジェクトの状態を把握して、それぞれの役割を認識するためにはプロセスの定義は必要だと感じる。

プロセスを設計してそれをキチンと実施することは組込みソフトウェアの品質が高いことを示す一つの材料となる。組込みソフトウェアシステムにおける潜在的な価値が高いことを内外に示すためには、どんな工程を経てソフトウェアが作られてきたのかを説明する責任がある。

日本の組込みソフト開発の現場にはそのことをまず理解してもらわないといけない。ソフトウェアの設計者としては「プロセス改善」ということばに違和感や「余計なお世話」という感覚を覚えがちだけれども、そう主張する人達には「それでは、あなたたちが作ったソフトウェアの品質が高いということはどうやって証明できるのですか」と聞きたい。

「十分にテストしている」などと答えるようでは、20年前の組込みソフト開発から進化していない。

組込みソフトウェア開発では、ソフトウェアシステムに科せられた必達の要求がソフトウェア要求仕様書に定義され、そこに定義された項目が漏れなく検証工程で検査されているはずである。

テストするには、その基となる要求仕様が必要だ。要求仕様が何であるかを尋ねて「それは技術者の頭の中にあります」という状況では、必達の要求が確実に検証・妥当性確認されているのかどうかわからないし、証明もできない。

大規模・複雑化した組込みソフトウェア開発の組織は、ソフトウェアの開発計画段階で開発のプロセスを設計し、途中で見直しを加えながらも設計したプロセスに沿って開発を進めていくことが求められているし、それを実行しなければ、ソフトウェアの品質を保つことも品質が高いこと示すこともできない。

現場のソフトウェアプロジェクトを支援する立場、ソフトウェア品質が確保されていることを内外に示す立場になって、そのことが実感として感じられるようになった。

どんなにすぐれた組込みソフト技術者であっても、「自分が作っているのだから安心してくれ」という説明で納得してもらえる時代は終わった。