クロージングしていますか？
こんにちは、forsetiです。
「ゴメン、忘れた」
言いたくはないがいってしまう一言。これまでにどれだけいっていますか？
頑張って築いた信頼も、この一言でガタガタになってしまうことがあります。
どれだけ経験を積んでも忘れてしまえば lｖ5。少しでも忘れないための工夫をしましょう、というのが今回のテーマ「クロージング」です。
●クロージングをしてみよう
作業がひと段落ついた時、「すぐ次に」となっていませんか。行った作業から得られた知識を半年後に思い出せますか。作業を振り返り、今を忘れた未来の自分にメッセージを送ってみませんか。
●クロージングにおける筆者のポイント
・電子化する
電子媒体に保存しておくと検索がしやすい。調査キーワードやURL等を付与しておくと便利です（わたしはGrep検索が可能なテキスト媒体を使用しています）。
・単純化する
作業を初めて行う場合、迷いながら完成させると思います。これを一度整理するだけで非常に覚えやすい形になります。
・高速化する
より少ない手順で実施できれば似た作業を振られた時に楽ですね。最速を目指すよりは「本人が許容できるレベル」で良いと思います。
・応用を探す
作業の中に他の事に使える情報を探す。汎用的に使える情報が見つかればベストですね。
・他人の視点で見る
普通に見ようと思ってもなかなか見れません。「自分で書いたプログラムも3日経てば他人のプログラム」と言う言葉を聞いたことがあります。逆をいえば、忘れているであろう3日以上後に自分のプログラムを見ると、他人のプログラムのように見ることができます。
●終わりに
サボっている人のために努力はしたくない、けど自分がサボるのも嫌という方はぜひ始めてみてはいかがでしょうか。もちろんではありますが、作業を期日より早く終わらせ周りの状況を見て行いましょう。
「こんなこと当たり前」と言われればそれまでですが、
当たり前のことでも、その当たり前をこなすレベルは案外違うのではないでしょうか。
「当たり前と思っていたけど、その発想はなかった」
今後1つでも、このようなことを多く発信していければと思います。
コメント
しっぱ
こんにちは。しっぱと申します。
私の経験上、開発後のまとめができている会社は非常に信用がおけます。
１００％バグのないコーディングは人間には不可能ですし、出来たとしても「改修」に際しての影響調査でミスが出る可能性もあります。
そこで重要になってくるのがforseti様のおっしゃられていることかと思います。
・電子化
⇒これは今となっては当然ですが、自社システムとか昔からのシステムには漏れや欠けがあったりします。
また、改修の際のドキュメント修正はしっかり行い、プログラムだけでなくこちらもバージョン管理が必須ですね。
・単純化
⇒ここはプログラマの範疇にもなりますが、回りくどい書き方をして何とか動いてるってだけじゃだめですね。（理由が説明できるだけでもダメです）
もっと簡単に考えれば・・・・ってことは常に頭に入れながら作らないといけませんね。
また、合わせて言えば、複雑でテクニカルなコーディングは性能は良くても汎用性に欠ける場合もあります。
当然性能は必要ですが、今後の「直しやすさ」も念頭に置くべきかと思っています。
・高速化
⇒ここは難しいですね・・・・・・
私だと、後回しになるかもです＾＾；
上でも書きましたが、大きなシステムになればなるほど「分かりやすく直しやすい」が優先される気がします。。。。
理由は後ほど。
・応用
⇒これはプロジェクトの初期段階でやりたいですね。
共通ルーチン化できる部分がしっかり切りだせれば、開発工期の圧縮にもつながります。
ただし、共通ルーチンの作りが汎用化されていないとクリティカルなことにつながるので、似てるから全部共通化っていうのは一概に言いきれませんね。
・他人の視点で見る
⇒これが一番重要です。
forseti様の前のコラムでも書かせていただいたかもしれませんが、「wizardの暴走」ではありませんが、自分が作りたいように作ってしまうことがいいことではありません。
本当にそれがクライアントの求めるモノなのか、さらに言うなら、本当の目的がつかみ切れているのか。
常に自分を疑いながらモノづくりをするようにしています。
さらに！
最近このあたりが「効率化」「工期圧縮」に押し込まれてあまり叫ばれなくなっていますが、メンテナンス性ですね。
開発したものを自分が入院しようが死のうが絶対に「私がやります」と言える人はいないはず。
作ったものは自分が運用するとは限りません。ひょっとしたら運用は全く別会社になり、メンテナンスもそちらになる可能性もあります。
そこまで考えて分かりやすく作っておくことが重要かと思います。
単純化にもつながりますが、シンプルに書かれたものはバグ要素も少なくなる傾向にあります。
開発者として、管理者としてお客様に資金を頂いて開発をしていることを忘れずにやるということを忘れなければ、「クライアントの視点」「運用者の視点」「エンドユーザーの視点」「改修技術者の視点」等色々多角的に見ることができると思います。
長文失礼いたしました。
非常に共感できる部分が多くありました。
あと、私としては・・・・
・疑問を持つ
ってところが追加かなと思います。
今の仕様でクライアントは満足しているかもしれませんが、もっと良いUIや運用は無いのか？
根本の目的に遠回りしてないか。
常に疑問と探究心をもつことでクライアントとの新たな取り組みもあるかもしれませんし、自身の成長にもつながります。
IT技術者がまずやることはクライアントニーズと業務把握だと思っています。
いくら良いプログラムが書けても目的を間違えていたら意味がないですからね。
そういう意味でIT技術者は広い知識が必要ですね。。。。
書いてて自分でもちょっと反省点が・・・・・
forseti
しっぱさんこんにちは。
> ・疑問を持つ
最近私も優先して気にするようにしています。
まだここに書けるレベルではありませんが、
「開発者、運用者、お客様全てが違和感なく楽に運用できる方法を」
忘れたくないですね。
先のコラムで話題にしようと思っていますが、SEの一番基本は
「早く簡単に正確に」だと思います。
俗に言う「力技」を開発で見る事が多いですが、
「顧客の業務を改善する仕事をしているのに、何故その開発過程を改善する努力をしないのか？」（もちろんしている方も多くいらっしゃいます）
これを気にするだけで生産性は飛躍的に改善すると思うのですがね・・・。
saki1208
forsetiさん、こんばんは。
saki1208です。
お客様への業務改善を提案するのですから、自分たちも業務改善していかないと
ダメですよね。
私もそう思います。
自分たちの作業そのものにも疑問を持ち、常に改善していく必要があると思いま
す。
成功しても失敗しても...
多分今年はこれで最後だと勝手に思っていますがw
よいお年をお迎えください。
forseti
sakiさん、こんばんは。
業務改善は失敗してナンボだと個人的には思います。
改善して誰か(特に新人が良いと思います)に適用し、そこからニーズを聞き更に改善する。
改善するメリットの1つがこの後輩指導です。（近々掲載予定）
分からない人に説明する機会と言うのは結構少ないので、貴重な時間だと私は思っています。
この時間を少しでも得られるように色々とネタを仕込んでおきたいものです。
> 多分今年はこれで最後だと勝手に思っていますがw
諸事情あり掲載が遅れてしまい、これが最後になりそうですね。
始まったばかりのコラムではありますが、
前回からご覧頂いている、コメントくださっている皆様方有難う御座います。
コメントからではありますが、この場で御礼申し上げます。
今後もよろしくお願いいたします。