アイロベックスメールマガジン　携帯版

プロジェクトとしてのチーム運営を考える場合、当然、リーダーの資質・覚悟が最も重要であると言えます。
なぜなら、リーダーが目的を見失ってしまったり、本来の責任から逃げてしまったりした場合、チームとしての機能は、うまく働かなくなってしまうからです。

一方、システム開発という仕事の中で、プログラマが次のキャリアアップを目論む場合には、サブSEとして設計に徐々に携わり、SEになっていく、といったことが通常となっていました。

しかし、プログラマとSEの職務の特性には違いがあり、ここに問題が潜んでいると思われます。

なぜならば、プログラマとして優秀な人というのは、どんな要求にも応えられる技術者を意味しているからです。
優秀なプログラマは、難易度が高いプログラムを、人よりもバグが少ない状態で、より速く生産するといったことが可能です。

そのため、孤独な戦いを強いられることが多く、人に説明したり、現状報告をすることよりも、とにかく作ればよい、結果を出せばよいといったことに目的をすり替えてしまう人も多く見られます。

しかし、大規模システムを、破綻無く成功させるためには、どうするか？
という視点で見てみると、こういった優秀なプログラマが居なくとも、また、そういった人の手を借りずとも構築できる仕組みが、圧倒的に望ましいのです。

仕組みに求められるものは、個人としての優秀さよりもむしろ、チームへの貢献度であり、それは、プロジェクト全体としての品質や生産性が安定することなのです。

そこで、プログラマとして技術が高い人は、共通のフレームワークを作ったり、プロジェクト全体のルールが守られているか、といった守り役を仰せ付かることになります。

実はこの役目こそ、先のSEやプロジェクトマネージャーとしての役割に直に結び付いているものとなります。

個人としての優秀な技能を、いかにチーム全体の品質、生産性の底上げのために使うのか、それこそが最も優秀なプログラマの役割となるわけです。

当然、予定外に自らの作業分担をはみ出した作業が発生します。
しかし、どんな場合もプロジェクトマネージャーに相談し、全体の効率、求める結果の優先順位を考えて作業に携わるべきであり、そのためには、個人としての当初の「達成度」や「満足感」を捨てなければならないことも多々あるわけです。

プログラマとして、新しい技術、より難易度の高い技術に挑戦することは、常識であり、当然のことです。
一方、チームとしての成果を求められるプロジェクトに係わっていく以上、その個人のキャリアステップは、どうやってチームに貢献していくか、どうやって全体としての成果を出すのかを考え、実践していくところにあるわけです。

プログラマ、SEといった職業名も、もっと細かく区分けされる時代ですが、実際のところ、役割名があるが故に、その役割名に準じた仕事をするのが自分の仕事だと思ってしまうことが、一番の問題であると私は思っています。

なぜならプロジェクトという視点で考えた場合に、個人が能力を発揮すればそれでよいというやり方では、やはり、成果を出すことは叶いません。
個人個人の積み重ねを、チームとしての成果に繋げるためには、常にチーム全体や「のりしろ」を気遣いながら作業を進めることが、SEだけでなくプログラマにも必要なのです。

SEに成り立ての頃でした。

お客さまとの打ち合わせにおいて、システムにおけるデータの流れを全部把握して、お客さまからの質問や要望に即時で回答できる先輩を見て、感動したことを覚えています。

その頃の自分といえば、一つの帳票の出力順や項目の意味を考えることがやっとの段階でした。

常に自分の未熟さを痛感し、どうしたら幅広く、かつ奥深く考える力が付くんだろうかと思ったものでした。

一体どうしたら、システム全体を頭の中に入れることができるのか、そしてそれを、どうやって学べばよいのかも分かりませんでした。

何年かのキャリアを経て、やっと分かってきたことは、システムの考え方には「王道が存在する」ということでした。

どのシステムも違うようでありながら、設計する場合の一つの基本線は、みな同じであると気づくわけです。

では一体、「王道」とは何なのでしょうか。

「常にシステム全体を意識すること」

これは、あらゆる側面からシステムを眺めることができるか、語ることができるか、ということなのです。

同じストーリーを、時間帯をずらしたり、別々の登場人物を主人公として見せる映画を、皆さんは観たことがあるでしょうか？

実は、私の大好きな宮藤官九郎さんという脚本家が得意とするやり方です。

主人公は一人だけではなく、ある場面で脇役だった登場人物でも、別の場面では主人公になって、ストーリーを展開するということが多いのです。

それぞれの瞬間においては、そのストーリーは自然であり、主人公である人物から観た主観となって表現されます。

そしてそれは、システムにおいても同じなのです。

入力画面においては、その画面の果たす役割を意識し、一番重要な役割に特化して活躍させるのです。

帳票においては帳票の果たす役割、例えば日に一度、締めてから出力されるのか、いつでも好きなとき（例え、月次締めの最中であろうとも？）に出力できることが必要なのか、といった、個々の役割を深く意識するのです。

しかし、システムというのは、全体の流れ、各機能の係わり方が重要になります。

そのため、データの流れを意識することが必要になります。

全てのデータは、どこかで入力されて（生まれて）、どこかで更新され（教育され）どこかで何かを出力し（働き）、そしてやがて消去される（死んでいく）。

という、人の一生やドラマと同じなのです。

システムは、人が複数集まって関係性を持ち、成果を出す会社と同じく、機能が複数集まって関係するものなのです。

どんな人にも役割があるように、どんな画面にも帳票にも、そして項目1つにも役割があるのです。

彼らを舞台に登場させて、そのキャラクターを生かし活躍させ、退場させることが、SEの仕事なのだと思ってきたのです。

そう思って、仕事を楽しんできたのです。

システムにはさまざまなトラブルがつきものです。

トラブルが、作りこんだアプリケーションのバグである場合、問題は大きいが、トラブル自体はシンプルなのです。

このようなことを書くと、「ひんしゅく」を買ってしまいそうですね。

なぜシンプルなのかというと、この場合は、障害であるプログラム、もしくは、設計内容を改めることでトラブルが解決する、というように、解決方法が明確であるからなのです。

また、開発側は、申し訳ないという加害者意識や、責任を明確に持つはずですので、はっきりしていて、シンプルなトラブルだと表現しました。

トラブルの原因を発見する能力もSEには重要です。

例えば、

・テストサーバーでは、正しく動作するのに、本番機では、正しく動作しない。
・数ヶ月間、順調だったにも関わらず、突然、正しく動作しなくなった。

というようなトラブルであれば、環境、データ、操作の「何が違うのか」といったことを調べる必要があります。

このとき、思い込みは禁物です。

「何も触っていない、何もしていない。だからプログラムのバグではなく、顧客の運用に問題があるんだろう」

このような安易な考え方こそが、解決への障害となることが多くあります。
だからこそ、若いうちに上記のような失敗の経験をしておくべきなのです。

本当に、バグが原因でないかどうかは、どんな時でも、具体的に証明することが求められます。
バグが原因でないと証明できる前に「自分の問題ではない」と決めつけてはいけません。

さて、問題は、原因は分かったものの、誰の責任なのかが分からないときです。

例えば、うまく動かない原因が、複数の環境やデータの組合せであったとか、動くはずの設定で動かないとか・・・まぁ、いろいろ考えられますね。

こういった場合に、SEが一番陥ってはいけない状態は、「当事者意識の欠如」でしょう。

お客様が「当事者意識が高い」のは、当たり前のことです。
自分の注文したものが、正しく動かなければ、納得するわけがありません。

ところが、時にシステムに携わるSEが、「OSやハードのメーカのせいじゃないか？」とか、「どうしたらいいか分からないが、当社の責任ではない」といったところに気持ちが行ってしまうことがあります。

それは、一つには、目先の仕事の忙しさのせいかもしれません。
確かに、自分がやらなくてよいことまで、手を拡げることができるほど、余裕はないものです。

しかし、仕事が目先、忙しくない人がいるのでしょうか？誰しも常にやるべきこと、スケジュールに縛られて仕事をしています。
その中で、アクシデントのように、トラブルが舞い降りてくるわけです。

「もともとの提案がいけない」「営業が安易に請けるからいけない」などという思いが出てきたとしても、そのような気持ちは、即時で判断すべき、行動すべきことの足かせになるばかりなのです。

解決方法に、「受注そのものをキャンセルさせていただく」という究極の方法があります。

しかし、「その仕事をやらなくてもよかった」ということは滅多にないでしょう。
本来は、解決すべきであるはずなのです。

解決できないトラブルが幾つもあることは、この世界に生きる人であれば分かっています。

しかし、システムというのは、常に思いがけないトラブルがつきものなのです。

「何がうまくいっていて（正しく動いていて）、何がうまくいっていないのか（正しく動かないのか）」

細かな検証を、1つずつしていくことが、まず第一です。

次に考えられるのは、顧客と現状の確認をしながら、妥協できるところは、運用やコストで妥協していただく、ということでしょう。

直せないとしても、諦めてはいけないのです。
しかし、直し続ける間、顧客がどう運用すべきかをきちんと確認する必要があります。

大切なのは、結局、どんな対処をするにせよ、どこまでやるか、やらないかは、SEと顧客の意思にかかっていることを忘れないことでしょう。

トラブルに負けないコツは、

・当事者意識を強く持つ
・できること、できないことをなるべく早く切り分ける
・別の方法をありとあらゆる角度から調査する
・小さなテストを実行する
・顧客と、とことん誠意をもって話しあう

他の会社の人も含めて、相談ができる技術者を、多く味方につけることも、重要なポイントといえるでしょう。

読者の方から激励のお便りをいただきました。嬉しいものですね。
その時に、「何かご要望は？」とお聞きしたら、このタイトルがご注文でした。
お題いただきました。・・です。

SEの促成栽培については、このメルマガを書き始めた頃からの、私自身の課題です。
これを語るために、「何が出来たらSEなのか？」ということを、初心に戻って考えようと思いました。

SEの定義は、プログラムを組み合わせて、業務の仕組みを作る人である。

では、「プログラムが得意な人がいいのか」というと、この業界では、何十年も前から、そう思われてきましたが、「そうとも言えない」と私は思っています。

ただ、プログラマに指示をしたり、報告を受けたりすることが作業になりますから、プログラマが「どのようなことを考えているのか」を知り、プログラマの癖を理解していることが、望ましいことになります。

優秀なプログラマは、「もし、例外的なデータが入ってきたらどうなるのか？」「もし、プログラムが起動しているところで電源が落ちたら？」といった、1％の確立でしかありえないようなことでも、「絶対にないこと」でない限り、そのリスクを想定して、プログラムを作るのです。
それが、優秀といわれる所以です。

ですから、彼らの不安を解消してくれるSEが、プログラマにとって、一番頼りになるのです。

例えば、文字型の項目「税フラグ」というものがあるとします。
この「税フラグ」を使用する場合、プログラムには、

1の場合は・・・・。
2の場合は・・・・。

というように、処理を記述します。

仕様書には、この1と2の場合についてのみ、記述されていたとしても、プログラマは、0のとき、NULLのときなど、全てのデータパターンにおいて、正しく動くプログラムを作らなければいけないのです。

NULLである場合が存在するのか、といったことも含めて、そのシステムで発生するデータパターンを、きちんと説明することが非常に重要です。

実際、プログラマにしてみれば、データパターンだけでなく、
・プログラムで用いるレコード件数が、何件を想定しているのか。
・レスポンス（応答時間）はどのくらいまで待つことを許されるのか。
など、説明がなければ、分からないことばかりなのです。

このような一つ一つの背景を、きちんと説明しておかなければ、プログラマに、余分なコーディングをさせることとなり、生産性の悪さにも繋がります。

プログラマが理解していれば、作成をする前から、対処していたものを、説明が足らなかったばかりに、作り終えてから修正しなければいけない、ということさえ、引き起こしてしまうこともあるのです。

ですから、SEは、プログラマからの質問がなくても、また、「仕様書を読んでから質問します」などと言われても、無理やりにでも、

1．誰が、いつ、どこで、そのプログラムを使用するのか。
2．そのプログラムが、システムの中でどのような役目をするのか。
3．データの中身について、どんなパターンが考えられるのか。
逆に、どんなパターンは考えなくてよいのか。
4．データの件数と、求められるレスポンス。

を、丁寧に説明するべきなのです。

そういった意味では、優秀なプログラマは、SEが教えてくれなくても、これらのことを突っ込んで聞くものです。
だから、若手SEは、キャリアのある（優秀な）プログラマと、仕事をするのが良いと思うのです。

●ポイント

SEは、プログラマの不安を解消し、一番最適な技術やアイデアを引き出すために、そのシステムの情報を、正しく伝える責任があります。
プログラムの設計については、プログラマに正確な情報を提供し、お互いの役割を果たせるような、コミュニケーションをとる義務があります。