経緯
Twitterで以下のような流れの会話がありました。
@tbpgr Excel方眼紙やスクショとはどういった仕事のことなんですか？てぃーびーさんのRTしたツイートの流れがよくわからないので教えてほしいです！
— 学生 (@yuutarou22) 2016, 1月 13確かに 学生さんたちに届けこの想い。 といっておきながら呟いている内容は体験した人にしか分からないので
これでは届くはずがないですね。
※ここでいう学生さんはツイッターの相手の 学生さん(@yuutarou22さん) ではなくて、一般の システム開発業界を志す学生さんたち です。
@yuutarou22 巻き込みリプを避けるためにあらためて個別にツイート。説明、長くなりそうなのでブログエントリで説明しますね。今日の夜書きますー。
— てぃーびー (@tbpgr) 2016, 1月 13ということで システム開発におけるExcel方眼紙とスクショに関するまとめ をすることにしました。
前提
- あくまで私の経験、友人からの伝聞、ネットの情報を元にした内容であり業界全体を表した内容ではありません
- 受託開発について書くことになりますが、受託開発の現場も様々であり優秀な方も多くいらっしゃることは知っています。あくまで大変な現場の事例です
- 受託開発全体をディスる意図はありません。受託開発の中でも非効率な開発をやっている現場と技術志向の学生のミスマッチを防ぐ目的でまとめています
以降で登場する「受託開発」という言葉は上記の前提を含んだ「大変な現場の受託開発」です。
Excel方眼紙とスクショについて
Excel方眼紙による設計書
主にウォーターフォール型の開発手法を採用している受託開発の現場では、多くの会社で仕様書・設計書に
MS Officeを利用します。納品先であるお客様がMS Officeに慣れていて、その形式を希望することが多い、などの理由があります。
WordかExcelを利用することになる現場が多いのですが、その中でもExcel方眼紙を利用する場合があります。
Excel方眼紙とは、Excelの行列幅を小さな正方形にしてExcelのシートを方眼紙に見立てる使い方です。
Excel方眼紙は、細かくレイアウトを調整しやすいため見栄えのよいドキュメントを作成しやすいという利点があります。
しかし、変更時に行や列を挿入するとレイアウトが狂うために見栄えと変更内容の文章を追加することを
両立する際にレイアウトを再調整するなど非常に手間がかかる場合が多々あります。
どのように更新時に手間がかかるかについてはこちらのスライドの1-22ページが分かりやすいです。
このようにExcel方眼紙の変更は手動で行う上に手間がかかるため、
変更の少ないドキュメントならそのメリットを活かせるが、
変更が多いドキュメントの場合は変更コストのデメリットが非常に大きくなります。
（そもそも表計算ソフトをそれ以外の目的に使うのがおかしいという意見もあるでしょうし、
私も同意ですがその点はここではスルーします）
そして、システム開発は難しいものであり大抵のプロジェクトにおいてプログラミングしてみないと分からないことや、
画面を確認してみて初めて明らかになった不足などがでてきます。
時代の流れとしてビジネスの速度も早くなっています。つまり、システムを開発している最中に仕様を変えなければ
ビジネスの要件に合致しなくなることも多く、開発途中に変更が入ることも多々あります。
つまり、システム開発における仕様書などのドキュメント類は本来変更が多く入ることを前提に作られなければならないということであり、
Excel方眼紙とは非常に相性が悪いのです。
本来システム開発を行うプログラマは業務を自動化・効率化することで価値を生み出す、という面が強い職業です。
そのプログラマに手動で非効率な単純作業を長時間強いることになってしまうわけです。
例えば仕様の不備を発見し、ソースコードを1分で修正し終わったが
Excel方眼紙の仕様書のメンテナンスに30分-1時間かかる、ということが起こる現場が少なからずあるのです。
本来仕様の変更に関わる文章の変更だけのコストで済むべきところが、レイアウトの調整に多くの時間を取られてしまうのです。
また、こういった受託開発の現場では開発の作業が分業制になっていることが多く、
設計者(SE)と製造者(PG:プログラマ)に分かれて作業をする場合があります。
※製造者という呼び方は好きではないですが、現場に合わせてあえて使っています
一般的に受託開発の現場ではプログラマよりもSEの方が高単価であることや、
できる人ほど上流の仕事を任されやすく、本人の希望とは裏腹にSEの立場になってしまう場合があります。
設計業務が主になりほとんどプログラミングをしなくなるわけです。
すると、お客様からの要求や上流の設計書をもとに次の成果物となるExcel方眼紙の設計書を作成する。
製造はプログラマに依頼する。設計が終わったらテスト仕様書をExcel方眼紙で作成する。
それらの修正が発生する度に多くの時間をかけてドキュメントを更新する。長時間労働をしながら。
技術志向で設計・実装が一体となったプログラミングでビジネスの価値をどんどん生み出すために
プログラマになったはずが気づけば始発から終電までExcel方眼紙を手動で編集し続けるということになります。
もちろん、途中で方向性の違いに気づいて技術志向の強い会社に転職する場合も多いと思います。
ただ、不幸なのはこういった不遇な現場にいて長時間・単純労働を続けていると
元々優秀な人でも正常な判断ができなくなるほど疲弊してしまったり、
そもそも転職するための自己学習の時間や体力が残らないことがあることです。
画面キャプチャをExcelに貼る慣習
受託開発ではお客様の希望した要件を満たすシステムを納品します。
その際に、きちんとテストをしていることを証明するためにテストのエビデンス（証跡）を提出する場合があります。
そして現場によってはExcelに貼り付けた画面操作のキャプチャ（スクリーンショット=スクショ）をもってエビデンスとする場合があります。
例えばWebシステムであれば、手動でWebの画面を操作してその画面操作ごとにキャプチャをとりExcelに貼り付けていきます。
この作業は、画面を動かすことでシステムの要件や動作を覚えることができることから新人に割り振られる事が多いです。
そして、希望に燃えて入社してきた技術志向の技術力のある新人プログラマがここにアサインされると・・・
- 自動化を提案 => 自動化は信頼できないので却下
- 他の新人（非技術志向）は黙々とペタペタしている => 自分だけ不まじめなのだろうか？
- こういう現場は不具合発生率が高い事が多い => バグが発生する度に画面キャプチャをとりなおすことになる
あっという間にストレスゲージがMAXになるわけです。
メモ
より細かい話はググるといろんな闇がでてくるので、気になる方はどうぞ。
光ある受託開発の事例
お題の都合上、受託開発の悪い例を紹介することになりましたが光も当てて見たいと思います。
モダンな受託開発
まっとうなエンジニアリングを追求している受託開発の現場もあります。
事例
納品のない受託開発
2015年「ITエンジニア本大賞」を受賞した「「納品」をなくせばうまくいく」でも有名な納品のない受託開発が
新たな開発形態として注目を集めています。
納品のない受託開発を提唱し、実践しているソニックガーデンさんのホームページに詳しい内容がまとめられています。
事例
内製化
受託開発という括りではないのですが、
悪い例であげたような受託開発のデメリットを回避したり、
業務を理解した社内の人間が主導することで素早くビジネスの価値を生むために
今まで外部発注していたシステムを内製化するケースがあります。
この際、内製化されたシステムを開発する開発者になった場合、
まっとうな開発をしやすくなるケースがあります。
