トップページ | 全エントリー一覧 | RSS購読

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
トラックバック
トラックバック送信先 :
コメント

知らない、分からないで済ませるマインド

ソフトウェアのアーキテクチャや設計、実装は、少なからず現在の要求に特化されて、ある程度最適化されている。
ソフトウェアのメンテナンスとは、その要求の変化に伴う改修。

要求は、一度に大きな変化は起こらないけれども、じわじわと気づかないうちに変容していく。
気がつけば、最も頻繁に使うはずだった立派な機能はすでに使わなくなり、間に合わせで作った機能をフル活用することもある。

要求Aが要求A+1に変わったとき、それを支える設計等も変えて行かなくてはいけない。


でも、そんなしょっちゅう設計を変更することは、時間もかかるし、変更リスクも大きい。

なので、あらかじめ設計等には、多少の変更の余地があるように、ゆとりを持たせた設計をし、過度な最適化はしない。
そうすれば、後の改修時に、毎回設計等の変更をしなくて済む。


だけれども、いずれはゆとりも食いつぶし、設計等を見直さなくてはならない時が来る。

問題は、この3点に集約される。
①そのタイミングに気づくこと
②それに着手すること
③新しい設計等を実現する能力があること


③は、技術や設計等やコンピュータサイエンスへのセンスが必要だが、そんなことは自明。

②は、ビジネス環境の制約もあるが、要求にあわなくなった古い設計等を捨てる覚悟と勇気が必要。
必要な力は、リーダーシップかもしれないし、ソフトウェアへの責任感かもしれない。

①は、③と同類の力が必要だ。
違いは、問題が与えられているかどうか。
つまり、①をするには自分で問題を発見し、他の問題よりもこの問題に対処する価値があると決めること。



ところが、問題発見力、これが難しい。
もうちょっと大枠で言えば、ロバート・カッツの提唱したコンセプチュアル・スキルが該当する。

問題発見をするには、知識も経験も必要だが、何よりセンス(知恵)が問われる。

センスを磨くには、他人の作った良いものに触れるのも良い方法だが、
それよりももっと(少しだけ)簡単にできる方法がある。

それは、今目の前にあるソフトウェアの設計等の、存在理由を理解していくことだ。


設計等には、必ず作った人の狙いと、実現できずに妥協したこと、そしてその対応限界がある。

プログラムは、何でもできる至上の価値と、何物にもならない最低の価値を、両方兼ね備えている。
その何でも屋さんに、一定の限界を定めることで、その限界を超えない範囲内で、より効果的になる。



ちょっと具体的な例を出してみよう。

うちの会社では、有給の半休をとると、働くべき時間(4時間)を超えて働くと、超えた分が残業扱いになる。
その割増賃金を支払うため、自社開発のシステムで、労働時間などの基礎資料を作成している。

システム内の勤怠情報が多種多量にあるので、資料の作成ロジックは、かなり複雑化している。

今日、管理部門の人が7月度分の資料作成を行っていたようで、そのロジックが実行され、なんと○×秒かかっていた。
(私はチューニングを担当しているので、時折、100ミリ秒以上のデータベース処理を監視している。)


確かに時間がかかる処理ではあるが、あまりに長いので点検してみたら、
うちの会社のルールを実現するために付け加えられたコードが、非常に大型で高水準の処理結果を返すViewを参照していた。

そこは面倒な計算の部分だったので、作った人の気持ちはよく分かるが、
DRYの法則(Don't repeat yourself)に反しない程度に、機能に必要な最小ロジックで置き換えて、△秒になり解決した。



ここで話が戻って、

労働時間などの基礎資料の作成ロジック
非常に大型で高水準の処理結果を返すView

どちらも、勤怠管理系のロジックで、機能レベルでの趣旨はあっている。
出力結果も機能要件に対して正しい。


問題は、のViewは、ちょこっと気軽に参照できるほど、軽量級の扱いやすいパーツではなかったこと。
(もちろん、のViewのロジックが悪いのだが、現在の設計等では改善できない複雑さ。)

作った人は知らなかったとか、そのデータを引用するにはのViewを使うことになっていたとか、
いろいろと、こうなってしまった理由は考えられる。


でも、考え直してほしい。

人が作ったルール(のViewを使うルール)は、あくまでの現実をより良くしようと定めたものに過ぎず、
現実がルールの想定を超えたとき、変えるべきはルールの方だ。


処理の遅いコードを書いたのが問題なのではない。
直すべきときに、直すべきものに気づけなかったことが問題なのだ。


なぜ気づけなかったのだろうか。


作った人は、きっと作るときに「このViewを使えば良いのか?」と詳しい人に聞いたはず。

おそらくは、そのViewの外部仕様を策定したあの人が、
・そこまで思いが至らずの答えた
・そういうルールにしてるからと答えた
・何か思ったけど、より詳しい人を紹介する、自分で確認してから答える、といったことをせず妥協な答えをした
のいずれかの行動をとったのだろう。

その答えを、私が知る術はないが、
結果的に、のViewの妥協点、注意点、限界、想定する用法の理解に至らなかったのはないかと思う。



根底には、「分からなくても、期日までに機能を作ることが自分の任務」というのがあると思う。
この考えはビジネスマンとして、評価できる。
期日に間に合わない「すごい物」を作っていては、ビジネスができない。
分かることに時間を使うよりも、もっと良い時間の使い道もあるはずだ。

でも、プロフェッショナルとしては評価できない。
プロならば、分かった上で、期日に間に合わせるべきだし、
仮に間に合わせるために、理解を妥協したのならば、後日に分かるまで追究するするべきだ。



世の中からは、エンジニアは全てプロフェッショナルであり、できて当然、と思われている節もあるが
現場では、各人の価値観や得意分野にあわせて役割分担がなされると思う。

企業として完成を請け負ったのなら、企業内で分担して達成さえすればいい、ただその程度のこと。



エンジニアの生きる道は、ギークだけではないが、
ギークの道を選ぶのならば、「分からないけど、まぁいいか。」などという考え方は捨てた方が良い。


ただ、苦手で不得意な人に、できるべきだから、と無理強いするのは止めた方が良い。

関係者全ての幸せを願って。

スポンサーサイト
トラックバック
トラックバック送信先 :
コメント

プロフィール

とむころり

Author:とむころり
24時間システムエンジニア。研究開発など何でも屋を担当。知的でおもてなし精神に満ちたシステム(サービス)が作りたい。
@tomcat_ch

最新記事

最新コメント

最新トラックバック

月別アーカイブ

カテゴリ

検索フォーム

RSSリンクの表示

リンク

ブロとも申請フォーム

QRコード

QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。