エンジニアリングの現場には、 「主体的かつ自律的に成長できるエンジニア」から「受け身のエン ジニア」まで、いろんなエンジニアがいるように思います。ここでは、 「個人の仕組み作り」とい う考え方で、 「エンジニア個人の成長」について考えてみたいと思います。長文で少し主張が錯綜 しているようにも思いますが、何かのヒントになれば幸いです。また、いくつかの点については まだ内容にも表現にも改善の余地があるような気がしています。もしお気づきの点がございま したら、是非こちら（[email protected]）までメールでご教授戴ければ幸いです。 エンジニアと個人の仕組み作り エンジニアとは、専門的な技術を使って技術的な課題を解決することによって、経済的な価値を 生み出すのが仕事である。一方で職人と呼ばれる人たちも、専門的な技術によって経済的な価値 を生み出す点は同じである。両者の違いは、技術を「工学的に」利用するか否かという点にある と 言 う こ と が で き る だ ろ う。す な わ ち、エ ン ジ ニ ア の 仕 事 は、技 術（Technology）と 工 学 （Engineering）という２つの要素で構成されている。「工学的である」ことは（職人に対する相対的 な）エンジニアの価値を生み出す源泉であり、重要な特性の１つだと考える。そして、 「工学的で ある」ためには、 「個人の仕組み」を業務遂行を通じて意識して構築する「個人の仕組み作り」が 重要だと考えている。以下では、 「工学的である」、 「個人の仕組み」、 「個人の仕組み作り」といっ た概念について順番に説明して行きたい。 「工学的である」とは何か？ それでは、 「工学的である」とはどういうことだろうか？ここでは、以下の３つの観点から、 「工 学的である」ということについて考えてみたい。 ・合理性（説明可能性） ・改善可能性 ・予測可能性 合理性（説明可能性） 合理性（説明可能性）とは、 「自分以外の第３者に説明して納得してもらえるか？」という特性で ある。仕事を進める（技術課題を解決する）プロセスや判断が、客観的なデータに基づいて決定 されているか、論理に飛躍が無いか、といった点について留意しておく必要がある。 職人であれば、なぜそうなったのか、どうすれば同じことができるのか、といったことが説明で きなくても、 「説明できないが俺にはできる」で良いかも知れない。しかしエンジニアは、組織の 中で、あるいは組織から委託されて業務を行うことが多いため、恊働や説明責任について留意し なくてはならないだろう。業務を合理的に進め、常に説明可能な状態にしておくことにより、組 織（チーム）の総合力の発揮や内部統制の徹底も容易になると考えられる。 「工学的である」ためには「常に説明責任を意識している」必要がある。 改善可能性 エンジニアがまったく同じ業務を繰り返し行うことは稀である。未解決の技術課題を解決する ことが本質的な業務であるため、まったく同じ業務の繰り返しにはならず、具体的な末端の業務 内容は常に変化すると言える。しかしながら、抽象化したレベルでは、やはり多くの作業が繰り 返されることになる。例えば、「業務 A の実験の準備」は１度きりしか実施しないかもしれない 1 が、 「実験の準備」として汎化／抽象化したレベルでこれを捉えれば、きっと何度も繰り返し実施 することになるだろう。 エンジニアは限られた資源（時間や費用）で技術課題を解決しなくてはならない。もちろん、エ ンジニア間の競争力確保という点では、より少ない資源で技術課題を解決することが求められ る。すなわち、エンジニアは技術課題の解決に関して、より良い効率や精度やコストを追求し続 けなくてはならないのである。 この観点では、業務の再現可能性の確保や経験知の蓄積が重要である。具体的には、再び（汎化 ／抽象化したレベルで）同じ業務を行う際には、より良い効率／精度／コストで実現できるよう、 改善の元手（作業記録や実績データ）や改善のアイデアを確保することが大切になる。 「工学的である」ためには「常に改善を意識している」必要がある。 予測可能性 エンジニアはプロフェッショナルであり、その責任を果たすためには、仕事に必要な資源を確保 し、それを十分に活用することが重要である。 エンジニアの業務は技術課題の解決だから、資源（ヒト、モノ、カネ、時間など）の確保とは、経 営的に見れば「投資」である。必要な投資額を上司や経営者や依頼主に納得してもらい、承認し てもらうためには、その必要十分性の根拠となるデータが必要となる。 一方、資源を十分に活用し、最大の成果を上げるためには、 （個人レベルでも）進捗管理や品質管 理が必要不可欠である。せっかく資源を確保しても、早い段階で無駄に多くの資源を使い果たし てしまっては元も子もない。また、資源の不足を早期に検知し、必要なら追加投資を進言するこ とも重要な責任の 1 つである。進捗管理や品質管理の精度を高めるためには、過去の実績データ と、それに基づくモデルの構築が重要である。（「占いの能力を高める」のは工学的とは言えない） データやモデルといっても難しく考える必要はなく、例えば以下のようなデータやモデルでも、 それを持っているのと持っていないのとでは、予測精度は大きく異なるだろう。 ・（ある作業を自分がやる場合の）作業時間、作業期間、手戻りはだいたいどれくらいか？ （作業の定量的な実績データ） ・ある仕事が完了するまでに必要な作業や手続きは何か？（プロセスのモデル） 自分自身や自分が経験した業務に関するデータやモデルを集めることにより、予測可能性が高 まっていく。言い換えれば、新たな業務に取り組む際の不確実性を減らすための努力である。 「工学的である」ためには「常に不確実性を減らしていく」必要がある。 「個人の仕組み」とは何か？ 以上、３つの視点から「工学的である」とは何かを考えてみた。あるエンジニアが「工学的であ る」とは、限られた納期などの制約の中で、 ・合理性（説明可能性） ・改善可能性 2 ・予測可能性 を重視しながら作業を実施している様子を指す。 工学的な観点での業務遂行能力 エンジニアは、業務遂行において「工学的である」ことによって、そのエンジニア自身の業務遂 行能力を（工学的な観点で）向上させていく。改善可能性や予測可能性によって業務の効率や精 度が高まり、裏付けのある合理的な判断も可能となるからである。 この文書では、工学的な観点で見た「業務遂行能力」を「個人の仕組み」と呼ぼう。「個人の仕組 み」は、過去の業務経験や勉強によって培われた、工学的に有用なスキルと知識の集合体とも表 現できる。次節では、この「個人の仕組み」をいかにして構築するか、 「個人の仕組み作り」につ いての意見を紹介したいと思う。 個人の仕組み作りとは何か？ 前説で述べた「個人の仕組み」は、自覚の有無はともかく、すべてのエンジニアが身につけてい る。だが、 「個人の仕組み」の拡大あるいは向上の「スピード」は、個人間で大きな差が見受けら れる。強い「個人の仕組み」を持ち、多様な業務に対して平均以上のパフォーマンスを上げるエ ンジニアは、そうでないエンジニアよりも、同じ業務からより多くのものを掴んで自身の「仕組 み」を強化する。すなわち、「個人の仕組み作り」に長けている。 以降では、「個人の仕組み作り」に関して重要なポイントは、たった 1 つ、 ・すべての業務を 2 つの観点から捉えること 1. 解決すべき技術的課題 2. 自分自身の業務遂行能力を磨く材料 ではないかと考えている。この点は、過去のエンジニアとしての経験から気づかされたり、先輩 から教え込まれたものであり、多様で変化の激しいエンジニアリング業務に対応するエンジニア にとって有益なヒントになり得ると考えている。 ある業務に取り組む際に、その業務において求められている成果を達成するのは当たり前であ る。しかしそれだけでは、十分に自分自身の業務遂行能力が向上するとは限らない。一方でどん な業務からも何らかのデータや知見を得ることが可能である。であれば、漠然と業務に取り組む のではなく、その業務を例えば以下のようなことをするための手段として活用する方が得策であ る。 ・実績データの収集 ・見積り能力の検証 ・プロセスの記録 ・業務遂行中に発生する外部からの割込み要因の把握 ・新規技術や新しいプロセスの試験的な導入 これらは業務の要件としては通常与えられていない。あくまでも自分自身の業務遂行能力向上 を目的として、自分自身で設定するものである。多くのテーマを盛り込まなくても、たった 1 つ のテーマを盛り込むだけでも、それを意識して業務を遂行することにより、そうでない場合と比 3 較すると大きな違いが生じる。 この観点において「個人の仕組み作り」とは、業務を業務遂行能力の改善機会と捉え、能動的か つ意識的に活用することであると言えるだろう。 具体的な手順とポイント 「個人の仕組み作り」の手順 ここでは、これまでに述べたような意識でテーマを設定した場合に、具体的にどのように業務を 活用すれば良いのか、その手順を紹介したい。 手順を PFD（プロセスフローダイアグラム）で表現すると下図のようになる。 図のように、手順は以下の３つのプロセスから構成される。 1. モデルを作る（予測する／計画する） 2. 業務を遂行する（作業しながら実績を記録する／モデルを評価する） 3. モデルを更新する これら３つのプロセスのうち、2. と 3. は、個人の仕組み作りの観点で取り組むものである。この 2. と 3. の部分について意識して取り組むか否かによって、同じ業務を遂行して同じ成果を出した としても、エンジニア個人が得るものに大きな差が生まれるのである。 「個人の仕組み作り」のポイント 前節で述べた手順を踏むにあたってのポイントは下記の通りである。 ・モデルの精度は粗くて良い ・特に初めての業務や（抽象化したレベルでも）経験の浅い業務については、精度の高 いモデルを作ることは難しい。モデルを作る能力そのものを引き上げることよりも、 とにかくモデルを作ってそのモデルの精度を段階的に引き上げる「経験的な」アプ ローチなので、モデルを作る段階であれこれと悩む必要はない。 ・業務遂行時の実績データの記録は欲張らない ・あれもこれも実績を記録しようとすると、業務遂行に対して負荷になる。ましてや定 量的なデータを逐次記録するような作業は大変な負荷である。特にまだモデルの精度 が低い時点では、どのようなデータが重要なのかも見極められないので、１つか２つ くらいの観点に絞り、負荷にならない程度の粗さで実績に関する情報を入手すれば良 い。 ・モデルの更新も、重要なポイントだけにする ・実績に基づくからといって、細かい点までモデルを精密化してしまうと、モデルの中 小度が下がってしまい、次回の業務に対するそのモデルの適合度が下がる可能性があ る。大きな手戻りを予防したり、予測精度を確保する上での重要なポイント（上司は 不在がちなので上司承認の所要日数は３日と読むこと！など）だけで良い。 ・モデルの管理に手間をかけない ・モデルをどこにどのように記録するか？という点についても、できるだけ自分の負担 にならないよう工夫する必要がある。後述の事例紹介でいくつかのアイデアを紹介し ておく。 事例紹介 以上で論じた「個人の仕組み作り」という考え方の理解を深め、実践できるようにするために、い くつか具体的な実践事例を紹介したい。なお紹介する事例は、誰にでもわかりやすいように、非 4 常に一般的な業務を選んでいる。高度に専門的な技術課題の解決であっても、ここに挙げたもの と本質的な考え方／取り組み方は同じである。 上司の承認を得る 私が駆け出しの新人だったときの事例を紹介する。 提案や稟議や決裁等、上司の承認を得るプロセスは、多くの業務の中に登場する。上司も人間で あるため、承認する／しないの判断において「くせ」が存在するだろう。文章の表現にうるさい 上司もいれば、事前の根回しを重視する上司もいる。 自分が素早く承認を得ることができるように（そして小言を言われなくて済むように）、以下のよ うなモデルを作って使っていた。 小言リストは、いつも使っている手帳の１ページに記録していた。上記のモデル（業務プロセス） は特にどこにも記録していなかったが、上司の承認を得なくてはならない状況になると、いつも 手帳の小言リストを見るところから作業を開始していた。これにより、上司に小言を言われる頻 度を段階的に下げていくことができた。もちろん小言リストには自分の弱点も含まれていて、そ れを克服できたのかもしれないが。 まったく初めての業務に取り組む これは今でも頻繁に実践している事例である。年に１、２度だが、第一印象として「これは今ま でやったことがない」と感じるような、新規性の高い業務に取り組む機会がある。実際には、 「パッとモデルが頭の中に浮かばない」ので、そのように感じているのである。 このような業務に臨む際は、そもそもモデルを作ることができない。そういう場合には、特に意 識して、下図に示す「初めての業務」用のモデルを使うようにしている。 とにかく最初に、業務遂行中にやったことや気づいた点を記録するためのメモ（記入先）を用意 してから、業務に着手する。業務遂行中は、なるべくやったことや気づいた点を記録しておくよ うにする。業務が終わった後（直後）に、そのメモを見返して、簡単なモデルを作る。本当にま た類似性のある業務を行う機会があるかどうかわからないので、メモさえ残しておけば、モデル を作る作業はやらなくても良い。 このモデルは「初めての業務」に対して汎用的に使えて重宝している。 海外に出張する 海外出張には前準備や後処理として実施すべき作業項目が多く、しかもそのうちいくつかは重要 だったりタイムリーな処理が必要だったりする。このようなポイントを見逃し、重要な作業が漏 れたり、タイムリーにやるべきことをやっていなかったりすると、大きな調整が必要になったり して被害が大きい。 私の場合、海外出張は年に 1 回あるかないか程度である。このように稀に実施する業務は、必要 なプロセスを覚えにくく忘れやすい。またモデル（業務プロセス）を改善する機会が少ないため、 5 改善のスピードも遅い。 私にとっての海外出張のように、 ・実施する頻度は少ないが、繰り返し実施する可能性は高い ・作業項目が（暗記できないほど）多い ・作業プロセスの質が悪いと被害が大きい といった特性を持つ業務に対しては、自分なりの「仕組み」を構築して管理することによるメリッ ト（被害の予防効果）が大きい。 具体的な手順は、先に紹介した２つの事例から類推できると思うので省略するが、紙一枚に、大 まかな作業項目と実施すべき時期（出発日起点）を記録して管理しておくだけでも、十分に効果 を得ることができる。 まとめ 具体的な事例として紹介したような「一般的な業務」に対しては、 「個人の仕組み作り」を実践し ている人は多いかも知れない。しかし、ことエンジニアリングに関しては、意外とそれをやって いない人（エンジニア）が多く見受けられる。前にも述べたが、一見するとエンジニアリングは すべてが固有かつ一過性の業務のように感じられてしまい、最初から「個人の仕組み作り」の対 象範囲外として取り扱っているのではないだろうか？大事な点（そして人によっては難しい点） は、業務を１レベル抽象化したレベルで捉えて、その抽象化した業務に対する「個人の仕組み作 り」を実践することにある。また、技術と工学を切り分けて考え、エンジニアとして「工学的で あること」を常に意識することが、 「個人の仕組み作り」の実践に対する強力な動機付けになると 考えている。 6
© Copyright 2024 Paperzz
