プロセス改良について考える

プロセスを改良する場合、改良する視点に２通りある。ひとつは、そのプロジェクトの環境や状況に合わせて最適なプロセスを構築すること。もうひとつは、Framework に合わせたプロセスに改良するケースである。プロセス改良の目的は、プロセスを改善することにより、従来より性能の高いもの、品質に優れたものを生成することを目指しているわけだが、２つのプロセス改善は目的を異にしている。プロジェクトに合わせたプロセス改善は、そのままプロジェクトに恩恵をもたらすが、Framework に合わせたプロセス改善は、必ずしも適用したプロジェクトに直接恩恵を与えるとは限らない。Framework に合わせたプロセス改善は、もっと先を見た５年後１０年後、もしくはもっと大きな組織の観点で効果が現れるものである。取り組みとしては意味のあることであるが、そのプロセス改善は、現プロジェクトには逆に負担を強いることにもなりかねない。プロセス改良は、よりよいものづくりを目指す製造業には必須であり、それはプロジェクトは日々進化し変化していくものだからである。過去の成功体験にとらわれてはいけない。リーダーはプロセス改良の性格をよく理解して現場に適用していくべきである。

vol.49

プロジェクトに合わせたプロセス改良の代表格はトヨタの「カイゼン」でしょう。設計から工員まですべての人が設計の改善と品質問題の解決に努めるという考えは技術志向職人型といえます。それに対しフレームワークはCMMIなどのマネジメント志向組織型のものがあります。目的はお互い異なりますが、プロジェクトに負担がかからずかつ中長期的に変化に対応できるプロセスを組み上げることが大事かと思います。

ドキュメントが必要なわけ

ドキュメントは、ソフトウェアの世界では、唯一の目に見える成果物である。ソフトウェア開発では、ドキュメントを通してしか、ソフトウェアを可視化できない。ドキュメントが、貧弱なものしかないと、残るは難解なソースコードだけになってしまう。ドキュメントからしか、作成状況を目で確認できないからこそ、ソフトウェア開発は難しいとされている。

だが、エンジニアは、ドキュメントなんかは信じていない。信じられるのは、ソースコードだけだと皆が言う。それは、世の中にあるドキュメントは、全て貧弱でうそが書いてある（アップデートされていない）からである。そこで、エンジニアは、ドキュメントの正当性を確かめるためにも、ソース解析を始める。これは、よほどのロス作業である。開発後の確認であれば、ソースがあるからよいが、開発途中のサブシステム間の連携の場合は、ドキュメントが全てになってしまう。

ドキュメントとは、ソフトウェアを人間が分かる形に具現化したものである。それだけ大事なものであることを、よく理解し、頭の中にしまいこんでいるロジックを、吐き出して共有すべきである。エンジニアは、ドキュメントの作成を嫌がる傾向がある。それは、目に見えないものを創出する作業が、難しいことを意味する。だが、頭の中で構築したロジックは、不完全なものが多い。一度目で見て確認することにより、格段の向上が見られる。リーダーは、ドキュメント作成作業が、業務の負荷にならないように、無駄な生成物を除外し、真に必要なものだけを判断し、スケジューリングにも作成とアップデートの時間を考慮すべきである。

Framework を導入すると、往々にして管理ドキュメントが、増える傾向にあるようだ。エンジニアに対する負荷が高くなり、多すぎるドキュメントは、真に必要なドキュメントを埋もれさせ、ドキュメントの品質を落とし、ドキュメントに対する信頼を落としかねない。Framework を導入する際は、管理のためのドキュメントに偏らないように、開発のためのドキュメントを最優先に考えるべきである。

vol.48

成果としてドキュメントの量が評価対象なんて笑い話もありますが、ドキュメントは大局的にみるためのツールでソースコードはその具体的な実現手法がかかれたものです。視点や表現する内容が異なりますがどちらも同期していることによってソフトウェア的「着眼大局、着手小局」が実現できます。ですが人が行うとどちらかに偏ってしまいがちです。つじつまを合わせるために四苦八苦するよりもMDDなどのツールの力を利用していくことも大事ではないかと思います。

会議はなぜ行われるか

仕事をする上で会議はかならず存在する。会議とは、Face to Face で話し合う場であり（中には電話会議もあるが）、文面では、確認／解決できないことを顔を合わせて相手の反応を見ながら行うものであると考えている。一言で会議と言っても経営会議や、方針会議のようなトップ会談から、進捗会議やテクニカルミーティング、チーム内のちょっとした打合せの会議もある。業務の中で、会議が占める割合は結構多い。会議の間は拘束状態なので他の作業が行えない状況となる。そのため、会議が多い人ほど概ね多忙であり仕事が溜まっていることが多い。

会議は、本当に必要なのだろうか。意味も無い会議に参加していないだろうか？会議を必要とするのは、重要な決断や検討を行う際に相互の認識ずれを無くすために必要なのだと考える。なのでタイミングと人選が大事である。

あまりに参加人数の多い会議は議論が発散し意味をなさない。結果だけ知りたい人は議事録を見ればすむ。また、会議を行うときは、事前に参加者を招集した議長が、議題を送付するべきである。そうすることで、参加者は事前に検討を行うことが出来、会議にスムーズに入ることが出来る。もうひとつ大事なことは、会議に時間制限をつけることである。議長は、時間内に終わるように裁量し、参加メンバーのスケジュールを守るべきであり、それが最低限の礼儀である。もし、時間が過ぎてしまった場合は、それだけ議論がまとまらなかったとゆうことを意味しているのだから残課題を確認したうえで、再度開催を提案するべきである。もうひとつ、付け加えるならば、参加者が自由に出入りできるような仕組みもよいだろう。そうすることによってより、自由な会議の場を持つことが出来る。

会議は無くてはならないものだがありすぎると業務に支障きたす。会議は特に必要な人にのみ参加するようにして選別することが大事である。議長やリーダーも、参加すべき人を選別することを心がけるべきだし、それが皆の貴重な時間を有効に使う術である。

vol.47

最近はTV会議の環境もととのってきて気軽におこなえるようになりました。とは言っても多くなると問題です。別なはなしですが海外では重要な決定事項は打合せ前にしっかりネゴッてあって会議はセレモニーでしかないとか。逆に日本では会議は議論するところとの認識が強いように思います。だから長引くんですかね・・

空き時間が発生したら

「やることが無いのですが、どうしたらよいのでしょうか？」、若手のエンジニアからこのように質問される。あなたならどうこたえるだろうか？働き者だなと感心してしまう反面、自分なりに工夫する知恵をつけて欲しいと思うものである。そのような時には、静養して次に備えて欲しいと私は話すようにしている。このような質問は、実は管理者にとっては結構つらい質問ではないだろうか。何か作業を与えなければならないとゆう、えもしれぬ不可思議なプレッシャーがかかってくるのを感じる。

このようなプレッシャーは、幻想である。空き工数と指摘されるのではないか？見積もりが甘いと責められるのではないか？自分の管理能力を問われるのではないか？このような幻想に負けて、まだ進めてはならない先の作業に、手をつけてしまいそうになるものである。ここでまだ中途半端なまま、作業を進めると、全てが狂ってしまう。これこそ、管理能力を疑うものである。ものには順番がある。かならずプロジェクトには、山谷がある。暇なときには、山に備えて勉強するなり、静養するなりして備えるほうが、モチベーションもスキルもあがり結果的によいものである。

残業と一緒で、ここで多少の作業を行ったとしても、たいした成果は期待できない。管理者が感じているプレッシャーを、メンバーも感じている。管理者は、これらの幻想を取り去って、メンバーへ平穏な心を取り戻してあげるべきである。

vol.46

忙しいときにははやく暇になりたいと思いながらいざ暇になるとなんか落ち着かないものです。そんなときに限って意味のない作業をしながら次の日には猛殺の日々がはじまる。なんてことしょっちゅうですよね。体の静養も大事ですが脳みその静養はもっと大事です。だいいち考える仕事は時間がないと出来ません。充実感をもとめるあまり請負作業にならないように注意することです。

残業がもたらすもの

日本のエンジニアは、残業が好きだなと、つくづく感じる。海外の、ある日系企業を見ても、遅くまで残っているのは、日本人だけである。これは、国民性によるものなのかも知れない。海外のエンジニアは、定時には、必ず帰宅してしまう。金曜日などは、３時くらいにはあがってしまう。これは、家庭や自分の時間を、大切にしているからだ。だが、ただ早く帰るだけではない。早く帰れるように、日々業務の効率化を考えている。これは、開発の効率化ではなく、日常業務の効率化である。例えば、朝早くから作業を行ったり、会議を効率よく実施したりして、自分の時間を守っているのだ。それに比べて、日本人はどうであろうか。終電間際まで皆で居残って作業を行い、次の日の朝は、力尽きて遅く出社してしまう。さらに悪いのは、作業が無い人も、帰れる雰囲気じゃないと、一緒に残ってしまう。家に帰れば、寝るだけであり、家庭や自分の時間などは、わずかしか存在しない。これで本当に、創造的な開発が出来るのであろうか？

研究・開発に、残業を無くせと言っているわけではない。逆に、研究・開発作業には、山谷があって、やるときはとことんやらなければならないときがあるだろう。だが、慢性的な残業は、健康的な発想をつぶし、モチベーションを下げ、健康を損ないかねない。これでは、長い目で見れば良い事など無いことは、一目瞭然である。一番問題なのは、惰性で仕事を進めてしまうことである。惰性で行った作業には、創造性などは存在しない。ただ、言われたことを行い、責任を逃れ、結果を待つのみである。もっとメリハリをつけ、エンジニアとして自覚を持って、作業に当たるようにしなければならない。それは、雰囲気も変え、管理者や上司が率先して、環境作りに励まなければならない。それが、知的創造性を高め、よりよい製品を作ることになるのだと思う。

vol.45

日本では昔から江戸幕府の4〜5人の老中らによる合議制にも代表されるように寄り合いによる意思決定が多いですよね。そのこともあって「摺り合せ上手」な日本独自の文化ができたんだと勝手に理解しているのですが、これはこれで日本の大事な利点だと思います。ですが、全てに根回ししてみんなから８０点をとるような決定を下すのが日本です。逆に一部から１００点とるようなものは切り捨てられる。これらを変えるためには個人個人がオリジナリティの主張と責任をもつことが大事だと思っています。で戻って、今回の残業にしても自分でしっかりと主張と責任を持つことによって変わっていくものではないかと思います。

割り込みの危険性

日々の業務で、割り込み作業が占める割合を、意識したことがあるだろうか？たぶん、３割から５割を占めるのではないだろうか？しかも、その割り込み作業は、断続的に発生し、こちらの状況も知らずに、なりふりかまわず発生する。割り込み作業には、電話の応対から、ちょっとした問い合わせ、緊急の対応などの大きな作業から、上司からのどうでもよい世間話など、さまざまなものがある。電話の音や騒音、後ろを歩く人の気配、遠くから聞こえる怒鳴り声や、館内放送などの環境に依存するものも、思考を中断すると言う意味では、割り込み要因になる。

エンジニアとゆう、知的創造を行わなければならない職種にとって、割り込みは非常に有害である。それは、知的創造作業は、頭の中でロジックを構築し、重ね重ね検討をしなおす作業である。その熟考中に、割り込み作業が発生すれば、思考は中断してしまう。割り込み作業が終了した後に、再度続行しようとしても、集中するまでは時間がかかる。（ちなみに、人間は、非常によく集中した状態になると、周りのことが気にならなくなり、作業にとことん打ち込めるような状況になることがある。これは、ちまたで、トランス状態とかゾーンとか言われ、トップスポーツ選手が備えている、と言われているものである。ここまでの集中状態は、まれだが、そのような状態は、知的創造作業にも必要である）集中して作業に入れたとしても、そこまでのいきさつを、忘れてしまっている。もう一度、断片をつなぎ合わせ作業に復帰する。

このように、非常に多くのロスをしてしまう。もしかしたら、二度と割り込み前の、ようなすばらしいひらめきは、出来ないことだってありうる。このように、割り込み作業が発生する環境は、エンジニアにとって好ましくないものである。管理者は（もしかしたらエンジニア自信も）、この弊害に、気づいていないかもしれない。そんなもんだろうと、思っているかもしれない。だが、ここで失っている、多くの知的創造力を見過ごしてはいけない。管理者は、チームをよりよい環境で作業できるように、数人の個室や、電話問い合わせのエチケット、館内放送の停止や、リフレッシュルームの確保などに、全力を尽くすべきである。確かに、お金の問題や、場所の問題など、多くの弊害があるだろう。だが、これらを、クリアするように努力することは、エンジニアに伝わるはずであり、最終的には、プロジェクトの成果となって帰ってくるはずである。

vol.44

電子メールが一般化している現在では電話による割り込みは多少緩和されているのではないかと思います。逆に情報社会である今は自らが割り込みの無い（しない）環境をいかに作るかが能率を左右することにになるのではないでしょうか。集中すべきときは作業中にメーラは立ち上げない、コミュニケーションをとる場と作業する場のメリハリをつけるなど・・。人は一日に１、２時間ほどしか集中を持続できないといわれています。この時間を有効に使うかどうかは自分次第です。

品質と効率は両立するか？

ソフトウェア開発の永遠の課題として、「品質」と「効率」が存在する。よく耳にするフレーズである。「今年のわが社の目標は、品質第一！開発効率化を促進し利益を上げる！！」、などとゆう年間目標を、掲げている会社は多いことと思う。確かに、通常業務や雑務を見ていると、効率の悪い人のアウトプットは、品質が悪いケースがよく目に付く。必要な範囲の効率化は、無駄な作業を省き、作業を明確に出来るので有効である。だが、それは低レベルな話であって、必要以上の効率化は、品質と相反するものであると考える。

例えば、ビルの工事現場で、早く建てるように要請が降りてきたとする。その工事が問題なく進んでいるとすれば、現場監督は不審に思うだろう。そして取る行動は、手抜き工事になってしまう。手抜き工事の結末は、欠陥が随所で発見され、それこそ、当初の予定を上回る納期になるか、納入後にクレームが多発し、信用を落としてしまうことになる。これは、全てのことに言える。料理に関しても、手抜きをした料理がうまいはずが無い。

エンジニアは、アーティストであり、プロフェッショナルである。自分が作成したものに、プライドを持ち、完璧なものを作成することを、誰しも望む。そのような人に、「効率を上げてくれ」ということは、品質を下げてくれといってるも同じことなのである。それは、品質だけではなく、その人のプライドも傷つけ、如いては、モチベーションが下がり、結局は効率
が低下してしまい、品質も下がる。結局のところ、効率を上げることを目的とする効率化は、意味を成さない。だが、最終的に、「品質」「効率」を上げることは、可能である。これまで、説明してきたように、環境を整え、チーム力を強化し、モチベーションを挙げることにより、最終的にはよい結果が生まれる。だが、注意しなければならないのは、これを「効率化」なんて言葉にしてしまったら最後、これまで築いてきたものは、一気に崩れ去ってしまうだろう。

vol.43

「品質」と「効率」を両立させるものとしてひとつ可能性があるとしたら前回も書きましたがモデルベース開発(MBA)ないしモデル駆動開発（MDD）ではないかと思いますが、残念ながらまだまだ未成熟です。今後ソフトウェアにおけるこの二つの長年の課題をクリアするためには新しい開発技法を成熟させていく必要があるでしょう。コンパイラも最初はバグだらけでした。コンパイルの後にアセンブラを確認していたころが懐かしいです。自動コード生成も同じようなものです。成熟していけばそのうちソースコードを見なくてもよい日がくるでしょう。