ビジネスモデルは変化してもシステム開発は変化しない？
ＳＥとしてシステム開発していると、ときどきビジネスのスピードとのギャップを感じることがある。
十数年前、きっとシステム開発というのは、非常に特殊なものだったのだろう、と思う。
要件定義をして、開発して、テストして。。。
そのスピードは、ようは伝言ゲームになっているわけだ。。
でも、ビジネスモデルが急激に変化しているいま、それでいいのかな？とふと思う。
要件に即した画面と要件に即した帳票・・・
一方でExcelでちゃちゃっと作った資料・・・
この差は何なんだろ？
画面と帳票はずっと変わらないもので資料はよくかわるもの？
そんな区分けでいいのだろうか？と思う
いろいろ考えた。
WebシステムのインターフェースをExcelにする。
ひとつひとつ画面を作らなくても、Excelで入力を作って、DBに書き込めればいいわけ。
よくよく考えたらできそう。。
ちょっと気になるからしらべてみよう
あたりまえのことをあたりまえにやってみたら不安になった
仕事をしていて、ふと気づくと不安なことがある。
リリースが近い時期、決算期が近い時期。。。
不安なんて感じなければいいのにな、と思ったりするけど、不安は自信の裏返しなんだろう
今回もそう。
６月くらいからのべ600時間くらい使ったプロジェクトが佳境を迎えている。
これまでいくつもプロジェクトに参加したし、自分で半分しきったりもした。
でも、期間に対して600時間は異常。。というか、過去これまで600時間はない
ある意味、これまでやってきたことの集大成のプロジェクトになった
知識的にも技術的にも、いろんな意味で集大成。これでもかっていうくらい詰め込んでみました。
社会人になって５年間、上司や先輩・そしてお客さんに教えてもらったものをどーんとぶつけてみた。
そりゃ、不安になるさ
しかも、あたりまえのことをあたりまえにやってみた、ただただそれだけのプロジェクトです。奇抜なこと、斬新的なことなんて、本当にない。
でもね、自分でも思うんだけど、これでまた成長できるのかもしれない。
と、数年後に振り返ってみて思えるといいな
遠回りに思えても、実はショートカットになっていることがある
ブログにするかどうか悩んだけど、やっぱりブログにします。
ずっと悩んでた、３年くらい前の自分のために書きます。。
ＳＥという仕事柄、いろいろな知識が求められます。
プログラミングスキルはもちろん必要で、受託開発だとさらに業務知識も必要です。
どうやったらスキルアップできるか？知識を増やせるか？そんなことを考えてました。
今になったら思うんです。
知識はアタリマエのことをアタリマエにやってたら、増えます。
プログラミングスキルでいうと、本を読むとか、そもそもプログラムソースを読むとか
業務知識でいえば、お客さんとお話しするとか、疑問に思った単語を調べるとか。。
学生時代に比べれば、たしかに体系的には学んでいないのかもしれない。
知識のパッチワークといわれても仕方ないかもしれない
まとまった時間をとれずに勉強した気にならないかもしれない。
でもね、一定以上覚えると一気にブレークするんです
ブレークするまでは大変なんだけど、ブレークしたら一気にいける
だから、コツコツ調べて、コツコツ本読んで、ということがタイセツ
もっとタイセツなのは、先輩たちが話している言葉とか単語を頭のすみにとっておく。
どっか、自分が困ったとき、いろんな言葉がつながって、それが自分の答えになることがあります。
最近ちょいそんなことがあったので、ちょっと書いてみました。
27才で気づいたこと、28才で気にしたいこと
今日、28才になりました。
この１年間、いろいろな気づきがありました。自分がやりたいコトが見つかったり、視点がかわったり。。
今日は、27才で気づいて28才で気にしていたいこと２つを紹介します。
ファシリテーション
10年前、日本にアジャイルを普及しようとして滝に打たれ、アジャイルという言葉を使わず、ウォーターフォールの中でもできる、その心だけ伝えようとしたのがプロジェクトファシリテーション(PF)です。新コンテンツが増えました！ http://t.co/AUcm7GLBXh
— Kenji Hiranabe (@hiranabe) 2013, 12月 26この一言が自分がやりたいことだった。
アジャイルというのは、ITシステムの開発手法のことで、ユーザーと常に対話しながらPDCAサイクルを高速で回すという方法のこと。
従来のITシステムの開発手法（ウォーターウォール）とはちょっと違う。
PDCAサイクルを回すというのがミソで、フィードバックが返ってくる。振り返りをする。
それも超高速で。
目標とはしてるけど、まったくできていない。まずは週次レビューで仕事の棚卸をしっかりやっていきたい。
Do the Right Things Right
「正しい方法で正しいことをやる」
アタリマエじゃんって言われそう。
でも、週次レビューとかも含めて、仕事も含めて、本当にできているのか？と言われると、正直怪しい
というよりも、８割はできていない自信があるww
すべてを完璧にやることはムリだと思うし、現実的じゃない。
でもね、それを目指したいと、こないだ強く思った
ということで、今年もヨロシクっ
不安なこと、そして不安なこと
いろいろ混乱しているけど、いまの気持ちを書いとく
どうも、ほぼ転勤する感じっぽい。
同じ会社、職種なので仕事内容は大きくかわらないけど、でもいろいろ変わっていく。
これまで作ってきたお客さんとのつながりも、なくなる
ちょうど去年の今ごろからコツコツ作ってきたことを誰かに引き継いで、
自分はもう一度そのコツコツをやらないといけない。
人間関係だけじゃない。仕事も含めていろいろ
正直、不安はある。というか、不安しかない。。
転勤して新しいお客さんとやっていけるんだろ？
会社の同僚とやっていけるだろう？（といっても先輩たちは知ってる
３年ぶりに転勤を目の当たりにして、以前とは違う不安感がある
そりゃそうだ
希望がない、わけでもない
もうちょっと心の整理はしよう。。。
そして、やることはやるしかない
３年前の自分へ：正解なんてないんだよ、
転勤前の部署の人と一緒に仕事しているんだけど、ちょっと忙しさがヤバそう。
いつも「戻っておいでよ」って言ってくれるけど、そろそろなのかな。。。と思って、転勤のまえのメモを見てみた。
あのときもいろいろ悩んでいた。でも、今とはちょっと違うかな。
当時は、先輩たちの背中が遠いものに感じていた。
ミスにびびっていたし、正直今思って、周りがみえていなかった。
大きなプロジェクト、しっかりとした仕様書、後戻りしない開発
そんなことを考えて、そしてそれが学べると思って転勤した。
転勤して３年、今考えると、なんだかおかしい。
結局、当時の自分はどこかに「正解」というのがあって、その正解を知りたいと思っていたんだ
でもね、「正解」なんてないんだよ
いろいろ工夫して、反省して、失敗して、それで自分にあったやり方を見つけていくんだ。
あのとき、失敗しっぱなしで、先輩に助けてもらって、どっかに「正解」があると勘違いしていたようだ
今の仕事に未練がないわけではないけど、
あのとき送り出してくれた先輩の気持ちを大切にはしたい。。
でも、そういうときって上司にどういればいいんだ？？
