昨年のシステム開発を振り返るのはなぜか！？

※文章に関しては殴り書きなので、落ち着いたときに直すかもしれない

過去を振り返ってfixすることにより、昨年の失敗や成功を全て精算して
新年はゼロから切り替えられるようにする

本当に抱え込んだまま日々を過ごしてはいけない
ストレスで休暇にならないからだ

今日のことは今日で十分である
明日のことは明日悩め
仕事は定時で上がり、仕事を離れたら仕事のことは一切考えないことだ
休日は仕事のことを忘れて休め

持ち帰り仕事はしないようにしよう！

開発中に意識した事

システムを使う人に寄り添ったシステムを作ろうとした

過去に在籍したシステム屋の自分には出来なかったことだ
大抵の開発案件ではユーザーが使うことまで想定したシステムをリリース出来ていないのではないか？
実際のところはシステムを使う会社の従業員にまで気を回せないのではないだろうか？
これは仕方がない、自分のところの会社の人じゃないし、自分がその会社の人達と普段やりとりすることはないだろう
だから開発する側には分からない
たとえ、開発側に伝えようとしたところで不十分になってしまう
自分でも無意識で気付いていないことは必ずあるからだ
また、受注したら開発がメインになるため意識がそこまで飛ばせないだろうし、開発に頭が行ってしまうだろう

しかし、それでは最終的に使う人の立場には立っていないし、実際に使う人達にとって使えないシステムだとしたら
そのシステムはゴミだ。結果、誰にも使われない、または使いにくいゴミを生産したことになる
誰もHappyになっていないし、プロジェクトに関わった全員の活動が無駄になったこととなる

昔は自分に対してお客さんがいたが、今は使う立場にいるからこそ分かる問題である
正直、今の自分はシステム開発自体にはまったく興味がない
なぜならば、システムは道具であるためシステムに価値は見出していないからだ
一方で実際、システムを使うとどうなるのかにはとても興味がある
なぜならば、ユーザーは道具を使って何かしら行って、目的に対する結果を得たいと思うからだ

つまり、ユーザーは何らかの目的があって行動を行うのであって
システムは選択肢のひとつでしかない、時にはシステムを使う以外の方法で取り組むことが最適解になることもあるだろう
それが分かったからこそ、実際に使う人にとって使えるシステムを用意することが至上だと考え開発に取り組んだ

開発中、リリース後に経験した事、起きた事、そこから得られた事

完全性は疲れる

開発に完全性を求めたら、作り手は疲れるだけなので完全性は忘れよう
完全なリリースのことは忘れるんだ

逆に大事な点をヒアリングして外さないようにすれば案外進むものだ
つまり、修正が効く範囲かどうかを意識したらよい

本番リリースした後、問題が発生してもすぐに修正できる作りにしよう！

実例として、気付かなかった挙動をユーザーから指摘されて
たまたま、即座に本番で修正できたことがあった。メチャクチャ助かった！

そこから学べることは、相手のことを100%理解出来ているとは限らないし、気付かない点は多々ある
だったら、すぐに修正出来るようにしておけば要求に対して即時応えられる

見積は難しい（その１）

だいたい、スムーズに進むパターンしか考えていないから
見積の２倍ほど時間が毎回掛かっていた

これに対してはPERTなどで代表される「最悪のパターン」「最速のパターン」「標準値」
の考え方を取り入れてみようと思う。今よりは少しでもマシな時間を出せるか実験してみたい。

見積は難しい（その２）

開発を進めると、想定していない要素が現れてくる

公的に宣言した期限から遅れると信用はなくすようだが、
内部的な期限であるならば進めていて「遅れる原因」が発生するからか
進めていても変更（リスケ）できるらしい

ここの感覚がまだよく理解できないけど、それでも事前に分かることであるため、すぐアクションできるし、
ギリギリでも分かった時点で言えるので、とてもありがたいことだと思った
自分は内部的にでも締め切りはあると思うから理解は難しい
もちろん、今のままではどうにもならないからということだろう

レビューは100%でなくてよい

内部的なレビューに完全じゃなくてよいと言ってもらえたことがありがたかった
気は楽になるしポジティブになれる魔法の言葉
事象に対して目を向けられるので重要な取り組み、許容して自分も行えるようにしよう

分からないことはサポートに聞こう！

パッと考えても分からないことで悩んでいてはいけない
関わる人間が少なければ少ないことほど、とりあえず他の人に悩みを打ち明けよう！
正直なところ、１人は開発して１人は何もせず考える側、話し相手になってくれた方が開発は上手くいくのではないかと思う
開発側の脳に余裕はないからだ

システムは全体から俯瞰することもしよう

実際に、指摘されて画面や機能を一部だけ見ていると気付かないことがあった
全ての画面を印刷してみた後に、俯瞰してみてみたら統一されていないことが分かった

統一されていないことに気付ければ、修正して統一感を持たすことが出来る
内容が統一されていれば同じように修正できるし、問題が発生しても個別に考えずに全体的に考えられるようになる

共通するコントロールのサイズは同じか
共通するロジックは同じように作られているか
コントロールのキャプションなど同じ言葉が使われているか
同じように可用性はあるか

言った言わないは不毛である

実例として、仕様通りに作ったが、後から相手と話が違うことが後から発覚した
しかし、言った言わないを議論してもまったく不毛である
使う側からすれば、受容されていない異なる仕様のシステムでは使えないからだ
使えないシステムなんて意味がないので、そこからどう直すかを考えよう

実際に、リリース後に作り直しが発生したときはかなりモチベーションが下がった
感情的には相手を攻撃したくなった
しかし、その人やその人の責任を攻撃しても意味はない
相手は保守的になり自分は悪くないと言い張れば事象的には何も進まないので無駄になる
もしくが相手が委縮して行動も起こせなくなることを立場的に知っているので意味がない
そもそも、同じように自分もミスしてフォローされることを思えば責めるのは不毛である
人は完全ではない

そんなことを考えても使う人は待っているのだし、
全ては事象面を見ておけばいいのだと思う、そっちに集中しよう
結果が起きてしまってからは、自分の行動面だけをみて反省すればいい。行動を直せばいい。

行動面だけ指摘しても今回は意味がない（それをしても仕方がない）

説明会は何人かで組んで実施しよう

説明する人、パソコンを操作する人、質問を書き溜める人、
三人くらいはいると楽である。会の最後に質問は振り返るといいことを学んだ

良かった点（興味深かったこと）

ポジティブに仕事が出来た

画面等のデザインも含めて草案を作ることが出来たのは面白かった
使う立場になって考えることが出来たことも興味深い
もちろん、レビューで変更が加わるがより他の人の観点が加わるので
精度が増すと考えられればプラスに捉えられる
視野が広がるのだ

可用性を意識した作りについて学ぶことが出来た

たまたま、相手に設計思想を聞くことが出来た、そのときに可用性について学んだ
今の仕様（一時）だけではなく将来変わるかもしれない可能性を見越して作成すると気が楽になったし、
広い視野を持つことが出来たと思う

業務ベースで設計できる（システムに落とし込める）こともあると学んだ

100%とはないが、代替案も含めて駆使すれば、
かなり業務ベースで落とし込めることを学んだ
人が想像できることは出来ることが多い
しかし、それは想像なので実際に出来ないことも分かってきた
ユーザーベースにシステムをある程度は組めることを学べたのは収穫だった

逆にいえば、パッケージ等を採用するときは細部まで見えはしないのだろうが
出来るだけ要求通りに出来るかは下調べと実験が大切なのだと思う
精度を上げられる大事な場面であるように感じた

反省点（仕事始めからの課題）

ユーザーのことを理解できていない（その１）

実例として、こちらが仕様の把握を間違えていた
そこから学べることは、だいたい相手のことは何ひとつ理解できていない、人は都合よく考える生き物である
今回の対応策としては、会社のことを自分の中で曖昧にしないことだ
全ての運用を洗い出すことだ
疑問に持つことで解決できないかを取り組む

従前という考え方もあるので「生産性」を採ることも考えた方がいいし
今までどうしていたかだけで、理由までは問わなくてもいいという考え方もありだと思う

しかし、純粋に疑問に思わない、改善を考えないのもいかがだと思う
だが、それが組織全体にとって仕事する上で優先する内容かは分別した方がいいかと思う

単純に俺が理解したい理由は、自分の責を取りたくない、怒られたくないのが理由だし。
そっちの気持ちが強いなら、あまり拘る内容ではないのだ
純粋な改善や疑問だったら、有益だと信じたいので行動を起こしたらいい
思考停止したら改善なんて見込めないし自主性は失われる

別な面でも見て再考しよう

目的は何か
理由はなぜか
いつまでにするのか
どの程度のクオリティに落とし込むつもりか
自分のモチベーションはどうなのか

ユーザーのことを理解できていない（その２）

開発するときには気付けなかった点を挙げる

人によってブラウザの表示サイズが異なるため画面の見え方は異なる
同じような意味のボタンが２つあったら、どっちを使うかは分からない
前のシステムにはあった機能どこにあったか
人によってはファイルを開くソフトウェアが異なるので印刷結果が異なる
印刷結果はバインディング出来る余白はあるか
PDFに変換したときに見た目は欠けたりしていないか
入力枠がせまい、もっと入力したい
この言葉の意味は何か
ここの運用ルールは何か（運用ルールなので少し話は別）

ユーザーによってはパソコンを使うことに慣れていない人もいる前提を忘れてはいけない
またはユーザーは役職の違いや部署の違いによって、分かる言葉と分からない言葉が発生する
したがって、誰でも分かるレベルのシステムに落とし込めているかが重要である

例えば、初見で右も左も分からない状況の人がいることを想定して使い方を明示したり、
システムを使った後に運用は何をしているかを知ることが肝要であると思う

例えば、実際に自分が作ったシステムを実用してみるとよいのではないだろうか
少しはユーザーの気持ちになれるのではないだろうか
案外使いづらいシステムになっていることが分かるかもしれない
ゴールにするのは実際に使う人が使える状況であることだ

システムと業務上の運用ルールは切り分ける

業務上の運用ルールとシステム機能は区別した方が問題は切り分けられるが、
誰かが応えられるように準備をしたほうがよい

システムの特性と運用ルールが合わないことがある
つまり、痒いところに手が届かないことがある
これはどちらも悪くない
そのためにはシステム（パッケージの思想）と業務ルールを別々に考えたほうがいいのだ
だから、落としどころをつける必要がある
また、想定していなかった業務ルールが開発したいたロジックと現時点で合わないこともある
よくある「仕様」ですという言葉で片付ければ開発者は楽ではあるがそれはあまりに冷たい
一方で、今の内容では出来ないという言葉（事象）は業務ルールをないがしろにしているわけではないのだ
そのあと、検討できるか考えたらよいのだ。事象を見よう

ユーザーのことを理解できていない（その３）

前に出来ていたことは当然出来ていると思うし、システムを比較してしまうのは仕方がない
というか自分も使う立場なら間違いなく比較する
システムも特性があるので慣れることや代替案を提示して回避していこう

ユーザーのことを理解できていない（その４）

他のシステムとの連携について考えていなかった

実際に、別案件で同一システムを使っていたが
お互いがお互いの設定を邪魔する可能性があることを加味せず開発していた
お互いのことを考えて作ることの重要性、相手はシステムだが相手を思いやることを学んだ

また、全てのシステムから俯瞰してみることの重要性を学んだ
システムの数は適正か、使いづらくはないかを考えることが大切である
例えば、ログインIDとパスワードを覚えるのが大変なのではないかという最もな意見が
自分の頭にないことはユーザーを意識できていない証拠である

代替案としては下記内容が候補として挙がった

IDとパスワード入力は不要でサービスINはできないか
シングルサインオンは実装できないか

相手に見積を伝えるには

まずは問題が発生しない前提での仮スケジュールを伝えよう
今、想定できる内容に限った仮の時間であることを付け加えることだ

絶対、終わるとは言い切れないから人は黙るのである
だったら、上記内容が落としどころだろう

設計はしとこう（二度手間を防ぐ）

まずは自分がするなら（当事者意識）これがいいだろうということをシステムに落とし込む
自分なりのロジックを持っておこう

自分の技術で出来ないことは出来ないとハッキリ伝えよう

出来ないこと自体は事象的に見てそれはそれでいいのだ
それは自分のレベルの話だし嘘をついても仕方ないし伝えよう
だから、その上でどうするのかを考えた方がいい
いくつか代替案の提示できないだろうか？
出来なくても、目的に重要性を見出していれば満たせなくていいとは思ってはいないハズだ

例えば、目的を見出せないなら開発以前に目的の理由を聞いておけばいいし、
こうなっては仕方ないので重要性を再度問うことも必要だと思う
（出戻りになるかもしれないけど・・・)

代替案としては下記の話題があるのではないだろうか

単純に自分が実装できるか分かっていないのでサポートに聞いてみる
とりあえずロジック的に実装できるか分からないので誰かに話を聞いてもらう
自分が実装できる他の方法でなら、同じような機能を持たせられる（自分が出来るレベルに下げる）
全員重要でなければ捨てる

非エンジニアにも伝わるように話そう

エンジニア用語はNG、相手に分かる言葉、相手の立場で話そう
逆に考えるんだ、他の部署の専門用語で話されても何言っているか分からないだろ？
ロジカルな話題であれば専門用語を使わなくても仕事の行動面やシステムの動きは話せると思うんだ
はじめて会話する人に、前提条件を全てなくして話すようにしよう
要するに端折って話さないようにしよう

余談（自己研鑽）

システム屋さんの前に、一人の会社員として共通すること（ベース）を学ぶとよいと思っている
案外、専門分野に落とし込む前に解決できる内容もある

今、仕事的には「マネジメント」本を読んでいる

しかし、それが仕事のためだったら本来は仕事中にする方法を考えるべきだ
休日は仕事を忘れて休憩する日だからである

仮に暇になりポジティブに活動できると思えるとき、
自分が将来、興味を持てるビジネスのために有益だと思えるならば
ご自由にってところだ。そのときは自然に強制力なく学んでいるだろう
興味って大切である

仕事に興味なければ強制的にやらされている感がモロでるし、
疲れていれば状況的にやりたくない
自主的にはもちろんやらない

楽しくポジティブに自然に実験的にしていることが興味を持っているという状況なのだと思う