2018.08.08

「優先順位づけ」は重要なエンジニアリングスキル

 時間や費用や人手など、開発プロジェクトではさまざまなリソースが不足しているものだ。これを与件として顧客が満足できる成果を生み出さねばならない。そのためには、「あきらめること」を決定し、「やること」については優先順位を与える必要がある。取捨選択と優先順位づけ――これらの配慮は地味ではありながら工学的活動においては決定的に重要だ。

 そこらへんの重要性を再認識した出来事が「モデリング/超高速開発ライブ」だった。共通のスコープとなるデータモデルをその場でまとめ、各チームが60~90分といった制限時間内で実装するのである。何度か実施してわかってきたのだが、「ログインしてメニューを開けてほぼ終わり」みたいな残念な結果になるチームがたまにある。私の観察ではそれは開発ツールの問題ではなくて、作業担当者(イベントでは1名と決められている)が作業を取捨選択し優先順位を与えることに失敗したからだ。

 もちろん現実には、それほど極端に時間が制約されることはない。開発ライブに比べたら、アジャイル手法でのイテレーション単位とされる「2週間」などあきれるほど長い。しかし、あえて極端な時間制限で実装作業をさせてみると、技術者に必要なセンスがあるかどうかが歴然とする。

 時間制限に関して思い出すことがある。学生時代に美術部に所属していたのだが、そこでは毎月「クロッキー会」が開かれていた。モデルを囲んでスケッチする集まりのことで、1つのポーズ毎に20分、10分、5分、2分といった時間を決めて絵を完成させるのである。今思うとそれは、制約条件に応じて対象の本質を捉えるための素晴らしい訓練だった。それぞれの制限時間に応じた詳細さが、絵の全体に行き届いていなければいけない。どんな時間であろうと全体を満遍なく扱わねば、まともな人物画としては完成しない。

 こういった特性は、システム開発を含めた工学系課題のそれと同型である。「制約されたリソース内で目的を果たす」という本来の特性が、厳しい制限時間を設けることで際立つ。たとえば超高速開発ライブにおいては、細かい見かけや動きを飾ることよりも、データモデルが表すスコープに含まれるデータの関係性を眺められることが優先されなければいけない。そういうことを一瞬で決定して行動に移す。わざわざ指示するまでもないほど当たり前の話だ。

 ところが、課題の全体感を把握することをせずに、関心が向くまま細かい部分に延々と時間をかける技術者がときどきいる。喩えるならば「規定日数内で一人乗りの飛行機を作ってアマゾン川の対岸にたどりつく」といった課題で、たまたま興味のある「通信機器」の製作ばかりにこだわるようなものだ。どんなに通信機器が素晴らしくても、空を飛べなかったら完全な失敗だし、あまりにマヌケな失敗である。中途半端ならば0点。工学的課題にはその種のものが少なくない。

 いわゆる開発方法論には、優先順位づけをガイドするための多くの知恵が盛り込まれている。たとえばDOA系では「アプリのあり方を考えることは後回しにして、何よりもDB構成の確立を優先すべし」という価値観を含んでいる。多くの失敗経験から抽出された珠玉のノウハウだ。大枠についてはそういった知見にまかせてしまえばいいが、タスク内のこまごました優先順位づけについては担当者自身にまかせざるを得ない。

 とはいえそれは想像するほど簡単な課題ではない。取捨選択や優先順位づけを含む「価値づけ」の作業は、「論理」を扱う大脳新皮質ではなく、「情動(感情)」を生み出す大脳辺縁系と大脳新皮質との複雑な連係によってなされる。つまり「論理と情動の精妙な化学反応」としてそれは起こる。新皮質に含まれる前頭前野の一部が損なわれたある患者は、知的レベルでは変化がないにもかかわらず、その日の食事をメニューから選ぶことさえ出来なくなったという。こういった価値づけを伴う作業は、思いのほか高度かつ重要な脳の働きなのである。

 それだけに開発者の採用に際しては、そこらへんのセンスの有無を確認すべきだし、採用後にはそのための訓練も意識的になされるべきだ。といっても採用試験で「クロッキー会」をやる必要はなくて、「あらすじ」を語らせるだけでいい。すなわち、ちょっとした長文を読ませて、2000字と200字の2種類の概要をまとめてもらう。これによって言語的センスが測れるだけでなく、規定のリソース量(この場合は文字数)に合わせて枝葉と本質を切り分けられるかどうかがわかる(枝葉かどうかはリソース量によって変わる)。この種の課題を軽々こなせるようでないと、業務システムのような複雑で膨大な工学構築物は扱えない。

| | コメント (0) | トラックバック (0)

«システム開発者の給料が安すぎる理由