先日の部会で、その中の「マナーに気を配るべし」という項目が話題に挙がりました。
「マナーを守るために実践していることは？」
「そもそも、マナーとは？」
先輩のSEからも、様々な意見が挙げられました。
皆がそれぞれの経験から感じたこと、学んだことをもとに、マナーに対するそれぞれの考え方を持っていました。
私は部会の中で、自分の意見として、
「マナーは法律とは違い、必ずしも明文化すべきものではない。
だが、基本的な考え方として、自分がされて嫌なことを、他人にもやらないようにするべきである」
と述べました。
そう感じるようになったのも、ここ数年のことだと記憶しています。
私は、時間に対して独自の考え方があるのかもしれません。
ただ、
「自分1人の簡単な工夫や配慮で早く終わらせることができるのならば、なるべく短く済ませたい」
と考えるのです。
（ここでの「自分」とは、私のことでもあり、私以外の誰かのことである場合もあります）
これまでに経験したことの無い作業や、自分のスキルだけではどうしようもないことであれば、手戻りが発生したり、予想より時間がかかってしまうこともあるでしょう。
ところが、
「打合せが少しでも早く済むように、相手に前もって議題や質問内容を伝えておこう」
「分担しやすいように、必要な作業を細分化して挙げておこう」
といったことを考えるのは、決して難しいことではないと思うのです。
自分にロスを発生させないようにすること、そして相手にもロスを発生させないようにすることは同じくらいに重要であると、私は考えます。
]]>マインドマップとは、簡単に言うと ニューロン(神経細胞)やシナプス結合など、
私達の脳の仕組みを目に見える形に現した絵です。
その為、記憶、整理、理解、発想などが格段にやりやすくなります。
利点は色々ありますが、
私の場合は、特に「プレイバック効果」について利点を感じます。
例えば、メモ代わりにマインドマップを使う場合は、
文字で書くメモとは違い、キーワード間の繋がりがビジュアル的に見れるので、
内容が思い出しやすくなります。
書くときのポイントは、記載表現にこだわらず、その時に思いついたことを
何でも自由なキーワードで記載すればよいということだと思います。
他人からすればその話題に一見関係のないキーワードでも、
例えば、その人の過去の体験から一瞬頭をよぎるようなものもあると思います。
そういったキーワードも含めて、脳のなかで行われている発想手順を
そのまま絵にすれば良いという考えです。
記憶を紐解くときに役立つと思います。
テストのときはよく、
「網羅（もうら）性を持ったテストパターンでテストして欲しい」
と、上司や先輩から指示を受けます。
「網羅する」とは、対象や範囲が全てに及ぶことを指します。
一般的に、
「この一冊で試験範囲を網羅している」
のような表現をすると思います。
つまり、「網羅性を持ったテストパターン」とは、
「いくつかの条件をもとに、考えられ得る場合の全てを挙げたテストパターン」
ということです。
ここで、
「条件1が真、または、条件2と条件3の両方が真」
のときに実行されるべき処理を、テストするとします。
このとき、考えられ得るテストパターンを挙げるために、
表計算ソフトやテキストエディタなどに、パターンを書き上げていきます。
この場合では、「条件1」「条件2」「条件3」の列を作り、
真ならば「Y」、偽ならば「N」を記入します。
さらに、3つの条件の右側に「結果」のような列を作っておき、
その条件のもとで、処理（表示、更新、削除、登録など）が、
実行されるべきである場合は「○」、
実行されるべきでない場合は「×」を記入します。
例えば、条件1と条件3が真で、条件2が偽のとき、
テスト対象の処理は実行されるはずなので、「○」となります。
これを「Y、N、Y、○」のように書くとすると、
全ての条件のパターンと、その実行の可否は以下のようになります。
Y、Y、Y、○
Y、Y、N、○
Y、N、Y、○
Y、N、N、○
N、Y、Y、○
N、Y、N、×
N、N、Y、×
N、N、N、×
このような一覧を手元においてテストを進めていくと、
テストパターンに取りこぼしがなく、
網羅性のあるテストができると思います。
1つずつテストしていくのも良いですが、
一覧表示や一括登録などは複数のパターンを一度にテストすると良いでしょう。
ちなみに、テキストエディタでも一覧表を作成できますが、
コピー＆ペーストのしやすさ、印刷時の見やすさから、
私は表計算ソフトを使用しています。
viはvi上級者にとっては多くの選択肢（コマンド）が用意されているので
便利なテキストエディタなのですが、
初心者にとっては、Windowsなどで使い慣れているエディタとは操作が違ったり、
コマンドの種類が多すぎたりする点で比較的とっつき難いかもしれません。
もうひとつ、viにはモードの概念があるという点も特徴です。
文字入力するための「入力モード」と、編集コマンドをタイプするための「コマンドモード」があり、
入力モードでは、単に文字を打ち込んでいくこと以外はできず、
カーソルの移動、文字の消去といった作業は、コマンドモードで行うことになります。
使い始めは慣れずに苦労しますが、
慣れてくると非常に扱い易く感じてきます。
まず、一般的なエディタではカーソルの移動や文字の削除の操作は、
指をホームポシションから離さなくてはならないことが多いですが、
viはホームポジションに手をおいたままあらゆる編集操作が可能です。
例えば、カーソル移動は、カーソルキーではなく、hjklキー で代用でき、
文字削除は、x(１文字削除)、dd(1行削除) などのコマンドを使う。など。
次から次へ失敗の連鎖が起こる状態のことです。
なぜ、負のループに陥ってしまうのかを考えてみました。
まず、負のループに陥るきっかけというのは、何が多いかというと、
たった一回の失敗です。
そもそも、全てうまくいけば、負のループに陥ることはありません。
しかし、実際は全てうまくいく人間なんてほとんどいません。
必ず何かしらの失敗をします。
ところが失敗しても、負のループに陥る人と陥らない人がいます。
何が異なるかというと、ネガティブかポジティブか、
失敗を反省し次に生かせるか生かせないかということが大きく異なるところです。
ネガティブというのは負のスパイラルとなり、
負のループが始まるきっかけになってしまいます。
そして一旦負のループに陥ってしまうと、抜け出すのは非常に困難です。
何をしてもうまくいかないのに、何とか抜け出すために
一生懸命考えて何かしても、うまくいくわけはありません。
何をしてもうまくいかないのだから。
だからこそ負のループなのです。
最終的に、何をしても駄目なら何もしない。
という最悪の結果を導いてしまいます。
ここまでくると、ある種、うつ病といってもいいかも知れません。
インターネットでも、本でも構わないので、うつ病の症状を調べてみてください。
おそらく、類似している点が多いはずです。
さらに悪いことに、自分が負のループに陥ったきっかけを忘れてしまいます。
何もしない状態、無気力・無関心になると、それが当たり前になってしまい、
いつしか本当の自分を忘れてしまいます。
ではこの状態から抜け出すには一体どうしたらいいのか。
私が今も行っている解決方法を書こうと思います。
解決方法は少し違った視点から考えます。
無気力、無関心を言い換えると、面倒くさい、やる気が起きない。
という状態と言い換えられます。
面倒くさいと思うということは、面倒くさいことを考えてはいる、
もしくは、面倒くさいことが見つかっているということになります。
どんなにやる気がないにしても、必ず面倒なことは思い浮かび、見つかり、教えられるのです。
負のループを抜け出す最も良い方法は、
【あえて、面倒くさいことをする。】
これが最も簡単な脱出方法です。
あえて自分を痛めつけてください。
はっきりいって、面倒くさいことをやるというのは、精神的にもきつく、
ストレスも溜まります。
しかし、いつの間にか負のループは抜けているはずです。
]]>ただしプロジェクトを推進する立場からすれば新しい技術を使うとき、
またチームのメンバーがスキルを欠いている場合は常にメンバーの
トレーニングをプロジェクトマネージメントのプロセスとして行う
必要があります。つまりOJTとは新入社員だけのトレーニングではなく
必要であればいつでも・どこでも行われるトレーニングであるといえます。
このトレーニングは必要なので行わなければいけないものであるが、
自己目標や組織としてのキャリアパスと合致しているかは非常に難しい
問題です。特に新入社員のOJTの一環としてプロジェクトに配属された場合、
プロジェクトの都合により思いもよらない業務に携わることも考えられます。
逆に言えばプロジェクトマネージャーはプロジェクトを成功に導くと共に
自社組織の教育プランをも考慮に入れたメンバーの配置を求められる
立場ということになります。
プロジェクトマネージャーという立場はここでも顧客と会社の板挟みに
あうわけです。こんな時に思い出すのはやはり馬場史朗氏の「顧客が51,
会社が49」という言葉ですが、この場合も適用してよいものだろうか？
メンバの配置に関してはそのあたりも考慮してもらいたいものです。
]]>では、システムを開発する立場としてのゴールは何でしょうか？
それは、システムを構築し、納品するのがゴールだと一般的に考えられています。
この様に、お客様のゴールと私たちシステム開発者のゴールが実は一致していない事がわかります。
これで本当にお客様に満足して頂き、喜んで頂くシステム構築ができているのでしょうか？
やはり最終ゴールがずれているので、答えは「NO」と言わざるを得ない状況です。
では、共通のゴールを持つためにはどうすればよいのでしょうか？
それは、「システム運用」という視点を持つ事です。
システム運用の目的は、お客様のシステムを効率よく使用し、お客様のビジネスを向上させる事です。
これは、お客様が望まれているゴールと同じです。
現状の「システム構築」に「システム運用」を加えると、お客様と共にゴールを共有する事ができます。
これこそが、今のお客様が望まれている理想の形ではないかと考えています。
お客様に満足して頂くだけでなく、実は私たちシステム開発者にも効果があります。
それは次のゴールを達成するためのシステム導入を依頼されるという事です。
システム運用を行なうと、お客様が早くゴールにたどりつくためのサポートが可能です。
また、お客様のゴールを知る事ができます。
お客様がゴールに達したならば、必ず次のゴールを目指す事になります。
その時に依頼が来るのは前回共にゴールを目指したシステム開発会社になります。
この様に、「システム構築」→「システム運用」→「システム構築」とよいスパイラルを
構築する事ができ、またお客様との信頼関係を密にする事ができます。
「システム運用」を加える事で、お客様に満足頂き、
そして私たちにもよい効果をもたらしてくれます。
お客様と共にゴールを目指すのであれば、「システム運用」は必須であると考えています。
部員達の満点が当たり前になってきた。
ここで部員からの提案で次のアクションとして
SE行動指針を実践できているかどうかを見るという意見が上がった。
その方法は毎部会、SE行動指針の10項目から1つテーマを決め
実際にどんな行動をとったのか一人一人発表していくということである。
メリットとして他のSEの行動が具体的に分かり、
経験の浅い部員は先輩の行動を参考にするチャンスでもある。
そして毎部会前にテーマをあげれば否が応でも行動しなければならない。
これを繰り返せば、行動癖がつくのではないだろうか。
どちらにしろSE行動指針の項目は暗記するのではなく
行動することに意味がある。
【SE行動指針】
・情報の収集に努めるべし
・マナーに気を配るべし
・第二領域の時間を増やすべし
・事前準備をして会議に参加すべし
・リーダーである意識を持つべし
・お客様を知るべし
・時間厳守を宣言すべし
・取引先への感謝の念を持つべし
・早寝、早起き、朝ごはん
・責任を自覚すべし
自分がモチベーションの高低を決めないということは、
仮に自分が自分のモチベーションは高いと思っていても、
周りの人間(上司・部下)があなたのモチベーションは低いと思ったら、
それはモチベーションが高いとはいえないのです。
逆に、自分のモチベーションが低くても、周りの人間があなたのモチベーションが
高いと思ったら、あなたはモチベーションの高い人間であるということです。
ところで
モチベーションが高い。
モチベーションが普通。
モチベーションが低い。
この違いは一体誰がどのように決めているのか・・・。
万人共通なのか・・・。
はっきりいって明確な定義なんてありません。
人それぞれに定義が存在します。
自分のモチベーションをコントロールするというのは基本的には
自分のモチベーションが高いと思って欲しい人間を知ることから始めなくてはいけません。
周りの人間を知り、自分がその人にどの程度のモチベーションを見せることで
自分のモチベーションが高くなるのかを測れるようになります。
モチベーションを保てる人というのは周りの人間を知ってるということになります。
]]>しかしこの仕事が人に依存しているという部分はプロジェクトにとって
かなり厄介な問題である。開発工数の見積りが難しくなってしまうからである。
システムを作っている人であれば「人月」だとか「人日」だとか言う
単位を聞いたことがあるだろう。これが曲者なのである。
例えば5人日と見積もったプログラムがあったとしよう。
これは人ひとりが5日間で完成できると見積もったわけであるが、
実際はAさんが作業をしたら2日で終わってしまい、Bさんが作業を
したら10日かかってしまったということが起きるのである。
上記のような状態がおきるのであれば正確な工数の見積もりなんてできない。
そのためか見積りは『勘・経験・度胸』などと言われてきた。
しかし『勘・経験・度胸』で導いた見積りで顧客が納得できるだろうか？
おそらく納得のいく説明はできないと考えられる。
そのために定量的な見積りを行うべきであるし、定量的な見積もりを
続けていくことで後の見積りに活きてくる過去のデータが残るのである。
ただし定量的に工数を見積るには上に書いたような人に依存する開発を
無くす必要がある。そのために準備すべきことは多い。
例えば誰がコードを書いたとしても同じ工数になるようにより手書き
部分を少なくするフレームワークを準備するというのも前提条件の一つに
なるだろう。そのような環境ができて始めて定量的な見積りが可能となる。
現在、私は見積りについて調べている最中である。
結果はまたこの場に書くことができればと思っている。
中でも、「スキマ時間」の使い方が、無視できないほど重要であると思います。
ここでは、作業と作業の間の1時間未満の時間を「スキマ時間」と呼び、その活用方法について書きたいと思います。
仕事をしていて、突然、数分から数十分程度のスキマ時間ができることは時々あります。
例えば、
「本日15時に開始するはずの単体テストが延期になった」
「ドキュメントの作成を行うはずだったが、作成する必要が無くなった」
「昼休みに同僚と食事に行く予定だったが、翌週に変更になった」
など、様々です。
発生してしまうスキマ時間は、1分かもしれません。
あるいは、10分、30分、60分という場合もあります。
このようなスキマ時間を有効に使うために、普段から、
「この作業に何分かかるか」
といったことを、作業単位で把握しておくことをおすすめします。
例えば、スキマ時間が1分ならば、メールチェックができるでしょう。
メールの内容を全て把握するのは難しいとしても、
「メールが来ているかどうか」
「何通来ているか」
といったことは、1分あれば可能だと思います。
10分ならば、その日の作業で使った資料を片付ける時間に充てることもできます。
また、翌日の予定をあらかじめ確認することもできるでしょう。
30分ならば、60分ならば、…。
スキマ時間の長さに応じて、色々と応用を利かせることができます。
細かい作業にかかる時間をあらかじめ把握しておくことで、いざスキマ時間が発生したときに、
「30分空いたから、これと、これ！」
といったように、(優先度を加味して)決めることができます。
そして、スキマ時間活用の応用によって、
「このプログラムの完成まで、あと●時間」
「この機能の仕様の確定は、●日後まで」
といったように、作業を全体的に見たときの時間の見積もりにも応用できると、私は考えます。
前回の部ブログでも説明したと思いますが、少しおさらいします。
ITILファンデーション資格はitSMF および英国政府OGCが
ガイドラインを出している世界共通の認定資格のことです。
また、ITIL（Information Technology Infrastructure Library）とは、
英国政府官公庁の情報システム管理基準として1989年に策定され、
IT運用における実際の知識・ノウハウが集約された基準となるものです。
資格を取得するために、個人で資格の勉強は行っていました。
勉強時間は会社までの行き時間に20分と帰り時間に20分ずつ。
けれどさぼってしまうときは多々ありました。正直頭に入ってきません。
けれど私はつい最近まで、あるプロジェクトで企画マーケティング部の
齋藤さんとITILに基づいた運用設計を行っていました。
最初は自分の知らない言葉がたくさん出てきて戸惑いましたが、
わからないところは質問し、自分の中に落とし込むことによって、
個人で勉強するよりもずっと理解することができました。
ITILについて勉強するのに、とても恵まれた環境にいたと思います。
やはり勉強するための『環境』はとても重要なポイントだと感じました。
勉強するための環境を与えられるだけではなく、
自ら進んで勉強できる環境を作り出したいと思っています。
その為には、自分の気の持ちようも重要になってきます。
例えば「面倒くさいな」と思うような仕事でも、
「これはこういうところで役立つだろう」
というように自分の気持ちをプラスに持っていくことです。
日々精進です。
正しいSQL文を書いていても、膨大なデータ件数を扱う場合は、
インデックスを適用すべきケースが多々あります。
しかし、Oracleのコストベースオプティマイザは、
実行時のDB状況により、インデックスを参照しない実行計画を選択するケースもあります。
場合によっては主キーも無視されることもあります。
この時に有効なのがヒント文です。
例えば強制的にインデックスを参照するように記述することが出来ます。
レスポンスがあがらないSQLは、まず実行計画を参照し、
インデックスとヒント文の適用を検討する必要があると思います。
但しヒントの適用は慎重に行うべきです。
強制的にインデックスを使用するよう実行計画を変えてしまう訳なので、
例えば、データ件数が変わってインデックスを使用しない方が、
むしろレスポンスが良いという状況になったとしても
Oracleオプティマイザはその実行計画を選択してくれません。
必ずインデックスを参照します。
その他、ヒント文適用時の注意点
①コメント内に記述する為、間違った書き方をしてもエラーが出ない。
②テーブルに別名を使用している時は、ヒントには別名で記述しなければ動かない。
③INDEXヒントを使用すると、主キーが使われなくなることがあります。
これに限らず、ヒントを使用する際は、大量データにて
実際に実行計画を見ながら１つずつ地道に確認し、
検討していく必要があります。
例えば、「この部分をこのように変えてほしい。」などの
解決策を提示される場合があります。
その内容を何も考えずに、変更を行うのではなく
なぜその変更が必要なのか、
なぜその変更方法なのか、など
必要性とその先を考えて行動することがSEにとって重要なことだと思います。