組込みプレス 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 の特集記事 『できるエンジニアの“頭の中”徹底解剖』で福田さんが書いているというわけである。
が発行された。この号で是非読んでいただきたいのは「文系エンジニアのためのハードウェア講座－電子回路を読む－」だ。
が発売になった。今号から季刊になるとのこと。組込みプレス はこれまでは「是非、読んでね」くらいのレベルだったが、Vol.3 は「絶対読んでおけよ！」くらいのインパクトがある。バラエティに富んだ構成でありながら内容が濃い。