　これまで、「組み込みエンジニアに求められるものとは」「組み込みシステムとは」「MPU（CPU）とは」「メモリ（ROM・RAM）とは」「デジタル信号・アナログ信号とは」「A/D・D/Aとは」「パルス信号とは」「組み込みソフトとは」「組み込みソフトに求められるものとは」と、いろいろ書かせていただきました。

　この間、自分自身が組み込みソフトウェアにかかわり出したころを思い出しました。

自分の言葉で説明できる？

　あのころ、先輩エンジニアからいわれたのは「口を開けて待ってたって誰も教えてくれない」「マニュアルを読め」「自分で調べろ」「調べたら（分かったら）説明してみろ」でした。いまでも技術情報などを調べるにはマニュアルを読んだり、Webを調べたりしますが、情報が簡単に検索できるので「ちょっと調べたら分かる（分かるだろう）」と思い込んでいる人たちが多いのではないでしょうか。

　逆に情報が氾濫（はんらん）しているせいで、本当に必要な（有用な）情報がどれなのかが分かりにくくなった気がします。先日も社内で使うためのデータベースをアクセスするWeb系ソフトを作ろうと思い、いろいろなサイトから情報を得ようとしたのですが、さまざまな手順や方法があり、どれが正しいのか理解できませんでした。結局はいろいろなやり方から自分が納得できそうなものを組み合わせてソフトをコーディングして、何とかそれなりに動くものが出来上がり、ほっとしているところです。本格的なWebプログラマの方たちも苦労しているのでしょうね。

　少々、脱線しましたが、何がいいたいのかというと、

組み込みエンジニアに求められるものとは
組み込みシステムとは
MPU（CPU）とは
メモリ（ROM・RAM）とは
デジタル信号・アナログ信号とは
A/D・D/Aとは
パルス信号とは
組み込みソフトとは
組み込みソフトに求められるものとは

と質問をされたら「答えられますか？」ということです。

　これまで本連載を続けて読んでくれた方は理解しているはずですが、質問をされたら本当に説明できるでしょうか。「調べたら（分かったら）説明してみろ」ができるでしょうか。読者の皆さんが「できる」といってくれたら、これほど心強いことはありませんし、組み込み技術の未来も明るいと思います。

デスマーチに捕まらないように

　さて、少々話題を変えますが、「デスマーチ」という言葉をご存じでしょうか。エドワード・ヨードン（Edward Yourdon）氏が書いた本のタイトル『Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects』（邦題：『デスマーチ - なぜソフトウエア・プロジェクトは混乱するのか』）です。最初にデスマーチという部分だけを見たときにはホラー小説のタイトルかと思ったのは私だけでしょうか。デスマーチ（death march）は「死への行進」と訳されていますが、何とも不気味なタイトルです。

　デスマーチとは、ソフトウェア開発プロジェクト（組み込みとは限りません）において、何らかの理由（大半は、コストや納期）により開発現場に大きな負担を強要したせいで、失敗に終わるプロジェクトのことです。大きな負担とは、以下のような状況です。

開発期間が極端に短い
開発に携わるエンジニアの数が極端に少ない
予算やリソースが極端に少ない
機能や要求が極端に多い

　これを見ただけで、長い間いろいろなプロジェクトにかかわってきたエンジニアの方たちは、顔が暗くなるのではないでしょうか。「そういえばあのプロジェクトでは、徹夜を3回くらいしたな～」などと、筆者も苦い記憶がよみがえりました。

　デスマーチの本当の怖さは、単にプロジェクトが失敗するだけではなく、かかわったエンジニアたちも不幸にするところにあります。デスマーチ状態に陥ると、エンジニアの能力が低下するだけでなく、コミュニケーションもなくなってきます。最悪はエンジニアが病気になったり、嫌気が差して退職したりとなり、補充した人たちともコミュニケーションがないため、説明や教育もしないで物を作らせることになります。これじゃあ、補充された人もたまりませんし、ますますコミュニケーションがなくなり、不満だらけのプロジェクトとなってしまいます。

　実際に筆者がコンサルティングした開発プロジェクトもこの状態になっていました。誰が見ても無理と思われるプロジェクトの進め方をしているのに、誰も幹部に対してそれを説明しようとしませんでした。

　「それなら筆者が代わりに幹部に説明するから」とプロジェクトのリーダーに持ち掛けても、なぜかかたくなに「それはできない」といいます。そんなことをすると「自分たちの評価が下がる」「自分たちが無能だと思われる」とでも思っているのでしょうか。それともデスマーチ状態にまったく気が付いていない、あるいは自分たちで何とかなると思い込んでいるのでしょうか（そんなことはないと思いますが）。

　結局、そのプロジェクトは失敗に終わり、製品も世に出ないで終わったようです。プロジェクトのメンバーにとってこれほど悔しいことはないでしょうし、体調を崩した方もいたのではないでしょうか。たとえ画期的な手法や優秀なツール、優秀な人材があってもどうにもならないことはあるのです。それにいかに早く気付くか（通常だと計画の段階で気付くでしょうが）で、不幸になる度合いを最小限にできるはずです。

　この状態に陥らないための唯一の方法は、無理を強いる幹部の意識を変えることだそうですが、これは並大抵のことではできません。常日ごろからどれだけコミュニケーションができているか、どれだけ正しい説明をしているかにかかっています。第1回の「どんな組み込みエンジニアになりたいですか？」でも書いたように、組み込みエンジニアに求められる資質のトップになっているのが「コミュニケーション能力」というのも納得できるような気がします。

　もし、デスマーチになりそうな（なっている）プロジェクトに関係している方がいたら、外部のコンサルタントに相談してみるのも1つの方法です。内部からいっても聞いてくれない場合でも、第三者の助言なら聞いてくれることはよくあります。不幸が広がる前に「ピリオド」を打つか、計画の見直しをしましょう。